Hi Philipp, On Fri, 26 Jun 2015 17:31:18 +0200 Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
