[alsa-devel] [PATCH v2] ASoC: ics43432: Add codec driver for InvenSense ICS-43432
V2: Update after comments from Lars-Peter yesterday: set rate to CONTINUOUS and let ALSA figure out the details, also removing hw_params as it is then not needed.
Add support for the InvenSense ICS-43432 I2S MEMS microphone.
This is a non-software-configurable MEMS microphone with I2S output.
Signed-off-by: Ricard Wanderlof ricardw@axis.com --- .../devicetree/bindings/sound/ics43432.txt | 17 ++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ics43432.c | 101 ++++++++++++++++++++ 5 files changed, 125 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ics43432.txt create mode 100644 sound/soc/codecs/ics43432.c
diff --git a/Documentation/devicetree/bindings/sound/ics43432.txt b/Documentation/devicetree/bindings/sound/ics43432.txt new file mode 100644 index 0000000..b02e3a6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ics43432.txt @@ -0,0 +1,17 @@ +Invensense ICS-43432 MEMS microphone with I2S output. + +There are no software configuration options for this device, indeed, the only +host connection is the I2S interface. Apart from requirements on clock +frequency (460 kHz to 3.379 MHz according to the data sheet) there must be +64 clock cycles in each stereo output frame; 24 of the 32 available bits +contain audio data. A hardware pin determines if the device outputs data +on the left or right channel of the I2S frame. + +Required properties: + - compatible : Must be "invensense,ics43432" + +Example: + + ics43432: ics43432 { + compatible = "invensense,ics43432"; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8033919..7966637 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -103,6 +103,7 @@ img Imagination Technologies Ltd. innolux Innolux Corporation intel Intel Corporation intercontrol Inter Control Group +invensense InvenSense Inc. isee ISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 061c465..d696c85 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -62,6 +62,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_BT_SCO select SND_SOC_ES8328_SPI if SPI_MASTER select SND_SOC_ES8328_I2C if I2C + select SND_SOC_ICS43432 select SND_SOC_ISABELLE if I2C select SND_SOC_JZ4740_CODEC select SND_SOC_LM4857 if I2C @@ -444,6 +445,9 @@ config SND_SOC_ES8328_SPI tristate select SND_SOC_ES8328
+config SND_SOC_ICS43432 + tristate + config SND_SOC_ISABELLE tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index abe2d7e..23a2caf 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -55,6 +55,7 @@ snd-soc-dmic-objs := dmic.o snd-soc-es8328-objs := es8328.o snd-soc-es8328-i2c-objs := es8328-i2c.o snd-soc-es8328-spi-objs := es8328-spi.o +snd-soc-ics43432-objs := ics43432.o snd-soc-isabelle-objs := isabelle.o snd-soc-jz4740-codec-objs := jz4740.o snd-soc-l3-objs := l3.o @@ -240,6 +241,7 @@ obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o obj-$(CONFIG_SND_SOC_ES8328) += snd-soc-es8328.o obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o obj-$(CONFIG_SND_SOC_ES8328_SPI)+= snd-soc-es8328-spi.o +obj-$(CONFIG_SND_SOC_ICS43432) += snd-soc-ics43432.o obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o diff --git a/sound/soc/codecs/ics43432.c b/sound/soc/codecs/ics43432.c new file mode 100644 index 0000000..fe0af4a --- /dev/null +++ b/sound/soc/codecs/ics43432.c @@ -0,0 +1,101 @@ +/* + * I2S MEMS microphone driver for InvenSense ICS-43432 + * + * - Non configurable. + * - I2S interface, 64 BCLs per frame, 32 bits per channel, 24 bit data + * + * Copyright (c) 2015 Axis Communications AB + * + * Licensed under GPL2. + */ + +#include <linux/module.h> +#include <linux/init.h> +#include <linux/slab.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/initval.h> +#include <sound/tlv.h> + +#define ICS43432_RATE_MIN 7190 /* Hz, from data sheet */ +#define ICS43432_RATE_MAX 52800 /* Hz, from data sheet */ + +static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{ + switch (fmt & SND_SOC_DAIFMT_INV_MASK) { + case SND_SOC_DAIFMT_NB_NF: + break; + default: + return -EINVAL; + } + + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + case SND_SOC_DAIFMT_I2S: + break; + default: + return -EINVAL; + } + + return 0; +} + +#define ICS43432_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32) + +static const struct snd_soc_dai_ops ics43432_dai_ops = { + .set_fmt = ics43432_set_dai_fmt, +}; + +static struct snd_soc_dai_driver ics43432_dai = { + .name = "ics43432-hifi", + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rate_min = ICS43432_RATE_MIN, + .rate_max = ICS43432_RATE_MAX, + .rates = SNDRV_PCM_RATE_CONTINUOUS, + .formats = ICS43432_FORMATS, + }, + .ops = &ics43432_dai_ops, +}; + +static struct snd_soc_codec_driver ics43432_codec_driver = { +}; + +static int ics43432_probe(struct platform_device *pdev) +{ + return snd_soc_register_codec(&pdev->dev, &ics43432_codec_driver, + &ics43432_dai, 1); +} + +static int ics43432_remove(struct platform_device *pdev) +{ + snd_soc_unregister_codec(&pdev->dev); + return 0; +} + +#ifdef CONFIG_OF +static const struct of_device_id ics43432_ids[] = { + { .compatible = "invensense,ics43432", }, + { } +}; +MODULE_DEVICE_TABLE(of, ics43432_dt_ids); +#endif + +static struct platform_driver ics43432_driver = { + .driver = { + .name = "ics43432", + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(ics43432_ids), + }, + .probe = ics43432_probe, + .remove = ics43432_remove, +}; + +module_platform_driver(ics43432_driver); + +MODULE_DESCRIPTION("ASoC ICS43432 driver"); +MODULE_AUTHOR("Ricard Wanderlof ricardw@axis.com"); +MODULE_LICENSE("GPL2");
On Fri, Aug 14, 2015 at 11:10:10AM +0200, Ricard Wanderlof wrote:
V2: Update after comments from Lars-Peter yesterday: set rate to CONTINUOUS and let ALSA figure out the details, also removing hw_params as it is then not needed.
Please add any non-changelog content like this after the --- as covered in SubmittingPatches.
+static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
This still seems redundant (IIRC Lars mentioned this...).
On Fri, 14 Aug 2015, Mark Brown wrote:
On Fri, Aug 14, 2015 at 11:10:10AM +0200, Ricard Wanderlof wrote:
V2: Update after comments from Lars-Peter yesterday: set rate to CONTINUOUS and let ALSA figure out the details, also removing hw_params as it is then not needed.
Please add any non-changelog content like this after the --- as covered in SubmittingPatches.
Ok, sorry.
+static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
This still seems redundant (IIRC Lars mentioned this...).
I though Lars was referring solely to the hw_params function, not set_dai_fmt, but of course I could have misunderstood him.
I can understand the rates constraints being handled by the ALSA framework based on the parameters set in struct snd_soc_dai_driver, but how would the framework know about the acceptable INV_MASK and FORMAT_MASK values?
/Ricard
On 08/17/2015 09:09 AM, Ricard Wanderlof wrote:
On Fri, 14 Aug 2015, Mark Brown wrote:
On Fri, Aug 14, 2015 at 11:10:10AM +0200, Ricard Wanderlof wrote:
V2: Update after comments from Lars-Peter yesterday: set rate to CONTINUOUS and let ALSA figure out the details, also removing hw_params as it is then not needed.
Please add any non-changelog content like this after the --- as covered in SubmittingPatches.
Ok, sorry.
+static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
This still seems redundant (IIRC Lars mentioned this...).
I though Lars was referring solely to the hw_params function, not set_dai_fmt, but of course I could have misunderstood him.
Yes, I was. In my opinion this set_dai_fmt() implementation is useful to have as a mechanism to detect invalid configurations. E.g. if you don't implement the callback the CODEC will accept any setting while with he callback it will error out with the wrong configuration. Given that a I2S link typically at least somewhat works, even if you have the wrong setting, I think it makes sense to keep it to catch errors early on.
On Mon, 17 Aug 2015, Lars-Peter Clausen wrote:
+static int ics43432_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt) +{
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
This still seems redundant (IIRC Lars mentioned this...).
I though Lars was referring solely to the hw_params function, not set_dai_fmt, but of course I could have misunderstood him.
Yes, I was. In my opinion this set_dai_fmt() implementation is useful to have as a mechanism to detect invalid configurations. E.g. if you don't implement the callback the CODEC will accept any setting while with he callback it will error out with the wrong configuration. Given that a I2S link typically at least somewhat works, even if you have the wrong setting, I think it makes sense to keep it to catch errors early on.
Makes sense to me.
Ok, then, unless Mark seriously objects, I'll leave this as it is, and resubmit the patch with a revised MODULE_LICENSE string and repartitioning of the commit message / version comment.
/Ricard
On Mon, Aug 17, 2015 at 09:48:11AM +0200, Lars-Peter Clausen wrote:
Yes, I was. In my opinion this set_dai_fmt() implementation is useful to have as a mechanism to detect invalid configurations. E.g. if you don't implement the callback the CODEC will accept any setting while with he callback it will error out with the wrong configuration. Given that a I2S link typically at least somewhat works, even if you have the wrong setting, I think it makes sense to keep it to catch errors early on.
I agree that it's useful to catch such errors however I don't want to go to implementing basically empty functions if we don't have to - we should add the ability to specify capabilites in the DAI for the core to check instead.
participants (3)
-
Lars-Peter Clausen
-
Mark Brown
-
Ricard Wanderlof