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
Attachment:
signature.asc
Description: PGP signature
