[alsa-devel] ASoC: auto-loading board-specific modules
Currently in ASoC, there is for each supported board a module describing the board-specific DAI links by creating a "soc-audio" platform device with an associated struct snd_soc_card.
The problem with this is that these modules are not automatically loaded by udev (or other device-scanning mechanisms) so some intervention is required before sound will work.
I can think of a few different ways to make everything happen automatically:
1. Build the board-specific bits into the platform modules which are already loaded as platform drivers.
2. Create another platform device whose only function is to cause the board modules to be loaded.
3. Something entirely different.
Someone had a recollection of the current scheme being introduced as a "temporary" solution a couple of years ago, in which case it is about time it got fixed.
I'd appreciate some input on which direction to pursue this before spending time on a potentially inappropriate solution.
-- Mans Rullgard Multimedia mans.rullgard@linaro.org
On Wed, Sep 07, 2011 at 11:16:47PM +0100, Mans Rullgard wrote:
Always CC maintainers. Please folks, this shouldn't be hard to work out.
Currently in ASoC, there is for each supported board a module describing the board-specific DAI links by creating a "soc-audio" platform device with an associated struct snd_soc_card.
No, this has not been the case for new drivers for quite some time now and new drivers trying to do this get rejected. You should probe using a regular device and use snd_soc_register_card() to register the card.
On 7 September 2011 23:35, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Sep 07, 2011 at 11:16:47PM +0100, Mans Rullgard wrote:
Always CC maintainers. Please folks, this shouldn't be hard to work out.
Currently in ASoC, there is for each supported board a module describing the board-specific DAI links by creating a "soc-audio" platform device with an associated struct snd_soc_card.
No, this has not been the case for new drivers for quite some time now and new drivers trying to do this get rejected. You should probe using a regular device and use snd_soc_register_card() to register the card.
Is there some driver that does it right I could look at as a template for fixing at least some of the old ones?
On Thu, Sep 08, 2011 at 12:37:56AM +0100, Mans Rullgard wrote:
Is there some driver that does it right I could look at as a template for fixing at least some of the old ones?
Anything contributed in the past few kernel releases should be good - Speyside if I had to pick one because I maintain it but anything being actively worked on should do the right thing.
participants (2)
-
Mans Rullgard
-
Mark Brown