[alsa-devel] [PATCH 0/7] WM8580 updates
This batch of patches should get the sample ratio selection for the WM8580 based on the configured sysclk correct, and also fixes a few random other things.
The configuration of the ADC clocking (which is slaved to the DAC clocking) is still not ideal - userspace has to configure playback at the sample rate to be used prior to starting a record - but this needs some more thought at the framework level since this is essentially the same problem we have when multiple DAIs run over one physical interface using TDM. Ideally we'd solve the more general problem.
Mark Brown (7): ASoC: Add a bit of resource unwinding in the S3C IISv4 driver ASoC: Convert WM8580 hw_params to use snd_soc_update_bits() ASoC: Remove unused rate selection bitmasks from WM8580 ASoC: Automatically calculate clock ratio for WM8580 ASoC: Implement BCLK rate selection for WM8580 ASoC: Fix inverted WM8580 capture mute control ASoC: Automatically manage WM8580 DAC OSR
sound/soc/codecs/wm8580.c | 144 +++++++++++++++++++++++++--------- sound/soc/codecs/wm8580.h | 14 ++-- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 11 +++ sound/soc/s3c24xx/smdk64xx_wm8580.c | 9 +- 4 files changed, 128 insertions(+), 50 deletions(-)
There's much more needed but this'll get us started.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c index a13415a..a962847 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c @@ -187,7 +187,18 @@ err:
static __devexit int s3c64xx_i2sv4_dev_remove(struct platform_device *pdev) { + struct s3c_i2sv2_info *i2s = &s3c64xx_i2sv4; + struct resource *res; + snd_soc_unregister_dai(&pdev->dev); + clk_put(i2s->iis_cclk); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) + release_mem_region(res->start, resource_size(res)); + else + dev_warn(&pdev->dev, "Unable to get I2S SFR address\n"); + return 0; }
All the cool kids are using snd_soc_update_bits() these days.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index b1a80e5..4f41419 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -485,9 +485,8 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_codec *codec = rtd->codec; - u16 paifb = snd_soc_read(codec, WM8580_PAIF3 + dai->driver->id); + u16 paifb = 0;
- paifb &= ~WM8580_AIF_LENGTH_MASK; /* bit size */ switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: @@ -505,7 +504,8 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, return -EINVAL; }
- snd_soc_write(codec, WM8580_PAIF3 + dai->driver->id, paifb); + snd_soc_update_bits(codec, WM8580_PAIF3 + dai->driver->id, + WM8580_AIF_LENGTH_MASK, paifb); return 0; }
In the case of the BCLK rate the defines are at best misleading anyway.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 12 ------------ 1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 4f41419..9964f02 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -112,19 +112,7 @@
/* AIF control 1 (registers 9h-bh) */ #define WM8580_AIF_RATE_MASK 0x7 -#define WM8580_AIF_RATE_128 0x0 -#define WM8580_AIF_RATE_192 0x1 -#define WM8580_AIF_RATE_256 0x2 -#define WM8580_AIF_RATE_384 0x3 -#define WM8580_AIF_RATE_512 0x4 -#define WM8580_AIF_RATE_768 0x5 -#define WM8580_AIF_RATE_1152 0x6 - #define WM8580_AIF_BCLKSEL_MASK 0x18 -#define WM8580_AIF_BCLKSEL_64 0x00 -#define WM8580_AIF_BCLKSEL_128 0x08 -#define WM8580_AIF_BCLKSEL_256 0x10 -#define WM8580_AIF_BCLKSEL_SYSCLK 0x18
#define WM8580_AIF_MS 0x20
Implement set_sysclk() and then rather than assuming 256fs use the supplied value to calculate and configure the clock ratio for the currently used sample rate. As a side effect we also end up implementing clock selection for the ADC path.
In order to avoid confusion remove the existing set_clkdiv() based configuration of the clock source for the DAC and update the SMDK64xx driver (which is the only in-tree user of the CODEC).
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 101 +++++++++++++++++++++++++++-------- sound/soc/codecs/wm8580.h | 14 +++--- sound/soc/s3c24xx/smdk64xx_wm8580.c | 9 ++-- 3 files changed, 90 insertions(+), 34 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 9964f02..3d7ff55 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -192,6 +192,7 @@ struct wm8580_priv { u16 reg_cache[WM8580_MAX_REGISTER + 1]; struct pll_state a; struct pll_state b; + int sysclk[2]; };
static const DECLARE_TLV_DB_SCALE(dac_tlv, -12750, 50, 1); @@ -464,6 +465,10 @@ static int wm8580_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id, return 0; }
+static const int wm8580_sysclk_ratios[] = { + 128, 192, 256, 384, 512, 768, 1152, +}; + /* * Set PCM DAI bit size and sample rate. */ @@ -473,7 +478,10 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_codec *codec = rtd->codec; + struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec); + u16 paifa = 0; u16 paifb = 0; + int i, ratio;
/* bit size */ switch (params_format(params)) { @@ -492,6 +500,22 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, return -EINVAL; }
+ /* Look up the SYSCLK ratio; accept only exact matches */ + ratio = wm8580->sysclk[dai->id] / params_rate(params); + for (i = 0; i < ARRAY_SIZE(wm8580_sysclk_ratios); i++) + if (ratio == wm8580_sysclk_ratios[i]) + break; + if (i == ARRAY_SIZE(wm8580_sysclk_ratios)) { + dev_err(codec->dev, "Invalid clock ratio %d/%d\n", + wm8580->sysclk[dai->id], params_rate(params)); + return -EINVAL; + } + paifa |= i; + dev_dbg(codec->dev, "Running at %dfs with %dHz clock\n", + wm8580_sysclk_ratios[i], wm8580->sysclk[dai->driver->id]); + + snd_soc_update_bits(codec, WM8580_PAIF1 + dai->driver->id, + WM8580_AIF_RATE_MASK, paifa); snd_soc_update_bits(codec, WM8580_PAIF3 + dai->driver->id, WM8580_AIF_LENGTH_MASK, paifb); return 0; @@ -501,9 +525,11 @@ static int wm8580_set_paif_dai_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt) { struct snd_soc_codec *codec = codec_dai->codec; + struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec); unsigned int aifa; unsigned int aifb; int can_invert_lrclk; + int sysclk;
aifa = snd_soc_read(codec, WM8580_PAIF1 + codec_dai->driver->id); aifb = snd_soc_read(codec, WM8580_PAIF3 + codec_dai->driver->id); @@ -572,6 +598,8 @@ static int wm8580_set_paif_dai_fmt(struct snd_soc_dai *codec_dai, return -EINVAL; }
+ sysclk = wm8580->sysclk[codec_dai->driver->id]; + snd_soc_write(codec, WM8580_PAIF1 + codec_dai->driver->id, aifa); snd_soc_write(codec, WM8580_PAIF3 + codec_dai->driver->id, aifb);
@@ -611,28 +639,6 @@ static int wm8580_set_dai_clkdiv(struct snd_soc_dai *codec_dai, snd_soc_write(codec, WM8580_PLLB4, reg); break;
- case WM8580_DAC_CLKSEL: - reg = snd_soc_read(codec, WM8580_CLKSEL); - reg &= ~WM8580_CLKSEL_DAC_CLKSEL_MASK; - - switch (div) { - case WM8580_CLKSRC_MCLK: - break; - - case WM8580_CLKSRC_PLLA: - reg |= WM8580_CLKSEL_DAC_CLKSEL_PLLA; - break; - - case WM8580_CLKSRC_PLLB: - reg |= WM8580_CLKSEL_DAC_CLKSEL_PLLB; - break; - - default: - return -EINVAL; - } - snd_soc_write(codec, WM8580_CLKSEL, reg); - break; - case WM8580_CLKOUTSRC: reg = snd_soc_read(codec, WM8580_PLLB4); reg &= ~WM8580_PLLB4_CLKOUTSRC_MASK; @@ -666,6 +672,55 @@ static int wm8580_set_dai_clkdiv(struct snd_soc_dai *codec_dai, return 0; }
+static int wm8580_set_sysclk(struct snd_soc_dai *dai, int clk_id, + unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = dai->codec; + struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec); + int sel, sel_mask, sel_shift; + + switch (dai->driver->id) { + case WM8580_DAI_PAIFTX: + sel_mask = 0x3; + sel_shift = 0; + break; + + case WM8580_DAI_PAIFRX: + sel_mask = 0xc; + sel_shift = 3; + break; + + default: + BUG_ON("Unknown DAI driver ID\n"); + return -EINVAL; + } + + switch (clk_id) { + case WM8580_CLKSRC_ADCMCLK: + if (dai->id != WM8580_DAI_PAIFTX) + return -EINVAL; + sel = 0 << sel_shift; + break; + case WM8580_CLKSRC_PLLA: + sel = 1 << sel_shift; + break; + case WM8580_CLKSRC_PLLB: + sel = 2 << sel_shift; + break; + case WM8580_CLKSRC_MCLK: + sel = 3 << sel_shift; + break; + default: + dev_err(codec->dev, "Unknown clock %d\n", clk_id); + return -EINVAL; + } + + /* We really should validate PLL settings but not yet */ + wm8580->sysclk[dai->id] = freq; + + return snd_soc_update_bits(codec, WM8580_CLKSEL, sel, sel_mask); +} + static int wm8580_digital_mute(struct snd_soc_dai *codec_dai, int mute) { struct snd_soc_codec *codec = codec_dai->codec; @@ -719,6 +774,7 @@ static int wm8580_set_bias_level(struct snd_soc_codec *codec, SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
static struct snd_soc_dai_ops wm8580_dai_ops_playback = { + .set_sysclk = wm8580_set_sysclk, .hw_params = wm8580_paif_hw_params, .set_fmt = wm8580_set_paif_dai_fmt, .set_clkdiv = wm8580_set_dai_clkdiv, @@ -727,6 +783,7 @@ static struct snd_soc_dai_ops wm8580_dai_ops_playback = { };
static struct snd_soc_dai_ops wm8580_dai_ops_capture = { + .set_sysclk = wm8580_set_sysclk, .hw_params = wm8580_paif_hw_params, .set_fmt = wm8580_set_paif_dai_fmt, .set_clkdiv = wm8580_set_dai_clkdiv, diff --git a/sound/soc/codecs/wm8580.h b/sound/soc/codecs/wm8580.h index 8328ef6..1d34656 100644 --- a/sound/soc/codecs/wm8580.h +++ b/sound/soc/codecs/wm8580.h @@ -19,14 +19,14 @@ #define WM8580_PLLB 2
#define WM8580_MCLK 1 -#define WM8580_DAC_CLKSEL 2 -#define WM8580_CLKOUTSRC 3 +#define WM8580_CLKOUTSRC 2
-#define WM8580_CLKSRC_MCLK 1 -#define WM8580_CLKSRC_PLLA 2 -#define WM8580_CLKSRC_PLLB 3 -#define WM8580_CLKSRC_OSC 4 -#define WM8580_CLKSRC_NONE 5 +#define WM8580_CLKSRC_MCLK 1 +#define WM8580_CLKSRC_PLLA 2 +#define WM8580_CLKSRC_PLLB 3 +#define WM8580_CLKSRC_OSC 4 +#define WM8580_CLKSRC_NONE 5 +#define WM8580_CLKSRC_ADCMCLK 6
#define WM8580_DAI_PAIFRX 0 #define WM8580_DAI_PAIFTX 1 diff --git a/sound/soc/s3c24xx/smdk64xx_wm8580.c b/sound/soc/s3c24xx/smdk64xx_wm8580.c index 5c21e26..91367f7 100644 --- a/sound/soc/s3c24xx/smdk64xx_wm8580.c +++ b/sound/soc/s3c24xx/smdk64xx_wm8580.c @@ -113,14 +113,13 @@ static int smdk64xx_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret;
- /* Explicitly set WM8580-DAC to source from MCLK */ - ret = snd_soc_dai_set_clkdiv(codec_dai, WM8580_DAC_CLKSEL, - WM8580_CLKSRC_MCLK); + ret = snd_soc_dai_set_pll(codec_dai, WM8580_PLLA, 0, + SMDK64XX_WM8580_FREQ, pll_out); if (ret < 0) return ret;
- ret = snd_soc_dai_set_pll(codec_dai, WM8580_PLLA, 0, - SMDK64XX_WM8580_FREQ, pll_out); + ret = snd_soc_dai_set_sysclk(codec_dai, WM8580_CLKSRC_PLLA, + pll_out, SND_SOC_CLOCK_IN); if (ret < 0) return ret;
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Implement set_sysclk() and then rather than assuming 256fs use the supplied value to calculate and configure the clock ratio for the currently used sample rate. As a side effect we also end up implementing clock selection for the ADC path.
In order to avoid confusion remove the existing set_clkdiv() based configuration of the clock source for the DAC and update the SMDK64xx driver (which is the only in-tree user of the CODEC).
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
sound/soc/codecs/wm8580.c | 101 +++++++++++++++++++++++++++-------- sound/soc/codecs/wm8580.h | 14 +++--- sound/soc/s3c24xx/smdk64xx_wm8580.c | 9 ++-- 3 files changed, 90 insertions(+), 34 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 9964f02..3d7ff55 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c
(snip)
@@ -666,6 +672,55 @@ static int wm8580_set_dai_clkdiv(struct snd_soc_dai *codec_dai, return 0; }
+static int wm8580_set_sysclk(struct snd_soc_dai *dai, int clk_id,
- unsigned int freq, int dir)
+{
- struct snd_soc_codec *codec = dai->codec;
- struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec);
- int sel, sel_mask, sel_shift;
- switch (dai->driver->id) {
- case WM8580_DAI_PAIFTX:
- sel_mask = 0x3;
- sel_shift = 0;
- break;
- case WM8580_DAI_PAIFRX:
- sel_mask = 0xc;
- sel_shift = 3;
- break;
These CLKSEL settings looks different with my WM8580 datasheet (released March 2009, Rev 4.7). I think these codes look... + case WM8580_DAI_PAIFRX: + sel_mask = 0x3; + sel_shift = 0; + break; + + case WM8580_DAI_PAIFTX: + sel_mask = 0xc; + sel_shift = 2; + break;
- default:
- BUG_ON("Unknown DAI driver ID\n");
- return -EINVAL;
- }
- switch (clk_id) {
- case WM8580_CLKSRC_ADCMCLK:
- if (dai->id != WM8580_DAI_PAIFTX)
- return -EINVAL;
- sel = 0 << sel_shift;
- break;
During my test case with smdk6410 board, clock source of ADC should be set by ADCMCLK, if we want to hear a correct sound on playback and capture. And when ADC select MCLK or PLLA, source clock was broken both of playback and capture. Can you verify this(set source clock of ADC set to ADCMCLK) is right or is there something missing on other settings?
- case WM8580_CLKSRC_PLLA:
- sel = 1 << sel_shift;
- break;
- case WM8580_CLKSRC_PLLB:
- sel = 2 << sel_shift;
- break;
- case WM8580_CLKSRC_MCLK:
- sel = 3 << sel_shift;
- break;
- default:
- dev_err(codec->dev, "Unknown clock %d\n", clk_id);
- return -EINVAL;
- }
(snip)
-- 1.7.1
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Thanks,
Claude
On Sun, Aug 15, 2010 at 06:00:50PM +0900, Seungwhan Youn wrote:
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown
- switch (dai->driver->id) {
- case WM8580_DAI_PAIFTX:
- sel_mask = 0x3;
- sel_shift = 0;
- break;
- case WM8580_DAI_PAIFRX:
- sel_mask = 0xc;
- sel_shift = 3;
- break;
These CLKSEL settings looks different with my WM8580 datasheet (released March 2009, Rev 4.7). I think these codes look...
case WM8580_DAI_PAIFRX:sel_mask = 0x3;sel_shift = 0;break;
This one is exactly what's above as far as I can tell?....
case WM8580_DAI_PAIFTX:sel_mask = 0xc;sel_shift = 2;break;
...but the shift is typoed here, yes.
- switch (clk_id) {
- case WM8580_CLKSRC_ADCMCLK:
- if (dai->id != WM8580_DAI_PAIFTX)
- return -EINVAL;
- sel = 0 << sel_shift;
- break;
During my test case with smdk6410 board, clock source of ADC should be set by ADCMCLK, if we want to hear a correct sound on playback and capture. And when ADC select MCLK or PLLA, source clock was broken both of playback and capture. Can you verify this(set source clock of ADC set to ADCMCLK) is right or is there something missing on other settings?
This should not be required in general. Without knowing anything about the tests you did, the problems you observed or why you believe this configuration helps it's a bit hard to comment in detail. I did test briefly since I remembered the use of this from your code.
My best guess would be that this is related to the issue I mentioned in the cover mail with multiple DAI links on one physical DAI. Since the DAIs are cross wired we really shouldn't have both CODEC interfaces driving the audio interface simultaneously.
What would be much more straightforward for this configuration is to run the PLL output from the CODEC into the CPU and then have the CPU master the actual audio interface but Jassi was fairly insistent on having the CODEC master the bus and I'd need to verify again with the schematic if the appropriate clock lines are run. Actually, I think I'll just do that if the hardware allows.
On Sun, Aug 15, 2010 at 8:09 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
What would be much more straightforward for this configuration is to run the PLL output from the CODEC into the CPU and then have the CPU master the actual audio interface but Jassi was fairly insistent on having the CODEC master the bus and I'd need to verify again with the schematic if the appropriate clock lines are run. Actually, I think I'll just do that if the hardware allows.
For us, having CPU in slave mode is more important than clearing all the use cases perfectly on a _reference_ platform. More so when the 'problem' can be obviously attributed to the h/w design.
So please modify only if you must, otherwise, as I said, we'd prefer CPU slave mode working by default in mainline.
Thanks.
On Mon, Aug 16, 2010 at 01:36:50PM +0900, Jassi Brar wrote:
For us, having CPU in slave mode is more important than clearing all the use cases perfectly on a _reference_ platform. More so when the 'problem' can be obviously attributed to the h/w design.
Hrm, OK - this is the opposite way around to what most CPU vendors would ask for. Is there any particular reason for this preference?
So please modify only if you must, otherwise, as I said, we'd prefer CPU slave mode working by default in mainline.
Well, I'd like to see the driver working as well as possible, especially since people tend to take reference code from mainline and clone it. The way the hardware is the clock tree should definitely be rooted in the WM8580, it's just the LRCLK and BCLK I'm thinking about here.
On Mon, Aug 16, 2010 at 7:20 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 01:36:50PM +0900, Jassi Brar wrote:
For us, having CPU in slave mode is more important than clearing all the use cases perfectly on a _reference_ platform. More so when the 'problem' can be obviously attributed to the h/w design.
Hrm, OK - this is the opposite way around to what most CPU vendors would ask for. Is there any particular reason for this preference?
When CPU MASTER was default, people asked for SLAVE. But nobody asked for MASTER since we selected SLAVE by default. Both work equally well, it just saves our efforts. Btw, I thought CODEC usually provide more accurate signals and hence CPU SLAVE is better. Is is too wrong?
On Mon, Aug 16, 2010 at 09:51:35PM +0900, Jassi Brar wrote:
When CPU MASTER was default, people asked for SLAVE. But nobody asked for MASTER since we selected SLAVE by default. Both work equally well, it just saves our efforts.
What were people actually complaining about? I suspect it was the root clock for the audio tree that they were concerned about rather than the I2S bus clock.
Btw, I thought CODEC usually provide more accurate signals and hence CPU SLAVE is better. Is is too wrong?
Well, the main issue is the quality of the root clock for the tree which I'd not propose to change away from the CODEC. In terms of just passing through a well generated clock at a useful rate it's fairly rare to have problems, the problem is getting that 256fs (or whatever) root clock.
On Tue, Aug 17, 2010 at 12:19 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 09:51:35PM +0900, Jassi Brar wrote:
When CPU MASTER was default, people asked for SLAVE. But nobody asked for MASTER since we selected SLAVE by default. Both work equally well, it just saves our efforts.
What were people actually complaining about? I suspect it was the root clock for the audio tree that they were concerned about rather than the I2S bus clock.
No complaints. I just get the task to do. I guess most quality conscious products can afford to attach a dedicated OSC to a good CODEC. A CODEC already specifies the clocks it support and usually comes with 'preferred' input clocks. So, just having a specified rating accurate enough OSC can take care of quality. On the other hand the clock sources on CPU side are not particularly accurate for audio-clock generation. Or so have I seen so far.
On Tue, Aug 17, 2010 at 08:14:43AM +0900, Jassi Brar wrote:
I guess most quality conscious products can afford to attach a dedicated OSC to a good CODEC. A CODEC already specifies the clocks it support and usually comes with 'preferred' input clocks. So, just having a specified rating accurate enough OSC can take care of quality. On the other hand the clock sources on CPU side are not particularly accurate for audio-clock generation. Or so have I seen so far.
Right, this shouldn't be an issue with the change I proposed - the clocks are still rooted from the CODEC and its clock generation facilities would still be used, it's just that they get routed differently.
The issue with using most CPU clocks isn't really the dedicated oscillator so much as the ability to generate non-integer divisions of whatever input clock is available. If this can't be done then it can be hard to generate the full range of common audio frequencies.
On Tue, Aug 17, 2010 at 6:46 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Tue, Aug 17, 2010 at 08:14:43AM +0900, Jassi Brar wrote:
I guess most quality conscious products can afford to attach a dedicated OSC to a good CODEC. A CODEC already specifies the clocks it support and usually comes with 'preferred' input clocks. So, just having a specified rating accurate enough OSC can take care of quality. On the other hand the clock sources on CPU side are not particularly accurate for audio-clock generation. Or so have I seen so far.
Right, this shouldn't be an issue with the change I proposed - the clocks are still rooted from the CODEC and its clock generation facilities would still be used, it's just that they get routed differently.
The issue with using most CPU clocks isn't really the dedicated oscillator so much as the ability to generate non-integer divisions of whatever input clock is available. If this can't be done then it can be hard to generate the full range of common audio frequencies.
Ok, now that I am faced with supporting latest SMDKs that use codecs other than WM8580 (like wm8994), I think we'd better break the MACHINE driver into SMDK specific (setup CPU master, CODEC slave and root-clock sourced acc to option provided vai platform_data) and CODEC specific part. That will also help code reuse.
Any opinions, before I start working on it?
Thanks, Jassi
On Tue, Aug 31, 2010 at 03:46:44PM +0900, Jassi Brar wrote:
Ok, now that I am faced with supporting latest SMDKs that use codecs other than WM8580 (like wm8994), I think we'd better break the MACHINE driver into SMDK specific (setup CPU master, CODEC slave and root-clock sourced acc to option provided vai platform_data) and CODEC specific part. That will also help code reuse.
Any opinions, before I start working on it?
If you're looking at this it'd be a good idea to look at pulling the clocking configuration for the CPU into the CPU driver - the Samsung CPU hardware is fairly straightforward and easy to use and it should be possible to automate much more of the configuration, at least by default. At the minute there's a lot of cut'n'paste code for the clocking configuration which could do with being shared.
In terms of the stuff that is genuinely board specific I'd need to look at the designs and discuss the use cases with you to really comment in too much detail. The WM8994 is a vastly more flexible part and there's a number of interesting things you can do with it that might result in a noticably different clocking configuration from the machine driver, especially around things like the analogue bypass cases and keeping the the device active during suspend, but a lot of this depends on the system design as a whole.
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
.....
+static int wm8580_set_sysclk(struct snd_soc_dai *dai, int clk_id,
- unsigned int freq, int dir)
+{
- struct snd_soc_codec *codec = dai->codec;
- struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec);
- int sel, sel_mask, sel_shift;
- switch (dai->driver->id) {
- case WM8580_DAI_PAIFTX:
should be WM8580_DAI_PAIFRX:
Because, WM8580_DAI_PAIFTX --> Capture --> ADC.
- sel_mask = 0x3;
- sel_shift = 0;
- break;
- case WM8580_DAI_PAIFRX: --> TX
should be WM8580_DAI_PAIFTX:
Because, WM8580_DAI_PAIFRX --> Playback --> DAC.
- sel_mask = 0xc;
- sel_shift = 3;
Shouldn't the shift be 2 ?
....
- /* We really should validate PLL settings but not yet */
- wm8580->sysclk[dai->id] = freq;
- return snd_soc_update_bits(codec, WM8580_CLKSEL, sel, sel_mask);
Seems the value and mask arguments are swapped ?
Thanks, Claude
On Mon, Aug 16, 2010 at 01:16:15PM +0900, Seungwhan Youn wrote:
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown
So, this is a great example of a general problem with your mails: you're generally very light on detail. This makes it hard to work out exactly what you're talking about. This applies to both regular e-mails and also patches where your descriptions also tend towards the terse.
- switch (dai->driver->id) {
- case WM8580_DAI_PAIFTX:
should be WM8580_DAI_PAIFRX:
Because, WM8580_DAI_PAIFTX --> Capture --> ADC.
Gah, right.
- return snd_soc_update_bits(codec, WM8580_CLKSEL, sel, sel_mask);
Seems the value and mask arguments are swapped ?
Yup.
On Mon, Aug 16, 2010 at 9:21 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 01:16:15PM +0900, Seungwhan Youn wrote:
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown
So, this is a great example of a general problem with your mails: you're generally very light on detail. This makes it hard to work out exactly what you're talking about. This applies to both regular e-mails and also patches where your descriptions also tend towards the terse.
If it's a fault, it's mine. Since he couldn't explain clearly the last time and/or you couldn't understand, I suggested he be terse and exact.
Drive a minimal supported number of clocks required for the current bit format in master mode. In slave mode this setting has no effect.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 3d7ff55..6262124 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -486,14 +486,18 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, /* bit size */ switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: + paifa |= 0x8; break; case SNDRV_PCM_FORMAT_S20_3LE: + paifa |= 0x10; paifb |= WM8580_AIF_LENGTH_20; break; case SNDRV_PCM_FORMAT_S24_LE: + paifa |= 0x10; paifb |= WM8580_AIF_LENGTH_24; break; case SNDRV_PCM_FORMAT_S32_LE: + paifa |= 0x10; paifb |= WM8580_AIF_LENGTH_24; break; default: @@ -515,7 +519,8 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, wm8580_sysclk_ratios[i], wm8580->sysclk[dai->driver->id]);
snd_soc_update_bits(codec, WM8580_PAIF1 + dai->driver->id, - WM8580_AIF_RATE_MASK, paifa); + WM8580_AIF_RATE_MASK | WM8580_AIF_BCLKSEL_MASK, + paifa); snd_soc_update_bits(codec, WM8580_PAIF3 + dai->driver->id, WM8580_AIF_LENGTH_MASK, paifb); return 0;
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 6262124..357f7d5 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -262,7 +262,7 @@ SOC_SINGLE("DAC1 Switch", WM8580_DAC_CONTROL5, 0, 1, 0), SOC_SINGLE("DAC2 Switch", WM8580_DAC_CONTROL5, 1, 1, 0), SOC_SINGLE("DAC3 Switch", WM8580_DAC_CONTROL5, 2, 1, 0),
-SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 0), +SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 1), SOC_SINGLE("Capture High-Pass Filter Switch", WM8580_ADC_CONTROL1, 4, 1, 0), };
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
sound/soc/codecs/wm8580.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 6262124..357f7d5 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -262,7 +262,7 @@ SOC_SINGLE("DAC1 Switch", WM8580_DAC_CONTROL5, 0, 1, 0), SOC_SINGLE("DAC2 Switch", WM8580_DAC_CONTROL5, 1, 1, 0), SOC_SINGLE("DAC3 Switch", WM8580_DAC_CONTROL5, 2, 1, 0),
-SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 0), +SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 1), SOC_SINGLE("Capture High-Pass Filter Switch", WM8580_ADC_CONTROL1, 4, 1, 0), };
-- 1.7.1
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I can't apply only this patch on Liam's branch 'for-2.6.37', 'for-2.6.36' and 'topic/multi-component' . Can you tell me which branch did you work on?
Thank you,
Claude.
On Sun, Aug 15, 2010 at 1:50 PM, Seungwhan Youn claude.youn@gmail.com wrote:
On Sat, Aug 14, 2010 at 4:35 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
sound/soc/codecs/wm8580.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 6262124..357f7d5 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -262,7 +262,7 @@ SOC_SINGLE("DAC1 Switch", WM8580_DAC_CONTROL5, 0, 1, 0), SOC_SINGLE("DAC2 Switch", WM8580_DAC_CONTROL5, 1, 1, 0), SOC_SINGLE("DAC3 Switch", WM8580_DAC_CONTROL5, 2, 1, 0),
-SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 0), +SOC_DOUBLE("Capture Switch", WM8580_ADC_CONTROL1, 0, 1, 1, 1), SOC_SINGLE("Capture High-Pass Filter Switch", WM8580_ADC_CONTROL1, 4, 1, 0), };
-- 1.7.1
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I can't apply only this patch on Liam's branch 'for-2.6.37', 'for-2.6.36' and 'topic/multi-component' . Can you tell me which branch did you work on?
Sorry, I found your working branch on your git rep. 'for-2.6.37'. :-)
Thanks,
Claude
The DAC OSR should be selected based on the sample clock ratio.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8580.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8580.c b/sound/soc/codecs/wm8580.c index 357f7d5..cb862df 100644 --- a/sound/soc/codecs/wm8580.c +++ b/sound/soc/codecs/wm8580.c @@ -94,6 +94,8 @@
#define WM8580_MAX_REGISTER 0x35
+#define WM8580_DACOSR 0x40 + /* PLLB4 (register 7h) */ #define WM8580_PLLB4_MCLKOUTSRC_MASK 0x60 #define WM8580_PLLB4_MCLKOUTSRC_PLLA 0x20 @@ -481,7 +483,7 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, struct wm8580_priv *wm8580 = snd_soc_codec_get_drvdata(codec); u16 paifa = 0; u16 paifb = 0; - int i, ratio; + int i, ratio, osr;
/* bit size */ switch (params_format(params)) { @@ -518,6 +520,22 @@ static int wm8580_paif_hw_params(struct snd_pcm_substream *substream, dev_dbg(codec->dev, "Running at %dfs with %dHz clock\n", wm8580_sysclk_ratios[i], wm8580->sysclk[dai->driver->id]);
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + switch (ratio) { + case 128: + case 192: + osr = WM8580_DACOSR; + dev_dbg(codec->dev, "Selecting 64x OSR\n"); + break; + default: + osr = 0; + dev_dbg(codec->dev, "Selecting 128x OSR\n"); + break; + } + + snd_soc_update_bits(codec, WM8580_PAIF3, WM8580_DACOSR, osr); + } + snd_soc_update_bits(codec, WM8580_PAIF1 + dai->driver->id, WM8580_AIF_RATE_MASK | WM8580_AIF_BCLKSEL_MASK, paifa);
On Sat, Aug 14, 2010 at 4:33 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This batch of patches should get the sample ratio selection for the WM8580 based on the configured sysclk correct, and also fixes a few random other things.
The configuration of the ADC clocking (which is slaved to the DAC clocking) is still not ideal - userspace has to configure playback at the sample rate to be used prior to starting a record - but this needs some more thought at the framework level since this is essentially the same problem we have when multiple DAIs run over one physical interface using TDM. Ideally we'd solve the more general problem.
Mark Brown (7): ASoC: Add a bit of resource unwinding in the S3C IISv4 driver ASoC: Convert WM8580 hw_params to use snd_soc_update_bits() ASoC: Remove unused rate selection bitmasks from WM8580 ASoC: Automatically calculate clock ratio for WM8580 ASoC: Implement BCLK rate selection for WM8580 ASoC: Fix inverted WM8580 capture mute control ASoC: Automatically manage WM8580 DAC OSR
Much needed changes. Thanks a lot. Happily, I am too occupied with other matters as well these days. I hope Claude(Seungwhan Youn) tests and give status on the patches.
Regards.
On Sat, Aug 14, 2010 at 1:09 PM, Jassi Brar jassisinghbrar@gmail.com wrote:
On Sat, Aug 14, 2010 at 4:33 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This batch of patches should get the sample ratio selection for the WM8580 based on the configured sysclk correct, and also fixes a few random other things.
The configuration of the ADC clocking (which is slaved to the DAC clocking) is still not ideal - userspace has to configure playback at the sample rate to be used prior to starting a record - but this needs some more thought at the framework level since this is essentially the same problem we have when multiple DAIs run over one physical interface using TDM. Ideally we'd solve the more general problem.
Mark Brown (7): ASoC: Add a bit of resource unwinding in the S3C IISv4 driver ASoC: Convert WM8580 hw_params to use snd_soc_update_bits() ASoC: Remove unused rate selection bitmasks from WM8580 ASoC: Automatically calculate clock ratio for WM8580 ASoC: Implement BCLK rate selection for WM8580 ASoC: Fix inverted WM8580 capture mute control ASoC: Automatically manage WM8580 DAC OSR
Much needed changes. Thanks a lot. Happily, I am too occupied with other matters as well these days. I hope Claude(Seungwhan Youn) tests and give status on the patches.
Hi,
First of all, I'm really happy to test this patch-set. Thanks Mark. :-)
Anyway, I tested this patch-set about WM8580 updates with SMDK6410 board. Unfortunately, I faced with some problem in capture.
Briefly report of test is :- o Playback test with various frequency ; all works fine. 8000 Hz sampling freq. 11025 Hz sampling freq. 16000 Hz sampling freq. 22050 Hz sampling freq. 44100 Hz sampling freq. 48000 Hz sampling freq. 88200 Hz sampling freq. o Capture test ; it doesn't work, even after capture, playback also doesn't work.
I commented more details at corresponding patch.
Thanks, Claude
On Sun, Aug 15, 2010 at 8:10 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Sun, Aug 15, 2010 at 06:21:08PM +0900, Seungwhan Youn wrote:
o Capture test ; it doesn't work, even after capture, playback also doesn't work.
This doesn't match up with my testing at all, especially the impact on playback. What revision of the SMDK hardware are you using?
Test Environments
SMDK6410 board - CPU board Rev. 1.0 - Base board Rev. 1.0 (2008.07.23)
Board switch settings - CPU board ; CFG6 - 1111 (all on) - Base board - CFG1 - 0000 (all off) - CFG2 - 1000 (only 1 pin is on, others off) - CFG5 - set I2SMULTI_CDCLK (pin 1-2 connected)
Kernel - repos ; git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git - branch ; for-2.6.37 - pull time ; 2010-08-16 17:36 - config ; Add I2S driver and ALSA as a static into kernel(not a module), and remove AC97.
Test Process and Log capture... -- Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.35-rc1-81021-gec62dbd (claude@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2000 CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: SMDK6410 Ignoring unrecognised tag 0x41001099 Memory policy: ECC disabled, Data cache writeback CPU S3C6410 (id 0x36410101) S3C24XX Clocks, Copyright 2004 Simtec Electronics ... mmc0: Minimum clock frequency too high for identification mode s3c6400_setup_sdhci_cfg_card: CTRL 2=c0004100, 3=80808080 asoc: wm8580-hifi-playback <-> s3c64xx-iis-v4 mapping ok asoc: wm8580-hifi-capture <-> s3c64xx-iis-v4 mapping ok ALSA device list: #0: smdk64xx VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) ... Samsung SMDK Board on a armv6l Samsung login: root login[981]: root login on 'ttySAC0' [root@Samsung ~]# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: smdk64xx [smdk64xx], device 0: Playback wm8580-hifi-playback-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 [root@Samsung ~]# speaker-test -tsine
speaker-test 1.0.15
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Sine wave rate is 440.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 32768 Period size range from 1024 to 2048 Using max buffer size 32768 Periods = 4 was set period_size = 2048 was set buffer_size = 32768 0 - Front Left Time per period = 2.326402 0 - Front Left Time per period = 2.986289 0 - Front Left
--> In this point, I can hear clear sound of sine wave so I pushed 'ctrl+c' to stop it.
[root@Samsung ~]# arecord -Dhw:0 -d5 -fS16_LE -r48000 -c2 > /tmp/tmp.wav arecord: main:546: audio open error: No such device [root@Samsung ~]# arecord -Dhw:0,1 -d5 -fS16_LE -r48000 -c2 > /tmp/tmp.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo s3c2412_snd_lrsync: timeout s3c64xx-iis-v4 s3c64xx-iis-v4: RXDIS: Invalid MODE 0 in IISMOD arecord: pcm_read:1347: read error: Connection timed out [root@Samsung ~]# arecord -Dhw:0,1 -d5 -fS16_LE -r8000 -c2 > /tmp/tmp.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo [root@Samsung ~]# aplay /tmp/tmp.wav Playing WAVE '/tmp/tmp.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo [root@Samsung ~]# arecord -Dhw:0,1 -d5 -fS16_LE -r48000 -c2 > /tmp/tmp.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo s3c2412_snd_lrsync: timeout s3c64xx-iis-v4 s3c64xx-iis-v4: RXDIS: Invalid MODE 0 in IISMOD arecord: pcm_read:1347: read error: Connection timed out [root@Samsung ~]# speaker-test -tsine
speaker-test 1.0.15
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Sine wave rate is 440.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 32768 Period size range from 1024 to 2048 Using max buffer size 32768 Periods = 4 was set period_size = 2048 was set buffer_size = 32768 0 - Front Left s3c2412_snd_lrsync: timeout s3c64xx_dma_stop: channel still active Write error: -110,Connection timed out xrun_recovery failed: -110,Connection timed out Transfer failed: Operation not permitted
--> I didn't do anything, but stopped with noise...
[root@Samsung ~]# --
Best Regards, Claude
On Mon, Aug 16, 2010 at 06:44:28PM +0900, Seungwhan Youn wrote:
On Sun, Aug 15, 2010 at 8:10 PM, Mark Brown
- CPU board Rev. 1.0
- Base board Rev. 1.0 (2008.07.23)
Board switch settings
- Base board
- CFG1 - 0000 (all off)
- CFG2 - 1000 (only 1 pin is on, others off)
Hrm, I have CFG2 all on. Why would I want a mixed configuration?
- CFG5 - set I2SMULTI_CDCLK (pin 1-2 connected)
I have pins 2 and 3 connected (which was the board default as shipped) but this does sound like it might be relevant. Unfortunately I don't have a schematic for the R1.0 base board so I can't comment on this configuration. If you could supply me with an updated schematic that'd be great.
[root@Samsung ~]# arecord -Dhw:0,1 -d5 -fS16_LE -r48000 -c2 >
-f dat might be easier here FWIW. Once the S3C CPU has started reporting errors it tends not to recover terribly well so any further tests you've done without a reboot are a bit suspect.
On Mon, Aug 16, 2010 at 11:49 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 06:44:28PM +0900, Seungwhan Youn wrote:
On Sun, Aug 15, 2010 at 8:10 PM, Mark Brown
- CPU board Rev. 1.0 - Base board Rev. 1.0 (2008.07.23)
Board switch settings
- Base board - CFG1 - 0000 (all off) - CFG2 - 1000 (only 1 pin is on, others off)
Hrm, I have CFG2 all on. Why would I want a mixed configuration?
- CFG5 - set I2SMULTI_CDCLK (pin 1-2 connected)
I have pins 2 and 3 connected (which was the board default as shipped) but this does sound like it might be relevant. Unfortunately I don't have a schematic for the R1.0 base board so I can't comment on this configuration. If you could supply me with an updated schematic that'd be great.
[root@Samsung ~]# arecord -Dhw:0,1 -d5 -fS16_LE -r48000 -c2 >
-f dat might be easier here FWIW. Once the S3C CPU has started reporting errors it tends not to recover terribly well so any further tests you've done without a reboot are a bit suspect.
Hi,
I setup my SMDK6410 as you note before. and, test again. I'm concerned about my test process is right, because capture is still not working on my test. Is there any problem with my test? or should I have to write some more information about this test?
Details are following... :-
Board environment - CPU board setting - CFG6 - 1111 (all on) - Base board settings - CFG1 - 0000 (all off) - CFG2 - 1111 (all on) - CFG5 - connect pin 2 and 3
Kernel - repos ; git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git - branch ; for-2.6.37 - based on ; commit id - b6905d0b1652efddb96cefdb3c8552cac8d98ed2 - config ; Add I2S driver and ALSA as a static into kernel(not a module), remove AC97, and remove 'Secure Digital Host Controller Interface support' on SDMMC, because of compile error. (http://www.spinics.net/lists/arm-kernel/msg95847.html)
Test Process and Log capture... (removed lot's of "WARNING: at fs/inode.c:692 unlock_new_inode+0x20/0x3c()" warnings) -- Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.36-rc1-90955-gb6905d0 (claude@starstone) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) )0 CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: SMDK6410 Ignoring unrecognised tag 0x41001099 Memory policy: ECC disabled, Data cache writeback CPU S3C6410 (id 0x36410101) S3C24XX Clocks, Copyright 2004 Simtec Electronics ... asoc: wm8580-hifi-playback <-> s3c64xx-iis-v4 mapping ok asoc: wm8580-hifi-capture <-> s3c64xx-iis-v4 mapping ok ALSA device list: #0: smdk64xx VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 s3c-rtc s3c64xx-rtc: hctosys: invalid date/time RAMDISK: cramfs filesystem found at block 0 ... Samsung SMDK Board on a armv6l Samsung login: root login[981]: root login on 'ttySAC0' [root@Samsung ~]# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: smdk64xx [smdk64xx], device 0: Playback wm8580-hifi-playback-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 [root@Samsung ~]# speaker-test -tsine
speaker-test 1.0.15
Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Sine wave rate is 440.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 2048 to 32768 Period size range from 1024 to 2048 Using max buffer size 32768 Periods = 4 was set period_size = 2048 was set buffer_size = 32768 0 - Front Left Time per period = 2.583049 0 - Front Left Time per period = 2.986436 0 - Front Left Time per period = 2.986436 0 - Front Left
--> I pushed 'ctrl+c', because I can hear clear sine sound.
[root@Samsung ~]# arecord -Dhw:0,1 -d5 -c2 -fS16_LE > /tmp/tmp.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
--> record finished about 3sec later, not 5sec.
[root@Samsung ~]# aplay /tmp/tmp.wav Playing WAVE '/tmp/tmp.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
--> When I start to play captured file, I heard a noise sound but finished without error.
[root@Samsung ~]# --
Best Regards, Claude.
On Fri, 2010-08-13 at 20:33 +0100, Mark Brown wrote:
This batch of patches should get the sample ratio selection for the WM8580 based on the configured sysclk correct, and also fixes a few random other things.
The configuration of the ADC clocking (which is slaved to the DAC clocking) is still not ideal - userspace has to configure playback at the sample rate to be used prior to starting a record - but this needs some more thought at the framework level since this is essentially the same problem we have when multiple DAIs run over one physical interface using TDM. Ideally we'd solve the more general problem.
Mark Brown (7): ASoC: Add a bit of resource unwinding in the S3C IISv4 driver ASoC: Convert WM8580 hw_params to use snd_soc_update_bits() ASoC: Remove unused rate selection bitmasks from WM8580 ASoC: Automatically calculate clock ratio for WM8580 ASoC: Implement BCLK rate selection for WM8580 ASoC: Fix inverted WM8580 capture mute control ASoC: Automatically manage WM8580 DAC OSR
sound/soc/codecs/wm8580.c | 144 +++++++++++++++++++++++++--------- sound/soc/codecs/wm8580.h | 14 ++-- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 11 +++ sound/soc/s3c24xx/smdk64xx_wm8580.c | 9 +- 4 files changed, 128 insertions(+), 50 deletions(-)
All
Acked-by: Liam Girdwood lrg@slimlogic.co.uk
participants (4)
-
Jassi Brar -
Liam Girdwood -
Mark Brown -
Seungwhan Youn