[PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Peter Rosin]

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 at 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