[alsa-devel] [PATCH 0/2] davinci ASoC interface changes
This series updates the DaVinci ASoC support after various DaVinci core interface changes. These core changes are part of the DaVinci core changes submitted for 2.6.32.
This compiles on top of the v2.6.31-rc2 based 'davinci-next' branch of the DaVinci git repo here: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
Naresh Medisetty (1): ASoC: DaVinci: Change default output volume
Sudhakar Rajashekhara (1): ASoC: davinci: update after EDMA interface changes
sound/soc/codecs/tlv320aic3x.h | 2 +- sound/soc/davinci/davinci-evm.c | 8 ++++---- sound/soc/davinci/davinci-pcm.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-)
From: Sudhakar Rajashekhara sudhakar.raj@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar.raj@ti.com Reviewed-by: David Brownell dbrownell@users.sourceforge.net Signed-off-by: Kevin Hilman khilman@deeprootsystems.com --- sound/soc/davinci/davinci-evm.c | 8 ++++---- sound/soc/davinci/davinci-pcm.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index 58fd1cb..832d5db 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -175,8 +175,8 @@ static struct resource evm_snd_resources[] = { };
static struct evm_snd_platform_data evm_snd_data = { - .tx_dma_ch = DAVINCI_DMA_ASP0_TX, - .rx_dma_ch = DAVINCI_DMA_ASP0_RX, + .tx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP0_TX), + .rx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP0_RX), };
/* DM335 EVM uses ASP1; line-out is a stereo mini-jack */ @@ -189,8 +189,8 @@ static struct resource dm335evm_snd_resources[] = { };
static struct evm_snd_platform_data dm335evm_snd_data = { - .tx_dma_ch = DAVINCI_DMA_ASP1_TX, - .rx_dma_ch = DAVINCI_DMA_ASP1_RX, + .tx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP1_TX), + .rx_dma_ch = EDMA_CTLR_CHAN(0, DAVINCI_DMA_ASP1_RX), };
static struct platform_device *evm_snd_device; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index a059965..3ee38b6 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -143,7 +143,7 @@ static int davinci_pcm_dma_request(struct snd_pcm_substream *substream) prtd->master_lch = ret;
/* Request parameter RAM reload slot */ - ret = edma_alloc_slot(EDMA_SLOT_ANY); + ret = edma_alloc_slot(EDMA_CTLR(prtd->master_lch), EDMA_SLOT_ANY); if (ret < 0) { edma_free_channel(prtd->master_lch); return ret; @@ -160,8 +160,8 @@ static int davinci_pcm_dma_request(struct snd_pcm_substream *substream) * so davinci_pcm_enqueue_dma() takes less time in IRQ. */ edma_read_slot(prtd->slave_lch, &p_ram); - p_ram.opt |= TCINTEN | EDMA_TCC(prtd->master_lch); - p_ram.link_bcntrld = prtd->slave_lch << 5; + p_ram.opt |= TCINTEN | EDMA_TCC(EDMA_CHAN_SLOT(prtd->master_lch)); + p_ram.link_bcntrld = EDMA_CHAN_SLOT(prtd->slave_lch) << 5; edma_write_slot(prtd->slave_lch, &p_ram);
return 0;
From: Naresh Medisetty naresh@ti.com
Changes default output volume of alsa driver since it is very low
Signed-off-by: Naresh Medisetty naresh@ti.com Signed-off-by: Kevin Hilman khilman@deeprootsystems.com --- sound/soc/codecs/tlv320aic3x.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h index ac827e5..76dbff4 100644 --- a/sound/soc/codecs/tlv320aic3x.h +++ b/sound/soc/codecs/tlv320aic3x.h @@ -195,7 +195,7 @@ #define INVERT_VOL(val) (0x7f - val)
/* Default output volume (inverted) */ -#define DEFAULT_VOL INVERT_VOL(0x50) +#define DEFAULT_VOL INVERT_VOL(0x60) /* Default input volume */ #define DEFAULT_GAIN 0x20
On Mon, Jul 06, 2009 at 03:02:03PM -0700, Kevin Hilman wrote:
From: Naresh Medisetty naresh@ti.com
Changes default output volume of alsa driver since it is very low
Signed-off-by: Naresh Medisetty naresh@ti.com Signed-off-by: Kevin Hilman khilman@deeprootsystems.com
Nack. The setup of the audio routing should be handled by user space on the system - the default setup is generally taken from hardware. Most of the ASoC CODECs are flexible enough to make choosing a default which makes sense to all systems pretty much impossible, and even within systems many have sufficient options to mean that something needs to be worked out dynamically at runtime rather than hard coded into the kernel.
Naresh, changes like this which are not specific to the architecture should be submmitted directly to the subsystems.
On Mon, Jul 06, 2009 at 03:02:02PM -0700, Kevin Hilman wrote:
From: Sudhakar Rajashekhara sudhakar.raj@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar.raj@ti.com Reviewed-by: David Brownell dbrownell@users.sourceforge.net Signed-off-by: Kevin Hilman khilman@deeprootsystems.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Mark Brown broonie@opensource.wolfsonmicro.com writes:
On Mon, Jul 06, 2009 at 03:02:02PM -0700, Kevin Hilman wrote:
From: Sudhakar Rajashekhara sudhakar.raj@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar.raj@ti.com Reviewed-by: David Brownell dbrownell@users.sourceforge.net Signed-off-by: Kevin Hilman khilman@deeprootsystems.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Mark,
So should I queue this up along with my changes, or do you want to merge this into asoc?
Kevin
On Mon, Jul 06, 2009 at 03:19:01PM -0700, Kevin Hilman wrote:
So should I queue this up along with my changes, or do you want to merge this into asoc?
It needs to go along with your changes at least to preserve bisect (it should really be in the same commit that changes the API from that point of view). But see my reply to Troy's post - he's got some further ASoC changes which depend on the new API and complicate matters a little.
So long as it all merges down fine for 2.6.32 I'm open to anything which works well for you guys.
Mark Brown broonie@opensource.wolfsonmicro.com writes:
On Mon, Jul 06, 2009 at 03:19:01PM -0700, Kevin Hilman wrote:
So should I queue this up along with my changes, or do you want to merge this into asoc?
It needs to go along with your changes at least to preserve bisect (it should really be in the same commit that changes the API from that point of view).
OK, it was originally part of the same patch, but I separated it out thinking that the sound/* part would go upstream separately.
I'll merge it back into the original commit and update davinci-next.
But see my reply to Troy's post - he's got some further ASoC changes which depend on the new API and complicate matters a little.
OK, will reply there.
Kevin
participants (2)
-
Kevin Hilman -
Mark Brown