On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
