[alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant
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(-)
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);
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.
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
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.
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 } }
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
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.
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.
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
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...
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.
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.
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
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 };
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.
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
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=d7e124e8...
[2] https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging
Thanks, Daniel
Regards, Gururaja
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
I took existing edma driver from AM335x Arago release [1] (driver + edma device init).
Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
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
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
I took existing edma driver from AM335x Arago release [1] (driver + edma device init).
Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
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
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
I took existing edma driver from AM335x Arago release [1] (driver + edma device init).
Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
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
- (linux-next + AM335x patches)
- McASP DT conversion
- EDMA hack
- AM335x audio specific DT blobs
- 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
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
I took existing edma driver from AM335x Arago release [1] (driver + edma device init).
Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
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
- (linux-next + AM335x patches)
- McASP DT conversion
- EDMA hack
- AM335x audio specific DT blobs
- 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
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
I took existing edma driver from AM335x Arago release [1] (driver + edma device init).
Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
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
- (linux-next + AM335x patches)
- McASP DT conversion
- EDMA hack
- AM335x audio specific DT blobs
- 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
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
- (linux-next + AM335x patches)
- McASP DT conversion
- EDMA hack
- AM335x audio specific DT blobs
- 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
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?
- 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.
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?
- 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
On Mon, Nov 26, 2012 at 11:42:01AM +0000, Hebbar, Gururaja wrote:
I already sent the patches for these on 22/11/2012
You've resent the same bindings again without addressing the review comments from last time.
participants (6)
-
Daniel Mack -
Hebbar, Gururaja -
Mark Brown -
Matt Porter -
Peter Ujfalusi -
Yegor Yefremov