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

[David Jander]

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.