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. > 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. 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 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. I have just tried three different devices with LVDS displays, that show no reaction to changes of the clk_pol setting. > 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. regards Philipp _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
