* i.MX SDMA support @ 2010-08-09 9:11 Sascha Hauer 2010-08-09 10:47 ` Liam Girdwood 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2010-08-09 9:11 UTC (permalink / raw) To: alsa-devel; +Cc: broonie, Liam Girdwood 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-09 9:11 i.MX SDMA support Sascha Hauer @ 2010-08-09 10:47 ` Liam Girdwood 2010-08-09 12:19 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Liam Girdwood @ 2010-08-09 10:47 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, broonie 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 -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-09 10:47 ` Liam Girdwood @ 2010-08-09 12:19 ` Sascha Hauer 2010-08-09 14:09 ` Mark Brown 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2010-08-09 12:19 UTC (permalink / raw) To: Liam Girdwood; +Cc: alsa-devel, broonie 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-09 12:19 ` Sascha Hauer @ 2010-08-09 14:09 ` Mark Brown 2010-08-10 13:15 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Mark Brown @ 2010-08-09 14:09 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Liam Girdwood 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. >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-09 14:09 ` Mark Brown @ 2010-08-10 13:15 ` Sascha Hauer 2010-08-10 13:39 ` Mark Brown 2010-08-10 14:07 ` Liam Girdwood 0 siblings, 2 replies; 14+ messages in thread From: Sascha Hauer @ 2010-08-10 13:15 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, Liam Girdwood 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-10 13:15 ` Sascha Hauer @ 2010-08-10 13:39 ` Mark Brown 2010-08-10 14:07 ` Liam Girdwood 1 sibling, 0 replies; 14+ messages in thread From: Mark Brown @ 2010-08-10 13:39 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Liam Girdwood 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-10 13:15 ` Sascha Hauer 2010-08-10 13:39 ` Mark Brown @ 2010-08-10 14:07 ` Liam Girdwood 2010-08-11 8:42 ` Sascha Hauer 2010-08-11 8:44 ` Sascha Hauer 1 sibling, 2 replies; 14+ messages in thread From: Liam Girdwood @ 2010-08-10 14:07 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Mark Brown 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-10 14:07 ` Liam Girdwood @ 2010-08-11 8:42 ` Sascha Hauer 2010-08-11 10:09 ` Liam Girdwood 2010-08-11 13:43 ` Liam Girdwood 2010-08-11 8:44 ` Sascha Hauer 1 sibling, 2 replies; 14+ messages in thread From: Sascha Hauer @ 2010-08-11 8:42 UTC (permalink / raw) To: Liam Girdwood; +Cc: alsa-devel, Mark Brown 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); -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-11 8:42 ` Sascha Hauer @ 2010-08-11 10:09 ` Liam Girdwood 2010-08-11 11:59 ` Sascha Hauer 2010-08-11 13:43 ` Liam Girdwood 1 sibling, 1 reply; 14+ messages in thread From: Liam Girdwood @ 2010-08-11 10:09 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Mark Brown 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 -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-11 10:09 ` Liam Girdwood @ 2010-08-11 11:59 ` Sascha Hauer 2010-08-11 12:32 ` Liam Girdwood 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2010-08-11 11:59 UTC (permalink / raw) To: Liam Girdwood; +Cc: alsa-devel, Mark Brown 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"; > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-11 11:59 ` Sascha Hauer @ 2010-08-11 12:32 ` Liam Girdwood 0 siblings, 0 replies; 14+ messages in thread From: Liam Girdwood @ 2010-08-11 12:32 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Mark Brown 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-11 8:42 ` Sascha Hauer 2010-08-11 10:09 ` Liam Girdwood @ 2010-08-11 13:43 ` Liam Girdwood 1 sibling, 0 replies; 14+ messages in thread From: Liam Girdwood @ 2010-08-11 13:43 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Mark Brown 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-10 14:07 ` Liam Girdwood 2010-08-11 8:42 ` Sascha Hauer @ 2010-08-11 8:44 ` Sascha Hauer 2010-08-11 10:24 ` Liam Girdwood 1 sibling, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2010-08-11 8:44 UTC (permalink / raw) To: Liam Girdwood; +Cc: alsa-devel, Mark Brown 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"); -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: i.MX SDMA support 2010-08-11 8:44 ` Sascha Hauer @ 2010-08-11 10:24 ` Liam Girdwood 0 siblings, 0 replies; 14+ messages in thread From: Liam Girdwood @ 2010-08-11 10:24 UTC (permalink / raw) To: Sascha Hauer; +Cc: alsa-devel, Mark Brown 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); > err = device_register(&codec->ac97->dev); > if (err < 0) { > snd_printk(KERN_ERR "Can't register ac97 bus\n"); This looks good to me, as card will be set after the device_register. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-08-11 13:43 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-09 9:11 i.MX SDMA support Sascha Hauer 2010-08-09 10:47 ` Liam Girdwood 2010-08-09 12:19 ` Sascha Hauer 2010-08-09 14:09 ` Mark Brown 2010-08-10 13:15 ` Sascha Hauer 2010-08-10 13:39 ` Mark Brown 2010-08-10 14:07 ` Liam Girdwood 2010-08-11 8:42 ` Sascha Hauer 2010-08-11 10:09 ` Liam Girdwood 2010-08-11 11:59 ` Sascha Hauer 2010-08-11 12:32 ` Liam Girdwood 2010-08-11 13:43 ` Liam Girdwood 2010-08-11 8:44 ` Sascha Hauer 2010-08-11 10:24 ` Liam Girdwood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.