On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote:
On the other hand from a pragmatic point of view it's just much less hassle to just only provide the mechanism for instantiating a machine with custom code and use that for everything.
Right, that's the balance to find. A too descriptive device-tree becomes a mess, and attempting to deal with any kind of representation in SW is horrible.
There is a fine balance to be found between how much goes into the device-tree and how much is eventually just a plain C file that puts things together.
For example, one could imagine a /sound node with simply a "compatible" property that matches what we call in AOA terminology a "fabric" driver. IE. The one thing specific to the board that puts bits and pieces together.
Now, the device-tree is still obviously useful to provide things like the actual i2c IDs of codecs, GPIOs used for various actions, link to from various components to their clock source devices, etc.. All these things simplify the code, avoids horrid board specific code in the actual drivers (codecs, busses, etc...) and overall help keeping the code more maintainable.
This is not an issue specific to audio. The same problem to some extent shows up at the arch level, which is why I was never too much in favor of doing a "generic" platform on powerpc, but still want to have a per board (or at least board family) platform .c file which has the upper hand, even if it ends up mostly using device-tree based "helpers" to put things together.
The device-tree helps keep the platform .c file simple and devoid of too horrible hacks, it allows to easily pass various configuration data to leaf drivers such as i2c thingies, PHY devices etc... without gross hooks between these and the platform, but the platform code still has the upper hand for doing ad-hoc bits and pieces (or overwriting the device-tree based behaviour) if necessary.
Cheers, Ben.