On 10/24/07, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 10/24/07, Grant Likely <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] { 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. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev