Re: [PATCH 00/28] OMAP: DSS related board file changes

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

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

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