[alsa-devel] [PATCH 4/4] ASoC: soc core allow machine driver to register the card
From: Vinod Koul vinod.koul@intel.com
The machine driver can't register the card directly and need to do this thru soc-audio device creation
This patch allows the register and unregister card to be called by machine drivers
Signed-off-by: Vinod Koul vinod.koul@intel.com Signed-off-by: Harsha Priya harsha.priya@intel.com --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 21 +++++++++++---------- 2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h index 541ddfa..9952254 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -258,6 +258,8 @@ enum snd_soc_compress_type { SND_SOC_RBTREE_COMPRESSION };
+int snd_soc_register_card(struct snd_soc_card *card); +int snd_soc_unregister_card(struct snd_soc_card *card); int snd_soc_register_platform(struct device *dev, struct snd_soc_platform_driver *platform_drv); void snd_soc_unregister_platform(struct device *dev); diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 8305712..87348ab 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -58,8 +58,6 @@ static LIST_HEAD(dai_list); static LIST_HEAD(platform_list); static LIST_HEAD(codec_list);
-static int snd_soc_register_card(struct snd_soc_card *card); -static int snd_soc_unregister_card(struct snd_soc_card *card); static int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num);
/* @@ -1870,6 +1868,10 @@ static int soc_probe(struct platform_device *pdev) struct snd_soc_card *card = platform_get_drvdata(pdev); int ret = 0;
+ /* no card, so machine driver is registering card */ + if (!card) + return 0; + /* Bodge while we unpick instantiation */ card->dev = &pdev->dev; snd_soc_initialize_card_lists(card); @@ -1919,6 +1921,9 @@ static int soc_remove(struct platform_device *pdev) { struct snd_soc_card *card = platform_get_drvdata(pdev);
+ if (!card) + return 0; + snd_soc_unregister_card(card); return 0; } @@ -3105,11 +3110,8 @@ EXPORT_SYMBOL_GPL(snd_soc_dai_digital_mute); * * @card: Card to register * - * Note that currently this is an internal only function: it will be - * exposed to machine drivers after further backporting of ASoC v2 - * registration APIs. */ -static int snd_soc_register_card(struct snd_soc_card *card) +int snd_soc_register_card(struct snd_soc_card *card) { int i;
@@ -3141,17 +3143,15 @@ static int snd_soc_register_card(struct snd_soc_card *card)
return 0; } +EXPORT_SYMBOL_GPL(snd_soc_register_card);
/** * snd_soc_unregister_card - Unregister a card with the ASoC core * * @card: Card to unregister * - * Note that currently this is an internal only function: it will be - * exposed to machine drivers after further backporting of ASoC v2 - * registration APIs. */ -static int snd_soc_unregister_card(struct snd_soc_card *card) +int snd_soc_unregister_card(struct snd_soc_card *card) { if (card->instantiated) soc_cleanup_card_resources(card); @@ -3162,6 +3162,7 @@ static int snd_soc_unregister_card(struct snd_soc_card *card)
return 0; } +EXPORT_SYMBOL_GPL(snd_soc_unregister_card);
/* * Simplify DAI link configuration by removing ".-1" from device names
On Thu, Jan 13, 2011 at 10:49:10PM +0530, Koul, Vinod wrote:
@@ -1870,6 +1868,10 @@ static int soc_probe(struct platform_device *pdev) struct snd_soc_card *card = platform_get_drvdata(pdev); int ret = 0;
- /* no card, so machine driver is registering card */
- if (!card)
return 0;
I'll review this one more closely tomorrow - as I said with the combined patch I'd not expect the soc-audio device to be involved when the machine driver is registering a card so I'd like to understand in more detail why this is still required.
I am having problem creating 2nd ALSA sound card driver I developed:
I found snd_ctl_dev_register() in control.c is called successfully but I do not see the 2nd sound card entry below:
# ls /dev/snd controlC0 pcmC0D0c pcmC0D0p pcmC0D1c seq timer
And I saw a suspicious message at the end of boot steps:
Unmuting sound device: [FAIL] Starting dropbear sshd: OK
Well, this happens with one file system, and with another file system, the 2nd card entry is created correctly as below:
# ls /dev/snd controlC0 pcmC0D0c pcmC1D1c seq controlC1 pcmC0D0p pcmC1D1p timer
And I don't see that message.
Anybody has some suggestions?
Thanks a lot in advance.
Philip
At Thu, 13 Jan 2011 18:17:24 -0600, Philip Chu wrote:
I am having problem creating 2nd ALSA sound card driver I developed:
I found snd_ctl_dev_register() in control.c is called successfully but I do not see the 2nd sound card entry below:
# ls /dev/snd controlC0 pcmC0D0c pcmC0D0p pcmC0D1c seq timer
And I saw a suspicious message at the end of boot steps:
Unmuting sound device: [FAIL] Starting dropbear sshd: OK
Well, this happens with one file system, and with another file system, the 2nd card entry is created correctly as below:
# ls /dev/snd controlC0 pcmC0D0c pcmC1D1c seq controlC1 pcmC0D0p pcmC1D1p timer
And I don't see that message.
Anybody has some suggestions?
udev?
Takashi
Thanks a lot Takashi, udev works.
Philip
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Friday, January 14, 2011 3:32 AM To: Philip Chu Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] ALSA driver fails to creat ControlC1 and others...
At Thu, 13 Jan 2011 18:17:24 -0600, Philip Chu wrote:
I am having problem creating 2nd ALSA sound card driver I developed:
I found snd_ctl_dev_register() in control.c is called successfully but I do not see the 2nd sound card entry below:
# ls /dev/snd controlC0 pcmC0D0c pcmC0D0p pcmC0D1c seq timer
And I saw a suspicious message at the end of boot steps:
Unmuting sound device: [FAIL] Starting dropbear sshd: OK
Well, this happens with one file system, and with another file system, the 2nd card entry is created correctly as below:
# ls /dev/snd controlC0 pcmC0D0c pcmC1D1c seq controlC1 pcmC0D0p pcmC1D1p timer
And I don't see that message.
Anybody has some suggestions?
udev?
Takashi
@@ -1870,6 +1868,10 @@ static int soc_probe(struct platform_device *pdev) struct snd_soc_card *card = platform_get_drvdata(pdev); int ret = 0;
- /* no card, so machine driver is registering card */
- if (!card)
return 0;I'll review this one more closely tomorrow - as I said with the combined patch I'd not expect the soc-audio device to be involved when the machine driver is registering a card so I'd like to understand in more detail why this is still required.
If someone is still creating soc-audio device and not adding the drvdata the code following this will use a null pointer :(. So tried to protect, but again if people are doing right, then this shouldn't be invoked at all
~Vinod
On Fri, Jan 14, 2011 at 09:54:59AM +0530, Koul, Vinod wrote:
- /* no card, so machine driver is registering card */
- if (!card)
return 0;
I'll review this one more closely tomorrow - as I said with the combined patch I'd not expect the soc-audio device to be involved when the machine driver is registering a card so I'd like to understand in more detail why this is still required.
If someone is still creating soc-audio device and not adding the drvdata the code following this will use a null pointer :(. So tried to protect, but again if people are doing right, then this shouldn't be invoked at all
If that's all it is then the check should be changed to return -EINVAL or similar as this is an error which prevents the device being instantiated. It shouldn't pretend it succeeded, and not doing so will save us having to check in any of the other functions.
I'll review this one more closely tomorrow - as I said with the combined patch I'd not expect the soc-audio device to be involved when the machine driver is registering a card so I'd like to understand in more detail why this is still required.
If someone is still creating soc-audio device and not adding the drvdata the code following this will use a null pointer :(. So tried to protect, but again if people are doing right, then this shouldn't be invoked at all
If that's all it is then the check should be changed to return -EINVAL or similar as this is an error which prevents the device being instantiated. It shouldn't pretend it succeeded, and not doing so will save us having to check in any of the other functions.
Agreed, but on the other hand if someone is using register api they should not be creating the device, so probe shouldn't be called at all. We can leave this check. What do you think?
~Vinod
On Fri, Jan 14, 2011 at 04:55:47PM +0530, Koul, Vinod wrote:
If that's all it is then the check should be changed to return -EINVAL or similar as this is an error which prevents the device being instantiated. It shouldn't pretend it succeeded, and not doing so will save us having to check in any of the other functions.
Agreed, but on the other hand if someone is using register api they should not be creating the device, so probe shouldn't be called at all. We can leave this check. What do you think?
I think the check should be changed to report an error since they should never be calling this function in the first place; this is the standard thing for devices with an invalid setup.
If that's all it is then the check should be changed to return -EINVAL or similar as this is an error which prevents the device being instantiated. It shouldn't pretend it succeeded, and not doing so will save us having to check in any of the other functions.
Agreed, but on the other hand if someone is using register api they should not be creating the device, so probe shouldn't be called at all. We can leave this check. What do you think?
I think the check should be changed to report an error since they should never be calling this function in the first place; this is the standard thing for devices with an invalid setup.
Yes, that's a better idea. Sent you this patch updated.
~Vinod
participants (4)
-
Koul, Vinod -
Mark Brown -
Philip Chu -
Takashi Iwai