On Fri, Dec 02, 2011 at 03:59:01PM +0100, Cousson, Benoit wrote:

On 12/2/2011 3:00 PM, Mark Brown wrote:

...

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.

Mmm, I missed that series, but I'm not sure it is doing the right thing.

• First the name is missing :-(
• Secondly a dma-channel is not a dma-request... So I'm not sure

what that series is supposed to add...

The idea is that the thing going into the block is the request line, this is sufficient to identify to the DMA controller code which hardware is being talked about.

...

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

Yep, my point was about the DT churn that this will generate.

Adding new things isn't churn in quite the same way - extending bindings is a more natural process than dropping old bits of binding.

At the end, the effort should be only at OMAP core level, so the driver should not be affected if we decide to move hwmod stuff into DT or not.

Well, the binding will at least need to be updated. Though of course if we manage to ship the DTS for the OMAP with the kernel then it won't really matter if we churn the binding and we may as well not document it at all, treating it as an internal part of the kernel that happens to go through device tree.