[PATCH] staging: imx-drm: Fix pixel clock polarity

David Jander david at protonic.nl
Sun Jun 28 23:46:47 PDT 2015

Hi Philipp,

On Fri, 26 Jun 2015 17:31:18 +0200
Philipp Zabel <p.zabel at pengutronix.de> wrote:

> Hi David,
> Am Freitag, den 26.06.2015, 13:26 +0200 schrieb David Jander:
> > This is odd. We started investigating because one of our customers (using
> > an LVDS connected panel) reported some boards causing color errors in
> > gradients. If you displayed for example a horizontal red gradient from 0
> > to 255, you would see 3 stripes through the gradient (dividing it into 4
> > parts) of pixels that are too bright. Not all the boards had this issue,
> > and in many of them itwas an unstable symptom, which immediately pointed
> > at a problem related to process variations. The symptoms can be explained
> > by a latch in the LDB (LVDS bridge) that latches the individual bits in
> > the shift register on the same clock-edge that those signals change. So
> > the internal signal delay can cause either the old or the new value of the
> > pixel-bit getting latched. The color stripes are then caused by the
> > roll-over from xx0111 to xx1000, where bit 3 gets latched at it's new
> > value, while all lower bits get latched at their previous value. Most of
> > the time this situation was unstable. I even have scope images showing the
> > anomaly on the LVDS signal. This patch fixes the issue for all boards.
> I have seen similar artifacts in the red channel of LVDS0 on an i.MX6S
> once where changing clock polarity didn't have any effect, but switching
> from DI0 to DI1 helped.

That's weird, but I assume unrelated to this issue.

> > If you are confident that your code is correct, then maybe the LDB expects
> > an inverted clock signal?
> There are parallel panels that sample on the rising pixel clock edge,
> for those this information should be part of the panel descriptor. 

Yes, I have seen those.

> For
> LVDS the clock waveform is standardized, so this should be an issue in
> the LDB. On the other hand, the serializer in the LDB shouldn't care
> about the pixel clock polarity if it uses the 7x serializer clock and an
> internal counter compared to the counter_reset_val field to determine at
> which point to load the shift registers. But that's my understanding

I assume the 7x serializer clock is synchronized with the pixel clock. On
external LVDS transceivers, there's a PLL to generate the 7x clock derived
from the pixel-clock, but since this is an internal LVDS bridge, it uses a
generated clock for the serializer that's set to 7x the pixel clock. I think
that the clock _output_ of the LVDS interface is a synthesized signal that is
generated from the serializer clock. This is easier to design. That makes the
whole LDB block synchronous to the pixel-clock and it will always generate a
standards-compliant clock signal to the panel, BUT... if the input pixel clock
is out of phase, strange things can happen. I am pretty sure that the LDB
latches the pixel data to the shift registers on the wrong edge. The scope
images are clear as water. I don't know whether this is a silicon-bug or a
driver bug, but definitely inverting the pixel clock fixes the problem.
Just to make this entirely clear: The LVDS signal that comes out of the LVDS0
channel is clearly broken (on a small percentage of boards). It is NOT the
display panel that is misinterpreting an otherwise valid LVDS signal.

> from the reference manual, which doesn't necessarily have to be the same
> as reality. Maybe the pixel clock latches the input bus signal onto an
> internal register.

Yes, I am pretty sure it does. Problem is that this latch is supposed to work
on the other edge of the clock.

> I have just tried three different devices with LVDS displays, that show
> no reaction to changes of the clk_pol setting.

I know. It appears on one out of ten boards maybe, and sometimes it takes a
while for the problem to appear...

> > I must admit that this patch is rather old. I tested it thoroughly on 3.17,
> > but AFAICS, the patch you mention is also included in 3.17, so I suppose
> > the situation has not changed.
> Do you still have devices that show this issue available to test? I'd be
> very interested to know whether switching DIs or using the LDB_DI parent
> selection procedure described in 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313618.html
> makes any difference.

We can try this out. I'll try to find a board that has this issue. It was on a
i.MX6U (Dual-light). Unfortunately I don't think I manage to do it this week,
and from next week on I'll be on vacation, so it can take a while...
Again, all this testing was on mainline 3.17, so it will be good to check that
we still can reproduce this problem with 4.1.

Best regards,

David Jander
Protonic Holland.

More information about the dri-devel mailing list