Re: Audio codec device tree entries

["Jon Smirl" <jonsmirl@gmail.com>]

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Do you want to pick one and add it to the device tree documentation
> > with an example for i2s and ac97? I'll use which ever one is picked.
>
> Sure, I'll draft something up and post it for review.
>
> On the device probing front; what about this method:
>
> Rather than trying to figure things out from the board model, or the
> combination of the codec and i2s bus; add another node to represent
> the sound circuit.  All that node would need is a unique compatible
> property and a phandle to either the i2s bus or the codec (depending
> on which binding approach is used).  It could have additional
> properties to represent optional features, etc.

That's the pseudo-sound node proposal that other people objected to.

It makes sense to me, there needs to be some way to trigger loading
the fabric driver.

>
> For example:
> sound@0 {
>       compatible = "<mfg>,<board>,sound"   // The board might have
> more than one sound i/f which could be wired differently
>       codec-handle = <&codec0>;
> };

Do you even need the parameters,  how about simply this?

sound-fabric {
};

That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.

> This would give your fabric driver something unique to probe on; but
> the i2c, i2s and codec nodes which actually describe interconnects
> will still be present.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>


-- 
Jon Smirl
jonsmirl@gmail.com