i.MX SDMA support

i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Liam Girdwood]

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

Re: i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Mark Brown]

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.
>> 

Re: i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Mark Brown]

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.

Re: i.MX SDMA support

[Liam Girdwood]

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 

Re: i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Liam Girdwood]

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

Re: i.MX SDMA support

[Liam Girdwood]

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

Re: i.MX SDMA support

[Sascha Hauer]

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 |

Re: i.MX SDMA support

[Liam Girdwood]

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

Re: i.MX SDMA support

[Liam Girdwood]

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