* Adam Ford <aford173@xxxxxxxxx> [160222 04:26]: > Tony, > > How about I propose that I move the Panel Timings into the two dtsi > files, one for each panel type. Users can include the corresponding > dtsi file based on their panel type. In there I can also include > instructions on what line to patch since those panels need a small > delay inserted into the driver. Does that work for you? Well let's not add code that does not build into the mainline kernel. Also, please don't top-post on the mailing lists.. It breaks the flow of the thread making it hard to reply. > On Mon, Feb 22, 2016 at 2:09 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On 19/02/16 22:49, Tony Lindgren wrote: > >> * Adam Ford <aford173@xxxxxxxxx> [160219 11:37]: > >>> Ideally, I wanted to have both timings available and attempt to select > >>> them through kernel parameters. Do you (or anyone) know if it's > >>> possible to do that with the panel-dpi driver? I wanted to do > >>> something like omapfb.mode=<display> but I couldn't figure it out. > >> > >> Yeah maybe setting some display specific cmdline params would > >> make sense here. Tomi do you have better ideas on selecting > >> a LCD between multiple revisions? > > > > 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. > > 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. 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
