[alsa-devel] [PATCH] ASoC/multi-component: fix au1x platform
Hi Liam,
Attached is a patch which fixes the Alchemy (au1x) audio platform in your "topic/multi-component" branch.
Tested on my Db1200.
One minor issue remains: with AC97, the following warning is generated, courtesy of the generic ac97 codec: asoc: ac97-hifi <-> au1xpsc-ac97.1 mapping ok kobject (8fdc59b0): tried to init an initialized object, something is seriously wrong. Call Trace: [<804959c4>] dump_stack+0x8/0x34 [<802a30e4>] kobject_init+0x50/0xcc [<802ec27c>] device_initialize+0x2c/0x70 [<802ecb64>] device_register+0x14/0x28 [<8039e058>] snd_soc_instantiate_cards+0xa00/0xb10 [<8039e27c>] soc_probe+0x114/0x154 [<802ef0fc>] driver_probe_device+0xe4/0x1a0 [<802ee404>] bus_for_each_drv+0x60/0xb0 [<802ef370>] device_attach+0x74/0xa8 [<802ee1e8>] bus_probe_device+0x30/0x54 [<802ec9a0>] device_add+0x384/0x534 [<802f09a4>] platform_device_add+0x15c/0x1c8 [<805ccb14>] db1200_audio_load+0x70/0x9c [<801004fc>] do_one_initcall+0xfc/0x1e0 [<805ba32c>] kernel_init+0xc8/0x168 [<80105904>] kernel_thread_helper+0x10/0x18
ALSA device list: #0: DB1200_AC97
Best regards, Manuel Lauss
On Thu, Aug 19, 2010 at 03:21:35PM +0200, Manuel Lauss wrote:
Attached is a patch which fixes the Alchemy (au1x) audio platform in your "topic/multi-component" branch.
I would provide more detailed review but you've attached your patch as a base64 encoded attachment rather than including it inline so my MUA hasn't quoted it.
As far as your comments about multiple cards go this should now be supported, though the fact that you're modifying the static data for the DAI means that the aux1x drivers probably don't support this or only support it in a limited fashion.
Your kobject_name() stuff looks pretty fishy - is there some reason for not using dev_name()? -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mark,
On Thu, Aug 19, 2010 at 4:06 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 03:21:35PM +0200, Manuel Lauss wrote:
Attached is a patch which fixes the Alchemy (au1x) audio platform in your "topic/multi-component" branch.
I would provide more detailed review but you've attached your patch as a base64 encoded attachment rather than including it inline so my MUA hasn't quoted it.
As far as your comments about multiple cards go this should now be supported, though the fact that you're modifying the static data for the DAI means that the aux1x drivers probably don't support this or only support it in a limited fashion.
The hardware does support it with the issue you mentioned fixed, but the global "soc_ac97_ops" needs to go away first. The alchemy line can support up to 4 independent ac97 "cards" with certain models.
Your kobject_name() stuff looks pretty fishy - is there some reason for not using dev_name()?
no reason, I'll change it.
Thanks, Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 04:30:10PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 4:06 PM, Mark Brown
As far as your comments about multiple cards go this should now be supported, though the fact that you're modifying the static data for the DAI means that the aux1x drivers probably don't support this or only support it in a limited fashion.
The hardware does support it with the issue you mentioned fixed, but the global "soc_ac97_ops" needs to go away first. The alchemy line can support up to 4 independent ac97 "cards" with certain models.
So this comment only applies to the AC97 DAIs, not the I2S ones? Actually, even for AC97 I'd expect things to work fine off the top of my head - while you are forced to use the same ops for everything the ops is just a vtable which I'd expect to be the same for all DAIs? -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 4:35 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 04:30:10PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 4:06 PM, Mark Brown
As far as your comments about multiple cards go this should now be supported, though the fact that you're modifying the static data for the DAI means that the aux1x drivers probably don't support this or only support it in a limited fashion.
The hardware does support it with the issue you mentioned fixed, but the global "soc_ac97_ops" needs to go away first. The alchemy line can support up to 4 independent ac97 "cards" with certain models.
So this comment only applies to the AC97 DAIs, not the I2S ones? Actually, even for AC97 I'd expect things to work fine off the top of my head - while you are forced to use the same ops for everything the ops is just a vtable which I'd expect to be the same for all DAIs?
True, but I don't see how one can pass instance data to the ac97_read/write/whatever functions.
Manuel -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 04:39:17PM +0200, Manuel Lauss wrote:
True, but I don't see how one can pass instance data to the ac97_read/write/whatever functions.
The struct snd_ac97 * passed in to them has a pointer to the struct snd_card * for the card which should (via some further indirection) allow you to get back to the ASoC specific structures. -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 4:48 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 04:39:17PM +0200, Manuel Lauss wrote:
True, but I don't see how one can pass instance data to the ac97_read/write/whatever functions.
The struct snd_ac97 * passed in to them has a pointer to the struct snd_card * for the card which should (via some further indirection) allow you to get back to the ASoC specific structures.
Are there an in-tree examples I could look at? (and for example on how to pass per-instance platform data around? It's not immediately obvious to me how to get data allocated in a platform_driver.probe() callback to the various dai_ops and pcm_ops).
Thanks! Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 4:58 PM, Manuel Lauss manuel.lauss@googlemail.com wrote:
On Thu, Aug 19, 2010 at 4:48 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 04:39:17PM +0200, Manuel Lauss wrote:
True, but I don't see how one can pass instance data to the ac97_read/write/whatever functions.
The struct snd_ac97 * passed in to them has a pointer to the struct snd_card * for the card which should (via some further indirection) allow you to get back to the ASoC specific structures.
(and for example on how to pass per-instance platform data around? It's not immediately obvious to me how to get data allocated in a platform_driver.probe() callback to the various dai_ops and pcm_ops).
Nevermind, figured it out by accident.
Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 19, 2010 at 04:58:55PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 4:48 PM, Mark Brown
Please remember to keep people CCed on Linux mailing list postings.
The struct snd_ac97 * passed in to them has a pointer to the struct snd_card * for the card which should (via some further indirection) allow you to get back to the ASoC specific structures.
Are there an in-tree examples I could look at? (and for example on how to pass per-instance platform data around? It's not immediately obvious to me how to get data allocated in a platform_driver.probe() callback to the various dai_ops and pcm_ops).
This is the only embedded device I've ever seen where anyone wanted to use multiple AC97 controllers so not directly. If you look at the SoC core you can see how the various ALSA structures are converted into ASoC specific ones, though.
On Thu, Aug 19, 2010 at 5:52 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 04:58:55PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 4:48 PM, Mark Brown
Please remember to keep people CCed on Linux mailing list postings.
The struct snd_ac97 * passed in to them has a pointer to the struct snd_card * for the card which should (via some further indirection) allow you to get back to the ASoC specific structures.
Are there an in-tree examples I could look at? (and for example on how to pass per-instance platform data around? It's not immediately obvious to me how to get data allocated in a platform_driver.probe() callback to the various dai_ops and pcm_ops).
This is the only embedded device I've ever seen where anyone wanted to use multiple AC97 controllers so not directly. If you look at the SoC core you can see how the various ALSA structures are converted into ASoC specific ones, though.
There are up to four PSCs, each capable of both AC97 and I2S operation, with separate RX and TX DMA channels. I consider each PSC a separate "card".
I figured out how to access platform data in dai_ops, however I see absolutely no way to get at it from the ac97_ops.
Manuel
On Thu, Aug 19, 2010 at 05:59:24PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 5:52 PM, Mark Brown
This is the only embedded device I've ever seen where anyone wanted to use multiple AC97 controllers so not directly. ?If you look at the SoC core you can see how the various ALSA structures are converted into ASoC specific ones, though.
I figured out how to access platform data in dai_ops, however I see absolutely no way to get at it from the ac97_ops.
The snd_card has private data...
On Thu, Aug 19, 2010 at 6:06 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Aug 19, 2010 at 05:59:24PM +0200, Manuel Lauss wrote:
On Thu, Aug 19, 2010 at 5:52 PM, Mark Brown
This is the only embedded device I've ever seen where anyone wanted to use multiple AC97 controllers so not directly. ?If you look at the SoC core you can see how the various ALSA structures are converted into ASoC specific ones, though.
I figured out how to access platform data in dai_ops, however I see absolutely no way to get at it from the ac97_ops.
The snd_card has private data...
Thanks. However there's another problem: the ac97 codec accesses the snd_ac97_ops() before the AC97 controller has been set up, which, naturally, results in an oops. I'll keep the current crutch for ac97 in place for now.
AC97 SoC Audio Codec 0.6 CPU 0 Unable to handle kernel paging request at virtual address 00000050, epc == 803a42dc, ra == 80396ad0 Call Trace: [<803a42dc>] au1xpsc_ac97_cold_reset+0x1c/0x14c [<80396ad0>] snd_ac97_mixer+0x1dc/0x198c [<803a2ea4>] ac97_soc_probe+0xa8/0xd4 [<8039db20>] snd_soc_instantiate_cards+0x4c8/0xb10 [<8039e27c>] soc_probe+0x114/0x154 [<802ef0fc>] driver_probe_device+0xe4/0x1a0 [<802ee404>] bus_for_each_drv+0x60/0xb0 [<802ef370>] device_attach+0x74/0xa8 [<802ee1e8>] bus_probe_device+0x30/0x54 [<802ec9a0>] device_add+0x384/0x534 [<802f09a4>] platform_device_add+0x15c/0x1c8 [<805ccb04>] db1200_audio_load+0x70/0x9c [<801004fc>] do_one_initcall+0xfc/0x1e0 [<805ba32c>] kernel_init+0xc8/0x168 [<80105904>] kernel_thread_helper+0x10/0x18
Manuel
participants (2)
-
Manuel Lauss -
Mark Brown