[alsa-devel] i.MX SDMA support
Hi,
I just posted a series adding SDMA support for i.MX to the Arm Linux Kernel mailing list. It also contains a patch for adding SDMA support to the i.MX SSI units. I haven't cc'd alsa-devel because most of the stuff is not sound related. I know at least Mark and Liam are interested, so I leave a pointer here. The sound stuff needs to be synchronized with the other patches, so it's probably best if all patches go via my tree.
Sascha
On Mon, 2010-08-09 at 11:11 +0200, Sascha Hauer wrote:
Hi,
I just posted a series adding SDMA support for i.MX to the Arm Linux Kernel mailing list.
I noticed. It's good to see SDMA support going upstream :)
It also contains a patch for adding SDMA support to the i.MX SSI units. I haven't cc'd alsa-devel because most of the stuff is not sound related. I know at least Mark and Liam are interested, so I leave a pointer here. The sound stuff needs to be synchronized with the other patches, so it's probably best if all patches go via my tree.
Yeah, that should be OK. However, we do have a ASoC core multi-component update merging later this week. This may conflict with some of your SDMA updates, although the multi-component support only really affects ASoC component probe() and remove() as every component is a regular Linux device now (with platform data, etc) and private data access.
The multi-component branch is here:-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git topic/multi-component
I did have to make some changes to i.MX ASoC in order to de-couple some of the components in order for them to be distinct kernel devices. Any chance you could give this a test with the new SDMA code ?
Thanks
Liam
On Mon, Aug 09, 2010 at 11:47:03AM +0100, Liam Girdwood wrote:
On Mon, 2010-08-09 at 11:11 +0200, Sascha Hauer wrote:
Hi,
I just posted a series adding SDMA support for i.MX to the Arm Linux Kernel mailing list.
I noticed. It's good to see SDMA support going upstream :)
It also contains a patch for adding SDMA support to the i.MX SSI units. I haven't cc'd alsa-devel because most of the stuff is not sound related. I know at least Mark and Liam are interested, so I leave a pointer here. The sound stuff needs to be synchronized with the other patches, so it's probably best if all patches go via my tree.
Yeah, that should be OK. However, we do have a ASoC core multi-component update merging later this week. This may conflict with some of your SDMA updates, although the multi-component support only really affects ASoC component probe() and remove() as every component is a regular Linux device now (with platform data, etc) and private data access.
That won't be a problem. The SDMA code will wait until the next merge window anyway, I will rebase it after the multi-compoment merge if necessary.
The multi-component branch is here:-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git topic/multi-component
I did have to make some changes to i.MX ASoC in order to de-couple some of the components in order for them to be distinct kernel devices. Any chance you could give this a test with the new SDMA code ?
Yes, will do later today or tomorrow. In fact, I wanted to do earlier, but didn't find the time.
Sascha
On 9 Aug 2010, at 13:19, Sascha Hauer s.hauer@pengutronix.de wrote:
On Mon, Aug 09, 2010 at 11:47:03AM +0100, Liam Girdwood wrote:
Yeah, that should be OK. However, we do have a ASoC core multi-component update merging later this week. This may conflict with some of your SDMA updates, although the multi-component support only really affects ASoC component probe() and remove() as every component is a regular Linux device now (with platform data, etc) and private data access.
That won't be a problem. The SDMA code will wait until the next merge window anyway, I will rebase it after the multi-compoment merge if necessary.
This is precisely the issue - multi component will go in 2.6.37 too, meaning conflicts in -next unless one tree is pulled into the other during the release cycle.
On Mon, Aug 09, 2010 at 03:09:44PM +0100, Mark Brown wrote:
On 9 Aug 2010, at 13:19, Sascha Hauer s.hauer@pengutronix.de wrote:
On Mon, Aug 09, 2010 at 11:47:03AM +0100, Liam Girdwood wrote:
Yeah, that should be OK. However, we do have a ASoC core multi-component update merging later this week. This may conflict with some of your SDMA updates, although the multi-component support only really affects ASoC component probe() and remove() as every component is a regular Linux device now (with platform data, etc) and private data access.
That won't be a problem. The SDMA code will wait until the next merge window anyway, I will rebase it after the multi-compoment merge if necessary.
This is precisely the issue - multi component will go in 2.6.37 too, meaning conflicts in -next unless one tree is pulled into the other during the release cycle.
Linus Walleij just proposed to implement the SDMA engine as part of the dmaengine API, so expect some delays here. I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Sascha
On Tue, Aug 10, 2010 at 03:15:27PM +0200, Sascha Hauer wrote:
Linus Walleij just proposed to implement the SDMA engine as part of the dmaengine API, so expect some delays here.
I saw. I suspect it might be sensible to merge SDMA support and then do updates for DMAENGINE as followup work, the lack of it is painful enough to make the feature worth the win.
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Oh dear. It has been difficult to get testers, unfortunately.
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Thanks
Liam
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Many of them, yes ;)
The following patch puts i.MX (nearly) back into business.
Sascha
commit cbd076cc6238efcabd1e23176b3829ddc74266e8 Author: Sascha Hauer s.hauer@pengutronix.de Date: Wed Aug 11 10:37:34 2010 +0200
ASoC: multi-component - i.MX fixes
Signed-off-by: Sascha Hauer s.hauer@pengutronix.de
diff --git a/sound/soc/imx/imx-pcm-fiq.c b/sound/soc/imx/imx-pcm-fiq.c index bb69825..413b78d 100644 --- a/sound/soc/imx/imx-pcm-fiq.c +++ b/sound/soc/imx/imx-pcm-fiq.c @@ -241,15 +241,8 @@ static int ssi_irq = 0; static int imx_pcm_fiq_new(struct snd_card *card, struct snd_soc_dai *dai, struct snd_pcm *pcm) { - struct imx_ssi *ssi = snd_soc_dai_get_drvdata(dai); int ret;
- ret = claim_fiq(&fh); - if (ret) { - dev_err(dai->dev, "failed to claim fiq: %d", ret); - return ret; - } - ret = imx_pcm_new(card, dai, pcm); if (ret) return ret; @@ -270,17 +263,6 @@ static int imx_pcm_fiq_new(struct snd_card *card, struct snd_soc_dai *dai, imx_ssi_fiq_rx_buffer = (unsigned long)buf->area; }
- mxc_set_irq_fiq(ssi->irq, 1); - ssi_irq = ssi->irq; - - imx_pcm_fiq = ssi->irq; - - imx_ssi_fiq_base = (unsigned long)ssi->base; - - ssi->dma_params_tx.burstsize = 4; - ssi->dma_params_rx.burstsize = 6; - - set_fiq_handler(&imx_ssi_fiq_start, &imx_ssi_fiq_end - &imx_ssi_fiq_start);
@@ -302,7 +284,36 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq = {
static int __devinit imx_soc_platform_probe(struct platform_device *pdev) { - return snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq); + struct imx_ssi *ssi = platform_get_drvdata(pdev); + int ret; + + ret = claim_fiq(&fh); + if (ret) { + dev_err(&pdev->dev, "failed to claim fiq: %d", ret); + return ret; + } + + mxc_set_irq_fiq(ssi->irq, 1); + ssi_irq = ssi->irq; + + imx_pcm_fiq = ssi->irq; + + imx_ssi_fiq_base = (unsigned long)ssi->base; + + ssi->dma_params_tx.burstsize = 4; + ssi->dma_params_rx.burstsize = 6; + + ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq); + if (ret) + goto failed_register; + + return 0; + +failed_register: + mxc_set_irq_fiq(ssi_irq, 0); + release_fiq(&fh); + + return ret; }
static int __devexit imx_soc_platform_remove(struct platform_device *pdev) diff --git a/sound/soc/imx/imx-ssi.c b/sound/soc/imx/imx-ssi.c index 6a27048..7eb318f 100644 --- a/sound/soc/imx/imx-ssi.c +++ b/sound/soc/imx/imx-ssi.c @@ -452,7 +452,22 @@ static struct snd_soc_dai_driver imx_ssi_dai = { .ops = &imx_ssi_pcm_dai_ops, };
+static int imx_ssi_dai_probe(struct snd_soc_dai *dai) +{ + struct imx_ssi *ssi = dev_get_drvdata(dai->dev); + uint32_t val; + + snd_soc_dai_set_drvdata(dai, ssi); + + val = SSI_SFCSR_TFWM0(ssi->dma_params_tx.burstsize) | + SSI_SFCSR_RFWM0(ssi->dma_params_rx.burstsize); + writel(val, ssi->base + SSI_SFCSR); + + return 0; +} + static struct snd_soc_dai_driver imx_ac97_dai = { + .probe = imx_ssi_dai_probe, .ac97_control = 1, .playback = { .stream_name = "AC97 Playback", @@ -572,15 +587,12 @@ struct snd_ac97_bus_ops soc_ac97_ops = { }; EXPORT_SYMBOL_GPL(soc_ac97_ops);
-static struct snd_soc_dai_driver imx_ssi_pcm_dai[2]; - static int imx_ssi_probe(struct platform_device *pdev) { struct resource *res; struct imx_ssi *ssi; struct imx_ssi_platform_data *pdata = pdev->dev.platform_data; int ret = 0; - unsigned int val; struct snd_soc_dai_driver *dai;
ssi = kzalloc(sizeof(*ssi), GFP_KERNEL); @@ -654,9 +666,7 @@ static int imx_ssi_probe(struct platform_device *pdev) ssi->flags |= IMX_SSI_DMA; }
- val = SSI_SFCSR_TFWM0(ssi->dma_params_tx.burstsize) | - SSI_SFCSR_RFWM0(ssi->dma_params_rx.burstsize); - writel(val, ssi->base + SSI_SFCSR); + platform_set_drvdata(pdev, ssi);
ret = snd_soc_register_dai(&pdev->dev, dai); if (ret) { @@ -664,10 +674,22 @@ static int imx_ssi_probe(struct platform_device *pdev) goto failed_register; }
- platform_set_drvdata(pdev, ssi); + ssi->soc_platform_pdev = platform_device_alloc("imx-fiq-pcm-audio", pdev->id); + if (!ssi->soc_platform_pdev) + goto failed_pdev_alloc; + platform_set_drvdata(ssi->soc_platform_pdev, ssi); + ret = platform_device_add(ssi->soc_platform_pdev); + if (ret) { + dev_err(&pdev->dev, "failed to add platform device\n"); + goto failed_pdev_add; + }
return 0;
+failed_pdev_add: + platform_device_put(ssi->soc_platform_pdev); +failed_pdev_alloc: + snd_soc_unregister_dai(&pdev->dev); failed_register: failed_ac97: iounmap(ssi->base); @@ -687,6 +709,9 @@ static int __devexit imx_ssi_remove(struct platform_device *pdev) struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0); struct imx_ssi *ssi = platform_get_drvdata(pdev);
+ platform_device_del(ssi->soc_platform_pdev); + platform_device_put(ssi->soc_platform_pdev); + snd_soc_unregister_dai(&pdev->dev);
if (ssi->flags & IMX_SSI_USE_AC97) @@ -706,7 +731,7 @@ static struct platform_driver imx_ssi_driver = { .remove = __devexit_p(imx_ssi_remove),
.driver = { - .name = "imx-ssi-dai", + .name = "imx-ssi", .owner = THIS_MODULE, }, }; diff --git a/sound/soc/imx/imx-ssi.h b/sound/soc/imx/imx-ssi.h index c46d8df..53b780d 100644 --- a/sound/soc/imx/imx-ssi.h +++ b/sound/soc/imx/imx-ssi.h @@ -210,6 +210,8 @@ struct imx_ssi { struct imx_pcm_dma_params dma_params_tx;
int enabled; + + struct platform_device *soc_platform_pdev; };
struct snd_soc_platform *imx_ssi_fiq_init(struct platform_device *pdev, diff --git a/sound/soc/imx/phycore-ac97.c b/sound/soc/imx/phycore-ac97.c index 18fa91b..6a65dd7 100644 --- a/sound/soc/imx/phycore-ac97.c +++ b/sound/soc/imx/phycore-ac97.c @@ -34,8 +34,8 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = { .stream_name = "HiFi", .codec_dai_name = "wm9712-hifi", .codec_name = "wm9712-codec", - .cpu_dai_name = "imx-ssi-dai.0", - .platform_name = "imx-pcm-audio", + .cpu_dai_name = "imx-ssi.0", + .platform_name = "imx-fiq-pcm-audio.0", .ops = &imx_phycore_hifi_ops, }, }; @@ -63,6 +63,11 @@ static int __init imx_phycore_init(void) platform_set_drvdata(imx_phycore_snd_device, &imx_phycore); ret = platform_device_add(imx_phycore_snd_device);
+ imx_phycore_snd_device = platform_device_alloc("wm9712-codec", -1); + if (!imx_phycore_snd_device) + return -ENOMEM; + ret = platform_device_add(imx_phycore_snd_device); + if (ret) { printk(KERN_ERR "ASoC: Platform device allocation failed\n"); platform_device_put(imx_phycore_snd_device);
On Wed, 2010-08-11 at 10:42 +0200, Sascha Hauer wrote:
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Many of them, yes ;)
The following patch puts i.MX (nearly) back into business.
Thanks for this.
if (ssi->flags & IMX_SSI_USE_AC97) @@ -706,7 +731,7 @@ static struct platform_driver imx_ssi_driver = { .remove = __devexit_p(imx_ssi_remove),
.driver = {
.name = "imx-ssi-dai",
.name = "imx-ssi",
The reason that the DAI driver name was changed on all platforms to include a "-dai" suffix was to distinguish the ASoC SSI driver from a generic SSI serial IO driver (i.e. SSI for non audio users). This is mainly due to the fact that most audio interfaces on SoC CPUs exist within a generic serial interface and are also often used for non audio purposes.
So if this suffix is ok, I guess I would need to update the the following too ?
arch/arm/mach-mx2/devices.c:418: .name = "imx-ssi", \ arch/arm/mach-mx2/clock_imx27.c:656: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx2/clock_imx27.c:657: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx31.c:561: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx31.c:562: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx35.c:467: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx35.c:468: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/devices.c:565: .name = "imx-ssi", arch/arm/mach-mx3/devices.c:572: .name = "imx-ssi", arch/arm/plat-mxc/audmux-v2.c:52: return "imx-ssi.0"; arch/arm/plat-mxc/audmux-v2.c:54: return "imx-ssi.1";
Thanks
Liam
On Wed, Aug 11, 2010 at 11:09:54AM +0100, Liam Girdwood wrote:
On Wed, 2010-08-11 at 10:42 +0200, Sascha Hauer wrote:
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Many of them, yes ;)
The following patch puts i.MX (nearly) back into business.
Thanks for this.
There are probably some bits for the DMA part missing, I haven't tested it yet, but will do soon.
if (ssi->flags & IMX_SSI_USE_AC97) @@ -706,7 +731,7 @@ static struct platform_driver imx_ssi_driver = { .remove = __devexit_p(imx_ssi_remove),
.driver = {
.name = "imx-ssi-dai",
.name = "imx-ssi",The reason that the DAI driver name was changed on all platforms to include a "-dai" suffix was to distinguish the ASoC SSI driver from a generic SSI serial IO driver (i.e. SSI for non audio users). This is mainly due to the fact that most audio interfaces on SoC CPUs exist within a generic serial interface and are also often used for non audio purposes.
So if this suffix is ok, I guess I would need to update the the following too ?
Yes, they have to be updated too. I have some more occurences in my tree, but a wcgrep imx-ssi should catch them all.
arch/arm/mach-mx2/devices.c:418: .name = "imx-ssi", \ arch/arm/mach-mx2/clock_imx27.c:656: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx2/clock_imx27.c:657: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx31.c:561: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx31.c:562: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx35.c:467: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx35.c:468: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/devices.c:565: .name = "imx-ssi", arch/arm/mach-mx3/devices.c:572: .name = "imx-ssi", arch/arm/plat-mxc/audmux-v2.c:52: return "imx-ssi.0"; arch/arm/plat-mxc/audmux-v2.c:54: return "imx-ssi.1";
On Wed, 2010-08-11 at 13:59 +0200, Sascha Hauer wrote:
On Wed, Aug 11, 2010 at 11:09:54AM +0100, Liam Girdwood wrote:
On Wed, 2010-08-11 at 10:42 +0200, Sascha Hauer wrote:
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Many of them, yes ;)
The following patch puts i.MX (nearly) back into business.
Thanks for this.
There are probably some bits for the DMA part missing, I haven't tested it yet, but will do soon.
if (ssi->flags & IMX_SSI_USE_AC97) @@ -706,7 +731,7 @@ static struct platform_driver imx_ssi_driver = { .remove = __devexit_p(imx_ssi_remove),
.driver = {
.name = "imx-ssi-dai",
.name = "imx-ssi",The reason that the DAI driver name was changed on all platforms to include a "-dai" suffix was to distinguish the ASoC SSI driver from a generic SSI serial IO driver (i.e. SSI for non audio users). This is mainly due to the fact that most audio interfaces on SoC CPUs exist within a generic serial interface and are also often used for non audio purposes.
So if this suffix is ok, I guess I would need to update the the following too ?
Yes, they have to be updated too. I have some more occurences in my tree, but a wcgrep imx-ssi should catch them all.
arch/arm/mach-mx2/devices.c:418: .name = "imx-ssi", \ arch/arm/mach-mx2/clock_imx27.c:656: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx2/clock_imx27.c:657: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx31.c:561: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx31.c:562: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/clock-imx35.c:467: _REGISTER_CLOCK("imx-ssi.0", NULL, ssi1_clk) arch/arm/mach-mx3/clock-imx35.c:468: _REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk) arch/arm/mach-mx3/devices.c:565: .name = "imx-ssi", arch/arm/mach-mx3/devices.c:572: .name = "imx-ssi", arch/arm/plat-mxc/audmux-v2.c:52: return "imx-ssi.0"; arch/arm/plat-mxc/audmux-v2.c:54: return "imx-ssi.1";
Ok, I'll apply and fix these up too.
Thanks
Liam
On Wed, 2010-08-11 at 10:42 +0200, Sascha Hauer wrote:
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Many of them, yes ;)
The following patch puts i.MX (nearly) back into business.
Sascha
Both applied. I'll do the string change for SSI shortly.
Thanks
Liam
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Besides the patch that I just sent I get a null pointer deref without the following patch. I couldn't find who should set codec->ac97->bus->card, but it's null when I get here. Is this an i.MX fault or is there something else missing here?
Sascha
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 81a77e0..eddb26e 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -312,7 +312,7 @@ static int soc_ac97_dev_register(struct snd_soc_codec *codec) codec->ac97->dev.release = soc_ac97_device_release;
dev_set_name(&codec->ac97->dev, "%d-%d:%s", - codec->ac97->bus->card->number, 0, codec->name); + codec->snd_card->number, 0, codec->name); err = device_register(&codec->ac97->dev); if (err < 0) { snd_printk(KERN_ERR "Can't register ac97 bus\n");
On Wed, 2010-08-11 at 10:44 +0200, Sascha Hauer wrote:
On Tue, Aug 10, 2010 at 03:07:43PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 15:15 +0200, Sascha Hauer wrote:
I just looked at the i.MX part in the multi-component update and this is currently far from being in a working state, so there's still some work to do before thinking about possible conflicts...
Ok, I don't think it's that far off. Everything builds for i.MX and all components should register. The part I can't test is the component probe() and playback/capture.
Have you seen an oops ?
Besides the patch that I just sent I get a null pointer deref without the following patch. I couldn't find who should set codec->ac97->bus->card, but it's null when I get here. Is this an i.MX fault or is there something else missing here?
That is set in the AC97 core and did work at the time of the RFC (when I could test on my now non working Zylonite). Although since the RFC there had been changes to use the dev_name for component binding and a little re-reordering on the bind (and would have affected this piece of code too).
Sascha
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 81a77e0..eddb26e 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -312,7 +312,7 @@ static int soc_ac97_dev_register(struct snd_soc_codec *codec) codec->ac97->dev.release = soc_ac97_device_release;
dev_set_name(&codec->ac97->dev, "%d-%d:%s",
codec->ac97->bus->card->number, 0, codec->name);
codec->snd_card->number, 0, codec->name);
This looks good to me, as card will be set after the device_register.
Thanks
Liam
participants (3)
-
Liam Girdwood -
Mark Brown -
Sascha Hauer