On 07/25/2013 09:32 PM, Rob Clark wrote: > On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge <detheridge at ti.com> > wrote: >> Russell King and Sebastian Hasselbarth had proposed some very good changes >> for the tda998x HDMI encoder driver. But when those changes were tested >> on BeagleBone Black against the tilcdc driver many modes would no longer >> display correctly. After analyzing the sync signals from the TI lcd >> contoller >> to the nxp it is apparent that the hsync/vsync's are not rising at the same >> time as per the VESA spec and this is causing the HDMI encoder to get >> messed up and failing to lock correctly. >> >> This series of patches should be applied on top of: >> >> Russell King's >> rmk's Dove DRM/TDA19988 Cubox driver series >> >> Sebastian Hasselbarth's >> drm/i2c: tda998x: fix sync generation and calculation >> >> I have done as much of the change as I can in the tilcdc driver but there >> is a small unavoidable change in the tda998x driver. However I have been >> careful not to break anything from the Dove drivers perspective. It >> would be great if somebody can test on Cubox and confirm that. >> >> This patch set inverts the hsync signal coming from the tilcdc so the NXP >> is kept happy and then shifts the output to the right to compensate for the >> sync timing issues. Display modes from the NXP have been verified using a >> HDMI analyzer and are reporting correct timings at the output stage. >> >> Hopefully this will allow the dove/tda driver changes to progress now that >> were blocked as per this discussion: >> http://lists.freedesktop.org/archives/dri-devel/2013-July/040900.html >> > > Good find Darren! The patches look good to me from a quick review. > It would be good to get a tested-by from someone on cubox, but it is > good that we finally found the issue so that we can unblock further > tda998x development.
Thanks to Darren, I can now test tda998x sync changes on both Cubox and Beaglebone Black. I don't think the changes will affect Armada DRM in any way, as it is not setting adjusted_mode. I will put a scope on AM335x/TDA998x sync signals to fully understand the issues tilcdc has, but I can think of a flag for TDA998x to always accept falling input hsync/vsync and tilcdc to supply that sync. That will maybe allow us to get rid of hskew workaround. As far as I understand the issue, tilcdc always aligns VS with the rising HS edge? If so, enforcing positive HS/VS on tilcdc and telling TDA998x that it is always positive, may be a cleaner workaround. TDA998x can invert input and output sync independently. In any way, it will take some time to get a working setup. If you are happy with the patches, I can still send some follow-up patches later. Sebastian
