On 2020-03-03 15:20, Thierry Reding wrote:
On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
On 2020-03-02 21:34, Ville Syrjala wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is correct?
TL/DR; I do not care if you change the refresh rate or the dotclock.
The whole entry for that panel in simple-panel is dubious. The panel is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable with the SELLVDS pin). With Jeida you can, as usual, omit the 4th data channel and use the panel with RGB666. In either case, you need an LVDS signal and nothing else...
The panel can also rotate the picture 180 degrees using the RL/UD pin.
These options are of course not expressed in the simple panel driver (and we have always used fixed signals for those pins in our designs, IIRC). As far as I'm concerned, the panel can be removed from simple-panel. Our device trees are nowadays correctly expressing the hardware with an LVDS encoder between the RGB output and the panel and points to the panel-lvds driver for the panel.
How do you make sure that you always bind against the correct driver? If it matches simple-panel and panel-lvds, it's not deterministically going to pick the right one. Well, it may actually be deterministic on Linux, but perhaps only by accident.
You are probably right that it's fragile, but no problems so far. That said, I did wonder why the panel-lvds driver "wins" over simple-panel for
compatible = "sharp,lq150x1lg11", "panel-lvds";
I figured it was by design and didn't spend too much time thinking about it. Maybe I should have?
The reason that it is as it is, is that we obviously didn't understand what we were doing when we added the entry, and this garbage was what we came up with that produced a picture.
If you want to keep the panel in simple-panel despite all this, the timing constraints are as follows:
Pixel clock 50-80 MHz, 65 MHz typical Horizontal period 1094-1720 clocks, 1344 typical 16.0-23.4 us 20.7 us Horizontal enable 1024 clocks, always Vertical period 776-990 lines, 806 typical 13.3-18.0 ms 16.7 ms Vertical enable 768 lines, always
Using a "long" (the datasheet is not very specific on this issue) vertical period may introduce deterioration of display quality, flicker etc.
I don't think the division between front-porch/back-porch matters much.
That said, I have no idea whatsoever if others have started using this panel entry. My guess is that it has zero users, but who can tell?
A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is the only device tree that uses this panel in the upstream kernel.
This is our design, and what made us originally add the entry to simple panel, but as I said, we no longer need simple-panel support for it...
Cheers, Peter