Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3826 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]