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. 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. 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. > 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. >> So the ifdeffery is not very nice. But, as discussed, this is the best way >> forward, and should be seen as a temporary solution until we get full DT >> support. > > I've missed this discussion, can you please point to it? Well, not so much discussion, but a few mails under "Display related board specific boot args" subject on l-o. I proposed a board specific kernel argument to select the displays present, Tony was less than enthusiastic about that. > And what will change with full DT support? > Will we be able to define several displays through DT and > select and active one during runtime? No, not as such. DT will let the bootloader pass the DT data, thus telling which displays are present. So we can have single kernel binary, which will work for all the cases. Dynamic switching during runtime will still be missing. For that I think we need board specific drivers. That driver should know about board specific restrictions etc (which are rather missing currently), remove the old display device, and create the new one. Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
