This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x TILCDC and Double Buffering Configuration

Other Parts Discussed in Thread: DA8XX

We are currently working on getting our application up and running using double buffering. We are using the tilcdc driver, in the source code it mentions that the DRM only allocates enough memory to account for the active screen resolution. I need to double the vyres, but cannot find any documentation on how to do that.

Our application attempts to adjust the vres for the current resolution and we get the following error:

fb userspace requested width/height/bpp is greater than current 1024x768-32 (virtual 1024x1536) > 1024x768-32

I am using a default panel setting from a device tree example. It appears as follows:

/ {
	panel {
		status = "okay";
		compatible = "ti,tilcdc,panel";
		pinctrl-names = "default";
		pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
		panel-info {
			ac-bias           = <255>;
			ac-bias-intrpt    = <0>;
			dma-burst-sz      = <16>;
			bpp               = <32>;
			fdd               = <0x80>;
			sync-edge         = <0>;
			sync-ctrl         = <0>;
			raster-order      = <1>;
			fifo-th           = <0>;
		};
		
		display-timings {
			native-mode = <&timing0>;
			timing0: 1024x768 {
				clock-frequency = <65000000>;
				hactive = <1024>;
				vactive = <768>;
				hfront-porch = <110>;
				hback-porch = <90>;
				hsync-len = <30>;
				vback-porch = <22>;
				vfront-porch = <12>;
				vsync-len = <4>;
				hsync-active = <1>;
				vsync-active = <1>;
				de-active = <1>;
				pixelclk-active = <0>;
			};
		};
	};
};

We have omitted the tilcdc slave because we are not connecting to a traditional monitor. How do I go about allocating the proper buffer by default?

  • Biser,

    Is that value going to have an impact since we are no longer using the DA8XX driver. We are making use of the tilcdc driver which is drm based. We are making using of the frame buffer emulation provided by that.

    I will give your suggestion a shot.

    Regards,

    Matt Minga

  • I'm not sure. You can find some links to DRM documentation here:

    http://processors.wiki.ti.com/index.php/Linux_Core_LCD_Controller_User_Guide?keyMatch=linux core lcd&tisearch=Search-EN#AM335x_LCDC_Display_Driver_.28DRM.29

  • Biser,

    Thank you for the link. I have been using that link quite extensively to get to this point.It appears that the amount memory being allocated is tied directly to the panel size defined in the device tree. I have not confirmed this suspicion quite yet. The exact point we are failing from our application making the following call:

    if (variable_info.yres_virtual < variable_info.yres*2)
    {
    unsigned int Yold = variable_info.yres_virtual;
    variable_info.yres_virtual = variable_info.yres * 2;
    if ( ioctl( fdfb, FBIOPUT_VSCREENINFO, &variable_info ) )
    {
    MainLogger->AddFormat("LinuxFB System not configured for double-buffering: %u/%u\n",
    variable_info.yres, Yold);
    return false;
    }
    }

    this results in the error message that I posted above. The error message posted above comes from the DRM driver. That is in the drm_fb_helper.c:

    lxr.free-electrons.com/.../drm_fb_helper.c

    I looking for any help on how I can default the memory allocation to allow for larger buffers.

    Regards,
    Matt Minga
  • I have asked the SW team for support on this.
  • Biser,

    I have confirmed that the memory allocated is tied to the panel size. I used the following panel settings in my device tree:

    640x480P60 {
    clock‐frequency = <25200000>;
    hactive = <640>;
    vactive = <480>;
    hfront‐porch = <16>;
    hback‐porch = <48>;
    hsync‐len = <96>;
    vback‐porch = <31>;
    vfront‐porch = <11>;
    vsync‐len = <2>;
    hsync‐active = <0>;
    vsync‐active = <0>;
    };

    A vyres of only 480 is allocated now. When attempting to change to anything higher, I get the same error as before.

  • The exact call that is erroring out is

    unsigned int Yold = variable_info.yres_virtual;
    variable_info.yres_virtual = variable_info.yres * 2;
    
    if (ioctl(fdfb, FBIOPUT_VSCREENINFO, &variable_info))

    We echoed 0xf into /sys/module/drm/parameters/debug to turn on the elevated debugging printouts for the drm driver. We were able to see the following error message:

    fb userspace requested width/height/bpp is greater than current 1024x768-32 (virtual 1024x1536) > 1024x768-32

    I have seen references indicating that drm defaults to only allocating enough memory for the attached resolution. I am struggling to find out where that is occurring and how I might increase the amount of memory allocated.

    I have been looking at the source for the driver and have yet to conclude can be done to change the buffer size upon driver load. I would like to avoid hard coding the value at all costs.

    I know that underneath the framebuffer emulation provided directly by the tilcdc there are are calls to create a contiguous memory allocation using the information for the crtcs, but it appears to only be using something called fb->height and width.

  • Hi Matt,

    Please provide me more information on kernel version being used and where did you get this kernel from (AMSDK??) ?

    Regards,

    Manisha

  • We are currently using mainline kernel 3.19.2. With the drivers being in the mainline it was assumed this might be functional especially since we were not attempting to make use of the ti graphics sdk at the time. I was also thinking that even though we are using a that kernel the solution or issue might be more conceptual than version dependent. As in we were doing something wrong.

    I understand that the TISDK ships with 3.14..26. We are currently attempting to get something up and running using the graphics SDK at the moment.

  • At this point I seem to be trading one thing for another. I have built the latest ti-sdk and the latest graphics sdk. Based on some rc scripts the frame buffer comes up with triple the memory, which is great, but it appears that the wait for vsync command is not waiting for vsync before drawing the next frame. The draws a coming too quickly.

    I am currently looking into checking if the Vsync interrupts are being registered correctly.

    I should also state that I am not familiar with this and would welcome any suggestions.

  • OMAPDRM has support for increased buffer size. This is not in the mainline. You can look for the commit id 1b66aa541a33239cbd60fb70ae1323c617c42155 in SDK 8.0 kernel. I have also attached patch for your reference. I have to rename the extension as .patch.123 to be able to upload the file.

    Note that AM335x does not use omapdrm, but tilcdc, so this feature isn’t available for AM335x. You can use this to implement similar support for your need.

    0001-drm-omap-fbdev-add-a-module-option-controlling-num-b.patch.123

  • How is the similarly being done inside of the ti-sdk then? When using the sdk and tilcdc we are getting framebuffer defaulted for triple buffering. We are also finding that vsync does not appear to be functioning when using builds based on the ti-sdk.
  • As of right now I have done the following:

    • Jumped backed to the TI-SDK 3.14.26 kernel version
    • Modified the device tree  to allow for the way that our board is configured
      • No encoders
    • Built the kernel withe sdk toolchain and default configuration given by omap2plus-defconfig
    • Built the graphics sdk modules using the sdk toolchain
    • Used the root filesystem provded by the TI SDK

    Somehow the kernel boots and 3 times the buffer space is allocated to the frame buffer. This happens whether I have the graphic modules installed or not. This is good for us since we require two buffers.

    We are able to do the double buffering flips on vsync if we are using the libDRM APIs and not framebuffer (even though the emulation is provided). When using the framebuffer API it appears that the draw for the next frame is not waiting for vsync causing our image to be drawn too rapidly. The libDRM APIs do not have this problem.

    It would be highly desirable to have our applications make use of the framebuffer emulation. This would save us additional work of having to write several applications that run on other boards.

    Please let me know if you need any more information about what we have done.

  • Hi Matt,

    Yes, FBIO_WAITFORVSYNC is not supported in the fbdev emulation. As FBDEV is legacy stuffs, general recommendation in the order of preference is –

    1. Use DRM API

    2. Use fbdev API with the fbdev driver, not DRM driver

    3. Implement the fbdev features on top of the DRM driver

    Please confirm if you really want to use DRM and use fbdev API, and are optimistic that FBIO_WAITFORVSYNC is the last piece needed on fbdev emulation. I can drive towards adding the feature while I hope you understand that it is possible that the mainline DRM will never support FBIO_WAITFORVSYNC. 

    Regards,

    Manisha

     

  • Manisha,

    As of right now we believe that the wait for vsync is our only current limitation. Currently fbdev is the method of drawing our applications use. I am looking into building our kernel with da8XX driver to support the frame buffer but am not being successful. It appears that the binding for this device is device tree is no longer there.

    Edits:

    We are experimenting with all the avenues recommended above:

    1. Use DRM API - we are currently attempting to make this work on at least one of our applications, but we are hitting the learning curve on project we need to be moving foward. This path also has the less appealing task of having to modify multiple drawing applications to use this API.
    2. Use fbdev API with the fbdev driver, DRM driver - This is a good suggestion that I thought we could easily transition to. If I am mistaken it looks like there were some changes made to the da8xx-fb driver that don't appear to have been carried forwarding into kernel 3.14.26 release. This release also does not have the binding information for the device tree in the documentation folder. Do I need to drop down to the older kernel rev for the previous SDK (not desireable)? I currently looking for why this might be. Do I need to attempt to pull forward the changes to the driver? I changed the kernel settings to include this driver and remove the DRM. I don't see the driver even attempt to load when looking at the dmesg output with elevated debug printouts.
    3. Implement the fbdev features on top of the DRM driver - I am unsure why vsync wouldn't be available anyways. We attended a TI Linux Workshop called "Introduction to Embeded Linux"  and were taught the double buffering with vsync technique there using writes to fbdev. I don't know what the driver layout was on the demo board, but nonetheless we came back from that training and successfully implemented the method taught in our applications. We successfully use those applications on our other controller that is IMX6 based using their DRM and frame buffer emulation. Based on what we are seeing above, I would like to know more about this path.

    Regards,

    Matt

  • Matt,

    Regarding #2 above, da8xx isn't forward ported to 3.14 kernel. It is possible to get it working proeprly by forward porting the patches from TI's 3.12 kernel.

    If  FBIO_WAITFORVSYNC is all you need, then I have attached the patch that might do the trick for you. It's unofficial patch with limited testing. Let me know how it goes and we can get this included in our future kernel release. 0001-drm-support-FBIO_WAITFORVSYNC.patch.123

    Regards,

    Manisha

  • Thank you for the patch. We applied it and ran our applications against it. We are certainly able to wait for vysnc when using the emulation. We have noticed other issues with this emulation when compared to running on other platforms providing similar emulation.

    Our tests using the DRM API have yielded much better results. I believe that this this is the path we are going to continue down rather than working through the emulation issue. Thank you for your support on this issue.

    Regards,
    Matt
  • Matt,

    I am glad to be of help and to know that you decided to go with DRM API. For my awareness, could you let me know what issues you ran into with this emulation. It would be helpful on improving our test setup and in decision making at our end to get this patch inluded in future kernel release or not.

    Regards,

    Manisha

  • Manisha,

    On the other platform that we run our application on we are able to control the framebuffer and launch a daemon in the background. On our custom board using the ti sdk the framebuffer crashes when this is done.

    Unfortunately I don't think we will be taking the time to figure out why due to time constraints, but it was enough to push us completely on to moving forward with the DRM API.

    Regards,
    Matt
  • Thanks for providing further details! Yes, DRM API is the way to go forward.