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: 3061 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]