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

On 02/09/13 09:15, Tony Lindgren wrote:

* Tomi Valkeinen [off-list ref] [130830 02:55]:

quoted

On 13/08/13 10:54, Tony Lindgren wrote:

quoted

* Tomi Valkeinen [off-list ref] [130809 01:46]:

quoted

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?

quoted

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