On Thu, Aug 1, 2013 at 10:29 AM, Darren Etheridge <detheridge@xxxxxx> wrote: > Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> wrote on Wed [2013-Jul-31 22:21:20 +0200]: >> Darren, >> >> I now fully understand the issues of AM335x's LCD controller and your >> fix for it. I suggest to clarify the comments you added to tilcdc to >> allow others to understand it more quickly. >> > Sebastian, > Thanks for looking at my proposed changes, you understand this sync > stuff very well so I appreciate your input that this is actually an > acceptable workaround. > >> Actually, the LCD controller always aligns vsync to the second edge >> of hsync, which will never give VESA-compliant sync. The (elegant) >> workaround you are proposing is to align both rising edges, so at >> least TDA998x can sync on those with some hskew added. Lucky you that >> it ignores hsync length but only looks for rising HS/VS edges ;) > Yes we definitely got lucky with this one, good thing the NXP > supported that reference pixel position, as I was out of options from > the lcd controller side of things to adjust the horizontal position. > >> >> Should we prepare a new patch set comprising the following patches? >> >> Russell King: >> drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices >> drm/i2c: nxp-tda998x: ensure VIP output mux is properly set >> drm/i2c: nxp-tda998x: fix npix/nline programming >> drm/i2c: nxp-tda998x: prepare for video input configuration >> drm/i2c: nxp-tda998x: add video and audio input configuration >> >> Sebastian Hesselbarth: >> drm/i2c: tda998x: fix sync generation and calculation >> >> Darren Etheridge: >> drm/i2c/tda998x prepare for tilcdc sync workaround >> drm/tilcdc fixup mode to workaound sync for tda998x >> >> Or do we keep them separated and possibly resend them if David cannot >> find them anymore? > I vote we submit a complete series that we can all test, there were quite > a lot of versions of things in flight at the same time so I am sure > David would appreciate a consolidated version. I'm sure Dave would appreciate it if someone set up a tree w/ all the patches consolidated and sent a pull req. I can help with that if needed, but it probably makes more sense for someone who is using a beagle-bone and/or CuBox on a more regular basis to do this BR, -R > The only thing I have not tested is audio support, but as the original > driver did not have that anyway I don't consider it blocking if it is > working for CuBox. > > Darren _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
