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