[PATCH 0/7] WM8580 updates

[PATCH 0/7] WM8580 updates

[Mark Brown]

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(-)

[PATCH 1/7] ASoC: Add a bit of resource unwinding in the S3C IISv4 driver

[Mark Brown]

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;
 }
 
-- 
1.7.1

[PATCH 2/7] ASoC: Convert WM8580 hw_params to use snd_soc_update_bits()

[Mark Brown]

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;
 }
 
-- 
1.7.1

[PATCH 3/7] ASoC: Remove unused rate selection bitmasks from WM8580

[Mark Brown]

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
 
-- 
1.7.1

[PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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;
 
-- 
1.7.1

[PATCH 5/7] ASoC: Implement BCLK rate selection for WM8580

[Mark Brown]

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;
-- 
1.7.1

[PATCH 6/7] ASoC: Fix inverted WM8580 capture mute control

[Mark Brown]

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

[PATCH 7/7] ASoC: Automatically manage WM8580 DAC OSR

[Mark Brown]

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);
-- 
1.7.1

Re: [PATCH 0/7] WM8580 updates

[Jassi Brar]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/7] WM8580 updates

[Liam Girdwood]

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>
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: [PATCH 6/7] ASoC: Fix inverted WM8580 capture mute control

[Seungwhan Youn]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 6/7] ASoC: Fix inverted WM8580 capture mute control

[Seungwhan Youn]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Seungwhan Youn]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/7] WM8580 updates

[Seungwhan Youn]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.

Re: [PATCH 0/7] WM8580 updates

[Mark Brown]

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?

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Seungwhan Youn]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Jassi Brar]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/7] WM8580 updates

[Seungwhan Youn]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Jassi Brar]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Jassi Brar]

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?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 0/7] WM8580 updates

[Mark Brown]

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.

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Jassi Brar]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.

Re: [PATCH 0/7] WM8580 updates

[Seungwhan Youn]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Jassi Brar]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 4/7] ASoC: Automatically calculate clock ratio for WM8580

[Mark Brown]

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.