On 2013-03-28 18:53, Tony Lindgren wrote: > * 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 guess I could've been more verbose in my descriptions. And I agree this is not a nice change. No, we can't switch between the LCD and DVI. But that's not strictly DSS issue. The selection between LCD and DVI (or any other displays on the same bus) are board specific things, sometimes requiring board specific gpios or even things like i2c commands to muxes. It works now because we have custom callbacks in the board files to do those things, but it'll break with DT. >> 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. I could look at using omapdss's module parameter for this. It has default display parameter. Perhaps the board files could parse this, and use it to decide which display to register. Perhaps that'd cause less inconvenience. It's still quite hacky, as you can only select one display. If there's a board with two video outputs, and, say, 2 displays connected to each. You can only select the display for one of the busses. Anyway, we don't have that kind of board in the mainline, so it's not an issue. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
