* Tomi Valkeinen [off-list ref] [130901 23:50]:

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

quoted

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.
 

quoted

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.

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