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. >> 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. >> 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. - Common Display Framework won't (most likely) support this kind of feature, as the feature itself is rather hacky, so this would anyway disappear. - DT support should solve this (except for runtime switching), and the board files are on the way out (as far as I understand). So in that sense this is temporary. - Keeping this feature functional consumes considerable amount of man-hours, which are in short supply. I still feel quite bad about this, though. Any ideas how to manage this better are appreciated. > I bet there must be a much better solution for DT support. Yes, I think I covered that in the last email. DT will solve the issue, except for runtime switching, which is still open. I'm not sure how these board specific drivers would be implemented. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
