[PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
register offset and missing generic SRAM APIs support

Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
  "ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.
- Provide a config option to indicate missing SRAM API support.

While here, fix a typo caused by recent commit (cf53756 - ASoC: davinci: 
davinci-pcm does not need to be a plaform_driver)

Note:
   DMA parameters (dma fifo offset) are not updated and will be done later.

Hebbar, Gururaja (3):
  ASoC: Davinci: McASP: add support new McASP IP Variant
  ASoC: Davinci: pcm: add support for sram-support-less platforms
  ASoC: Davinci: evm: Fix typo in cpu dai name

 .../bindings/sound/davinci-mcasp-audio.txt         |    1 +
 include/linux/platform_data/davinci_asp.h          |    1 +
 sound/soc/davinci/Kconfig                          |    5 ++
 sound/soc/davinci/davinci-evm.c                    |    2 +-
 sound/soc/davinci/davinci-mcasp.c                  |   71 ++++++++++++++++----
 sound/soc/davinci/davinci-pcm.c                    |    8 ++
 6 files changed, 74 insertions(+), 14 deletions(-)

[PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

The OMAP2+ variant of McASP is different from Davinci variant w.r.to
some register offset.

Changes
- Add new MCASP_VERSION_3 to identify new variant. New DT compatible
  "ti,omap2-mcasp-audio" to identify version 3 controller.
- The register offsets are handled depending on the version.

Note:
    DMA parameters (dma fifo offset) are not updated and will be done later.

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
---
:100644 100644 e6148ec... 374e145... M	Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
:100644 100644 79c26aa... d0c5825... M	include/linux/platform_data/davinci_asp.h
:100644 100644 c3eae1d... bb6ae9d... M	sound/soc/davinci/davinci-mcasp.c
 .../bindings/sound/davinci-mcasp-audio.txt         |    1 +
 include/linux/platform_data/davinci_asp.h          |    1 +
 sound/soc/davinci/davinci-mcasp.c                  |   71 ++++++++++++++++----
 3 files changed, 60 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index e6148ec..374e145 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible :
 	"ti,dm646x-mcasp-audio"	: for DM646x platforms
 	"ti,da830-mcasp-audio"	: for both DA830 & DA850 platforms
+	"ti,omap2-mcasp-audio"	: for OMAP2 platforms (TI81xx, AM33xx)
 
 - reg : Should contain McASP registers offset and length
 - interrupts : Interrupt number for McASP
diff --git a/include/linux/platform_data/davinci_asp.h b/include/linux/platform_data/davinci_asp.h
index 79c26aa..d0c5825 100644
--- a/include/linux/platform_data/davinci_asp.h
+++ b/include/linux/platform_data/davinci_asp.h
@@ -87,6 +87,7 @@ struct snd_platform_data {
 enum {
 	MCASP_VERSION_1 = 0,	/* DM646x */
 	MCASP_VERSION_2,	/* DA8xx/OMAPL1x */
+	MCASP_VERSION_3,        /* TI81xx/AM33xx */
 };
 
 enum mcbsp_clk_input_pin {
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index c3eae1d..bb6ae9d 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -111,6 +111,10 @@
 #define DAVINCI_MCASP_WFIFOSTS		(0x1014)
 #define DAVINCI_MCASP_RFIFOCTL		(0x1018)
 #define DAVINCI_MCASP_RFIFOSTS		(0x101C)
+#define MCASP_VER3_WFIFOCTL		(0x1000)
+#define MCASP_VER3_WFIFOSTS		(0x1004)
+#define MCASP_VER3_RFIFOCTL		(0x1008)
+#define MCASP_VER3_RFIFOSTS		(0x100C)
 
 /*
  * DAVINCI_MCASP_PWREMUMGT_REG - Power Down and Emulation Management
@@ -384,18 +388,32 @@ static void davinci_mcasp_start(struct davinci_audio_dev *dev, int stream)
 {
 	if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
 		if (dev->txnumevt) {	/* enable FIFO */
-			mcasp_clr_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
+			if (dev->version == MCASP_VERSION_3) {
+				mcasp_clr_bits(dev->base + MCASP_VER3_WFIFOCTL,
 								FIFO_ENABLE);
-			mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
+				mcasp_set_bits(dev->base + MCASP_VER3_WFIFOCTL,
 								FIFO_ENABLE);
+			} else {
+				mcasp_clr_bits(dev->base +
+					DAVINCI_MCASP_WFIFOCTL,	FIFO_ENABLE);
+				mcasp_set_bits(dev->base +
+					DAVINCI_MCASP_WFIFOCTL,	FIFO_ENABLE);
+			}
 		}
 		mcasp_start_tx(dev);
 	} else {
 		if (dev->rxnumevt) {	/* enable FIFO */
-			mcasp_clr_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+			if (dev->version == MCASP_VERSION_3) {
+				mcasp_clr_bits(dev->base + MCASP_VER3_RFIFOCTL,
 								FIFO_ENABLE);
-			mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+				mcasp_set_bits(dev->base + MCASP_VER3_RFIFOCTL,
 								FIFO_ENABLE);
+			} else {
+				mcasp_clr_bits(dev->base +
+					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
+				mcasp_set_bits(dev->base +
+					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
+			}
 		}
 		mcasp_start_rx(dev);
 	}
@@ -416,14 +434,24 @@ static void mcasp_stop_tx(struct davinci_audio_dev *dev)
 static void davinci_mcasp_stop(struct davinci_audio_dev *dev, int stream)
 {
 	if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
-		if (dev->txnumevt)	/* disable FIFO */
-			mcasp_clr_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
+		if (dev->txnumevt) {	/* disable FIFO */
+			if (dev->version == MCASP_VERSION_3)
+				mcasp_clr_bits(dev->base + MCASP_VER3_WFIFOCTL,
 								FIFO_ENABLE);
+			else
+				mcasp_clr_bits(dev->base +
+					DAVINCI_MCASP_WFIFOCTL,	FIFO_ENABLE);
+		}
 		mcasp_stop_tx(dev);
 	} else {
-		if (dev->rxnumevt)	/* disable FIFO */
-			mcasp_clr_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+		if (dev->rxnumevt) {	/* disable FIFO */
+			if (dev->version == MCASP_VERSION_3)
+				mcasp_clr_bits(dev->base + MCASP_VER3_RFIFOCTL,
 								FIFO_ENABLE);
+			else
+				mcasp_clr_bits(dev->base +
+					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
+		}
 		mcasp_stop_rx(dev);
 	}
 }
@@ -622,20 +650,33 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream)
 		if (dev->txnumevt * tx_ser > 64)
 			dev->txnumevt = 1;
 
-		mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, tx_ser,
+		if (dev->version == MCASP_VERSION_3) {
+			mcasp_mod_bits(dev->base + MCASP_VER3_WFIFOCTL, tx_ser,
 								NUMDMA_MASK);
-		mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
+			mcasp_mod_bits(dev->base + MCASP_VER3_WFIFOCTL,
+				((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK);
+		} else {
+			mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
+							tx_ser,	NUMDMA_MASK);
+			mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
 				((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK);
+		}
 	}
 
 	if (dev->rxnumevt && stream == SNDRV_PCM_STREAM_CAPTURE) {
 		if (dev->rxnumevt * rx_ser > 64)
 			dev->rxnumevt = 1;
-
-		mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, rx_ser,
+		if (dev->version == MCASP_VERSION_3) {
+			mcasp_mod_bits(dev->base + MCASP_VER3_RFIFOCTL, rx_ser,
 								NUMDMA_MASK);
-		mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+			mcasp_mod_bits(dev->base + MCASP_VER3_RFIFOCTL,
 				((dev->rxnumevt * rx_ser) << 8), NUMEVT_MASK);
+		} else {
+			mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+							rx_ser,	NUMDMA_MASK);
+			mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
+				((dev->rxnumevt * rx_ser) << 8), NUMEVT_MASK);
+		}
 	}
 }
 
@@ -874,6 +915,10 @@ static const struct of_device_id mcasp_dt_ids[] = {
 		.compatible = "ti,da830-mcasp-audio",
 		.data = (void *)MCASP_VERSION_2,
 	},
+	{
+		.compatible = "ti,omap2-mcasp-audio",
+		.data = (void *)MCASP_VERSION_3,
+	},
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, mcasp_dt_ids);
-- 
1.7.1

[PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Mark Brown]

On Fri, Aug 31, 2012 at 06:20:57PM +0530, Hebbar, Gururaja wrote:

> +			if (dev->version == MCASP_VERSION_3) {
> +				mcasp_clr_bits(dev->base + MCASP_VER3_RFIFOCTL,
>  								FIFO_ENABLE);
> -			mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
> +				mcasp_set_bits(dev->base + MCASP_VER3_RFIFOCTL,
>  								FIFO_ENABLE);
> +			} else {
> +				mcasp_clr_bits(dev->base +
> +					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
> +				mcasp_set_bits(dev->base +
> +					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
> +			}

This is all basically OK but it seems like it'd be better if all these
dev->version checks were switch statements.  That way when the hardware
designers get bored and add version 4 of the register map it'll slot in
naturally, and it'll be more clear what the code currently handles.

[PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

On Sat, Sep 01, 2012 at 06:14:44, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:57PM +0530, Hebbar, Gururaja wrote:
> 
> > +			if (dev->version == MCASP_VERSION_3) {
> > +				mcasp_clr_bits(dev->base + MCASP_VER3_RFIFOCTL,
> >  								FIFO_ENABLE);
> > -			mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
> > +				mcasp_set_bits(dev->base + MCASP_VER3_RFIFOCTL,
> >  								FIFO_ENABLE);
> > +			} else {
> > +				mcasp_clr_bits(dev->base +
> > +					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
> > +				mcasp_set_bits(dev->base +
> > +					DAVINCI_MCASP_RFIFOCTL,	FIFO_ENABLE);
> > +			}
> 
> This is all basically OK but it seems like it'd be better if all these
> dev->version checks were switch statements.  That way when the hardware
> designers get bored and add version 4 of the register map it'll slot in
> naturally, and it'll be more clear what the code currently handles.

Ok I will update this. Since 3/3 is already accepted & I don?t see any reviews
for 2/3, I will only resend this patch (1/3). Is it ok?

> 


Regards, 
Gururaja

[PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Mark Brown]

On Mon, Sep 03, 2012 at 06:57:22AM +0000, Hebbar, Gururaja wrote:

> Ok I will update this. Since 3/3 is already accepted & I don?t see any reviews
> for 2/3, I will only resend this patch (1/3). Is it ok?

Yes.

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Hebbar, Gururaja]

OMAP2+ platforms (like TI81xx, AM33xx) uses davinci-pcm driver. SRAM is
not needed/used in EDMA transfers for audio on such platforms. However
they do not provide generic SRAM APIs (sram_alloc() and sram_free()). In
such cases the pcm driver cannot be used directly as it results in
compilation failure on OMAP2 platforms.

Fix this by providing a config option to indicate missing SRAM API
support. This config is enabled by default on Davinci platform so as to
not break existing platforms. For OMAP2+ platforms, the config is
disabled.

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
---
:100644 100644 9e11a14... 328b463... M	sound/soc/davinci/Kconfig
:100644 100644 93ea3bf... 7ac5a19... M	sound/soc/davinci/davinci-pcm.c
 sound/soc/davinci/Kconfig       |    5 +++++
 sound/soc/davinci/davinci-pcm.c |    8 ++++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 9e11a14..328b463 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -15,6 +15,11 @@ config SND_DAVINCI_SOC_MCASP
 config SND_DAVINCI_SOC_VCIF
 	tristate
 
+config SND_DAVINCI_HAVE_SRAM
+	bool
+	default y if ARCH_DAVINCI=y
+	default n if ARCH_OMAP=y
+
 config SND_DAVINCI_SOC_EVM
 	tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM"
 	depends on SND_DAVINCI_SOC
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index 93ea3bf..7ac5a19 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -23,7 +23,9 @@
 #include <sound/soc.h>
 
 #include <asm/dma.h>
+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
 #include <mach/sram.h>
+#endif
 
 #include "davinci-pcm.h"
 
@@ -259,6 +261,7 @@ static void davinci_pcm_dma_irq(unsigned link, u16 ch_status, void *data)
 	}
 }
 
+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
 static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 		struct snd_pcm_hardware *ppcm)
 {
@@ -289,6 +292,7 @@ exit2:
 exit1:
 	return -ENOMEM;
 }
+#endif
 
 /*
  * Only used with ping/pong.
@@ -676,7 +680,9 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream)
 
 	ppcm = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ?
 			&pcm_hardware_playback : &pcm_hardware_capture;
+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
 	allocate_sram(substream, params->sram_size, ppcm);
+#endif
 	snd_soc_set_runtime_hwparams(substream, ppcm);
 	/* ensure that buffer size is a multiple of period size */
 	ret = snd_pcm_hw_constraint_integer(runtime,
@@ -817,11 +823,13 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
 		dma_free_writecombine(pcm->card->dev, buf->bytes,
 				      buf->area, buf->addr);
 		buf->area = NULL;
+#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
 		iram_dma = buf->private_data;
 		if (iram_dma) {
 			sram_free(iram_dma->area, iram_dma->bytes);
 			kfree(iram_dma);
 		}
+#endif
 	}
 }
 
-- 
1.7.1

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Hebbar, Gururaja]

On Fri, Aug 31, 2012 at 18:20:58, Hebbar, Gururaja wrote:
> OMAP2+ platforms (like TI81xx, AM33xx) uses davinci-pcm driver. SRAM is
> not needed/used in EDMA transfers for audio on such platforms. However
> they do not provide generic SRAM APIs (sram_alloc() and sram_free()). In
> such cases the pcm driver cannot be used directly as it results in
> compilation failure on OMAP2 platforms.
> 
> Fix this by providing a config option to indicate missing SRAM API
> support. This config is enabled by default on Davinci platform so as to
> not break existing platforms. For OMAP2+ platforms, the config is
> disabled.

Gentle ping. Is there any comments/review for this patch? 
If not, can this be pulled in?

> 
> Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
> ---
> :100644 100644 9e11a14... 328b463... M	sound/soc/davinci/Kconfig
> :100644 100644 93ea3bf... 7ac5a19... M	sound/soc/davinci/davinci-pcm.c
>  sound/soc/davinci/Kconfig       |    5 +++++
>  sound/soc/davinci/davinci-pcm.c |    8 ++++++++
>  2 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
> index 9e11a14..328b463 100644
> --- a/sound/soc/davinci/Kconfig
> +++ b/sound/soc/davinci/Kconfig
> @@ -15,6 +15,11 @@ config SND_DAVINCI_SOC_MCASP
>  config SND_DAVINCI_SOC_VCIF
>  	tristate
>  
> +config SND_DAVINCI_HAVE_SRAM
> +	bool
> +	default y if ARCH_DAVINCI=y
> +	default n if ARCH_OMAP=y
> +
>  config SND_DAVINCI_SOC_EVM
>  	tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM"
>  	depends on SND_DAVINCI_SOC
> diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
> index 93ea3bf..7ac5a19 100644
> --- a/sound/soc/davinci/davinci-pcm.c
> +++ b/sound/soc/davinci/davinci-pcm.c
> @@ -23,7 +23,9 @@
>  #include <sound/soc.h>
>  
>  #include <asm/dma.h>
> +#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
>  #include <mach/sram.h>
> +#endif
>  
>  #include "davinci-pcm.h"
>  
> @@ -259,6 +261,7 @@ static void davinci_pcm_dma_irq(unsigned link, u16 ch_status, void *data)
>  	}
>  }
>  
> +#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
>  static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
>  		struct snd_pcm_hardware *ppcm)
>  {
> @@ -289,6 +292,7 @@ exit2:
>  exit1:
>  	return -ENOMEM;
>  }
> +#endif
>  
>  /*
>   * Only used with ping/pong.
> @@ -676,7 +680,9 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream)
>  
>  	ppcm = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ?
>  			&pcm_hardware_playback : &pcm_hardware_capture;
> +#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
>  	allocate_sram(substream, params->sram_size, ppcm);
> +#endif
>  	snd_soc_set_runtime_hwparams(substream, ppcm);
>  	/* ensure that buffer size is a multiple of period size */
>  	ret = snd_pcm_hw_constraint_integer(runtime,
> @@ -817,11 +823,13 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
>  		dma_free_writecombine(pcm->card->dev, buf->bytes,
>  				      buf->area, buf->addr);
>  		buf->area = NULL;
> +#if defined(CONFIG_SND_DAVINCI_HAVE_SRAM)
>  		iram_dma = buf->private_data;
>  		if (iram_dma) {
>  			sram_free(iram_dma->area, iram_dma->bytes);
>  			kfree(iram_dma);
>  		}
> +#endif
>  	}
>  }
>  
> -- 
> 1.7.1
> 
> 


Regards, 
Gururaja

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Mark Brown]

On Wed, Sep 12, 2012 at 07:50:31AM +0000, Hebbar, Gururaja wrote:

> Gentle ping. Is there any comments/review for this patch? 
> If not, can this be pulled in?

Don't send contentless quoted pings.

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Mark Brown]

On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:

> +config SND_DAVINCI_HAVE_SRAM
> +	bool
> +	default y if ARCH_DAVINCI=y
> +	default n if ARCH_OMAP=y
> +

I've been sitting on this mostly since it seems like a step back from
multi-platform kernels (which is where we're trying to get to) and I've
been trying to decide what the best approach is.  I'm thinking that we
do want a generic API for allocating this stuff, it's a fairly generic
feature (there's TCMs as well).  

Adding ifdefs like this does just doesn't seem good.

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Hebbar, Gururaja]

On Sat, Sep 22, 2012 at 21:03:14, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> 
> > +config SND_DAVINCI_HAVE_SRAM
> > +	bool
> > +	default y if ARCH_DAVINCI=y
> > +	default n if ARCH_OMAP=y
> > +
> 
> I've been sitting on this mostly since it seems like a step back from
> multi-platform kernels (which is where we're trying to get to) and I've
> been trying to decide what the best approach is.  I'm thinking that we
> do want a generic API for allocating this stuff, it's a fairly generic
> feature (there's TCMs as well).  
> 
> Adding ifdefs like this does just doesn't seem good.
> 

I have no knowledge about multi-platform builds yet.

Currently this driver is shared between OMAP & DaVinci and both of them 
doesn't exist in single image build.

There was a effort done for this SRAM Consolidation [1] but it didn't progress.
Hence I took this approach as a time-being/workaround. This was we can get 
affected platforms (like AM335x) get going/working.


[1]. http://patchwork.ozlabs.org/patch/104059/

Regards, 
Gururaja

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Mark Brown]

On Thu, Sep 27, 2012 at 06:57:49AM +0000, Hebbar, Gururaja wrote:

> I have no knowledge about multi-platform builds yet.

> Currently this driver is shared between OMAP & DaVinci and both of them 
> doesn't exist in single image build.

...due to issues like having compile time things selecting between the
platforms.  In other words what these ifdefs would do is move us further
away from that goal rather than towards it as we should be doing.

> There was a effort done for this SRAM Consolidation [1] but it didn't progress.
> Hence I took this approach as a time-being/workaround. This was we can get 
> affected platforms (like AM335x) get going/working.

Looks like it just needs more people pushing it...

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Peter Ujfalusi]

On 09/22/2012 06:33 PM, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> 
>> +config SND_DAVINCI_HAVE_SRAM
>> +	bool
>> +	default y if ARCH_DAVINCI=y
>> +	default n if ARCH_OMAP=y
>> +
> 
> I've been sitting on this mostly since it seems like a step back from
> multi-platform kernels (which is where we're trying to get to) and I've
> been trying to decide what the best approach is.  I'm thinking that we
> do want a generic API for allocating this stuff, it's a fairly generic
> feature (there's TCMs as well).  
> 
> Adding ifdefs like this does just doesn't seem good.

I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.

-- 
P?ter

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Mark Brown]

On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:

> I also agree that ifdef is not a good solution.
> It is better to have this information passed as device_data and via DT it can
> be decided based on the compatible property for the device.

That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms.  The SRAM code needs to move to a standard API.

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 02.10.2012 11:37, Mark Brown wrote:
> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> 
>> I also agree that ifdef is not a good solution.
>> It is better to have this information passed as device_data and via DT it can
>> be decided based on the compatible property for the device.
> 
> That's not really the problem here - the problem is that the APIs used
> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> or other platforms.  The SRAM code needs to move to a standard API.

What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.

Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.


Daniel

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Sekhar Nori]

On 10/2/2012 4:03 PM, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>
>>> I also agree that ifdef is not a good solution.
>>> It is better to have this information passed as device_data and via DT it can
>>> be decided based on the compatible property for the device.
>>
>> That's not really the problem here - the problem is that the APIs used
>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>> or other platforms.  The SRAM code needs to move to a standard API.
> 
> What about following Matt Porter's idea and ignore the SRAM code
> entirely and port the entire PCM code to generic dmaengine code first?
> The EDMA driver needs to learn support for cyclic DMA for that, and I
> might give that a try in near future.
> 
> Later on, the SRAM ping-pong code can get added back using genalloc
> functions, as Sekhar proposed. That needs to be done by someone who has
> access to a Davinci board though, I only have a AM33xx/OMAP here.

We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?

Thanks,
Sekhar

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 02.10.2012 13:06, Sekhar Nori wrote:
> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>> On 02.10.2012 11:37, Mark Brown wrote:
>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>
>>>> I also agree that ifdef is not a good solution.
>>>> It is better to have this information passed as device_data and via DT it can
>>>> be decided based on the compatible property for the device.
>>>
>>> That's not really the problem here - the problem is that the APIs used
>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>> or other platforms.  The SRAM code needs to move to a standard API.
>>
>> What about following Matt Porter's idea and ignore the SRAM code
>> entirely and port the entire PCM code to generic dmaengine code first?
>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>> might give that a try in near future.
>>
>> Later on, the SRAM ping-pong code can get added back using genalloc
>> functions, as Sekhar proposed. That needs to be done by someone who has
>> access to a Davinci board though, I only have a AM33xx/OMAP here.
> 
> We cannot "get rid" of SRAM code and add it back "later". It is required
> for most DaVinci parts. The SRAM code can be converted to use genalloc
> (conversion should be straightforward and I can help test it) and the
> code that uses SRAM can probably keep using the private EDMA API till
> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> posted patches to move private EDMA APIs to a common location. That
> should keep AM335x build from breaking. Is this something that is feasible?

Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.

I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.

Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.

Is there a better way that I miss?


Daniel

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Matt Porter]

On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> On 02.10.2012 13:06, Sekhar Nori wrote:
> > On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >> On 02.10.2012 11:37, Mark Brown wrote:
> >>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>
> >>>> I also agree that ifdef is not a good solution.
> >>>> It is better to have this information passed as device_data and via DT it can
> >>>> be decided based on the compatible property for the device.
> >>>
> >>> That's not really the problem here - the problem is that the APIs used
> >>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>> or other platforms.  The SRAM code needs to move to a standard API.
> >>
> >> What about following Matt Porter's idea and ignore the SRAM code
> >> entirely and port the entire PCM code to generic dmaengine code first?
> >> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >> might give that a try in near future.
> >>
> >> Later on, the SRAM ping-pong code can get added back using genalloc
> >> functions, as Sekhar proposed. That needs to be done by someone who has
> >> access to a Davinci board though, I only have a AM33xx/OMAP here.
> > 
> > We cannot "get rid" of SRAM code and add it back "later". It is required
> > for most DaVinci parts. The SRAM code can be converted to use genalloc
> > (conversion should be straightforward and I can help test it) and the
> > code that uses SRAM can probably keep using the private EDMA API till
> > the dmaengine EDMA driver has cyclic DMA support. Matt has already
> > posted patches to move private EDMA APIs to a common location. That
> > should keep AM335x build from breaking. Is this something that is feasible?
> 
> Yes - by "later" I just meant in a subsequent patch. But you're probably
> right, we can also do that first.
> 
> I'm looking at that right now and the problem seems that we don't have a
> sane way to dynamically look up gen_pools independently of the actual
> run-time platform. All users of gen_pools seem to know which platform
> they run on and access a platform-specific pool. So I don't currently
> see how we could implement multi-platform code, gen_pools are fine but
> don't solve the problem here.
> 
> Would it be an idea to add a char* member to gen_pools and a function
> that can be used to dynamically look it up again? If a buffer with a
> certain name exists, we can use it and install that ping-pong buffer,
> otherwise we just don't. While that would be easy to do, it's a
> tree-wide change.
> 
> Is there a better way that I miss?

At the high level there's two platform models we have to handle, the
boot from board file !DT case, and then the boot from DT case. Since
Davinci is just starting DT conversion, we mostly care about the !DT
base in which the struct gen_pool * is passed in pdata to the ASoC
driver. It is then selectable on a per-platform basis where the decision
should be made.

Given a separate discussion with Sekhar, we're only going to have one
SRAM pool on any DaVinci part right now...this was only a question on
L138 anyway. But regardless, the created gen_pool will be passed via
pdata. Since DT conversion is starting and we need to consider that now,
the idea there is to use the DT-based generic sram driver [1] such that
when we do boot from DT on Davinci, the genpool is provided via phandle
and the pointer extracted with the OF helpers that are part of the
series.

That's pretty much it. I'm reworking the backend support as discussed
with Sekhar wrt to my uio_pruss series. I can post a standalone series
that just replaces sram_* with genalloc for davinci ASoC.

-Matt

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 02.10.2012 18:41, Matt Porter wrote:
> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>
>>>>>> I also agree that ifdef is not a good solution.
>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>> be decided based on the compatible property for the device.
>>>>>
>>>>> That's not really the problem here - the problem is that the APIs used
>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>> or other platforms.  The SRAM code needs to move to a standard API.
>>>>
>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>> might give that a try in near future.
>>>>
>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>
>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>> (conversion should be straightforward and I can help test it) and the
>>> code that uses SRAM can probably keep using the private EDMA API till
>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>> posted patches to move private EDMA APIs to a common location. That
>>> should keep AM335x build from breaking. Is this something that is feasible?
>>
>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>> right, we can also do that first.
>>
>> I'm looking at that right now and the problem seems that we don't have a
>> sane way to dynamically look up gen_pools independently of the actual
>> run-time platform. All users of gen_pools seem to know which platform
>> they run on and access a platform-specific pool. So I don't currently
>> see how we could implement multi-platform code, gen_pools are fine but
>> don't solve the problem here.
>>
>> Would it be an idea to add a char* member to gen_pools and a function
>> that can be used to dynamically look it up again? If a buffer with a
>> certain name exists, we can use it and install that ping-pong buffer,
>> otherwise we just don't. While that would be easy to do, it's a
>> tree-wide change.
>>
>> Is there a better way that I miss?
> 
> At the high level there's two platform models we have to handle, the
> boot from board file !DT case, and then the boot from DT case. Since
> Davinci is just starting DT conversion, we mostly care about the !DT
> base in which the struct gen_pool * is passed in pdata to the ASoC
> driver. It is then selectable on a per-platform basis where the decision
> should be made.
> 
> Given a separate discussion with Sekhar, we're only going to have one
> SRAM pool on any DaVinci part right now...this was only a question on
> L138 anyway. But regardless, the created gen_pool will be passed via
> pdata.

I thought about this too, as mmp does it that way.

> Since DT conversion is starting and we need to consider that now,
> the idea there is to use the DT-based generic sram driver [1] such that
> when we do boot from DT on Davinci, the genpool is provided via phandle
> and the pointer extracted with the OF helpers that are part of the
> series.

A phandle is the cleanest way I think, yes.

> That's pretty much it. I'm reworking the backend support as discussed
> with Sekhar wrt to my uio_pruss series. I can post a standalone series
> that just replaces sram_* with genalloc for davinci ASoC.

As you can also test it, it would be easiest if you came up with a patch
for that, yes. I can have a look at the dma bits laters, once my OMAP
board finally works with the code as it currently stands. I'm still
fighting with the mcasp driver right now ...


Daniel

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Matt Porter]

On Tue, Oct 02, 2012 at 06:50:14PM +0200, Daniel Mack wrote:
> On 02.10.2012 18:41, Matt Porter wrote:
> > On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> >> On 02.10.2012 13:06, Sekhar Nori wrote:
> >>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >>>> On 02.10.2012 11:37, Mark Brown wrote:
> >>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>>>
> >>>>>> I also agree that ifdef is not a good solution.
> >>>>>> It is better to have this information passed as device_data and via DT it can
> >>>>>> be decided based on the compatible property for the device.
> >>>>>
> >>>>> That's not really the problem here - the problem is that the APIs used
> >>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>>>> or other platforms.  The SRAM code needs to move to a standard API.
> >>>>
> >>>> What about following Matt Porter's idea and ignore the SRAM code
> >>>> entirely and port the entire PCM code to generic dmaengine code first?
> >>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >>>> might give that a try in near future.
> >>>>
> >>>> Later on, the SRAM ping-pong code can get added back using genalloc
> >>>> functions, as Sekhar proposed. That needs to be done by someone who has
> >>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
> >>>
> >>> We cannot "get rid" of SRAM code and add it back "later". It is required
> >>> for most DaVinci parts. The SRAM code can be converted to use genalloc
> >>> (conversion should be straightforward and I can help test it) and the
> >>> code that uses SRAM can probably keep using the private EDMA API till
> >>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> >>> posted patches to move private EDMA APIs to a common location. That
> >>> should keep AM335x build from breaking. Is this something that is feasible?
> >>
> >> Yes - by "later" I just meant in a subsequent patch. But you're probably
> >> right, we can also do that first.
> >>
> >> I'm looking at that right now and the problem seems that we don't have a
> >> sane way to dynamically look up gen_pools independently of the actual
> >> run-time platform. All users of gen_pools seem to know which platform
> >> they run on and access a platform-specific pool. So I don't currently
> >> see how we could implement multi-platform code, gen_pools are fine but
> >> don't solve the problem here.
> >>
> >> Would it be an idea to add a char* member to gen_pools and a function
> >> that can be used to dynamically look it up again? If a buffer with a
> >> certain name exists, we can use it and install that ping-pong buffer,
> >> otherwise we just don't. While that would be easy to do, it's a
> >> tree-wide change.
> >>
> >> Is there a better way that I miss?
> > 
> > At the high level there's two platform models we have to handle, the
> > boot from board file !DT case, and then the boot from DT case. Since
> > Davinci is just starting DT conversion, we mostly care about the !DT
> > base in which the struct gen_pool * is passed in pdata to the ASoC
> > driver. It is then selectable on a per-platform basis where the decision
> > should be made.
> > 
> > Given a separate discussion with Sekhar, we're only going to have one
> > SRAM pool on any DaVinci part right now...this was only a question on
> > L138 anyway. But regardless, the created gen_pool will be passed via
> > pdata.
> 
> I thought about this too, as mmp does it that way.
> 
> > Since DT conversion is starting and we need to consider that now,
> > the idea there is to use the DT-based generic sram driver [1] such that
> > when we do boot from DT on Davinci, the genpool is provided via phandle
> > and the pointer extracted with the OF helpers that are part of the
> > series.
> 
> A phandle is the cleanest way I think, yes.

See the of_get_named_gen_pool() helper example in the series
http://comments.gmane.org/gmane.linux.kernel/1352210

> > That's pretty much it. I'm reworking the backend support as discussed
> > with Sekhar wrt to my uio_pruss series. I can post a standalone series
> > that just replaces sram_* with genalloc for davinci ASoC.
> 
> As you can also test it, it would be easiest if you came up with a patch
> for that, yes. I can have a look at the dma bits laters, once my OMAP
> board finally works with the code as it currently stands. I'm still
> fighting with the mcasp driver right now ...

Ok. Also, as Sekhar pointed out, dmaengine itself isn't a blocker since
we can have AM33xx use the private EDMA API for ASoC until I finish
cyclic DMA support. Handling the ping-pong and normal case transparently
within the dmaengine driver will require a further look but at least
genalloc is our first step there.

-Matt

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 02.10.2012 18:50, Daniel Mack wrote:
> On 02.10.2012 18:41, Matt Porter wrote:
>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>
>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>> be decided based on the compatible property for the device.
>>>>>>
>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>> or other platforms.  The SRAM code needs to move to a standard API.
>>>>>
>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>> might give that a try in near future.
>>>>>
>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>
>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>> (conversion should be straightforward and I can help test it) and the
>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>> posted patches to move private EDMA APIs to a common location. That
>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>
>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>> right, we can also do that first.
>>>
>>> I'm looking at that right now and the problem seems that we don't have a
>>> sane way to dynamically look up gen_pools independently of the actual
>>> run-time platform. All users of gen_pools seem to know which platform
>>> they run on and access a platform-specific pool. So I don't currently
>>> see how we could implement multi-platform code, gen_pools are fine but
>>> don't solve the problem here.
>>>
>>> Would it be an idea to add a char* member to gen_pools and a function
>>> that can be used to dynamically look it up again? If a buffer with a
>>> certain name exists, we can use it and install that ping-pong buffer,
>>> otherwise we just don't. While that would be easy to do, it's a
>>> tree-wide change.
>>>
>>> Is there a better way that I miss?
>>
>> At the high level there's two platform models we have to handle, the
>> boot from board file !DT case, and then the boot from DT case. Since
>> Davinci is just starting DT conversion, we mostly care about the !DT
>> base in which the struct gen_pool * is passed in pdata to the ASoC
>> driver. It is then selectable on a per-platform basis where the decision
>> should be made.
>>
>> Given a separate discussion with Sekhar, we're only going to have one
>> SRAM pool on any DaVinci part right now...this was only a question on
>> L138 anyway. But regardless, the created gen_pool will be passed via
>> pdata.
> 
> I thought about this too, as mmp does it that way.
> 
>> Since DT conversion is starting and we need to consider that now,
>> the idea there is to use the DT-based generic sram driver [1] such that
>> when we do boot from DT on Davinci, the genpool is provided via phandle
>> and the pointer extracted with the OF helpers that are part of the
>> series.
> 
> A phandle is the cleanest way I think, yes.
> 
>> That's pretty much it. I'm reworking the backend support as discussed
>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>> that just replaces sram_* with genalloc for davinci ASoC.
> 
> As you can also test it, it would be easiest if you came up with a patch
> for that, yes. I can have a look at the dma bits laters, once my OMAP
> board finally works with the code as it currently stands. I'm still
> fighting with the mcasp driver right now ...

I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).


Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-davinci-pass-SRAM-gen_pool-to-mcasp-platform-dat.patch
Type: text/x-patch
Size: 8048 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ALSA-ASoC-McASP-use-gen_pool-from-platform-data.patch
Type: text/x-patch
Size: 4201 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0003.bin>

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Porter, Matt]

On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:

> 
> 
> On 02.10.2012 18:50, Daniel Mack wrote:
>> On 02.10.2012 18:41, Matt Porter wrote:
>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>> 
>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>> be decided based on the compatible property for the device.
>>>>>>> 
>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>> or other platforms.  The SRAM code needs to move to a standard API.
>>>>>> 
>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>> might give that a try in near future.
>>>>>> 
>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>> 
>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>> (conversion should be straightforward and I can help test it) and the
>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>> 
>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>> right, we can also do that first.
>>>> 
>>>> I'm looking at that right now and the problem seems that we don't have a
>>>> sane way to dynamically look up gen_pools independently of the actual
>>>> run-time platform. All users of gen_pools seem to know which platform
>>>> they run on and access a platform-specific pool. So I don't currently
>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>> don't solve the problem here.
>>>> 
>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>> that can be used to dynamically look it up again? If a buffer with a
>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>> otherwise we just don't. While that would be easy to do, it's a
>>>> tree-wide change.
>>>> 
>>>> Is there a better way that I miss?
>>> 
>>> At the high level there's two platform models we have to handle, the
>>> boot from board file !DT case, and then the boot from DT case. Since
>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>> driver. It is then selectable on a per-platform basis where the decision
>>> should be made.
>>> 
>>> Given a separate discussion with Sekhar, we're only going to have one
>>> SRAM pool on any DaVinci part right now...this was only a question on
>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>> pdata.
>> 
>> I thought about this too, as mmp does it that way.
>> 
>>> Since DT conversion is starting and we need to consider that now,
>>> the idea there is to use the DT-based generic sram driver [1] such that
>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>> and the pointer extracted with the OF helpers that are part of the
>>> series.
>> 
>> A phandle is the cleanest way I think, yes.
>> 
>>> That's pretty much it. I'm reworking the backend support as discussed
>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>> that just replaces sram_* with genalloc for davinci ASoC.
>> 
>> As you can also test it, it would be easiest if you came up with a patch
>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>> board finally works with the code as it currently stands. I'm still
>> fighting with the mcasp driver right now ...
> 
> I quickly prepared two patches to change that, so that topic is out of
> the way. But I did only compile-test them on OMAP - could you check on
> your Davinci platform? Note that these apply on top of the patch in
> discussion here (which isn't applied to the asoc tree yet).

I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).

I'll take a look a your OMAP patches.

-Matt

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 04.10.2012 11:38, Porter, Matt wrote:
> 
> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
> 
>>
>>
>> On 02.10.2012 18:50, Daniel Mack wrote:
>>> On 02.10.2012 18:41, Matt Porter wrote:
>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>>
>>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>>> be decided based on the compatible property for the device.
>>>>>>>>
>>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>>> or other platforms.  The SRAM code needs to move to a standard API.
>>>>>>>
>>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>>> might give that a try in near future.
>>>>>>>
>>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>>>
>>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>>> (conversion should be straightforward and I can help test it) and the
>>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>>>
>>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>>> right, we can also do that first.
>>>>>
>>>>> I'm looking at that right now and the problem seems that we don't have a
>>>>> sane way to dynamically look up gen_pools independently of the actual
>>>>> run-time platform. All users of gen_pools seem to know which platform
>>>>> they run on and access a platform-specific pool. So I don't currently
>>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>>> don't solve the problem here.
>>>>>
>>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>>> that can be used to dynamically look it up again? If a buffer with a
>>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>>> otherwise we just don't. While that would be easy to do, it's a
>>>>> tree-wide change.
>>>>>
>>>>> Is there a better way that I miss?
>>>>
>>>> At the high level there's two platform models we have to handle, the
>>>> boot from board file !DT case, and then the boot from DT case. Since
>>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>>> driver. It is then selectable on a per-platform basis where the decision
>>>> should be made.
>>>>
>>>> Given a separate discussion with Sekhar, we're only going to have one
>>>> SRAM pool on any DaVinci part right now...this was only a question on
>>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>>> pdata.
>>>
>>> I thought about this too, as mmp does it that way.
>>>
>>>> Since DT conversion is starting and we need to consider that now,
>>>> the idea there is to use the DT-based generic sram driver [1] such that
>>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>>> and the pointer extracted with the OF helpers that are part of the
>>>> series.
>>>
>>> A phandle is the cleanest way I think, yes.
>>>
>>>> That's pretty much it. I'm reworking the backend support as discussed
>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>>> that just replaces sram_* with genalloc for davinci ASoC.
>>>
>>> As you can also test it, it would be easiest if you came up with a patch
>>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>>> board finally works with the code as it currently stands. I'm still
>>> fighting with the mcasp driver right now ...
>>
>> I quickly prepared two patches to change that, so that topic is out of
>> the way. But I did only compile-test them on OMAP - could you check on
>> your Davinci platform? Note that these apply on top of the patch in
>> discussion here (which isn't applied to the asoc tree yet).
> 
> I put a series together yesterday, just ran out of time to post
> last night after testing. I'm posting that now...it's on top of my
> uio_pruss/genalloc series and only addresss switching davinci-pcm to
> genalloc (and actually enabling ping-pon from sram).

Ok, I don't care which version makes it in after all :)

> I'll take a look a your OMAP patches.

The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.


Daniel

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Matt Porter]

On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
> On 04.10.2012 11:38, Porter, Matt wrote:
> > 
> > On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
> > 
> >>
> >>
> >> On 02.10.2012 18:50, Daniel Mack wrote:
> >>> On 02.10.2012 18:41, Matt Porter wrote:
> >>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> >>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
> >>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
> >>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>>>>>>
> >>>>>>>>> I also agree that ifdef is not a good solution.
> >>>>>>>>> It is better to have this information passed as device_data and via DT it can
> >>>>>>>>> be decided based on the compatible property for the device.
> >>>>>>>>
> >>>>>>>> That's not really the problem here - the problem is that the APIs used
> >>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>>>>>>> or other platforms.  The SRAM code needs to move to a standard API.
> >>>>>>>
> >>>>>>> What about following Matt Porter's idea and ignore the SRAM code
> >>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
> >>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >>>>>>> might give that a try in near future.
> >>>>>>>
> >>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
> >>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
> >>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
> >>>>>>
> >>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
> >>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
> >>>>>> (conversion should be straightforward and I can help test it) and the
> >>>>>> code that uses SRAM can probably keep using the private EDMA API till
> >>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> >>>>>> posted patches to move private EDMA APIs to a common location. That
> >>>>>> should keep AM335x build from breaking. Is this something that is feasible?
> >>>>>
> >>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
> >>>>> right, we can also do that first.
> >>>>>
> >>>>> I'm looking at that right now and the problem seems that we don't have a
> >>>>> sane way to dynamically look up gen_pools independently of the actual
> >>>>> run-time platform. All users of gen_pools seem to know which platform
> >>>>> they run on and access a platform-specific pool. So I don't currently
> >>>>> see how we could implement multi-platform code, gen_pools are fine but
> >>>>> don't solve the problem here.
> >>>>>
> >>>>> Would it be an idea to add a char* member to gen_pools and a function
> >>>>> that can be used to dynamically look it up again? If a buffer with a
> >>>>> certain name exists, we can use it and install that ping-pong buffer,
> >>>>> otherwise we just don't. While that would be easy to do, it's a
> >>>>> tree-wide change.
> >>>>>
> >>>>> Is there a better way that I miss?
> >>>>
> >>>> At the high level there's two platform models we have to handle, the
> >>>> boot from board file !DT case, and then the boot from DT case. Since
> >>>> Davinci is just starting DT conversion, we mostly care about the !DT
> >>>> base in which the struct gen_pool * is passed in pdata to the ASoC
> >>>> driver. It is then selectable on a per-platform basis where the decision
> >>>> should be made.
> >>>>
> >>>> Given a separate discussion with Sekhar, we're only going to have one
> >>>> SRAM pool on any DaVinci part right now...this was only a question on
> >>>> L138 anyway. But regardless, the created gen_pool will be passed via
> >>>> pdata.
> >>>
> >>> I thought about this too, as mmp does it that way.
> >>>
> >>>> Since DT conversion is starting and we need to consider that now,
> >>>> the idea there is to use the DT-based generic sram driver [1] such that
> >>>> when we do boot from DT on Davinci, the genpool is provided via phandle
> >>>> and the pointer extracted with the OF helpers that are part of the
> >>>> series.
> >>>
> >>> A phandle is the cleanest way I think, yes.
> >>>
> >>>> That's pretty much it. I'm reworking the backend support as discussed
> >>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
> >>>> that just replaces sram_* with genalloc for davinci ASoC.
> >>>
> >>> As you can also test it, it would be easiest if you came up with a patch
> >>> for that, yes. I can have a look at the dma bits laters, once my OMAP
> >>> board finally works with the code as it currently stands. I'm still
> >>> fighting with the mcasp driver right now ...
> >>
> >> I quickly prepared two patches to change that, so that topic is out of
> >> the way. But I did only compile-test them on OMAP - could you check on
> >> your Davinci platform? Note that these apply on top of the patch in
> >> discussion here (which isn't applied to the asoc tree yet).
> > 
> > I put a series together yesterday, just ran out of time to post
> > last night after testing. I'm posting that now...it's on top of my
> > uio_pruss/genalloc series and only addresss switching davinci-pcm to
> > genalloc (and actually enabling ping-pon from sram).
> 
> Ok, I don't care which version makes it in after all :)

Ok :)

> > I'll take a look a your OMAP patches.
> 
> The patches I just sent out are only for Davinci and change the SRAM
> functions to genalloc in the mcasp driver. They work just fine on OMAP
> of course, as the code is disabled in there.

Ok, same thing as I did and just sent out. These are tested on AM180x
and hook up ping-pong buffering so that there's actually one user of
all this ping-pong code. It's been sitting idle for a long time.

I didn't see your patches come by yet but will take a look to see if
we need to combine.

-Matt

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Daniel Mack]

On 04.10.2012 12:28, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
>> On 04.10.2012 11:38, Porter, Matt wrote:
>>>
>>> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
>>>
>>>>
>>>>
>>>> On 02.10.2012 18:50, Daniel Mack wrote:
>>>>> On 02.10.2012 18:41, Matt Porter wrote:
>>>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>>>>
>>>>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>>>>> be decided based on the compatible property for the device.
>>>>>>>>>>
>>>>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>>>>> or other platforms.  The SRAM code needs to move to a standard API.
>>>>>>>>>
>>>>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>>>>> might give that a try in near future.
>>>>>>>>>
>>>>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>>>>>
>>>>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>>>>> (conversion should be straightforward and I can help test it) and the
>>>>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>>>>>
>>>>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>>>>> right, we can also do that first.
>>>>>>>
>>>>>>> I'm looking at that right now and the problem seems that we don't have a
>>>>>>> sane way to dynamically look up gen_pools independently of the actual
>>>>>>> run-time platform. All users of gen_pools seem to know which platform
>>>>>>> they run on and access a platform-specific pool. So I don't currently
>>>>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>>>>> don't solve the problem here.
>>>>>>>
>>>>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>>>>> that can be used to dynamically look it up again? If a buffer with a
>>>>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>>>>> otherwise we just don't. While that would be easy to do, it's a
>>>>>>> tree-wide change.
>>>>>>>
>>>>>>> Is there a better way that I miss?
>>>>>>
>>>>>> At the high level there's two platform models we have to handle, the
>>>>>> boot from board file !DT case, and then the boot from DT case. Since
>>>>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>>>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>>>>> driver. It is then selectable on a per-platform basis where the decision
>>>>>> should be made.
>>>>>>
>>>>>> Given a separate discussion with Sekhar, we're only going to have one
>>>>>> SRAM pool on any DaVinci part right now...this was only a question on
>>>>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>>>>> pdata.
>>>>>
>>>>> I thought about this too, as mmp does it that way.
>>>>>
>>>>>> Since DT conversion is starting and we need to consider that now,
>>>>>> the idea there is to use the DT-based generic sram driver [1] such that
>>>>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>>>>> and the pointer extracted with the OF helpers that are part of the
>>>>>> series.
>>>>>
>>>>> A phandle is the cleanest way I think, yes.
>>>>>
>>>>>> That's pretty much it. I'm reworking the backend support as discussed
>>>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>>>>> that just replaces sram_* with genalloc for davinci ASoC.
>>>>>
>>>>> As you can also test it, it would be easiest if you came up with a patch
>>>>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>>>>> board finally works with the code as it currently stands. I'm still
>>>>> fighting with the mcasp driver right now ...
>>>>
>>>> I quickly prepared two patches to change that, so that topic is out of
>>>> the way. But I did only compile-test them on OMAP - could you check on
>>>> your Davinci platform? Note that these apply on top of the patch in
>>>> discussion here (which isn't applied to the asoc tree yet).
>>>
>>> I put a series together yesterday, just ran out of time to post
>>> last night after testing. I'm posting that now...it's on top of my
>>> uio_pruss/genalloc series and only addresss switching davinci-pcm to
>>> genalloc (and actually enabling ping-pon from sram).
>>
>> Ok, I don't care which version makes it in after all :)
> 
> Ok :)
> 
>>> I'll take a look a your OMAP patches.
>>
>> The patches I just sent out are only for Davinci and change the SRAM
>> functions to genalloc in the mcasp driver. They work just fine on OMAP
>> of course, as the code is disabled in there.
> 
> Ok, same thing as I did and just sent out. These are tested on AM180x
> and hook up ping-pong buffering so that there's actually one user of
> all this ping-pong code. It's been sitting idle for a long time.
> 
> I didn't see your patches come by yet but will take a look to see if
> we need to combine.

I attached them to my mail for a quick review. I wanted to queue them up
to a bigger series I'll send out later ...


Daniel

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Matt Porter]

On Tue, Oct 02, 2012 at 12:33:39PM +0200, Daniel Mack wrote:
> On 02.10.2012 11:37, Mark Brown wrote:
> > On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> > 
> >> I also agree that ifdef is not a good solution.
> >> It is better to have this information passed as device_data and via DT it can
> >> be decided based on the compatible property for the device.
> > 
> > That's not really the problem here - the problem is that the APIs used
> > to get the SRAM are DaVinci only so it's not possible to build on OMAP
> > or other platforms.  The SRAM code needs to move to a standard API.
> 
> What about following Matt Porter's idea and ignore the SRAM code
> entirely and port the entire PCM code to generic dmaengine code first?
> The EDMA driver needs to learn support for cyclic DMA for that, and I
> might give that a try in near future.
> 
> Later on, the SRAM ping-pong code can get added back using genalloc
> functions, as Sekhar proposed. That needs to be done by someone who has
> access to a Davinci board though, I only have a AM33xx/OMAP here.

I already backed away from that idea since the older SoCs without a
FIFO absolutely need ping-pong buffering in SRAM.

-Matt

[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Matt Porter]

On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> On 09/22/2012 06:33 PM, Mark Brown wrote:
> > On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> > 
> >> +config SND_DAVINCI_HAVE_SRAM
> >> +	bool
> >> +	default y if ARCH_DAVINCI=y
> >> +	default n if ARCH_OMAP=y
> >> +
> > 
> > I've been sitting on this mostly since it seems like a step back from
> > multi-platform kernels (which is where we're trying to get to) and I've
> > been trying to decide what the best approach is.  I'm thinking that we
> > do want a generic API for allocating this stuff, it's a fairly generic
> > feature (there's TCMs as well).  
> > 
> > Adding ifdefs like this does just doesn't seem good.
> 
> I also agree that ifdef is not a good solution.
> It is better to have this information passed as device_data and via DT it can
> be decided based on the compatible property for the device.

The driver is going to be used by both !DT and DT only platforms for a
while so DT-centric solutions just don't make sense. There's a clean way
to do this that was used for uio_pruss.c. When davinci is further along
on DT conversion we can make use of the devicetree-based generic sram
driver that's progressing along right now [1]. It needs some minor help
to allow specifying the gen_pool allocation order, but it will work
nicely for getting access to the right sram pool.

-Matt

[1] https://patchwork.kernel.org/patch/1421961/

[PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

[Sekhar Nori]

Hi Mark,

On 9/22/2012 9:03 PM, Mark Brown wrote:
> On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
> 
>> +config SND_DAVINCI_HAVE_SRAM
>> +	bool
>> +	default y if ARCH_DAVINCI=y
>> +	default n if ARCH_OMAP=y
>> +
> 
> I've been sitting on this mostly since it seems like a step back from
> multi-platform kernels (which is where we're trying to get to) and I've
> been trying to decide what the best approach is.  I'm thinking that we
> do want a generic API for allocating this stuff, it's a fairly generic
> feature (there's TCMs as well).  
> 
> Adding ifdefs like this does just doesn't seem good.

How about converting to use genalloc instead of the DaVinci private SRAM
API and passing the pool to be used via platform data?

Matt Porter just used this approach to make the uio PRUSS driver usable
on both DaVinci and AM335x. It suffered from the exact same problem.

https://patchwork.kernel.org/patch/1522481/

Thanks,
Sekhar

[PATCH 3/3] ASoC: Davinci: evm: Fix typo in cpu dai name

[Hebbar, Gururaja]

Fix typo caused by recent commit (cf53756 - ASoC: davinci: davinci-pcm
does not need to be a plaform_driver)

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
---
:100644 100644 ca2a547... 2864f24... M	sound/soc/davinci/davinci-evm.c
 sound/soc/davinci/davinci-evm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index ca2a547..2864f24 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -208,7 +208,7 @@ static struct snd_soc_dai_link dm365_evm_dai = {
 	.cpu_dai_name = "davinci-vcif",
 	.codec_dai_name = "cq93vc-hifi",
 	.codec_name = "cq93vc-codec",
-	.platform_name = "avinci-vcif",
+	.platform_name = "davinci-vcif",
 #endif
 };
 
-- 
1.7.1

[PATCH 3/3] ASoC: Davinci: evm: Fix typo in cpu dai name

[Mark Brown]

On Fri, Aug 31, 2012 at 06:20:59PM +0530, Hebbar, Gururaja wrote:
> Fix typo caused by recent commit (cf53756 - ASoC: davinci: davinci-pcm
> does not need to be a plaform_driver)

Applied, thanks.

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Daniel Mack]

On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> register offset and missing generic SRAM APIs support
> 
> Changes
> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
>   "ti,omap2-mcasp-audio" to identify version 3 controller.
> - The register offsets are handled depending on the version.
> - Provide a config option to indicate missing SRAM API support.

Could you give some insight which hardware this was tested on? I'm
trying to get this up and running on a AM33xx board, and the patches
look all reasonable to me. My problem is that I can't make the DMA
engine move forward, I fail to receive a single interrupt on this
peripheral after the stream starts. I will continue searching for the
reason of this tomorrow, but maybe you can give me some hint by
explaining your setup?

Note that I'm using your patches together with Matt's from this series:

  https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1

... but it doesn't work without those either.



Thanks,
Daniel

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> > The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> > register offset and missing generic SRAM APIs support
> > 
> > Changes
> > - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
> >   "ti,omap2-mcasp-audio" to identify version 3 controller.
> > - The register offsets are handled depending on the version.
> > - Provide a config option to indicate missing SRAM API support.
> 
> Could you give some insight which hardware this was tested on? I'm
> trying to get this up and running on a AM33xx board, and the patches
> look all reasonable to me. My problem is that I can't make the DMA
> engine move forward, I fail to receive a single interrupt on this
> peripheral after the stream starts. I will continue searching for the
> reason of this tomorrow, but maybe you can give me some hint by
> explaining your setup?
> 
> Note that I'm using your patches together with Matt's from this series:
> 
>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
> 
> ... but it doesn't work without those either.


When I started working on adding DT support to McASP driver, Matt Porter 
EDMA port was not yet ready. 

So 
1. I took existing edma driver from AM335x Arago release [1] (driver + edma 
   device init). 
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2] 

3. Added DT support to McASP driver.

I tested this on AM335x EVM board. 

If you need the code, I can share it as a patch (I will send the patch as a 
private mail since the patch is huge).


[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commit;h=d7e124e8074cccf9958290e773c88a4b2b36412b

[2]
https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

> 
> 
> 
> Thanks,
> Daniel
> 
> 


Regards, 
Gururaja

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Daniel Mack]

On 03.10.2012 09:16, Hebbar, Gururaja wrote:
> On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
>> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
>>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
>>> register offset and missing generic SRAM APIs support
>>>
>>> Changes
>>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
>>>   "ti,omap2-mcasp-audio" to identify version 3 controller.
>>> - The register offsets are handled depending on the version.
>>> - Provide a config option to indicate missing SRAM API support.
>>
>> Could you give some insight which hardware this was tested on? I'm
>> trying to get this up and running on a AM33xx board, and the patches
>> look all reasonable to me. My problem is that I can't make the DMA
>> engine move forward, I fail to receive a single interrupt on this
>> peripheral after the stream starts. I will continue searching for the
>> reason of this tomorrow, but maybe you can give me some hint by
>> explaining your setup?
>>
>> Note that I'm using your patches together with Matt's from this series:
>>
>>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
>>
>> ... but it doesn't work without those either.
> 
> 
> When I started working on adding DT support to McASP driver, Matt Porter 
> EDMA port was not yet ready. 
> 
> So 
> 1. I took existing edma driver from AM335x Arago release [1] (driver + edma 
>    device init). 
> 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2] 
> 
> 3. Added DT support to McASP driver.
> 
> I tested this on AM335x EVM board. 

Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.

> If you need the code, I can share it as a patch (I will send the patch as a 
> private mail since the patch is huge).

Please do :) Or just push your entire tree somewhere.


Thanks,
Daniel

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
> On 03.10.2012 09:16, Hebbar, Gururaja wrote:
> > On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
> >> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> >>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> >>> register offset and missing generic SRAM APIs support
> >>>
> >>> Changes
> >>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
> >>>   "ti,omap2-mcasp-audio" to identify version 3 controller.
> >>> - The register offsets are handled depending on the version.
> >>> - Provide a config option to indicate missing SRAM API support.
> >>
> >> Could you give some insight which hardware this was tested on? I'm
> >> trying to get this up and running on a AM33xx board, and the patches
> >> look all reasonable to me. My problem is that I can't make the DMA
> >> engine move forward, I fail to receive a single interrupt on this
> >> peripheral after the stream starts. I will continue searching for the
> >> reason of this tomorrow, but maybe you can give me some hint by
> >> explaining your setup?
> >>
> >> Note that I'm using your patches together with Matt's from this series:
> >>
> >>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
> >>
> >> ... but it doesn't work without those either.
> > 
> > 
> > When I started working on adding DT support to McASP driver, Matt Porter 
> > EDMA port was not yet ready. 
> > 
> > So 
> > 1. I took existing edma driver from AM335x Arago release [1] (driver + edma 
> >    device init). 
> > 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2] 
> > 
> > 3. Added DT support to McASP driver.
> > 
> > I tested this on AM335x EVM board. 
> 
> Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
> kernels.
> 
> > If you need the code, I can share it as a patch (I will send the patch as a 
> > private mail since the patch is huge).
> 
> Please do :) Or just push your entire tree somewhere.

I have pushed the code at below git repo
Repo :https://github.com/hvaibhav/am335x-linux
Branch : am335x-upstream-staging-audio

This includes 
1. (linux-next + AM335x patches)
2. McASP DT conversion
3. EDMA hack
4. AM335x audio specific DT blobs
5. Am335x dma DT blobs [hack]

Kindly let me know if you need any more details.

> 
> 
> Thanks,
> Daniel
> 
> 


Regards, 
Gururaja

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Daniel Mack]

On 03.10.2012 14:57, Hebbar, Gururaja wrote:
> On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
>> On 03.10.2012 09:16, Hebbar, Gururaja wrote:
>>> On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
>>>> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
>>>>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
>>>>> register offset and missing generic SRAM APIs support
>>>>>
>>>>> Changes
>>>>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
>>>>>   "ti,omap2-mcasp-audio" to identify version 3 controller.
>>>>> - The register offsets are handled depending on the version.
>>>>> - Provide a config option to indicate missing SRAM API support.
>>>>
>>>> Could you give some insight which hardware this was tested on? I'm
>>>> trying to get this up and running on a AM33xx board, and the patches
>>>> look all reasonable to me. My problem is that I can't make the DMA
>>>> engine move forward, I fail to receive a single interrupt on this
>>>> peripheral after the stream starts. I will continue searching for the
>>>> reason of this tomorrow, but maybe you can give me some hint by
>>>> explaining your setup?
>>>>
>>>> Note that I'm using your patches together with Matt's from this series:
>>>>
>>>>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
>>>>
>>>> ... but it doesn't work without those either.
>>>
>>>
>>> When I started working on adding DT support to McASP driver, Matt Porter 
>>> EDMA port was not yet ready. 
>>>
>>> So 
>>> 1. I took existing edma driver from AM335x Arago release [1] (driver + edma 
>>>    device init). 
>>> 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2] 
>>>
>>> 3. Added DT support to McASP driver.
>>>
>>> I tested this on AM335x EVM board. 
>>
>> Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
>> kernels.
>>
>>> If you need the code, I can share it as a patch (I will send the patch as a 
>>> private mail since the patch is huge).
>>
>> Please do :) Or just push your entire tree somewhere.
> 
> I have pushed the code at below git repo
> Repo :https://github.com/hvaibhav/am335x-linux
> Branch : am335x-upstream-staging-audio
> 
> This includes 
> 1. (linux-next + AM335x patches)
> 2. McASP DT conversion
> 3. EDMA hack
> 4. AM335x audio specific DT blobs
> 5. Am335x dma DT blobs [hack]

Ha, that 5th point was what I was missing, in particular these DMA
offset matching bits. Thanks a lot! I'll get back to you soon with some
patches for the mcasp driver.


Daniel

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Matt Porter]

On Wed, Oct 03, 2012 at 04:07:41PM +0200, Daniel Mack wrote:
> On 03.10.2012 14:57, Hebbar, Gururaja wrote:
> > On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
> >> On 03.10.2012 09:16, Hebbar, Gururaja wrote:
> >>> On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
> >>>> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> >>>>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> >>>>> register offset and missing generic SRAM APIs support
> >>>>>
> >>>>> Changes
> >>>>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
> >>>>>   "ti,omap2-mcasp-audio" to identify version 3 controller.
> >>>>> - The register offsets are handled depending on the version.
> >>>>> - Provide a config option to indicate missing SRAM API support.
> >>>>
> >>>> Could you give some insight which hardware this was tested on? I'm
> >>>> trying to get this up and running on a AM33xx board, and the patches
> >>>> look all reasonable to me. My problem is that I can't make the DMA
> >>>> engine move forward, I fail to receive a single interrupt on this
> >>>> peripheral after the stream starts. I will continue searching for the
> >>>> reason of this tomorrow, but maybe you can give me some hint by
> >>>> explaining your setup?
> >>>>
> >>>> Note that I'm using your patches together with Matt's from this series:
> >>>>
> >>>>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
> >>>>
> >>>> ... but it doesn't work without those either.
> >>>
> >>>
> >>> When I started working on adding DT support to McASP driver, Matt Porter 
> >>> EDMA port was not yet ready. 
> >>>
> >>> So 
> >>> 1. I took existing edma driver from AM335x Arago release [1] (driver + edma 
> >>>    device init). 
> >>> 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2] 
> >>>
> >>> 3. Added DT support to McASP driver.
> >>>
> >>> I tested this on AM335x EVM board. 
> >>
> >> Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
> >> kernels.
> >>
> >>> If you need the code, I can share it as a patch (I will send the patch as a 
> >>> private mail since the patch is huge).
> >>
> >> Please do :) Or just push your entire tree somewhere.
> > 
> > I have pushed the code at below git repo
> > Repo :https://github.com/hvaibhav/am335x-linux
> > Branch : am335x-upstream-staging-audio
> > 
> > This includes 
> > 1. (linux-next + AM335x patches)
> > 2. McASP DT conversion
> > 3. EDMA hack
> > 4. AM335x audio specific DT blobs
> > 5. Am335x dma DT blobs [hack]
> 
> Ha, that 5th point was what I was missing, in particular these DMA
> offset matching bits. Thanks a lot! I'll get back to you soon with some
> patches for the mcasp driver.

You should be able to replace #3 with https://lkml.org/lkml/2012/9/20/275
The intention is for McASP to use the private EDMA API on both DaVinci
and AM33xx until the dmaengine conversion of McASP is ready. 

-Matt

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Yegor Yefremov]

On Wed, Oct 3, 2012 at 2:57 PM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote:
> On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
>> On 03.10.2012 09:16, Hebbar, Gururaja wrote:
>> > On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
>> >> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
>> >>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
>> >>> register offset and missing generic SRAM APIs support
>> >>>
>> >>> Changes
>> >>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
>> >>>   "ti,omap2-mcasp-audio" to identify version 3 controller.
>> >>> - The register offsets are handled depending on the version.
>> >>> - Provide a config option to indicate missing SRAM API support.
>> >>
>> >> Could you give some insight which hardware this was tested on? I'm
>> >> trying to get this up and running on a AM33xx board, and the patches
>> >> look all reasonable to me. My problem is that I can't make the DMA
>> >> engine move forward, I fail to receive a single interrupt on this
>> >> peripheral after the stream starts. I will continue searching for the
>> >> reason of this tomorrow, but maybe you can give me some hint by
>> >> explaining your setup?
>> >>
>> >> Note that I'm using your patches together with Matt's from this series:
>> >>
>> >>   https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
>> >>
>> >> ... but it doesn't work without those either.
>> >
>> >
>> > When I started working on adding DT support to McASP driver, Matt Porter
>> > EDMA port was not yet ready.
>> >
>> > So
>> > 1. I took existing edma driver from AM335x Arago release [1] (driver + edma
>> >    device init).
>> > 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
>> >
>> > 3. Added DT support to McASP driver.
>> >
>> > I tested this on AM335x EVM board.
>>
>> Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
>> kernels.
>>
>> > If you need the code, I can share it as a patch (I will send the patch as a
>> > private mail since the patch is huge).
>>
>> Please do :) Or just push your entire tree somewhere.
>
> I have pushed the code at below git repo
> Repo :https://github.com/hvaibhav/am335x-linux
> Branch : am335x-upstream-staging-audio
>
> This includes
> 1. (linux-next + AM335x patches)
> 2. McASP DT conversion
> 3. EDMA hack
> 4. AM335x audio specific DT blobs
> 5. Am335x dma DT blobs [hack]
>
> Kindly let me know if you need any more details.

What can be expected in 3.8? And what will have to wait for 3.9?

Yegor

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

Yegor,

On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:
> On Wed, Oct 3, 2012 at 2:57 PM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote:
> > On Wed, Oct 03, 2012 at 16:46:39, Daniel Mack wrote:
> >> On 03.10.2012 09:16, Hebbar, Gururaja wrote:
> >> > On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
> >> >> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> >> >>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> >> >>> register offset and missing generic SRAM APIs support
> >> >>>

..snip..
..snip..

> >>
> >> Please do :) Or just push your entire tree somewhere.
> >
> > I have pushed the code at below git repo
> > Repo :https://github.com/hvaibhav/am335x-linux
> > Branch : am335x-upstream-staging-audio
> >
> > This includes
> > 1. (linux-next + AM335x patches)
> > 2. McASP DT conversion
> > 3. EDMA hack
> > 4. AM335x audio specific DT blobs
> > 5. Am335x dma DT blobs [hack]
> >
> > Kindly let me know if you need any more details.
> 

> What can be expected in 3.8? 

1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
& McASP pinctrl support is yet to be accepted. I sent a patch recently and 
waiting for feedback.

> And what will have to wait for 3.9?
AFAIK
1. EDMA port for McASP driver
2. AM335x support on Davinci ASoC (Kconfig & makefile)
3. DT blobs for Audio modules on AM335x (am335x-evm.dts & am33xx.dtsi)

> 
> Yegor
> 


Regards, 
Gururaja

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Mark Brown]

On Mon, Nov 26, 2012 at 11:32:49AM +0000, Hebbar, Gururaja wrote:
> On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:

> > What can be expected in 3.8? 

> 1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
> & McASP pinctrl support is yet to be accepted. I sent a patch recently and 
> waiting for feedback.

I don't have anything in my review queue, please post patches if you
want them reviewed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121126/5539c7b7/attachment.sig>

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Hebbar, Gururaja]

On Mon, Nov 26, 2012 at 17:05:21, Mark Brown wrote:
> On Mon, Nov 26, 2012 at 11:32:49AM +0000, Hebbar, Gururaja wrote:
> > On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote:
> 
> > > What can be expected in 3.8? 
> 
> > 1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion
> > & McASP pinctrl support is yet to be accepted. I sent a patch recently and 
> > waiting for feedback.
> 
> I don't have anything in my review queue, please post patches if you
> want them reviewed.

I already sent the patches for these on 22/11/2012 

http://lkml.org/lkml/2012/11/22/857

> 

Regards, 
Gururaja

[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant

[Mark Brown]

On Mon, Nov 26, 2012 at 11:42:01AM +0000, Hebbar, Gururaja wrote:

> I already sent the patches for these on 22/11/2012 

> http://lkml.org/lkml/2012/11/22/857

You've resent the same bindings again without addressing the review
comments from last time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121126/4bcd5e98/attachment.sig>