MPC8610HPCD sound as module

MPC8610HPCD sound as module

[Peter Czanik]

Hello,

I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs
fine on this, with a catch: sound only works, when compiled in the
kernel (see:
http://www.alsa-project.org/db/?f=73fb074ce0b41463bb3f32aaa297a1e1f53caf2d
). When the exact same sound options are compiled as modules (see:
http://www.alsa-project.org/db/?f=c353962950284d61bd16ac7d48032b8b5f598062
), then sound card is not found. Both kernel configurations were based
on mpc8610_hpcd_defconfig with some minor tweaks (some additional fs
options to be able to boot SuSE Linux). The only difference between the
two configs is that in the second case sound is modular.

As far as I can see from comments in the sources, it should work also as
a module. Any hints how to achieve that?

Thanks, bye,
CzP

Re: MPC8610HPCD sound as module

[Timur Tabi]

On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik <pczanik@fang.fa.gau.hu> wrote:
> Hello,
>
> I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs
> fine on this, with a catch: sound only works, when compiled in the
> kernel

That's because the driver doesn't support being compiled as a module.
The Kconfig, as *I* wrote it, only allows for in-kernel compilation.

The only way you could have gotten my drivers to compile as a module
is if you hacked the Kconfig.

> As far as I can see from comments in the sources, it should work also as
> a module. Any hints how to achieve that?

The ASoC V2 version of the driver supports loading as a module.  ASoC
V1 does not support loading sound drivers as modules, which is why I
didn't implement that support in the V1 drivers.  The 2.6.27 kernel
has ASoC V1.  ASoC V2 won't be integrated into the mainline until at
least 2.6.29, and maybe even 2.6.30.  The ASoC V2 repository is
available at http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git
under the asoc-v2-dev branch.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: MPC8610HPCD sound as module

[Mark Brown]

On Thu, Dec 11, 2008 at 09:12:54AM -0600, Timur Tabi wrote:
> On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik <pczanik@fang.fa.gau.hu> wrote:

> > As far as I can see from comments in the sources, it should work also as
> > a module. Any hints how to achieve that?

> The ASoC V2 version of the driver supports loading as a module.  ASoC
> V1 does not support loading sound drivers as modules, which is why I
> didn't implement that support in the V1 drivers.  The 2.6.27 kernel

ASoC v1 supports loading drivers as modules (and this is fairly heavily
used), though as you say the MPC8610 drivers don't support that.

> has ASoC V1.  ASoC V2 won't be integrated into the mainline until at
> least 2.6.29, and maybe even 2.6.30.  The ASoC V2 repository is
> available at http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git
> under the asoc-v2-dev branch.

At the minute there's code queued for merge which defers card
instantiation until DAIs and platforms have registered, allowing the
various parts of the system to probe through the normal mechanisms.
That's the most substantial of the outstanding changes.

Re: MPC8610HPCD sound as module

[Timur Tabi]

Mark Brown wrote:

> ASoC v1 supports loading drivers as modules (and this is fairly heavily
> used), though as you say the MPC8610 drivers don't support that.

Well, at the time I wrote the drivers, I didn't see an easy way to support
modules, since V1 drivers typically have lots of hard-coded references to global
 variables in other files.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: MPC8610HPCD sound as module

[Mark Brown]

On Thu, Dec 11, 2008 at 09:40:55AM -0600, Timur Tabi wrote:
> Mark Brown wrote:

> > ASoC v1 supports loading drivers as modules (and this is fairly heavily
> > used), though as you say the MPC8610 drivers don't support that.

> Well, at the time I wrote the drivers, I didn't see an easy way to support
> modules, since V1 drivers typically have lots of hard-coded references to global
>  variables in other files.

The only references should be machine->{codec,ssi} and ssi->platform.
There's a reasonable chance that your drivers would work fine if you
just marked them all as tristate, though since they're written rather
differently to other ASoC drivers it's possible something will break.

Re: MPC8610HPCD sound as module

[Timur Tabi]

Mark Brown wrote:

> The only references should be machine->{codec,ssi} and ssi->platform.
> There's a reasonable chance that your drivers would work fine if you
> just marked them all as tristate, though since they're written rather
> differently to other ASoC drivers it's possible something will break.

And since I fixed the code in the V2 drivers, I have no interest in fixing it in
the V1 drivers, which are officially in maintenance mode -- only critical bug
fixes, no new features.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: MPC8610HPCD sound as module

[Mark Brown]

On Thu, Dec 11, 2008 at 09:45:26AM -0600, Timur Tabi wrote:

> And since I fixed the code in the V2 drivers, I have no interest in fixing it in
> the V1 drivers, which are officially in maintenance mode -- only critical bug
> fixes, no new features.

Well, from that point of view now would be a good time for you to start
backporting your newer code.  The concept of having the core wait for
subdevices to probe is now there which was the major win from the point
of view of integration with the device tree.  What's there now also has
the changes you wanted without the use of templates in the ASoC core so
you can do a single memory allocation for devices rather than having to
fill out templates and have the core do allocations for you.

Re: MPC8610HPCD sound as module

[Timur Tabi]

Mark Brown wrote:

> Well, from that point of view now would be a good time for you to start
> backporting your newer code.  The concept of having the core wait for
> subdevices to probe is now there which was the major win from the point
> of view of integration with the device tree.  What's there now also has
> the changes you wanted without the use of templates in the ASoC core so
> you can do a single memory allocation for devices rather than having to
> fill out templates and have the core do allocations for you.

Okee dokee.  I'll start working on it next month.

-- 
Timur Tabi
Linux kernel developer at Freescale