On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <[EMAIL PROTECTED]> 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:
> > [EMAIL PROTECTED] {
> > 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
