On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
However, as you and Mark rightly point out, it completely fails to represent complex sound devices with weird clocking and strange routes. Something like this is probably more appropriate:
[...] codec1 :codec@4f { compatible = "cirrus,cs4270"; reg = <0x4f>; /* MCLK source is a stand-alone oscillator */ clock-frequency = <12288000>; };
You also want to be representing unused pins here.
[...] ssi1: ssi@16000 { compatible = "fsl,mpc8610-ssi"; [...] fsl,mode = "i2s-slave";
I'd not include the master/slave decision; it's either implied by the fact that the CODEC has a standalone clock, a property of the link/card, or a policy decision that the running software can change on a whim.
sound { compatible = "fsl,mpc8610-hpcd-sound"; /* maybe something like (totally off the top of my head) */ dai-links = <&ssi1 0 &codec 0 &ssi1 1 &codec 1>;
I'm having a hard time loving this. I'd be looking for a lot more semantics on the links (things like information about separate clocks for the two directions, for example) which makes me think that that simple list format is far too simple and you want a list of more complex objects.
Oh, absolutely. This example is no where near complete. Mostly I just wanted to give a concrete example of a 'virtual' device like Ben was talking about. I'm not going to even attempt to draft a complete binding until I've got time to properly go over the issues involved and discuss them with you and Liam.
There's also analogue interconnects to deal with, and jacks (including detection and accessories). Jacks can be particularly entertaining here.
Or, in other words, the device tree should *not* be used to describe every possible detail and permutation. It is best used to describe the permutations that are common so that they don't need to be hard coded for each and every board.
I think the ideal is something that's purely descriptive of the hardware and doesn't include any policy decisions. Policy decisions covers an awful lot of the interesting issues, though - but they're the sort of things that can easily be changed with a new software load and therefore don't belong in the device tree.
Agreed.
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.
Also true, but this approach carries with it an incremental cost that distributions feel the pain of. Ultimately I think we'll find a sweet spot somewhere in between.
Cheers, g.