[alsa-devel] [PATCH 0/3] ASoC Blackfin part updates
Hi Mark,
These are some updates from Cliff and Mike for ASoC Blackfin part. I generated these patches against Takashi Iwai's sound-2.6.git tree.
Thanks -Bryan
From: Mike Frysinger vapier.adi@gmail.com
Signed-off-by: Mike Frysinger vapier.adi@gmail.com Signed-off-by: Bryan Wu cooloney@kernel.org --- sound/soc/blackfin/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig index dc00620..3fce187 100644 --- a/sound/soc/blackfin/Kconfig +++ b/sound/soc/blackfin/Kconfig @@ -80,7 +80,7 @@ config SND_BF5XX_SPORT_NUM int "Set a SPORT for Sound chip" depends on (SND_BF5XX_I2S || SND_BF5XX_AC97) range 0 3 if BF54x - range 0 1 if (BF53x || BF561) + range 0 1 if !BF54x default 0 help Set the correct SPORT for sound chip.
At Tue, 21 Oct 2008 11:36:11 +0800, Bryan Wu wrote:
From: Mike Frysinger vapier.adi@gmail.com
Signed-off-by: Mike Frysinger vapier.adi@gmail.com Signed-off-by: Bryan Wu cooloney@kernel.org
Please use a short summary line, and put more details in the changelog. An empty changelog is very bad in general.
thanks,
Takashi
sound/soc/blackfin/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig index dc00620..3fce187 100644 --- a/sound/soc/blackfin/Kconfig +++ b/sound/soc/blackfin/Kconfig @@ -80,7 +80,7 @@ config SND_BF5XX_SPORT_NUM int "Set a SPORT for Sound chip" depends on (SND_BF5XX_I2S || SND_BF5XX_AC97) range 0 3 if BF54x
- range 0 1 if (BF53x || BF561)
- range 0 1 if !BF54x default 0 help Set the correct SPORT for sound chip.
-- 1.5.6 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
From: Cliff Cai cliff.cai@analog.com
Signed-off-by: Cliff Cai cliff.cai@analog.com Signed-off-by: Bryan Wu cooloney@kernel.org --- sound/soc/blackfin/Kconfig | 8 ++ sound/soc/blackfin/bf5xx-ac97-pcm.c | 45 +++++++---- sound/soc/blackfin/bf5xx-ac97.c | 152 +++++++++++++++++++++-------------- sound/soc/blackfin/bf5xx-ac97.h | 35 +++++++- sound/soc/codecs/ad1980.c | 5 +- 5 files changed, 163 insertions(+), 82 deletions(-)
diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig index 3fce187..e58d5b1 100644 --- a/sound/soc/blackfin/Kconfig +++ b/sound/soc/blackfin/Kconfig @@ -55,6 +55,14 @@ config SND_MMAP_SUPPORT Say y if you want AC97 driver to support mmap mode. We introduce an intermediate buffer to simulate mmap.
+config SND_MULTICHAN_SUPPORT + bool "Enable Multichannel Support" + depends on SND_BF5XX_AC97 + default n + help + Say y if you want AC97 driver to support up to 5.1 channel audio. + this mode will consume much more memory for DMA. + config SND_BF5XX_SOC_SPORT tristate diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c b/sound/soc/blackfin/bf5xx-ac97-pcm.c index 25e50d2..eb1531f 100644 --- a/sound/soc/blackfin/bf5xx-ac97-pcm.c +++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c @@ -43,24 +43,34 @@ #include "bf5xx-ac97.h" #include "bf5xx-sport.h"
+static unsigned int ac97_chan_mask[] = { + SP_FL, /* Mono */ + SP_STEREO, /* Stereo */ + SP_2DOT1, /* 2.1*/ + SP_QUAD,/*Quadraquic*/ + SP_FL | SP_FR | SP_FC | SP_SL | SP_SR,/*5 channels */ + SP_5DOT1, /* 5.1 */ +}; + #if defined(CONFIG_SND_MMAP_SUPPORT) static void bf5xx_mmap_copy(struct snd_pcm_substream *substream, snd_pcm_uframes_t count) { struct snd_pcm_runtime *runtime = substream->runtime; struct sport_device *sport = runtime->private_data; + unsigned int chan_mask = ac97_chan_mask[substream->runtime->channels - 1]; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { - bf5xx_pcm_to_ac97( - (struct ac97_frame *)sport->tx_dma_buf + sport->tx_pos, - (__u32 *)runtime->dma_area + sport->tx_pos, count); + bf5xx_pcm_to_ac97((struct ac97_frame *)sport->tx_dma_buf + sport->tx_pos, + (__u16 *)runtime->dma_area + sport->tx_pos * substream->runtime->channels, + count, chan_mask); sport->tx_pos += runtime->period_size; if (sport->tx_pos >= runtime->buffer_size) sport->tx_pos %= runtime->buffer_size; sport->tx_delay_pos = sport->tx_pos; } else { - bf5xx_ac97_to_pcm( - (struct ac97_frame *)sport->rx_dma_buf + sport->rx_pos, - (__u32 *)runtime->dma_area + sport->rx_pos, count); + bf5xx_ac97_to_pcm((struct ac97_frame *)sport->rx_dma_buf + sport->rx_pos, + (__u16 *)runtime->dma_area + sport->rx_pos * substream->runtime->channels, + count); sport->rx_pos += runtime->period_size; if (sport->rx_pos >= runtime->buffer_size) sport->rx_pos %= runtime->buffer_size; @@ -123,10 +133,18 @@ static int bf5xx_pcm_hw_params(struct snd_pcm_substream *substream,
static int bf5xx_pcm_hw_free(struct snd_pcm_substream *substream) { + #if defined(CONFIG_SND_MMAP_SUPPORT) struct snd_pcm_runtime *runtime = substream->runtime; + struct sport_device *sport = runtime->private_data;
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - memset(runtime->dma_area, 0, runtime->buffer_size); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + sport->once = 0; + if (runtime->dma_area) + memset(runtime->dma_area, 0, runtime->buffer_size); + memset(sport->tx_dma_buf, 0, runtime->buffer_size * sizeof(struct ac97_frame)); + } else + memset(sport->rx_dma_buf, 0, runtime->buffer_size * sizeof(struct ac97_frame)); +#endif snd_pcm_lib_free_pages(substream); return 0; } @@ -174,7 +192,6 @@ static int bf5xx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_START: if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { bf5xx_mmap_copy(substream, runtime->period_size); - snd_pcm_period_elapsed(substream); sport->tx_delay_pos = 0; sport_tx_start(sport); } @@ -286,13 +303,11 @@ static int bf5xx_pcm_copy(struct snd_pcm_substream *substream, int channel, substream->stream ? "Capture" : "Playback", pos, count);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - bf5xx_pcm_to_ac97( - (struct ac97_frame *)runtime->dma_area + pos, - buf, count); + bf5xx_pcm_to_ac97((struct ac97_frame *)runtime->dma_area + pos, + (__u16 *)buf, count, chan_mask); else - bf5xx_ac97_to_pcm( - (struct ac97_frame *)runtime->dma_area + pos, - buf, count); + bf5xx_ac97_to_pcm((struct ac97_frame *)runtime->dma_area + pos, + (__u16 *)buf, count); return 0; } #endif diff --git a/sound/soc/blackfin/bf5xx-ac97.c b/sound/soc/blackfin/bf5xx-ac97.c index 5e5aafb..b88f796 100644 --- a/sound/soc/blackfin/bf5xx-ac97.c +++ b/sound/soc/blackfin/bf5xx-ac97.c @@ -54,65 +54,97 @@ static int *cmd_count; static int sport_num = CONFIG_SND_BF5XX_SPORT_NUM;
-#if defined(CONFIG_BF54x) +static u16 sport_req[][7] = { + PIN_REQ_SPORT_0, +#ifdef PIN_REQ_SPORT_1 + PIN_REQ_SPORT_1, +#endif +#ifdef PIN_REQ_SPORT_2 + PIN_REQ_SPORT_2, +#endif +#ifdef PIN_REQ_SPORT_3 + PIN_REQ_SPORT_3, +#endif + }; + static struct sport_param sport_params[4] = { { .dma_rx_chan = CH_SPORT0_RX, .dma_tx_chan = CH_SPORT0_TX, - .err_irq = IRQ_SPORT0_ERR, + .err_irq = IRQ_SPORT0_ERROR, .regs = (struct sport_register *)SPORT0_TCR1, }, +#ifdef PIN_REQ_SPORT_1 { .dma_rx_chan = CH_SPORT1_RX, .dma_tx_chan = CH_SPORT1_TX, - .err_irq = IRQ_SPORT1_ERR, + .err_irq = IRQ_SPORT1_ERROR, .regs = (struct sport_register *)SPORT1_TCR1, }, +#endif +#ifdef PIN_REQ_SPORT_2 { .dma_rx_chan = CH_SPORT2_RX, .dma_tx_chan = CH_SPORT2_TX, - .err_irq = IRQ_SPORT2_ERR, + .err_irq = IRQ_SPORT2_ERROR, .regs = (struct sport_register *)SPORT2_TCR1, }, +#endif +#ifdef PIN_REQ_SPORT_3 { .dma_rx_chan = CH_SPORT3_RX, .dma_tx_chan = CH_SPORT3_TX, - .err_irq = IRQ_SPORT3_ERR, + .err_irq = IRQ_SPORT3_ERROR, .regs = (struct sport_register *)SPORT3_TCR1, } -}; -#else -static struct sport_param sport_params[2] = { - { - .dma_rx_chan = CH_SPORT0_RX, - .dma_tx_chan = CH_SPORT0_TX, - .err_irq = IRQ_SPORT0_ERROR, - .regs = (struct sport_register *)SPORT0_TCR1, - }, - { - .dma_rx_chan = CH_SPORT1_RX, - .dma_tx_chan = CH_SPORT1_TX, - .err_irq = IRQ_SPORT1_ERROR, - .regs = (struct sport_register *)SPORT1_TCR1, - } -}; #endif +};
-void bf5xx_pcm_to_ac97(struct ac97_frame *dst, const __u32 *src, \ - size_t count) +void bf5xx_pcm_to_ac97(struct ac97_frame *dst, const __u16 *src, \ + size_t count, unsigned int chan_mask) { while (count--) { - dst->ac97_tag = TAG_VALID | TAG_PCM; - (dst++)->ac97_pcm = *src++; + dst->ac97_tag = TAG_VALID; + if (chan_mask & SP_FL) { + dst->ac97_pcm_r = *src++; + dst->ac97_tag |= TAG_PCM_RIGHT; + } + if (chan_mask & SP_FR) { + dst->ac97_pcm_l = *src++; + dst->ac97_tag |= TAG_PCM_LEFT; + + } +#if defined(CONFIG_SND_MULTICHAN_SUPPORT) + if (chan_mask & SP_SR) { + dst->ac97_sl = *src++; + dst->ac97_tag |= TAG_PCM_SL; + } + if (chan_mask & SP_SL) { + dst->ac97_sr = *src++; + dst->ac97_tag |= TAG_PCM_SR; + } + if (chan_mask & SP_LFE) { + dst->ac97_lfe = *src++; + dst->ac97_tag |= TAG_PCM_LFE; + } + if (chan_mask & SP_FC) { + dst->ac97_center = *src++; + dst->ac97_tag |= TAG_PCM_CENTER; + } +#endif + dst++; } } EXPORT_SYMBOL(bf5xx_pcm_to_ac97);
-void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u32 *dst, \ +void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u16 *dst, \ size_t count) { - while (count--) - *(dst++) = (src++)->ac97_pcm; + while (count--) { + *(dst++) = src->ac97_pcm_l; + *(dst++) = src->ac97_pcm_r; + src++; + } } EXPORT_SYMBOL(bf5xx_ac97_to_pcm);
@@ -297,20 +329,15 @@ static int bf5xx_ac97_resume(struct platform_device *pdev, static int bf5xx_ac97_probe(struct platform_device *pdev, struct snd_soc_dai *dai) { - int ret; -#if defined(CONFIG_BF54x) - u16 sport_req[][7] = {PIN_REQ_SPORT_0, PIN_REQ_SPORT_1, - PIN_REQ_SPORT_2, PIN_REQ_SPORT_3}; -#else - u16 sport_req[][7] = {PIN_REQ_SPORT_0, PIN_REQ_SPORT_1}; -#endif + int ret = 0; cmd_count = (int *)get_zeroed_page(GFP_KERNEL); if (cmd_count == NULL) return -ENOMEM;
if (peripheral_request_list(&sport_req[sport_num][0], "soc-audio")) { pr_err("Requesting Peripherals failed\n"); - return -EFAULT; + ret = -EFAULT; + goto peripheral_err; }
#ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET @@ -318,54 +345,52 @@ static int bf5xx_ac97_probe(struct platform_device *pdev, if (gpio_request(CONFIG_SND_BF5XX_RESET_GPIO_NUM, "SND_AD198x RESET")) { pr_err("Failed to request GPIO_%d for reset\n", CONFIG_SND_BF5XX_RESET_GPIO_NUM); - peripheral_free_list(&sport_req[sport_num][0]); - return -1; + ret = -1; + goto gpio_err; } gpio_direction_output(CONFIG_SND_BF5XX_RESET_GPIO_NUM, 1); #endif sport_handle = sport_init(&sport_params[sport_num], 2, \ sizeof(struct ac97_frame), NULL); if (!sport_handle) { - peripheral_free_list(&sport_req[sport_num][0]); -#ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET - gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); -#endif - return -ENODEV; + ret = -ENODEV; + goto sport_err; } /*SPORT works in TDM mode to simulate AC97 transfers*/ ret = sport_set_multichannel(sport_handle, 16, 0x1F, 1); if (ret) { pr_err("SPORT is busy!\n"); - kfree(sport_handle); - peripheral_free_list(&sport_req[sport_num][0]); -#ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET - gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); -#endif - return -EBUSY; + ret = -EBUSY; + goto sport_config_err; }
ret = sport_config_rx(sport_handle, IRFS, 0xF, 0, (16*16-1)); if (ret) { pr_err("SPORT is busy!\n"); - kfree(sport_handle); - peripheral_free_list(&sport_req[sport_num][0]); -#ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET - gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); -#endif - return -EBUSY; + ret = -EBUSY; + goto sport_config_err; }
ret = sport_config_tx(sport_handle, ITFS, 0xF, 0, (16*16-1)); if (ret) { pr_err("SPORT is busy!\n"); - kfree(sport_handle); - peripheral_free_list(&sport_req[sport_num][0]); + ret = -EBUSY; + goto sport_config_err; + } + +sport_config_err: + kfree(sport_handle); +sport_err: #ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET - gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); + gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); #endif - return -EBUSY; - } - return 0; +gpio_err: + peripheral_free_list(&sport_req[sport_num][0]); +peripheral_err: + free_page((unsigned long)cmd_count); + cmd_count = NULL; + + return ret; }
static void bf5xx_ac97_remove(struct platform_device *pdev, @@ -373,6 +398,7 @@ static void bf5xx_ac97_remove(struct platform_device *pdev, { free_page((unsigned long)cmd_count); cmd_count = NULL; + peripheral_free_list(&sport_req[sport_num][0]); #ifdef CONFIG_SND_BF5XX_HAVE_COLD_RESET gpio_free(CONFIG_SND_BF5XX_RESET_GPIO_NUM); #endif @@ -389,7 +415,11 @@ struct snd_soc_dai bfin_ac97_dai = { .playback = { .stream_name = "AC97 Playback", .channels_min = 2, +#if defined(CONFIG_SND_MULTICHAN_SUPPORT) + .channels_max = 6, +#else .channels_max = 2, +#endif .rates = SNDRV_PCM_RATE_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { diff --git a/sound/soc/blackfin/bf5xx-ac97.h b/sound/soc/blackfin/bf5xx-ac97.h index 3f77cc5..04284d2 100644 --- a/sound/soc/blackfin/bf5xx-ac97.h +++ b/sound/soc/blackfin/bf5xx-ac97.h @@ -16,21 +16,46 @@ struct ac97_frame { u16 ac97_tag; /* slot 0 */ u16 ac97_addr; /* slot 1 */ u16 ac97_data; /* slot 2 */ - u32 ac97_pcm; /* slot 3 and 4: left and right pcm data */ + u16 ac97_pcm_l; /*slot 3:front left*/ + u16 ac97_pcm_r; /*slot 4:front left*/ +#if defined(CONFIG_SND_MULTICHAN_SUPPORT) + u16 ac97_mdm_l1; + u16 ac97_center; /*slot 6:center*/ + u16 ac97_sl; /*slot 7:surround left*/ + u16 ac97_sr; /*slot 8:surround right*/ + u16 ac97_lfe; /*slot 9:lfe*/ +#endif } __attribute__ ((packed));
+/* Speaker location */ +#define SP_FL 0x0001 +#define SP_FR 0x0010 +#define SP_FC 0x0002 +#define SP_LFE 0x0020 +#define SP_SL 0x0004 +#define SP_SR 0x0040 + +#define SP_STEREO (SP_FL | SP_FR) +#define SP_2DOT1 (SP_FL | SP_FR | SP_LFE) +#define SP_QUAD (SP_FL | SP_FR | SP_SL | SP_SR) +#define SP_5DOT1 (SP_FL | SP_FR | SP_FC | SP_LFE | SP_SL | SP_SR) + #define TAG_VALID 0x8000 #define TAG_CMD 0x6000 #define TAG_PCM_LEFT 0x1000 #define TAG_PCM_RIGHT 0x0800 -#define TAG_PCM (TAG_PCM_LEFT | TAG_PCM_RIGHT) +#define TAG_PCM_MDM_L1 0x0400 +#define TAG_PCM_CENTER 0x0200 +#define TAG_PCM_SL 0x0100 +#define TAG_PCM_SR 0x0080 +#define TAG_PCM_LFE 0x0040
extern struct snd_soc_dai bfin_ac97_dai;
-void bf5xx_pcm_to_ac97(struct ac97_frame *dst, const __u32 *src, \ - size_t count); +void bf5xx_pcm_to_ac97(struct ac97_frame *dst, const __u16 *src, \ + size_t count, unsigned int chan_mask);
-void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u32 *dst, \ +void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u16 *dst, \ size_t count);
#endif diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index 1397b8e..e22fbdf 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -145,7 +145,7 @@ struct snd_soc_dai ad1980_dai = { .playback = { .stream_name = "Playback", .channels_min = 2, - .channels_max = 2, + .channels_max = 6, .rates = SNDRV_PCM_RATE_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { @@ -256,6 +256,9 @@ static int ad1980_soc_probe(struct platform_device *pdev) ac97_write(codec, AC97_MASTER, 0x0000); /* unmute line out volume */ ac97_write(codec, AC97_PCM, 0x0000); /* unmute PCM out volume */ ac97_write(codec, AC97_REC_GAIN, 0x0000);/* unmute record volume */ + ac97_write(codec, AC97_CENTER_LFE_MASTER, 0x0000); /* unmute center and lfe volume */ + ac97_write(codec, AC97_SURROUND_MASTER, 0x0000); /* unmute surround volume */ + ac97_write(codec, AC97_EXTENDED_STATUS, 0x0000);/*power on LFE CENTER and Surround DACs*/
ad1980_add_controls(codec); ret = snd_soc_register_card(socdev);
At Tue, 21 Oct 2008 11:36:12 +0800, Bryan Wu wrote:
From: Cliff Cai cliff.cai@analog.com
Signed-off-by: Cliff Cai cliff.cai@analog.com Signed-off-by: Bryan Wu cooloney@kernel.org
sound/soc/blackfin/Kconfig | 8 ++ sound/soc/blackfin/bf5xx-ac97-pcm.c | 45 +++++++---- sound/soc/blackfin/bf5xx-ac97.c | 152 +++++++++++++++++++++-------------- sound/soc/blackfin/bf5xx-ac97.h | 35 +++++++- sound/soc/codecs/ad1980.c | 5 +- 5 files changed, 163 insertions(+), 82 deletions(-)
diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig index 3fce187..e58d5b1 100644 --- a/sound/soc/blackfin/Kconfig +++ b/sound/soc/blackfin/Kconfig @@ -55,6 +55,14 @@ config SND_MMAP_SUPPORT Say y if you want AC97 driver to support mmap mode. We introduce an intermediate buffer to simulate mmap.
+config SND_MULTICHAN_SUPPORT
SND_BF5XX_MULTICHAN_SUPPORT is preferred because it's pretty specific to bf5xx. (Well, the same about SND_MMAP_SUPPORT, which I overlooked it...)
- bool "Enable Multichannel Support"
- depends on SND_BF5XX_AC97
- default n
- help
Say y if you want AC97 driver to support up to 5.1 channel audio.this mode will consume much more memory for DMA.config SND_BF5XX_SOC_SPORT tristate
diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c b/sound/soc/blackfin/bf5xx-ac97-pcm.c index 25e50d2..eb1531f 100644 --- a/sound/soc/blackfin/bf5xx-ac97-pcm.c +++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c @@ -43,24 +43,34 @@ #include "bf5xx-ac97.h" #include "bf5xx-sport.h"
+static unsigned int ac97_chan_mask[] = {
- SP_FL, /* Mono */
- SP_STEREO, /* Stereo */
- SP_2DOT1, /* 2.1*/
- SP_QUAD,/*Quadraquic*/
- SP_FL | SP_FR | SP_FC | SP_SL | SP_SR,/*5 channels */
- SP_5DOT1, /* 5.1 */
+};
#if defined(CONFIG_SND_MMAP_SUPPORT) static void bf5xx_mmap_copy(struct snd_pcm_substream *substream, snd_pcm_uframes_t count) { struct snd_pcm_runtime *runtime = substream->runtime; struct sport_device *sport = runtime->private_data;
- unsigned int chan_mask = ac97_chan_mask[substream->runtime->channels - 1];
"substream->" can be removed here. Ditto for the lines below.
static int bf5xx_pcm_hw_free(struct snd_pcm_substream *substream) {
- #if defined(CONFIG_SND_MMAP_SUPPORT)
Put '#' at the beginning of the line.
Also, in general, I recommend you to run checkpatch.pl once before submitting patches.
thanks,
Takashi
On Tue, Oct 21, 2008 at 11:36:12AM +0800, Bryan Wu wrote:
+config SND_MULTICHAN_SUPPORT
- bool "Enable Multichannel Support"
- depends on SND_BF5XX_AC97
- default n
- help
Say y if you want AC97 driver to support up to 5.1 channel audio.this mode will consume much more memory for DMA.
Should this be a user visible option or selected by the machine drivers?
To be honest, I'm surprised that the multi-channel support can't only incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same way for a normal stereo stream even if multi-channel support is built in.
-void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u32 *dst, \ +void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u16 *dst, \ size_t count) {
Separately please submit a patch removing the needless continuation character here.
diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index 1397b8e..e22fbdf 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c
The codec driver changes should be submitted as a separate patch. They're good to go as-is.
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 4:37 PM To: Bryan Wu Cc: alsa-devel@alsa-project.org; Cliff Cai Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 11:36:12AM +0800, Bryan Wu wrote:
+config SND_MULTICHAN_SUPPORT
- bool "Enable Multichannel Support"
- depends on SND_BF5XX_AC97
- default n
- help
Say y if you want AC97 driver to support up to 5.1channel audio.
this mode will consume much more memory for DMA.Should this be a user visible option or selected by the machine drivers?
I think people want to enable this feature Only If they really want it,since it will consume much more memory To hold multi-channel data.
To be honest, I'm surprised that the multi-channel support can't only incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same way for a normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
-void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u32 *dst, \ +void bf5xx_ac97_to_pcm(const struct ac97_frame *src, __u16 *dst, \ size_t count) {
Separately please submit a patch removing the needless continuation character here.
diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index 1397b8e..e22fbdf 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c
The codec driver changes should be submitted as a separate patch. They're good to go as-is.
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support can't only incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same way for a normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for multi-channel playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in the same way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support
can't only
incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same
way for a
normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for multi-channel playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in the same way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate continuous memory dynamicly, Since embedded system has limited uncached DMA memory.
At Tue, 21 Oct 2008 17:35:49 +0800, Cai, Cliff wrote:
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support
can't only
incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same
way for a
normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for multi-channel playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in the same way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate continuous memory dynamicly, Since embedded system has limited uncached DMA memory.
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
Anyway, I agree with Mark. The setup can be ideally dynamically changed.
thanks,
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, October 21, 2008 5:39 PM To: Cai, Cliff Cc: Mark Brown; Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
At Tue, 21 Oct 2008 17:35:49 +0800, Cai, Cliff wrote:
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel
supporting
in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support
can't only
incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same
way for a
normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for
multi-channel
playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in
the same
way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate
continuous memory
dynamicly, Since embedded system has limited uncached DMA memory.
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
It will change the ac97 frame size defined in bf5xx-ac97.h,the frame size the basic unit of the DMA buffer
Anyway, I agree with Mark. The setup can be ideally dynamically changed.
thanks,
Takashi
On Tue, Oct 21, 2008 at 05:48:56PM +0800, Cai, Cliff wrote:
From: Takashi Iwai [mailto:tiwai@suse.de]
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
It will change the ac97 frame size defined in bf5xx-ac97.h,the frame size the basic unit of the DMA buffer
So this is purely a restriction in the driver, rather than a property of the hardware - is there any reason why you can't change the size of buffer that you allocate at runtime?
At Tue, 21 Oct 2008 10:49:16 +0100, Mark Brown wrote:
On Tue, Oct 21, 2008 at 05:48:56PM +0800, Cai, Cliff wrote:
From: Takashi Iwai [mailto:tiwai@suse.de]
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
It will change the ac97 frame size defined in bf5xx-ac97.h,the frame size the basic unit of the DMA buffer
So this is purely a restriction in the driver, rather than a property of the hardware - is there any reason why you can't change the size of buffer that you allocate at runtime?
It'd be possible, as far as I understand. It's rather a design issue.
bf5xx driver preallocates the max size buffer. Otherwise you may get no large buffer at later fragmentation. And that size is different between with and without multi-channel support.
Takashi
At Tue, 21 Oct 2008 17:48:56 +0800, Cai, Cliff wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, October 21, 2008 5:39 PM To: Cai, Cliff Cc: Mark Brown; Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
At Tue, 21 Oct 2008 17:35:49 +0800, Cai, Cliff wrote:
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel
supporting
in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support
can't only
incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same
way for a
normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for
multi-channel
playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in
the same
way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate
continuous memory
dynamicly, Since embedded system has limited uncached DMA memory.
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
It will change the ac97 frame size defined in bf5xx-ac97.h,the frame size the basic unit of the DMA buffer
Ah, I see. Then I find this patch OK, at least, changes for blackfin part. Basically MULTICHAN_SUPPORT will require more resources, but it still provides the same functionality as without it.
BTW, are your changes to ad1980.c applicable unconditionally? For example,
--- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -145,7 +145,7 @@ struct snd_soc_dai ad1980_dai = { .playback = { .stream_name = "Playback", .channels_min = 2,
.channels_max = 2,
.channels_max = 6,
This won't work if the machine side doesn't support the multi-channel. Right now, blackfin is the only one, but the codec driver should be generic.
Also, the below is dangerous:
@@ -256,6 +256,9 @@ static int ad1980_soc_probe(struct platform_device *pdev)
- ac97_write(codec, AC97_EXTENDED_STATUS, 0x0000);/*power on LFE CENTER and Surround DACs*/
This will disable all other features, too.
thanks,
Takashi
On Tue, Oct 21, 2008 at 12:01:45PM +0200, Takashi Iwai wrote:
Cai, Cliff wrote:
BTW, are your changes to ad1980.c applicable unconditionally? For example,
--- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -145,7 +145,7 @@ struct snd_soc_dai ad1980_dai = { .playback = { .stream_name = "Playback", .channels_min = 2,
.channels_max = 2,
.channels_max = 6,
This won't work if the machine side doesn't support the multi-channel. Right now, blackfin is the only one, but the codec driver should be generic.
This is fine - the ASoC core does constraint checks so if the controller doesn't support the extra channels user space will never be told about them.
At Tue, 21 Oct 2008 11:19:39 +0100, Mark Brown wrote:
On Tue, Oct 21, 2008 at 12:01:45PM +0200, Takashi Iwai wrote:
Cai, Cliff wrote:
BTW, are your changes to ad1980.c applicable unconditionally? For example,
--- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -145,7 +145,7 @@ struct snd_soc_dai ad1980_dai = { .playback = { .stream_name = "Playback", .channels_min = 2,
.channels_max = 2,
.channels_max = 6,This won't work if the machine side doesn't support the multi-channel. Right now, blackfin is the only one, but the codec driver should be generic.
This is fine - the ASoC core does constraint checks so if the controller doesn't support the extra channels user space will never be told about them.
OK, then this change itself is fine. But there is no volume control for surrounds and CLFE, so always loudest outputs?
As a simple workaround, one can set bit 0x4000 to register 0x76 (AD_MISC), so that the master volume controls surrounds, too. Of course, creating corresponding volume controls would be an option, but then it'll be annoying if the machine driver supports only two channels.
Or am I missing anything else?
Takashi
On Tue, Oct 21, 2008 at 12:30:23PM +0200, Takashi Iwai wrote:
Of course, creating corresponding volume controls would be an option, but then it'll be annoying if the machine driver supports only two channels.
That's a bit of a general problem for ASoC. It'd be possible to deal with it by passing in configuration from the machine driver which selects which controls are registered or which uses the ability to disable controls that you've got in your unstable tree.
Normally it's not a big deal since end users never see the ALSA controls directly but interact with a device-specific UI instead.
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, October 21, 2008 6:02 PM To: Cai, Cliff Cc: Mark Brown; Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
At Tue, 21 Oct 2008 17:48:56 +0800, Cai, Cliff wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, October 21, 2008 5:39 PM To: Cai, Cliff Cc: Mark Brown; Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
At Tue, 21 Oct 2008 17:35:49 +0800, Cai, Cliff wrote:
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel
supporting
in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
>To be honest, I'm surprised that the multi-channel support
can't only
>incur the extra memory consumpton when playing back a >multi-channel stream - I'd have expected the hardware to work >in the same
way for a
>normal stereo stream even if multi-channel support is
built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using
serial port.
My point is that the configuration of the hardware for
multi-channel
playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in
the same
way as when multi-channel support is not compiled in and
avoid the
additional costs which that incurs.
As well as saving memory I'd expect configuring this at
runtime to
also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate
continuous memory
dynamicly, Since embedded system has limited uncached DMA memory.
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer
allocation
behavior? I don't find it...
It will change the ac97 frame size defined in bf5xx-ac97.h,the frame size the basic unit of the DMA buffer
Ah, I see. Then I find this patch OK, at least, changes for blackfin part. Basically MULTICHAN_SUPPORT will require more resources, but it still provides the same functionality as without it.
BTW, are your changes to ad1980.c applicable unconditionally? For example,
--- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -145,7 +145,7 @@ struct snd_soc_dai ad1980_dai = { .playback = { .stream_name = "Playback", .channels_min = 2,
.channels_max = 2,
.channels_max = 6,This won't work if the machine side doesn't support the multi-channel. Right now, blackfin is the only one, but the codec driver should be generic.
This is a problem,what's your suggestion? I think if the CPU DAI only supports stereo,alsa will omit the 6 channel support for codec,am I wrong? It works for me,since I provide two choices for CPU DAI,2 or 6 channel(through CONFIG_SND_MULTICHAN_SUPPORT).
Also, the below is dangerous:
@@ -256,6 +256,9 @@ static int ad1980_soc_probe(struct
platform_device
*pdev)
- ac97_write(codec, AC97_EXTENDED_STATUS, 0x0000);/*power on LFE
+CENTER and Surround DACs*/
This will disable all other features, too.
OK, I will only enable the DACs needed.
thanks,
Takashi
On Tue, Oct 21, 2008 at 5:39 PM, Takashi Iwai tiwai@suse.de wrote:
At Tue, 21 Oct 2008 17:35:49 +0800, Cai, Cliff wrote:
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 5:16 PM To: Cai, Cliff Cc: Bryan Wu; alsa-devel@alsa-project.org Subject: Re: [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:08:31PM +0800, Cai, Cliff wrote:
To be honest, I'm surprised that the multi-channel support
can't only
incur the extra memory consumpton when playing back a multi-channel stream - I'd have expected the hardware to work in the same
way for a
normal stereo stream even if multi-channel support is built in.
Yes,hardware almost works in the same way as playing a stereo stream,except That it need to fill more data to DMA memory manually,since we just simulate AC97 Controller using serial port.
My point is that the configuration of the hardware for multi-channel playback only needs to be done when actually playing back multi-channel data. When playing back stereo data it should be possible to configure the hardware and do the simulation in the same way as when multi-channel support is not compiled in and avoid the additional costs which that incurs.
As well as saving memory I'd expect configuring this at runtime to also save some power when playing back two or four channel data.
Yes, it's an ideal way,but it's not safe to allocate continuous memory dynamicly, Since embedded system has limited uncached DMA memory.
But, CONFIG_SND_MULTICHAN_SUPPORT would change any buffer allocation behavior? I don't find it...
Anyway, I agree with Mark. The setup can be ideally dynamically changed.
Basically, I like Mark's idea.
But you know, it is very difficult for us to allocate big buffer in an NOMMU machine (such as Blackfin) on the fly, So we prefer to allocate them at the beginning. And in the embedded world, when the user want to use multi-channel function, they will enable this option. If they don't, they won't do that. It is very simple for both us and our users, although it is less elegant than Mark's idea.
-Bryan
On Tue, Oct 21, 2008 at 05:55:23PM +0800, Bryan Wu wrote:
But you know, it is very difficult for us to allocate big buffer in an NOMMU machine (such as Blackfin) on the fly, So we prefer to allocate them at the beginning. And in the embedded world, when the user want to use multi-channel function, they will enable this option. If they don't, they won't do that. It is very simple for both us and our users, although it is less elegant than Mark's idea.
So the issue is that you want to force a static allocation at startup due to hardware limitations? That makes a bit more sense. I guess that's OK but I'd suggest changing the code to also allow the user to select four channels - not all multi-channel systems use six channels. Another option would be to select it at driver startup time.
I'm still not sure that this is something that should be selected via the kernel configuration rather than by the machine driver - I would expect the use of six channels to be a property of the system rather than of the particular kernel build.
-----Original Message----- From: Mark Brown [mailto:broonie@sirena.org.uk] Sent: Tuesday, October 21, 2008 6:15 PM To: Bryan Wu Cc: Takashi Iwai; Cai, Cliff; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: add multi-channel supporting in Blackfin ASoC driver and AD1980 codec driver
On Tue, Oct 21, 2008 at 05:55:23PM +0800, Bryan Wu wrote:
But you know, it is very difficult for us to allocate big
buffer in an
NOMMU machine (such as Blackfin) on the fly, So we prefer to
allocate
them at the beginning. And in the embedded world, when the user want to use multi-channel function, they will enable this option. If they don't, they won't do that. It is very simple for both us and our users, although it is less elegant than Mark's idea.
So the issue is that you want to force a static allocation at startup due to hardware limitations? That makes a bit more sense. I guess that's OK but I'd suggest changing the code to also allow the user to select four channels - not all multi-channel systems use six channels.
The buffer struct of ac97 frame for 4/6 channels only has one slot difference -- LFE slot, 6-channel mode does support 4-channel mode.
Another option would be to select it at driver startup time.
I'm still not sure that this is something that should be selected via the kernel configuration rather than by the machine driver - I would expect the use of six channels to be a property of the system rather than of the particular kernel build.
From: Cliff Cai cliff.cai@analog.com
Also include some small coding style cleanup.
Signed-off-by: Cliff Cai cliff.cai@analog.com Signed-off-by: Bryan Wu cooloney@kernel.org --- sound/soc/blackfin/bf5xx-i2s.c | 33 +++++++++++++++++++++------------ 1 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/sound/soc/blackfin/bf5xx-i2s.c b/sound/soc/blackfin/bf5xx-i2s.c index 827587f..33f5549 100644 --- a/sound/soc/blackfin/bf5xx-i2s.c +++ b/sound/soc/blackfin/bf5xx-i2s.c @@ -70,12 +70,23 @@ static struct sport_param sport_params[2] = { } };
-static u16 sport_req[][7] = { - { P_SPORT0_DTPRI, P_SPORT0_TSCLK, P_SPORT0_RFS, - P_SPORT0_DRPRI, P_SPORT0_RSCLK, 0}, - { P_SPORT1_DTPRI, P_SPORT1_TSCLK, P_SPORT1_RFS, - P_SPORT1_DRPRI, P_SPORT1_RSCLK, 0}, -}; +/* + * Setting the TFS pin selector for SPORT 0 based on whether the selected port id F or G. If the port + * is F then no conflict should exist for the TFS. When Port G is selected and EMAC then there is a + * conflict between the PHY interrupt line and TFS. Current settings prevent the conflict by ignoring + * the TFS pin when Port G is selected. This allows both ssm2602 using Port G and EMAC concurrently. + */ +#ifdef CONFIG_BF527_SPORT0_PORTF +#define LOCAL_SPORT0_TFS (P_SPORT0_TFS) +#endif + +#ifndef CONFIG_BF527_SPORT0_PORTF +#define LOCAL_SPORT0_TFS (0) +#endif + +static u16 sport_req[][7] = { {P_SPORT0_DTPRI, P_SPORT0_TSCLK, P_SPORT0_RFS, + P_SPORT0_DRPRI, P_SPORT0_RSCLK, LOCAL_SPORT0_TFS, 0}, {P_SPORT1_DTPRI, + P_SPORT1_TSCLK, P_SPORT1_RFS, P_SPORT1_DRPRI, P_SPORT1_RSCLK, P_SPORT1_TFS, 0} };
static int bf5xx_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) @@ -98,23 +109,21 @@ static int bf5xx_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, ret = -EINVAL; break; default: + printk(KERN_ERR "Unknown SND_SOC_DAIFMT_FORMAT type\n"); ret = -EINVAL; break; }
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { - case SND_SOC_DAIFMT_CBS_CFS: - ret = -EINVAL; - break; - case SND_SOC_DAIFMT_CBM_CFS: - ret = -EINVAL; - break; case SND_SOC_DAIFMT_CBM_CFM: break; + case SND_SOC_DAIFMT_CBS_CFS: + case SND_SOC_DAIFMT_CBM_CFS: case SND_SOC_DAIFMT_CBS_CFM: ret = -EINVAL; break; default: + printk(KERN_ERR "Unknown SND_SOC_DAIFMT_MASTER type\n"); ret = -EINVAL; break; }
At Tue, 21 Oct 2008 11:36:13 +0800, Bryan Wu wrote:
From: Cliff Cai cliff.cai@analog.com
Also include some small coding style cleanup.
Try checkpatch.pl to make sure that you really cleaned up, not added new warnings :)
@@ -98,23 +109,21 @@ static int bf5xx_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, ret = -EINVAL; break; default:
printk(KERN_ERR "Unknown SND_SOC_DAIFMT_FORMAT type\n");
Put some prefix for error messages. Otherwise you don't know who tells it.
ret = -EINVAL; break;}
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
- case SND_SOC_DAIFMT_CBS_CFS:
ret = -EINVAL;break;- case SND_SOC_DAIFMT_CBM_CFS:
ret = -EINVAL;break;
- case SND_SOC_DAIFMT_CBS_CFS:
- case SND_SOC_DAIFMT_CBM_CFS: case SND_SOC_DAIFMT_CBS_CFM: ret = -EINVAL; break; default:
printk(KERN_ERR "Unknown SND_SOC_DAIFMT_MASTER type\n");
Ditto.
thanks,
Takashi
On Tue, Oct 21, 2008 at 08:39:19AM +0200, Takashi Iwai wrote:
At Tue, 21 Oct 2008 11:36:13 +0800, Bryan Wu wrote:
From: Cliff Cai cliff.cai@analog.com
Also include some small coding style cleanup.
Try checkpatch.pl to make sure that you really cleaned up, not added new warnings :)
Also, your Subject: should probably be moved in here and a shorter version used for the Subject: line. In general the entire subject line should be shorter than 80 columns otherwise it doesn't work too well when viewing the logs.
participants (4)
-
Bryan Wu -
Cai, Cliff -
Mark Brown -
Takashi Iwai