On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:

Even if the reg-names and interrupts-names are accepted, which is still not obvious due to a little bit of resistance, we still do not

Yeah, it seems like there's very little traction on any of the problems with legacy bindings that device tree has.

have dma request bindings, nor clock bindings, nor pin mux. All these information are provided today by hwmod, so it will still be there for a couple of more merge windows.

At least the DMA bindings seem fairly well sorted - we just merged the Tegra audio bindings which define a Tegra property for the DMA request signal. There's a reasonable amount of variation in how these things get plumbed together.

The important point for me, it to avoid having to change the driver whenever these bindings will be there. This will be OK today for reg and interrupts since they both go through Linux resources.

This is also OK for clocks since they'll go through the clock API so nothing needs doing there either.

...

Could we define and implement the "real" version now (it should be reasonable to code blind except possibly for the DMA channel as it's such a direct mapping) with hwmod left in there as something that's legacy for old kernels?

I think DT churn is unavoidable due to the ongoing effort to add clock, regulator, dma, pin mux into DT core. I don't think we should wait to have all that ready to start migrating to DT.

Well, it does make the whole process a bit silly. If we're planning to discard hwmod it seems like we shouldn't be transitioning it into device tree in the first place and instead just add the new properties to the bindings as we go. If hwmod must go into the device tree somehow is it not possible to keep the hwmod data in its own binding (referencing the nodes it affects rather than being in their bindings).