Re: Revisited, audio codec device tree entries.

[Timur Tabi <timur@freescale.com>]

Matt Sealey wrote:
> 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.

Earlier this year, when I started working on an ASoC driver, the fabric driver 
was called a "machine driver".

> 2) this device tree stuff will end up in more than Linux device trees

Sorry, I don't understand.  The device trees are technically OS-independent, 
so technically there's no such thing as a "Linux device tree".  In addition, 
the current master repository for device trees happens to be the Linux kernel, 
  so I'm not sure where else device trees are going to be.

> 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.

The current device trees have left their OF roots behind.  Sure, we try to 
conform as much as possible, but they're not OF trees any more.

> 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.

My position is that the "fabric" driver should be loaded as a normal device 
tree and it should use the device tree to pick up some data to help it 
instantiate the other drivers.  I'll be posting the code to my PowerPC ASoC 
driver in a couple weeks.

> If you require the codec to be subservient to some "fabric" then I

The codec is subservient to a bus (sometimes multiple buses), which is why it 
is a child to bus nodes.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale