On 10/24/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 08:17:57PM -0400, Jon Smirl wrote:
> > On 10/24/07, David Gibson <[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED] {
> 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
[EMAIL PROTECTED]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
