* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [160222 10:02]: > On 22/02/16 19:45, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [160222 09:30]: > >> On 22/02/16 18:49, Tony Lindgren wrote: > >>> 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 > > We can 'detect' the panel with a kernel cmdline parameter. Or maybe a DT > property. I think u-boot supports setting a DT property. Yeah both sound OK to me. > > 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. > > If there's no DT data for the panel then we need platform data. And I've > been removing platform data support from the display drivers, as it's a > total mess, and it doesn't support anything a bit more complex. Yeah DT works well for passing board specific parameters. > >> - 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 nice part about having the code in arch/arm/mach-omap2/ is that > outside that piece of code, the situation would look like as if the > u-boot passed proper HW data in the .dts. When the u-boot actually does > that, the piece of code could be just removed. If something can be done in pdata-quirks.c to pass a minimal display type in pdata to the panel driver that's fine with me. But let's not try to add any I2C based detection there as that clearly depends on drivers that should be possible to have as loadable modules. > In the other options we more or less get stuck with a custom solution > which may become a maintenance nightmare. > > >> - 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 :) > > I didn't mean the bootloader would do anything here. The .dts file would > contain all the panels, described as being all connected to the same SoC > video output. If there's some generic Linux kernel code to modify the dts that works too, but let's not add any custom hacks to pdata-quirks.c for that. > The problem with this one is that all the panels would need to be in > that .dts, and we'd need to support that in the future, and it's not > correct use of DT files. Also, the "somehow choose which one to use" is > unclear to me. > > >> 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. > > The kernel cmdline only provides part of the solution. Cmdline can be > used for the detection part, in any of the different options above. But > in addition to that we need information about the panel itself and how > it's integrated to the board. Yes agreed. 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
