* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [160222 09:30]: > On 22/02/16 18:49, Tony Lindgren wrote: > > >>> I think separate .dtb files are the best option at the moment, and > >>> choose the right one in the bootloader. > > > > That's not going to work for many boards as there are just too many > > combinations to support. > > I think it's fine if there's just one "base" .dts file, so for N panels > you'll end up with N .dtbs. The problems start if you have multiple base > .dts files for, say, different board and SoC revisions. Then the amount > of .dtbs explode. Yeah in this case of modular development boards you can have multiple CPU modules and multiple display panel options. Adam, just for fun, care to estimate the potential permutations with the torpedo kit for example? > >>> Hopefully DT overlays will provide a better solution in the near future. > > > > And that's been already years in making. > > > > I think the only current real fix for issues like this is to include > > multiple configurations in the panel code that can then be selected > > based on the device tree compatible flag or kernel cmdline. > > Well, there are a few options other than the DT overlays and dealing > with this in the bootloader, and each of those options is hacky. > > - board specific platform code detects the display, and appends the > necessary DT data (or uses platform data, but I'd rather get rid of > pdata, not add more). Yeah if the panel can be detected over I2C or by probing the GPIO pins then this might be doable. Probably no need to mix DT data into runtime detection like this though, it can be done in a board specific device driver that then creates the struct device for the panel detected. > - create board specific drivers that detect the display and use the > correct video timings. Having a custom driver seems better to me than trying stuff the detection code into the arch/arm/. > - abuse the board's .dts, and fill in all the possible panels there, and > then at runtime somehow choose which one is used. Heh yeah something like this could be done in the bootloader :) > Well, nothing else comes to my mind. And those above are roughly in my > least-bad-to-most-bad order. Yeah I'd still prefer a kernel cmdline option until we have a better Linux generic solution merged into the mainline kernel. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
