On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the device on the
> > > ALSA fabric driver.
> >
> > I also concluded that I need a of_platform stepping stone.
> >
> > There are several ways this could be done, which one is the right one?
> > a) fabric is global, create a global device node for it and implement
> > it as a of_platform device
>
> This is really board level description stuff. I'd make the node
> global off the root myself and use whatever linkage you think
> appropriate to get you to the codec nodes (phandle's most likely)
No. I think this is the whole damn point we've been spiralling
around.
An of_platform device is appropriate *only* if there is an OF node for
the device. There should be an OF node for the device only if it it
really is a well-defined hardware component which implements it.
As far as I can understand, the "fabric" driver is really just a
catchall to cover whatever various interconnections there are between
audio components on the board.
Those interconnections could (and probably should) be described in the
OF tree. But that description would be to describe each of those
interconnections individually e.g. codecs have links to "sound PHY"
devices (speakers) or whatever, codecs, i2s AC97 and so forth devices
have links between them appropriate to the type of device. Not as
some imaginary "fabric device".
Therefore the fabric driver cannot be instantiated as an of_platfornm
device.
Therfore arch code will have to instantiate the fabric driver some
other way. There are a couple of options here:
1) We have a "universal" device-tree-based fabric driver which
parses all the above-described interconnection information in the
device tree and handles any situation. Cool, but probably a lot of
work and fiddly to get right.
2) Or, the platform code instantiates an appopriate fabric
driver for the board (which will probably make assumptions about how
things are interconnected). Platform code can optionally examine
board level model properties or other device information to select the
correct fabric driver and/or options. The fabric driver can
optionally look at some parts of the device tree information to
configure details of its operation.
Option (2) is a hack, but it's a reasonably well-contained hack. It
works for now, and doesn't preclude switching to option (1) later -
without changes to the device tree, and on a board-by-board basis. It
can also handle the (almost inevitable) case of device trees with
missing or incorrect detailed audio interconnection information.
The basic thing is that we have a mismatch between the Linux driver
model and the device tree model. Rather than hacking the device tree
to match the Linux model, we should provide whatever glue code is
necessary to instantiate the necessary Linux drivers from the device
tree information we have. This is, essentially, the exact purpose for
which platform code exists.
--
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
