All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.