Re: [RFC 00/22] OMAPDSS: DT support

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

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

On 02/09/13 09:15, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130830 02:55]:
>> On 13/08/13 10:54, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130809 01:46]:
>>>>
>>>> So as is evident, I have things in my mind that should be improved. Maybe
>>>> the most important question for short term future is:
>>>>
>>>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>>>> some proper testing of the related code, and would also allow us to remove
>>>> the related hacks (which don't even work quite right). However, I have no
>>>> idea yet when the unstable DSS bindings would turn stable.
>>>>
>>>> If we shouldn't add the bindings as unstable, when should the bindings be
>>>> added? Wait until CDF is in the mainline, and use that?
>>>
>>> I don't think we should add any temporary bindings as it's going to be
>>> a pain to support those in the long run. I suggest you initially just
>>> stick to established bindings for the basic hardware IO address and
>>> interrupts etc, then those should still be valid with the generic panel
>>> bindings later on.
>>
>> I don't understand what does it matter if the bindings are temporary, or
>> basic established bindings. In both cases the DT data needs to be
>> changed when the CDF is taken into use.
> 
> Yes but the old bindings still need to be supported because people
> are doing devices using those. So any kind of temporary binding will be
> a pain to support.

If old bindings need to be supported, then we also need to support the
current state for Panda and SDP, i.e. there are no DSS related DT
bindings, but displays still work. Which means we'll have to keep the
current hacky DSS device construction mechanism for Panda and SDP.

Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda
and SDP in case they are missing from the real DT data.

Doesn't supporting old bindings also mean that we can never get rid of
the hwmods? Or will there be code that injects the missing interrupt
etc. entries?

>> Well, one difference is that the temporary bindings would give us
>> working display, but having only basic bindings would not. So I don't
>> see any reason to add only the basic bindings. Or how would it work?
> 
> You might be able to use just a minimal binding for now using the
> basic reg, interrupt and entries for the various components. Those will
> be still valid when the CDF bindings are available.

Well, the entries will be valid, but the displays won't work with just
the basic bindings. I could perhaps add a new hack that creates the
required panel devices and video pipeline connections dynamically in
code for Panda and SDP, a bit like what the code does now, except the
basic DSS entries would be in the DT. But that would just add another
set of DT data that I would need to support in the future, and there
would be three different cases to support for Panda and SDP:

- DT data with no DSS related nodes
- DT data with basic DSS related nodes
- DT data with full DSS

So... If old bindings have to be supported, I'd rather try to minimize
the pain, and not add anything but the final bindings. In retrospect, it
was a bit of a mistake to add the hacky DT display support for Panda and
SDP, as it won't be very nice to keep supporting those.

  Tomi



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