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

From: Thierry Reding <thierry.reding@gmail.com>
To: Peter Rosin <peda@axentia.se>
Cc: "Gustaf Lindström" <gl@axentia.se>,
	"Thierry Reding" <treding@nvidia.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
Date: Tue, 3 Mar 2020 15:20:31 +0100	[thread overview]
Message-ID: <20200303142031.GA2856480@ulmo> (raw)
In-Reply-To: <c9f756da-ba54-bfd6-87e4-4e52e3e7cecd@axentia.se>

[-- Attachment #1.1: Type: text/plain, Size: 2727 bytes --]

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.

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

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel