On Wed, Apr 28, 2010 at 02:25:29PM +1000, Benjamin Herrenschmidt wrote:
I'd stay stick to the basics and move incrementally up until it stops making sense:
- First, the basics: nodes for actual physical devices. i2c codecs on
their i2c busses, DMA controllers, etc...
This is already supported by the ASoC core and has been for about a year or so, it just needs the device drivers to make use of it. IIRC the drivers relevant to PowerPC are pretty much doing so already, but I didn't actually check.
- From there, see what simple properties are better off being put in
those respective nodes because they represent common enough variants of functionality or simply because they are specific attributes of a given device that aren't too concerned by the way things are interconnected.
This one is just a case of writing boiler plate for the existing platform data devices have to convert that from device tree into the existing formats. It's not a monumentally edifying task, but I don't think we really need to worry about it here.
- Provide at least one identifier (either in a "sound" virtual device,
or just use the board's own "compatible" property) to have a .c file to put everything together.
This has been the big sticking point so far. It has been difficult to get people to accept this idea at all, the idea that there may be more to the machine specific setup than can be readily expressed in static data and might even vary dynamically at runtime is what seems to upset people. I've been told on a number of occasions that instantiating machine specific code that's not part of a specific chip is very difficult and would cause the device tree to be horribly buggy.
What you're suggesting here is exactly what is supposed to happen from an ASoC point of view.
The whole thing is a matter of common sense and a bit of taste :-)
The impression that has been created in the past is that there are inflexible device tree rules which can't be varied.