* Igor Grinberg <grinberg@xxxxxxxxxxxxxx> [130328 09:13]: > On 03/28/13 14:49, Tomi Valkeinen wrote: > > Boards with multiple display options for the same video bus have all the > > possible linux display devices present at the same time. Only one of > > those devices should be used at a time, as the video bus cannot be > > shared. > > Yes, only one can be used at a time, but you can switch at runtime... > > > > > This model is hacky, and will be changed in the forthcoming DSS patches > > to a model where only one display device can be present on a single > > video bus. > > What do you mean by "present"? > Is it active? or registered? or compiled in? > > > > > This patch creates Kconfig options to select which of the display > > devices is present on the board. While this model is also somewhat > > hacky, and prevents us from using a single kernel image for all the > > display options, it allows us to make the DSS driver changes for DT > > adaptation. And with DT, the information about display devices can be > > passed from the bootloader, solving the mess. > > Hmmm, the fact that we cannot use the same binary for multiple displays... > This does not sound right and good at all... > While we try to move to support multiple platforms in the same binary, we > cannot support multiple displays? I agree that the multiplatform stuff is > not really related, but you know what I mean... Yes that's not nice from usability point of view. Can we still switch between LCD and DVI during the runtime? I thought the issue was registering multiple LCD panels where only one can exist at a time? > I bet there must be a much better solution for DT support. Well the best legacy support option would be some fbdev/panel generic cmdline option to specify which one to use. Maybe there is already something like that available that the board-*.c files can parse and can be used also later on with DT support to specify the preferred output? What we don't want to do is add a board specific cmdline option as the board-*.c files will be going away as soon as DT is usable for us and we don't want to support a board specific cmdline after that. But if it's a generic option then parsing it in the board-*.c file or the driver later on can be supported. Of course for some cases it might be possible to detect the configured panel based on what's plugged in over i2c. 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
