Audio codec device tree entries

[David Gibson]

On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <grant.likely at 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 at 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.

We shouldn't be basing driver configuration on the machine name unless
we really have to.  We should be able to find a sane way to encode the
necessary information in the tree proper.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson