Audio codec device tree entries

[Grant Likely]

On 10/24/07, Jon Smirl <jonsmirl at gmail.com> wrote:
> On 10/24/07, Grant Likely <grant.likely at secretlab.ca> wrote:
> > > Two valid methods have been proposed
> > > 1. a codec-
> >
> > oops
> >
> > 1. a codec-handle property in the i2s node
> > 2. an i2s-handle property in the codec node
> >
> > Either are reasonable.  I prefer putting the handle in the i2s node;
> > but I'm looking at it from the way that ethernet phys are being
> > described currently.  The other is also perfectly valid.
> >
> > I suppose it depends on what point of view you see the system from; either:
> > a. the codec is supported by the i2s bus, in which case use the
> > i2s-handle property
> > b. the i2s bus is supported by the codec; in which case use the
> > codec-handle property.
>
> 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.

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

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 at secretlab.ca
(403) 399-0195