Revisited, audio codec device tree entries.
Grant Likely
grant.likely at secretlab.ca
Tue Nov 20 03:31:22 EST 2007
On 11/19/07, Jon Smirl <jonsmirl at gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely at secretlab.ca> wrote:
> > On 11/19/07, Timur Tabi <timur at 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.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195
More information about the Linuxppc-dev
mailing list