Re: Revisited, audio codec device tree entries.

[Matt Sealey <matt@genesi-usa.com>]

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 <matt@genesi-usa.com>
Genesi, Manager, Developer Relations