[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

[Grant Likely]

On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
<broonie at 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 at 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 at 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.