[alsa-devel] Thoughts on ASOC v2 driver architecture

[Jon Smirl]

On 6/16/08, Timur Tabi <timur at freescale.com> wrote:
> Jon Smirl wrote:
>
>
> > I'd like for the fabric driver to be dynamically loaded by the device
> tree.
> >
>
>  You have a PPC problem, not an ASoC problem.  You're trying to use the
> device tree to load a device without specifying a specific node.  This is
> particularly difficult with device trees because once a driver has claimed a
> node via a probe, that node isn't probed again.  So you can't use any I2S,
> DMA, or codec nodes.
>
>
> > The root of my problem is that I want to handle my four board variants
> > with a single kernel. So when the kernel loads, I need to figure out
> > which board specific code to load. In the current ASOC design it is
> > assumed that this code is permanently linked in as a platform driver.
> >
>
>  Not with ASoC V2.  I load my fabric driver as a regular module.  It also
> doesn't matter what order I load the drivers in.  Once the fourth driver is
> loaded, ASoC does its magic and creates a sound card (or two) for me.
>
>  So do what I did: deal with the limitations of ASoC V1 as best you can, and
> port your driver to ASoC V2.

I'm already using ASOC V2.

I think I've come up with a solution. Push all of that generic setup
code in mpc8610_hpcd into fsl_ssi. Leave only the platform specific
support in mpc8610_hpcd. Now turn mpc8610_hpcd into a loadable module
but leave it as a platform_driver. During the fsl_ssi probe function
extract the platform name from the device tree and use it to
dynamically load the mpc8610_hpcd driver.


-- 
Jon Smirl
jonsmirl at gmail.com