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@xxxxxxxxxxxxxxx> >>> >>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
