On 2013-03-31 11:39, Igor Grinberg wrote: > On 03/28/13 18:48, Tomi Valkeinen wrote: >> On 2013-03-28 17:31, Igor Grinberg wrote: >>> On 03/28/13 14:48, Tomi Valkeinen wrote: >>>> So here are the DSS related board file changes for 3.10. >>>> >>>> First there are a bunch of patches adding the Kconfig options so that only one >>>> display device is created for a single video bus. Only Overo had more than two >>>> displays on the same bus, but unfortunately there were multiple boards with a >>>> setup that puts an LCD and DVI output on the same video bus. >>> >>> Hmmm, so basically, if one could switch the display at runtime... >>> This cannot be done anymore... >>> This sounds like feature removal, no? >>> I know several of our clients who used this feature >>> (at least for evaluation purposes). > >> At some point in time it was possible to have multiple displays for the >> same bus, and switch them at runtime. > >> Sometime later it was changed so that the board file adds all the >> displays, but only one (per bus) is actually added to the list of >> panels, but you could still set the default display in the kernel args, >> and thus you could select which display gets added. > > Yeah, I remember we had to hack this to have the functionality back... Ok. You could've informed me so that I knew it's needed =). I've received no complaints about it, so I thought nobody is even using it. >> The reason why the multiple-displays-per-bus is problematic is that the >> video bus cannot be shared, and if we have multiple devices on the same >> bus, the drivers need extra trickery, delaying initializations, etc, to >> handle this. And it still doesn't work right, as it's easy to get two >> displays enabled at the same time, configuring the same video bus, >> creating a mess. > > Yep, looks like additional display manager framework is needed. > Which will manage the displays on per bus basis? > > >> Quite often the case is that the other displays are not even present >> physically. But it is true that some boards have gpio switches that can >> be used to change the display during runtime. > > I don't think the runtime switch requirement will ever go away, so we'd > better prepare for it wisely. > > >>> Is there any strong pros you obtain while removing this feature? > >> For an user, only indirectly. The change will make things sane on the >> display side, and will thus make it much easier to proceed towards DT >> adaptation, and Common Display Framework. While I can't say it's a >> strict must to remove this feature, I can say that it's been a constant >> headache for me for, well, ever. And I presume CDF would not have this >> feature anyway, as it's rather bad design. > > Well, I don't know about the CDF, but the runtime switch was there > for ages... Think of a DVI or an HDMI... they have the EDID stuff > to make the switch work as expected and it really brings multiple > displays to the same video bus. > I see this is only a meter of how we represent things. > Instead of real EDID (or in addition), that comes with the display, > currently we have the panel info already in the kernel and > panel driver with board specific callbacks to make it work. > So abstracting the above (in the long run) to CDF or some other > framework, should suit everybody's needs. > Probably, we will need board specific drivers, but that never > was a problem... Comparing desktop DVI/HDMI to our case is not a very good comparison. For desktop DVI/HDMI there are no panel devices or such, so it's trivial to manage multiple outputs in the display driver. We need panel device hotplug/unplug support to make this work properly, and as there's no generic way to do that, we need board specific drivers to handle the hotplug/unplug. And we probably need some way to show the information about possible displays to the userspace. I mean, with a case like DVI/Panel on the board, it would make sense to show the userspace that there are those two options, even if the other device is not even present. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
