dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Rob Clark <robdclark@gmail.com>
Cc: linux@arm.linux.org.uk, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC
Date: Tue, 30 Jul 2013 09:36:19 +0200	[thread overview]
Message-ID: <51F76CF3.5070303@gmail.com> (raw)
In-Reply-To: <CAF6AEGteMTuVLjx7zz1Rb-qXKwX2upKNt-guUO9PSAoN_SKipw@mail.gmail.com>

On 07/25/2013 09:32 PM, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge <detheridge@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

  reply	other threads:[~2013-07-30  7:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 18:32 [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC Darren Etheridge
2013-07-25 18:32 ` [PATCH 1/2] drm/i2c/tda998x prepare for tilcdc sync workaround Darren Etheridge
2013-07-25 18:32 ` [PATCH 2/2] drm/tilcdc fixup mode to workaound sync for tda998x Darren Etheridge
2013-07-25 19:32 ` [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC Rob Clark
2013-07-30  7:36   ` Sebastian Hesselbarth [this message]
2013-07-31 20:21   ` Sebastian Hesselbarth
2013-07-31 20:28     ` Russell King - ARM Linux
2013-08-01 14:29     ` Darren Etheridge
2013-08-01 15:19       ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F76CF3.5070303@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox