Re: Revisited, audio codec device tree entries.

["Grant Likely" <grant.likely@secretlab.ca>]

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.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195