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

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

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

On 2013-03-31 11:39, Igor Grinberg wrote:
> On 03/28/13 18:48, Tomi Valkeinen wrote:
>> 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.
> 
> Yeah, I remember we had to hack this to have the functionality back...

Ok. You could've informed me so that I knew it's needed =). I've
received no complaints about it, so I thought nobody is even using it.

>> 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.
> 
> Yep, looks like additional display manager framework is needed.
> Which will manage the displays on per bus basis?
> 
> 
>> 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.
> 
> I don't think the runtime switch requirement will ever go away, so we'd
> better prepare for it wisely.
> 
> 
>>> 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.
> 
> Well, I don't know about the CDF, but the runtime switch was there
> for ages... Think of a DVI or an HDMI... they have the EDID stuff
> to make the switch work as expected and it really brings multiple
> displays to the same video bus.
> I see this is only a meter of how we represent things.
> Instead of real EDID (or in addition), that comes with the display,
> currently we have the panel info already in the kernel and
> panel driver with board specific callbacks to make it work.
> So abstracting the above (in the long run) to CDF or some other
> framework, should suit everybody's needs.
> Probably, we will need board specific drivers, but that never
> was a problem...

Comparing desktop DVI/HDMI to our case is not a very good comparison.
For desktop DVI/HDMI there are no panel devices or such, so it's trivial
to manage multiple outputs in the display driver.

We need panel device hotplug/unplug support to make this work properly,
and as there's no generic way to do that, we need board specific drivers
to handle the hotplug/unplug.

And we probably need some way to show the information about possible
displays to the userspace. I mean, with a case like DVI/Panel on the
board, it would make sense to show the userspace that there are those
two options, even if the other device is not even present.

 Tomi


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