[alsa-devel] [PATCH v2 4/4] ASoC: tegra: Harmony: Support the internal speaker

Stephen Warren swarren at nvidia.com
Wed Jan 26 04:46:57 CET 2011


Mark Brown wrote on Tuesday, January 25, 2011 1:30 PM:
> 
> On Wed, Jan 19, 2011 at 01:50:05PM -0700, Stephen Warren wrote:
> 
> > -static int __init harmony_soc_modinit(void)
> > +static __devinit int tegra_snd_harmony_probe(struct platform_device
> *pdev)
> 
> Unrelated change...

Yeah, I guess I should separate the device probing rework into a separate
patch.

> ...
> With the recently added exposure of snd_soc_register_card() you *should*
> just be able allocate a regular platform device with a regular name in
> your arch/arm code and then register that directly with the ASoC core -
> something like:
> 
> int __devinit harmony_audio_probe(struct platform_device *pdev)
> {
> 	/* Do GPIO stuff */
> 
> 	card->dev = &pdev->dev;
> 	snd_soc_register_card(&snd_soc_harmony);
> 
> 	/* Error handling */
> }
> 
> ought to do the trick, and is much neater and more idiomatic than the
> soc-audio stuff.

With the existing soc-audio structure, one has to:

	platform_set_drvdata(harmony_snd_device, &snd_soc_harmony);

I assume there's no need for this when registering via snd_soc_register_card;
In other words, I'm free to use dev_set_drvdata on the platform_device/device
so I can get rid of all the globals in harmony.y while I'm at it?

I do see some internal use of set_drvdata/get_drvdata in soc-core.c. It
looks like that's restricted to when the soc-audio platform_device is used,
but I don't know if that's just co-incidence, or if it's a guarantee of the
API. Can you confirm this?

Thanks.

--
nvpublic



More information about the Alsa-devel mailing list