[PATCH] drm/panel: panel-simple: Support panel-dpi

[Thierry Reding]

On Fri, Mar 08, 2019 at 02:01:48PM +0100, Sam Ravnborg wrote:
> > One thing that's not clear to me is whether or not we want to allow
> > video timings to be specified in DT. I used to think that we didn't,
> > because the video timings are implied by the specific compatible string
> > (which we already determined is mandatory anyway),
> 
> We often have two users of the timings for a simple panel.
> First we have the bootloader that may present something on the
> panel - next step it then the kernel.
> 
> Bootloaders such as U-boot and barebox supports devicetree.
> So with the timings specified in the devicetree there are three
> users that can use the timings, and it is simple to share the
> timing specifications.

I think this is not true in practice. As far as I know U-Boot and Linux
don't share the device tree. So we wouldn't actually be sharing the
video timings, we'd be duplicating them. And whether we duplicate them
in code or DT isn't really all that different.

> As it is now one has to patch the kernel to add a panel to panel-simple,
> and add timing to device tree to let barebox use it.
> 
> So it would be good once and for all to have the rules specified.
> And the preferred solution is to have timing in the devicetree
> so we can use it both in the kernel and in the bootloaders.

This is *exactly* the same argument that I've heard many times before.
And it is still overly simplistic. Video timings are just one part of
the description of the panel. In most cases you need at least also a
power sequence. You also typically want additional data like physical
dimensions of the visible area so that you can compute the DPI, etc.

The status quo of deriving all of this information from the compatible
string gives us all the flexibility that we need in order to add such
information as we find it to be necessary. If we accept video timings
to be defined in DT, people are just blindly going to use that and not
think about things like physical dimensions or power sequences. And
then we'll just end up in a situation that we can't properly fix
anymore.

From that perspective the status quo is the preferred solution because
it actually allows us to fix things.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190308/944ca323/attachment.sig>