On 2013-03-31 12:17, Igor Grinberg wrote: > > > On 03/28/13 19:02, Tomi Valkeinen wrote: >> On 2013-03-28 18:09, Igor Grinberg wrote: >>> 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... > >> Yep. But the panel drivers need to know about this, and they cannot do >> more or less anything in the driver probe function, which I think should >> be the place to reserve resources and do initialization. With the >> current model that would lead to multiple drivers trying to acquire the >> same resources. > > Yep, this is a problem, but it only means that probably > the platform device framework is not suitable for this. > > What about having some kind of display manager which will have a private > list of registered devices and will instantiate only those that are marked > active? > This also might be useful with DT.
We can't have a generic manager that handles instantiating the devices, as we don't know what device they are. They could be platform devices, i2c, anything. There could even be a single device that creates multiple displays. >>>> 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? > >> I mean that only one device can be registered. Well, nothing strictly >> prevents having multiple devices registered, but if the devices have >> matching drivers, the drivers would acquire the same resources. Possibly >> the same gpios, but at least the same video bus. > > Well, I think, we should follow/extend the already existing EDID concept... > Instantiate a display device only when one has been "plugged in". > By "plugged in" I mean enabled - made active. This brings the complication that we need a way to make the display active even if the display device doesn't exist. So we need to know about the display even if it's not there. >>>> 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, I quite agree that this sucks =). There are a few reasons I chose >> to try this approach: > >> - The whole multi-display feature is hacky > >> - DT support for DSS has been in development too long time. We really >> need it, preferably yesterday. This change helps getting DT support ready. > > Yes, but I don't think this should involve removing the existing > functionality.. > Let me exaggerate a bit: this is like removing ARM support from mainline, > so it will make less noise and headache to Linus... That is exaggerating quite a bit ;). But yes, I agree that we should not remove the features. I just couldn't find a manageable way to have them while still moving forward to DT and CDF. Tomi
signature.asc
Description: OpenPGP digital signature
