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?
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).
- 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
