Jon Smirl wrote: > > The codec-fabric node was just being used to trigger the loading of > the platform specific driver.
Just remember one thing. 1) the term "fabric" when coined for audio drivers is a new, ALSA SoC specific term. It isn't relevant for anything but ALSA SoC drivers. 2) this device tree stuff will end up in more than Linux device trees 3) you're going to piss off Open Firmware developers by specifying very Linux-specific features in a device tree the same way Apple pissed off Linux developers by encoding MacOS X-specific features in the device tree. Audio driver control like this has to be very specific for a good reason; you can do it a billion ways to Sunday. I'd suggest basically that if you must control a device in a way that needs to be defined by a device which can change address (either dynamically on boot or by board design change - per revision, for example, or with a change of controller) then simply use the device tree to report this address so that you can have the same basic fabric driver (all in Linux) which can handle minor modifications of your board design. If you require the codec to be subservient to some "fabric" then I suggest you make a "sound" node with a compatible entry which is defined as something specific to your board (digispeaker,audio) and let your driver pick that up and then switch on the model (rather like Apple's layout-id) of that device to pick out the specifics of that fabric. If it needs an audio codec (ac97 or i2s) and a control interface (i2c or spi) then it knows which ones it is looking for based on the model. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
