Re: Revisited, audio codec device tree entries.

["Jon Smirl" <jonsmirl@gmail.com>]

On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > > > Jon Smirl wrote:
> > > > > >
> > > > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > > > the board. What I haven't been able figure out is how to load the
> > > > > > > right fabric driver.
> > > > > >
> > > > > > Do not use the device tree to load the fabric driver!
> > > > >
> > > > > Heh, technically you can't use the device tree to load any device
> > > > > drivers, it's just a data structure.  :-)
> > > > >
> > > > > You probably mean "don't use the of_platform bus to load the fabric
> > > > > driver".  He still needs to use the data in the device tree to decide
> > > > > what fabric drivers to use.  of_platform_bus would be awkward to use
> > > > > for this because the node describing the fabric doesn't cleanly sit on
> > > > > any particular bus (ie. it describes the board; it does not describe
> > > > > the device).
> > > > >
> > > > > In this case; it probably is appropriate to have the platform code
> > > > > instantiate a platform_device for the fabric (instead of an
> > > > > of_platform device) which the fabric driver can bind against.
> > > >
> > > > First, I have platform bus turned off in my builds. Platform bus is a
> > > > place where cruft accumulates that really belongs somewhere else. For
> > > > example when I turned it off I discovered that there was a PC speaker
> > > > driver in my kernel and well as several drivers from 82xx chips.
> > > >
> > > > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > > > Kconfig attributes control if it is built-in. I've altered the i2c
> > > > code to look for child device tree nodes and then load the appropriate
> > > > drivers.
> > >
> > > Can't you then instantiate the ALSA bus device in your board platform
> > > code?  Then when the driver is registered, the bus should call it's
> > > probe routine.
> >
> > Yes, I can do that. I have just been resisting creating a code linkage
> > from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
> > to create the fabric driver after alsa has made the bus,
> > subsys_initcall(asoc_bus_init);
>
> Hmmm, you could add a drivers_initcall to the platform code, but that
> only works if the ALSA code is compiled statically.  It doesn't work
> for modules.  :-(
>
> 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
b) fabric is per audio bus, make it an attribute or child node under
i2s, ac97, spi. This is messy since it can appear in many places. This
is the apple layout-id scheme.
c) fabric is per codec entry. make it an attribute or child node under
the codec node.
d) after I load the codec node, walk up the device tree to the root
node and then use the compatible string in the root node to trigger
the specific fabric driver. This one avoids making obviously redundant
attributes down lower in the tree.

I need things to initialize in this order. All of these can be modules.
1) alsa subsystem
2) i2c ac97 bus
3) codec driver
4) fabric - it then glues everything together in alsa.

-- 
Jon Smirl
jonsmirl@gmail.com