[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