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

[Tony Lindgren <tony@atomide.com>]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130901 23:50]:
> On 02/09/13 09:15, Tony Lindgren wrote:
> > 
> > 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.

Yes we want to keep things working for the users where possible and
not cause regressions. At least some kind of output about what the
user needs to do to update to latest kernel and some documentation
is would be needed..

> 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.

.. but naturally that would certainly make users life easier :)
 
> 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?

I certainly hope we won't be stuck with that and can define most of
the hwmod related data in the .dts files. We should be able to
provide at least some debug output so users know what needs to
be done to upgrade.

But yeah, if there were popular devices with the .dtb in ROM using
the legacy hwmod binding, then we'd be stuck with building or generating
the data in the kernel. Or load the data later on via /lib/firmware and
let deferred probe deal with it.
 
> >> 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.

Yes if that just makes things more complex, it's probably best to work
on getting the generic binding done instead.

Or just rely on getting the configuration from kernel cmdline and always
use just the basic bindings? That might help keep things working for
the "DT data with no DSS related nodes" case?

Regards,

Tony

Regards,

Tony