On Wed, Apr 28, 2010 at 02:10:11PM +1000, Benjamin Herrenschmidt wrote:
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.
Sadly this often seems to be what the device tree folks are pushing for. I really want whatever you guys come up with to explicitly say that it's OK to just write standard code like we have at the minute and not faff around defining device tree representations for everything so that we can just point people at that when the discussion gets too bogged down.
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.
This is the current ASoC design (someone probably ought to look at merging AOA into ASoC, it's approximately the same hardware and at least the CPU driver ought to be useful for other systems).
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.
You're preaching to the choir here. With ASoC all this system specific code ends up in the machine driver (which you guys are calling the fabric driver). All the design stuff you're talking about here is already dealt with as-is, it's just that the parameterisation is done with C code and data structures in the kernel (which can deal with multiple boards if it chooses to) rather than with device tree stuff. The chip specific drivers do not have any board specific code so there is no meaningful change that's being proposed to them.
The problems with the device tree have been that people have been hostile to the idea of there being any board specific code at all in the kernel (or a board specific device tree node for the audio), and that people keep wanting to define some OF stuff that is supposed to cover a wide range of boards but makes unrealistic simplifying assumptions about what general hardware looks like.
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.
Once again, if you can get the device tree guys to buy into this and stick with it that sounds good but my experience has been that this isn't where any of these discussions end up.