On Mon, Feb 22, 2016 at 11:45 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * 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. > That is also what I'm trying to avoid. > 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? There are only 2 panels that Logic PD sold in their development kits. They had other displays, but I believe they are no longer being sold. 800 MHz Torpedo (Device trees TBD) 1000 MHz Torpedo (Device trees TBD) 800 MHz Torpedo + Wireless 1000 MHz Torpedo + Wireless (needs modified device tree) 800MHz DM37xx SOM-LV (Device trees pending review) 1000 MHz DM37xx SOM-LV (Device trees TBD) OMAP3530 Torpedo (Device trees to come soon) OMAP3530 SOM-LV (Device trees to come soon) 8 Devices * 2 Displays = 16 Device Trees (Yuck!) This would cut down a bit if the OMAP3630 /3730 had some way of detecting it's max speed. Thankfully, Logic PD doesn't sell all the displays they used to sell or it would be worse. > Logic PD did some evaluation kits for TI like an L138, AM1808 and an AM3517. Those kits should be compatible with these above mentioned displays, with a minor tweak to the panel-dpi driver. >> >>> 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/. The Logic PD panels are not probe-able. They are simple panel-dpi devices with not other interaction than the DSS lines and a few enable pins. For me it seems like a waste to copy/paste the panel-dpi driver to simply add one delay, but I can certainly look at doing that and integrating the display timings into that driver. Having the added delay I need be an optional device tree entry would reduce the amount of duplicate code. >> - 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. In my ideal world, we'd be able to have a device tree with a list of panel timings and a simple command line parameter that selects which one OR a nice way to merge the device trees in U-Boot so I could compile the panel info into a dtb and merge it with the module's DTB. If Tomi would permit me, I'd like to add a single optional delay entry into the panel-dpi device tree which should fix the TI kits made by Logic PD and allow them to work with both the Type 15 and Type 28 displays. > 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
