Audio codec device tree entries

[Jon Smirl]

On 10/24/07, David Gibson <david at gibson.dropbear.id.au> wrote:
> On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
> > On 10/24/07, David Gibson <david at gibson.dropbear.id.au> wrote:
> > > I'm afraid I still don't understand quite what information this
> > > "fabric" driver is conveying.  Is it really inherently platform
> > > specific, or is it something that can be encoded directly in a
> > > sensible way.  If the latter we could have a general "device tree"
> > > fabric driver that will handle all systems with the layout correctly
> > > encoded in the device tree.
> >
> > Codecs are like GPIOs, all of their pins are programmable. So the same
> > codec can be wired into various boards quite differently and then
> > software programmed to work the same. The fabric driver contains the
> > mapping information.
> >
> > People were making a codec driver for each board, but this resulted in
> > lots of similar codec drivers for the same chips. I believe a common
> > Wolfson chip had eight drivers in the kernel. In the new model the
> > codec drivers are generic and the fabric driver describes the mapping.
>
> Ok, but the fabric driver is about the wiring of a specific codec
> chip, yes?  If a board was foolishly designed to have two identical
> codec chips, but each wired differently, it would need two instances
> of the same codec driver, plus one instance each of two different
> fabric drivers?

AFAIK no one has built that case. My target board has two different
codec chips. I was handling them both in a single fabric driver but
there is no reason the code couldn't be split.

I was thinking that there was a single fabric for the board, but you
are right in observing that it is per codec chip.

The term fabric is coming from the Apple aoa driver. They only have a
single fabric per board. But there is no reason the Apple driver
couldn't also be adjusted.

> If this is so, then the fabric information *must* be per-codec, and
> should therefore go with the codec node.
>
> > A side effect of this is that we need to load the fabric driver which
> > doesn't have a device associated with it.
>
> Well, it does have a device associated with it, it's just a question
> of how to represent it.  There's not reason a single device node can't
> cause instantiation of multiple driver instances.  Depending on the
> complexity of typical fabric arrangements, one of the following
> options might make sense:
>         - the device node's compatible has enough information to
> specify both fabric and codec driver.  The fabric driver is
> instantiated from this node, and instantiates the codec driver itself
> (since I gather fabric drivers are frequently codec specific in any
> case).

This could work. The generic codec is a alsa soc_device_driver, not a
of_device_driver. The codec node could instantiate the fabric as a
of_device_driver which could then instantiate the soc_device_driver
for the generic codec.

The generic codecs are supposed to work cross platform so they can't
include code that munges the of device tree.


>         - both fabric and codec drivers are instantiated from the same
> device node, and co-ordinate with each other.
>         - The codec is represented as:
> codec-fabric at ... {
>         compatible = "...";
>         <properties describing the fabric>
>         codec {
>               compatible = "...";
>               <properties describing the codec>
>         }
> }
>
> This is different from a "pseudo" node, because the codec-fabric node
> represents a real piece of hardware:  specifically the cluster of
> wires between the sound bus and the codec.
>
> Remember: the device tree describes the hardware, how the chooses to
> structure its driver model to meet the demands of that hardware is up
> to it.  Don't put the cart before the horse.
>
> --
> 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
>


-- 
Jon Smirl
jonsmirl at gmail.com