sound/soc/codecs: add LAPIS Semiconductor ML26124

Add machine driver for LAPIS Semiconductor ML7213 IOH.

Quoted 1 line

Add machine driver for LAPIS Semiconductor ML7213 IOH.

This needs to come after you add the base platform support in the series
- clearly this won't work without the CPU side drivers it depends on.

BTW, every time I send mail to "[email protected]",
I receive returned mail "Your message to Alsa-devel awaits moderator approval". Is this normal things ?
Of course, I've already subscribed to "[email protected]".

At Fri, 2 Dec 2011 14:33:59 +0900,

Quoted 4 lines · Tomoya MORINAGA

BTW, every time I send mail to "[email protected]",
I receive returned mail "Your message to Alsa-devel awaits moderator approval". Is this normal things ?
Of course, I've already subscribed to "[email protected]".

Did you subscribe with your gmail address, too?

2011/12/2 Takashi Iwai <[email protected]>:

Quoted 8 lines

At Fri, 2 Dec 2011 14:33:59 +0900,

Quoted 4 lines · Tomoya MORINAGA

BTW, every time I send mail to "[email protected]",
I receive returned mail "Your message to Alsa-devel awaits moderator approval". Is this normal things ?
Of course, I've already subscribed to "[email protected]".

Did you subscribe with your gmail address, too?

Yes, I subscribed this gmail address.

At Fri, 2 Dec 2011 15:18:06 +0900,

Quoted 9 lines · Tomoya MORINAGA

2011/12/2 Takashi Iwai <[email protected]>:

Quoted 7 lines

At Fri, 2 Dec 2011 14:33:59 +0900,

Quoted 4 lines · Tomoya MORINAGA

BTW, every time I send mail to "[email protected]",
I receive returned mail "Your message to Alsa-devel awaits moderator approval". Is this normal things ?
Of course, I've already subscribed to "[email protected]".

Quoted 2 lines

Quoted 1 line

Did you subscribe with your gmail address, too?

Yes, I subscribed this gmail address.

The mail-server doesn't think so.
Maybe with a different address like mail.google.com or such?

Quoted 1 line

Quoted 1 line

Quoted 1 line

auth bd2de885 subscribe alsa-devel [email protected]

2011/12/2 Takashi Iwai <[email protected]>:

Quoted 14 lines

At Fri, 2 Dec 2011 15:18:06 +0900,

Quoted 11 lines · Tomoya MORINAGA

2011/12/2 Takashi Iwai <[email protected]>:

Quoted 8 lines

At Fri, 2 Dec 2011 14:33:59 +0900,

Quoted 4 lines · Tomoya MORINAGA

BTW, every time I send mail to "[email protected]",
I receive returned mail "Your message to Alsa-devel awaits moderator approval". Is this normal things ?
Of course, I've already subscribed to "[email protected]".

Did you subscribe with your gmail address, too?

Yes, I subscribed this gmail address.

Quoted 3 lines

The mail-server doesn't think so.
Maybe with a different address like mail.google.com or such?

For confirmation, I registered my e-mail account again yesterday. As a result, I got the following mail (Already registered).

From: [email protected]
12月1日 (1日前)

Quoted 1 line

As a result, I got the following mail (Already registered).>>>> From: [email protected]>> 12月1日 (1日前)>> Why vger?>

2011/12/2 Takashi Iwai <[email protected]>:>> For confirmation, I registered my e-mail account again yesterday.

Quoted 1 line

Quoted 1 line

As a result, I got the following mail (Already registered).>>>> From: [email protected]>> 12月1日 (1日前)>> Why vger?>

I referred http://vger.kernel.org/vger-lists.html#alsa-devel.
This looks not TRUE.

I must subscribe from below ?
https://lists.sourceforge.net/lists/listinfo/alsa-announce

2011/11/21 Mark Brown <[email protected]>:

Quoted 2 lines

This needs to come after you add the base platform support in the series
- clearly this won't work without the CPU side drivers it depends on.

Most of the chipset drivers for Intel Atom E6xx series have already accepted by upstream.
e.g. i2c-eg20t, pch_dma, pch_uart, spi-topcliff-pch, ml-ioh-gpio, etc...

Quoted 4 lines

2011/11/21 Mark Brown <[email protected]>:

Quoted 2 lines

This needs to come after you add the base platform support in the series
- clearly this won't work without the CPU side drivers it depends on.

Quoted 3 lines

Most of the chipset drivers for Intel Atom E6xx series have already accepted by upstream.
e.g. i2c-eg20t, pch_dma, pch_uart, spi-topcliff-pch, ml-ioh-gpio, etc...

The CPU side audio drivers are not there - there seemed to be some quite serious review issues with those.

2011/12/2 Mark Brown <[email protected]>:

Quoted 2 lines

The CPU side audio drivers are not there - there seemed to be some quite serious review issues with those.

Let me clarify your saying.
Does the above "audio drivers" mean i2s (of south bridge) driver or HD audio (of north bridge) or another?

Quoted 8 lines

2011/12/2 Mark Brown <[email protected]>:

Quoted 2 lines

The CPU side audio drivers are not there - there seemed to be some quite serious review issues with those.

Let me clarify your saying.
Does the above "audio drivers" mean i2s (of south bridge) driver or HD audio (of north bridge) or another?

I2S and audio DMA.

Do you mean you cannot review this codec driver any more unless I provide other 2 drivers (machine and platform) ?

Quoted 1 line

+#define I2S_CH0_MCLK (12288000) /* Master Clock Frequency[Hz] */

This looks like it should be board specific?

struct snd_soc_ops {
...
};

On the other hand, tegra_i2s.c describes like below.

static const struct snd_soc_dai_ops tegra_i2s_dai_ops = {
...
};

Which is true as modern driver ? or case by case ?

Quoted 3 lines

Quoted 2 lines

+#define I2S_CH0_MCLK (12288000) /* Master Clock Frequency[Hz] */

This looks like it should be board specific?

Should our platform driver use "clk_get()" ?
If no, how should our driver get the value ?

Quoted 10 lines

struct snd_soc_ops {
...
};

On the other hand, tegra_i2s.c describes like below.

static const struct snd_soc_dai_ops tegra_i2s_dai_ops = {
...
};

Quoted 1 line

Which is true as modern driver ? or case by case ?

The latter.  With things like this it would be *really* helpful if you could take a step back and think about what the differences mean and why they are different.

2011/12/12 Mark Brown <[email protected]>:

Quoted 3 lines

The latter.  With things like this it would be *really* helpful if you could take a step back and think about what the differences mean and why they are different.

Our driver needs ".pointer" method.
However, "struct snd_soc_dai_ops" doesn't have the method. So, I think "struct snd_soc_dai_ops" cannot be applied to our driver.

Searching other drivers, "blackfin/bf5xx-i2s-pcm.c" uses "struct snd_soc_ops" not "struct snd_soc_dai_ops".
Let me know your opinion.

ML26124-01HB/ML26124-02GD is 16bit monaural audio CODEC which has high resistance to voltage noise. On chip regulator realizes power supply rejection

+static const char *ml26124_lrmcon[] = {"Use L", "Use R", "Use (L+R)", "Use (L+R)/2"};

Quoted 2 lines

+static const struct snd_kcontrol_new ml26124_snd_controls[] = {
+     SOC_SINGLE_TLV("Record Digital Volume", ML26124_RECORD_DIG_VOL, 0, 0xff, 1, rec_play_digi_vol),

Capture, not Record.

Quoted 3 lines

+static const struct snd_kcontrol_new ml26124_dsp_controls[] = {
+     SOC_SINGLE("Play Limitter ON/OFF", ML26124_FILTER_EN, 0, 1, 0),

Quoted 1 line

+     SOC_SINGLE("Set ALC position", ML26124_FILTER_EN, 5, 1, 0),

What does this actually do?  From the name it *really* doesn't look like a mixer input.

sound/soc/codecs/ml26124.c line 165

Quoted 2 lines

sound/soc/codecs/ml26124.c new file +2 -0

+static const struct snd_soc_dapm_route intercon[] = {
+};

I can't see how any of the DAPM widgets you specify will ever work with no interconnections.

sound/soc/codecs/ml26124.c line 171

Quoted 7 lines

sound/soc/codecs/ml26124.c new file +6 -0

+
+static int snd_card_codec_reg_read(struct ml26124_priv *priv,
+                                unsigned char reg, unsigned char *val)
+{
+     unsigned char data;
+     struct i2c_client *i2c;

Use the standard register access code, don't open code things in your driver unless there's a good reason to.  Current best practice for most I2C or SPI devices is to use regmap, see any recently added driver for examples.

Quoted 5 lines

+     unsigned char data;
+     unsigned int rate = priv->rate;
+     unsigned int channels = priv->ch;
+
+     snd_card_codec_reg_read(priv, 0x30, &data);      /* Read MICVIAS Voltage */

sound/soc/codecs/ml26124.c line 232

Quoted 5 lines

sound/soc/codecs/ml26124.c new file +5 -0

+
+     snd_card_codec_reg_write(priv, 0x10, 0x01);     /* soft reset assert */
+     snd_card_codec_reg_write(priv, 0x10, 0x00);     /* soft reset negate */
+
+     snd_card_codec_reg_write(priv, 0x0c, 0x00);     /* Stop clock  */

Use snd_soc_update_bits() and the other standard register access functions.

2011/11/21 Mark Brown <[email protected]> wrote:

BTW, What's TLV ? Let me know the full spell of this "TLV".

Quoted 2 lines

Quoted 2 lines

+static const struct snd_kcontrol_new ml26124_dsp_controls[] = {
+     SOC_SINGLE("Play Limitter ON/OFF", ML26124_FILTER_EN, 0, 1, 0),

Do you mean SOC_SINGLE("Play Limitter Switch", ML26124_FILTER_EN, 0, 1, 0) ?

Quoted 4 lines

Quoted 1 line

+     SOC_SINGLE("Set ALC position", ML26124_FILTER_EN, 5, 1, 0),

What does this actually do?  From the name it *really* doesn't look like a mixer input.

The above means where connects the ALC.
So, this doesn't relate to mixer input.

However I couldn't understand the meaning of the widgets. So I didn't write anything.

Quoted 10 lines

sound/soc/codecs/ml26124.c line 171

Quoted 5 lines

sound/soc/codecs/ml26124.c new file +5 -0

+static int snd_card_codec_reg_read(struct ml26124_priv *priv,
+                                unsigned char reg, unsigned char *val)
+{
+     unsigned char data;
+     struct i2c_client *i2c;

Use the standard register access code, don't open code things in your driver unless there's a good reason to.  Current best practice for most I2C or SPI devices is to use regmap, see any recently added driver for examples.

What's "regmap" mean ? or do you mean drivers/mfd/* ? Could you tell me this ?

Quoted 2 lines

Use snd_soc_update_bits() and the other standard register access functions.

Using snd_soc_update_bits(), need to register ".read" method.

Is the same as the above snd_card_codec_reg_read ?

Quoted 7 lines

Quoted 4 lines

Use the standard register access code, don't open code things in your driver unless there's a good reason to.  Current best practice for most I2C or SPI devices is to use regmap, see any recently added driver for examples.

What's "regmap" mean ? or do you mean drivers/mfd/* ? Could you tell me this ?

drivers/base/regmap and also grep in sound/soc/codecs/*.c

Quoted 3 lines

2011/11/21 Mark Brown <[email protected]> wrote:

BTW, What's TLV ? Let me know the full spell of this "TLV".

Tag/Length/Value.

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

+static const struct snd_kcontrol_new ml26124_dsp_controls[] = {
+     SOC_SINGLE("Play Limitter ON/OFF", ML26124_FILTER_EN, 0, 1, 0),

Do you mean SOC_SINGLE("Play Limitter Switch", ML26124_FILTER_EN, 0, 1, 0) ?

Yes.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

+     SOC_SINGLE("Set ALC position", ML26124_FILTER_EN, 5, 1, 0),

What does this actually do?  From the name it *really* doesn't look like a mixer input.

The above means where connects the ALC.
So, this doesn't relate to mixer input.

If this control is not a mixer input it should not be a mixer input in the driver.  Though with your explanation I still don't understand what it does so presumably the naming also needs to be improved.

Quoted 2 lines

However I couldn't understand the meaning of the widgets. So I didn't write anything.

See Documentation/sound/alsa/soc/dapm.txt.

Quoted 11 lines

Quoted 10 lines

sound/soc/codecs/ml26124.c line 171

Quoted 5 lines

sound/soc/codecs/ml26124.c new file +5 -0

+static int snd_card_codec_reg_read(struct ml26124_priv *priv,
+                                unsigned char reg, unsigned char *val)
+{
+     unsigned char data;
+     struct i2c_client *i2c;

Use the standard register access code, don't open code things in your driver unless there's a good reason to.  Current best practice for most I2C or SPI devices is to use regmap, see any recently added driver for examples.

Quoted 2 lines

What's "regmap" mean ? or do you mean drivers/mfd/* ? Could you tell me this ?

drivers/base/regmap and also grep in sound/soc/codecs/*.c

Quoted 4 lines

Quoted 2 lines

Use snd_soc_update_bits() and the other standard register access functions.

Using snd_soc_update_bits(), need to register ".read" method.

Or use a cache.

Quoted 1 line

Is the same as the above  snd_card_codec_reg_read ?

I don't understand this question.

Quoted 1 line

drivers/base/regmap and also grep in sound/soc/codecs/*.c

Though grepping "regmap" at sound/soc/codecs/*.c, I couldn't find any file. Is this true ?