[PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

Rob Clark robdclark at gmail.com
Thu Aug 1 08:19:13 PDT 2013


On Thu, Aug 1, 2013 at 10:29 AM, Darren Etheridge <detheridge at ti.com> wrote:
> Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> 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


More information about the dri-devel mailing list