Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Mark Brown
On Tue, Jul 11, 2017 at 02:13:31PM +0200, Sebastian Reichel wrote:

> How is having a subnode without a compatible property different?

You don't *need* to have the subnode, I was only mentioning that if for
some reason it was super useful for organizing the properties.


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Mark Brown
On Tue, Jul 11, 2017 at 02:13:31PM +0200, Sebastian Reichel wrote:

> How is having a subnode without a compatible property different?

You don't *need* to have the subnode, I was only mentioning that if for
some reason it was super useful for organizing the properties.


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Sebastian Reichel
Hi,

On Tue, Jul 11, 2017 at 11:49:11AM +0100, Mark Brown wrote:
> On Mon, Jul 10, 2017 at 10:15:41PM -0700, Tony Lindgren wrote:
> > * Mark Brown  [170710 10:52]:
> 
> > > If this is part of a MFD shouldn't the parent device register it without
> > > it needing to be in the DT?
> 
> > Having the MFD core part just do devm_of_platform_populate() leaves out
> > dependencies between the MFD core and it's child devices.
> 
> > There are also a lot of board specific configuration to be done for many
> > child devices such as ADC wiring, GPIO pins used, and macro firmware
> > usage.
> 
> > Not sure what all board specific stuff needs to be configured for this
> > driver yet, but it seems at least the macro interrupt wiring needs to
> > be configured. I would not be surprised to find GPIOs or ADC being used
> > for some connector detection too.
> 
> We can use subnodes without compatible strings, that's not a problem,
> but having to have compatible strings means we're encoding the way Linux
> splits device drivers up into the DT which might not work for other OSs
> or even future versions of Linux.  For example with CODEC drivers it's
> common to have a good chunk of clock control in there which we might at
> some point want to move over to the clock subsystem.

How is having a subnode without a compatible property different?
Sure we will bind the driver manually and make our code (a little
bit) more complex, but we still encoded the way Linux splits the
device into DT. My understanding is, that adding a node without a
compatible value is almost always not ok.

-- Sebastian


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Sebastian Reichel
Hi,

On Tue, Jul 11, 2017 at 11:49:11AM +0100, Mark Brown wrote:
> On Mon, Jul 10, 2017 at 10:15:41PM -0700, Tony Lindgren wrote:
> > * Mark Brown  [170710 10:52]:
> 
> > > If this is part of a MFD shouldn't the parent device register it without
> > > it needing to be in the DT?
> 
> > Having the MFD core part just do devm_of_platform_populate() leaves out
> > dependencies between the MFD core and it's child devices.
> 
> > There are also a lot of board specific configuration to be done for many
> > child devices such as ADC wiring, GPIO pins used, and macro firmware
> > usage.
> 
> > Not sure what all board specific stuff needs to be configured for this
> > driver yet, but it seems at least the macro interrupt wiring needs to
> > be configured. I would not be surprised to find GPIOs or ADC being used
> > for some connector detection too.
> 
> We can use subnodes without compatible strings, that's not a problem,
> but having to have compatible strings means we're encoding the way Linux
> splits device drivers up into the DT which might not work for other OSs
> or even future versions of Linux.  For example with CODEC drivers it's
> common to have a good chunk of clock control in there which we might at
> some point want to move over to the clock subsystem.

How is having a subnode without a compatible property different?
Sure we will bind the driver manually and make our code (a little
bit) more complex, but we still encoded the way Linux splits the
device into DT. My understanding is, that adding a node without a
compatible value is almost always not ok.

-- Sebastian


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Mark Brown
On Mon, Jul 10, 2017 at 10:15:41PM -0700, Tony Lindgren wrote:
> * Mark Brown  [170710 10:52]:

> > If this is part of a MFD shouldn't the parent device register it without
> > it needing to be in the DT?

> Having the MFD core part just do devm_of_platform_populate() leaves out
> dependencies between the MFD core and it's child devices.

> There are also a lot of board specific configuration to be done for many
> child devices such as ADC wiring, GPIO pins used, and macro firmware
> usage.

> Not sure what all board specific stuff needs to be configured for this
> driver yet, but it seems at least the macro interrupt wiring needs to
> be configured. I would not be surprised to find GPIOs or ADC being used
> for some connector detection too.

We can use subnodes without compatible strings, that's not a problem,
but having to have compatible strings means we're encoding the way Linux
splits device drivers up into the DT which might not work for other OSs
or even future versions of Linux.  For example with CODEC drivers it's
common to have a good chunk of clock control in there which we might at
some point want to move over to the clock subsystem.


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-11 Thread Mark Brown
On Mon, Jul 10, 2017 at 10:15:41PM -0700, Tony Lindgren wrote:
> * Mark Brown  [170710 10:52]:

> > If this is part of a MFD shouldn't the parent device register it without
> > it needing to be in the DT?

> Having the MFD core part just do devm_of_platform_populate() leaves out
> dependencies between the MFD core and it's child devices.

> There are also a lot of board specific configuration to be done for many
> child devices such as ADC wiring, GPIO pins used, and macro firmware
> usage.

> Not sure what all board specific stuff needs to be configured for this
> driver yet, but it seems at least the macro interrupt wiring needs to
> be configured. I would not be surprised to find GPIOs or ADC being used
> for some connector detection too.

We can use subnodes without compatible strings, that's not a problem,
but having to have compatible strings means we're encoding the way Linux
splits device drivers up into the DT which might not work for other OSs
or even future versions of Linux.  For example with CODEC drivers it's
common to have a good chunk of clock control in there which we might at
some point want to move over to the clock subsystem.


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Tony Lindgren
* Mark Brown  [170710 10:52]:
> On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cpcap_audio_of_match[] = {
> > +   { .compatible = "motorola,cpcap-audio-codec", },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> > +#endif
> 
> If this is part of a MFD shouldn't the parent device register it without
> it needing to be in the DT?

Having the MFD core part just do devm_of_platform_populate() leaves out
dependencies between the MFD core and it's child devices.

There are also a lot of board specific configuration to be done for many
child devices such as ADC wiring, GPIO pins used, and macro firmware
usage.

Not sure what all board specific stuff needs to be configured for this
driver yet, but it seems at least the macro interrupt wiring needs to
be configured. I would not be surprised to find GPIOs or ADC being used
for some connector detection too.

Regards,

Tony


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Tony Lindgren
* Mark Brown  [170710 10:52]:
> On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cpcap_audio_of_match[] = {
> > +   { .compatible = "motorola,cpcap-audio-codec", },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> > +#endif
> 
> If this is part of a MFD shouldn't the parent device register it without
> it needing to be in the DT?

Having the MFD core part just do devm_of_platform_populate() leaves out
dependencies between the MFD core and it's child devices.

There are also a lot of board specific configuration to be done for many
child devices such as ADC wiring, GPIO pins used, and macro firmware
usage.

Not sure what all board specific stuff needs to be configured for this
driver yet, but it seems at least the macro interrupt wiring needs to
be configured. I would not be surprised to find GPIOs or ADC being used
for some connector detection too.

Regards,

Tony


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Mark Brown
On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:

>  snd-soc-cq93vc-objs := cq93vc.o
> +snd-soc-cpcap-objs := cpcap.o

Please keep Kconfig and Makefile lexically sorted.

> +static int cpcap_audio_write(struct cpcap_audio *cpcap,
> +  u16 reg, u16 mask, u16 val)
> +{
> + struct snd_soc_codec *codec = cpcap->codec;
> + struct device *dev = codec->dev;
> + int err;
> +
> + err = regmap_update_bits(cpcap->regmap, reg, mask, val);
> + if (err)
> + dev_err(dev, "write failed: reg=%04x mask=%04x val=%04x err=%d",
> + reg, mask, val, err);
> +
> + return err;
> +}

If we're going to have wrappers for the regmap functions it'd be good if
they were named in a similar way to the functions that they wrap, just
for clarity.  They're also not used consistently (and TBH I'm not sure
what they buy but if you want them that's fine).

> + switch (event) {
> + case SND_SOC_DAPM_PRE_PMU:
> + err += regmap_write(cpcap->regmap, CPCAP_REG_TEST,
> + STM_STDAC_EN_TEST_PRE);
> + err += regmap_write(cpcap->regmap, CPCAP_REG_ST_TEST1,
> + STM_STDAC_EN_ST_TEST1_PRE);
> + return err;

This'll return a nonsense error code if both error out, better to do
something like

if (!err)
err = regmap_write(...

> +static const char * const cpcap_onoff_texts[] = {
> + "Off", "On"
> +};
> +static const SOC_ENUM_SINGLE_DECL(cpcap_ext_cap_l_enum,
> + CPCAP_REG_TXI, CPCAP_BIT_RX_L_ENCODE, cpcap_onoff_texts);
> +static const SOC_ENUM_SINGLE_DECL(cpcap_ext_cap_r_enum,
> + CPCAP_REG_TXI, CPCAP_BIT_RX_R_ENCODE, cpcap_onoff_texts);
> +static const struct snd_kcontrol_new cpcap_extr_cap_control =
> + SOC_DAPM_ENUM("Ext Right Capture", cpcap_ext_cap_r_enum);
> +static const struct snd_kcontrol_new cpcap_extl_cap_control =
> + SOC_DAPM_ENUM("Ext Left Capture", cpcap_ext_cap_l_enum);

Why are these enums and not simple Switch controls?  They appear to be
muxes with only one arm connected.

> +static int cpcap_hifi_set_mute(struct snd_soc_dai *dai, int mute)
> +{
> + struct snd_soc_codec *codec = dai->codec;
> + struct cpcap_audio *cpcap = snd_soc_codec_get_drvdata(codec);
> + static const u16 reg = CPCAP_REG_RXSDOA;
> + static const u16 mask = BIT(CPCAP_BIT_ST_DAC_SW);
> + u16 val = mute ? 0 : BIT(CPCAP_BIT_ST_DAC_SW);

Please write a normal if statement, this was a bit confusing at first
glance.

> +#ifdef CONFIG_OF
> +static const struct of_device_id cpcap_audio_of_match[] = {
> + { .compatible = "motorola,cpcap-audio-codec", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> +#endif

If this is part of a MFD shouldn't the parent device register it without
it needing to be in the DT?


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Mark Brown
On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:

>  snd-soc-cq93vc-objs := cq93vc.o
> +snd-soc-cpcap-objs := cpcap.o

Please keep Kconfig and Makefile lexically sorted.

> +static int cpcap_audio_write(struct cpcap_audio *cpcap,
> +  u16 reg, u16 mask, u16 val)
> +{
> + struct snd_soc_codec *codec = cpcap->codec;
> + struct device *dev = codec->dev;
> + int err;
> +
> + err = regmap_update_bits(cpcap->regmap, reg, mask, val);
> + if (err)
> + dev_err(dev, "write failed: reg=%04x mask=%04x val=%04x err=%d",
> + reg, mask, val, err);
> +
> + return err;
> +}

If we're going to have wrappers for the regmap functions it'd be good if
they were named in a similar way to the functions that they wrap, just
for clarity.  They're also not used consistently (and TBH I'm not sure
what they buy but if you want them that's fine).

> + switch (event) {
> + case SND_SOC_DAPM_PRE_PMU:
> + err += regmap_write(cpcap->regmap, CPCAP_REG_TEST,
> + STM_STDAC_EN_TEST_PRE);
> + err += regmap_write(cpcap->regmap, CPCAP_REG_ST_TEST1,
> + STM_STDAC_EN_ST_TEST1_PRE);
> + return err;

This'll return a nonsense error code if both error out, better to do
something like

if (!err)
err = regmap_write(...

> +static const char * const cpcap_onoff_texts[] = {
> + "Off", "On"
> +};
> +static const SOC_ENUM_SINGLE_DECL(cpcap_ext_cap_l_enum,
> + CPCAP_REG_TXI, CPCAP_BIT_RX_L_ENCODE, cpcap_onoff_texts);
> +static const SOC_ENUM_SINGLE_DECL(cpcap_ext_cap_r_enum,
> + CPCAP_REG_TXI, CPCAP_BIT_RX_R_ENCODE, cpcap_onoff_texts);
> +static const struct snd_kcontrol_new cpcap_extr_cap_control =
> + SOC_DAPM_ENUM("Ext Right Capture", cpcap_ext_cap_r_enum);
> +static const struct snd_kcontrol_new cpcap_extl_cap_control =
> + SOC_DAPM_ENUM("Ext Left Capture", cpcap_ext_cap_l_enum);

Why are these enums and not simple Switch controls?  They appear to be
muxes with only one arm connected.

> +static int cpcap_hifi_set_mute(struct snd_soc_dai *dai, int mute)
> +{
> + struct snd_soc_codec *codec = dai->codec;
> + struct cpcap_audio *cpcap = snd_soc_codec_get_drvdata(codec);
> + static const u16 reg = CPCAP_REG_RXSDOA;
> + static const u16 mask = BIT(CPCAP_BIT_ST_DAC_SW);
> + u16 val = mute ? 0 : BIT(CPCAP_BIT_ST_DAC_SW);

Please write a normal if statement, this was a bit confusing at first
glance.

> +#ifdef CONFIG_OF
> +static const struct of_device_id cpcap_audio_of_match[] = {
> + { .compatible = "motorola,cpcap-audio-codec", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> +#endif

If this is part of a MFD shouldn't the parent device register it without
it needing to be in the DT?


signature.asc
Description: PGP signature


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Rob Herring
On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> Motorola CPCAP is a PMIC with audio functionality, that can be
> found on Motorola Droid 4 and probably a few other phones from
> Motorola's Droid series.
> 
> The driver has been written from scratch using Motorola's Android
> driver, register dumps from running Android and datasheet for NXP
> MC13783UG (which is similar to Motorola CPCAP, but not the same).
> 
> The chip provides two audio interfaces, that can be muxed to two
> different audio codecs. One provides support for stereo output
> (named StDAC or HiFi), while the other only provides mono output
> (named Voice). Only the Voice codec provides a Capture interface.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  .../bindings/sound/motorola,cpcap-audio-codec.txt  |   19 +

Acked-by: Rob Herring 

>  sound/soc/codecs/Kconfig   |3 +
>  sound/soc/codecs/Makefile  |2 +
>  sound/soc/codecs/cpcap.c   | 1422 
> 
>  4 files changed, 1446 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
>  create mode 100644 sound/soc/codecs/cpcap.c


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-10 Thread Rob Herring
On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> Motorola CPCAP is a PMIC with audio functionality, that can be
> found on Motorola Droid 4 and probably a few other phones from
> Motorola's Droid series.
> 
> The driver has been written from scratch using Motorola's Android
> driver, register dumps from running Android and datasheet for NXP
> MC13783UG (which is similar to Motorola CPCAP, but not the same).
> 
> The chip provides two audio interfaces, that can be muxed to two
> different audio codecs. One provides support for stereo output
> (named StDAC or HiFi), while the other only provides mono output
> (named Voice). Only the Voice codec provides a Capture interface.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  .../bindings/sound/motorola,cpcap-audio-codec.txt  |   19 +

Acked-by: Rob Herring 

>  sound/soc/codecs/Kconfig   |3 +
>  sound/soc/codecs/Makefile  |2 +
>  sound/soc/codecs/cpcap.c   | 1422 
> 
>  4 files changed, 1446 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
>  create mode 100644 sound/soc/codecs/cpcap.c


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-08 Thread Tony Lindgren
* Sebastian Reichel  [170707 09:43]:
> Motorola CPCAP is a PMIC with audio functionality, that can be
> found on Motorola Droid 4 and probably a few other phones from
> Motorola's Droid series.
> 
> The driver has been written from scratch using Motorola's Android
> driver, register dumps from running Android and datasheet for NXP
> MC13783UG (which is similar to Motorola CPCAP, but not the same).
> 
> The chip provides two audio interfaces, that can be muxed to two
> different audio codecs. One provides support for stereo output
> (named StDAC or HiFi), while the other only provides mono output
> (named Voice). Only the Voice codec provides a Capture interface.

I needed the patch below for modular .config. Other than that,
plays music fine for me, so feel free to add:

Acked-by: Tony Lindgren 

8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren 
Date: Sat, 8 Jul 2017 21:43:46 -0700
Subject: [PATCH] ALSA: pcm: Export soc_dpcm_runtime_update

Some drivers may need to use this from loadable modules. Otherwise we
will get:

ERROR: "soc_dpcm_runtime_update" [sound/soc/codecs/snd-soc-cpcap.ko]
undefined!

Signed-off-by: Tony Lindgren 
---
 sound/soc/soc-pcm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2539,6 +2539,8 @@ int soc_dpcm_runtime_update(struct snd_soc_card *card)
mutex_unlock(>mutex);
return 0;
 }
+EXPORT_SYMBOL_GPL(soc_dpcm_runtime_update);
+
 int soc_dpcm_be_digital_mute(struct snd_soc_pcm_runtime *fe, int mute)
 {
struct snd_soc_dpcm *dpcm;
-- 
2.13.2


Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-08 Thread Tony Lindgren
* Sebastian Reichel  [170707 09:43]:
> Motorola CPCAP is a PMIC with audio functionality, that can be
> found on Motorola Droid 4 and probably a few other phones from
> Motorola's Droid series.
> 
> The driver has been written from scratch using Motorola's Android
> driver, register dumps from running Android and datasheet for NXP
> MC13783UG (which is similar to Motorola CPCAP, but not the same).
> 
> The chip provides two audio interfaces, that can be muxed to two
> different audio codecs. One provides support for stereo output
> (named StDAC or HiFi), while the other only provides mono output
> (named Voice). Only the Voice codec provides a Capture interface.

I needed the patch below for modular .config. Other than that,
plays music fine for me, so feel free to add:

Acked-by: Tony Lindgren 

8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren 
Date: Sat, 8 Jul 2017 21:43:46 -0700
Subject: [PATCH] ALSA: pcm: Export soc_dpcm_runtime_update

Some drivers may need to use this from loadable modules. Otherwise we
will get:

ERROR: "soc_dpcm_runtime_update" [sound/soc/codecs/snd-soc-cpcap.ko]
undefined!

Signed-off-by: Tony Lindgren 
---
 sound/soc/soc-pcm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2539,6 +2539,8 @@ int soc_dpcm_runtime_update(struct snd_soc_card *card)
mutex_unlock(>mutex);
return 0;
 }
+EXPORT_SYMBOL_GPL(soc_dpcm_runtime_update);
+
 int soc_dpcm_be_digital_mute(struct snd_soc_pcm_runtime *fe, int mute)
 {
struct snd_soc_dpcm *dpcm;
-- 
2.13.2


[PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-07 Thread Sebastian Reichel
Motorola CPCAP is a PMIC with audio functionality, that can be
found on Motorola Droid 4 and probably a few other phones from
Motorola's Droid series.

The driver has been written from scratch using Motorola's Android
driver, register dumps from running Android and datasheet for NXP
MC13783UG (which is similar to Motorola CPCAP, but not the same).

The chip provides two audio interfaces, that can be muxed to two
different audio codecs. One provides support for stereo output
(named StDAC or HiFi), while the other only provides mono output
(named Voice). Only the Voice codec provides a Capture interface.

Signed-off-by: Sebastian Reichel 
---
 .../bindings/sound/motorola,cpcap-audio-codec.txt  |   19 +
 sound/soc/codecs/Kconfig   |3 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cpcap.c   | 1422 
 4 files changed, 1446 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
 create mode 100644 sound/soc/codecs/cpcap.c

diff --git 
a/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt 
b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
new file mode 100644
index ..6b8cd616bd46
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
@@ -0,0 +1,19 @@
+Motorola CPCAP audio CODEC
+--
+
+This module is part of the CPCAP. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
+
+Required properties:
+
+  - compatible : "motorola,cpcap-audio-codec"
+  - vdd-supply : Phandle to audio regulator
+
+Example:
+
+ {
+   audio-codec {
+   compatible = "motorola,cpcap-audio-codec";
+   vdd-supply = <>;
+   };
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 883ed4c8a551..e3d08ebeb37c 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -403,6 +403,9 @@ config SND_SOC_BT_SCO
 config SND_SOC_CQ0093VC
tristate
 
+config SND_SOC_CPCAP
+   tristate "Motorola CPCAP codec"
+
 config SND_SOC_CS35L32
tristate "Cirrus Logic CS35L32 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 28a63fdaf982..8750fd9c7dca 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -36,6 +36,7 @@ snd-soc-ak5386-objs := ak5386.o
 snd-soc-arizona-objs := arizona.o
 snd-soc-bt-sco-objs := bt-sco.o
 snd-soc-cq93vc-objs := cq93vc.o
+snd-soc-cpcap-objs := cpcap.o
 snd-soc-cs35l32-objs := cs35l32.o
 snd-soc-cs35l33-objs := cs35l33.o
 snd-soc-cs35l34-objs := cs35l34.o
@@ -271,6 +272,7 @@ obj-$(CONFIG_SND_SOC_ALC5632)   += snd-soc-alc5632.o
 obj-$(CONFIG_SND_SOC_ARIZONA)  += snd-soc-arizona.o
 obj-$(CONFIG_SND_SOC_BT_SCO)   += snd-soc-bt-sco.o
 obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o
+obj-$(CONFIG_SND_SOC_CPCAP)+= snd-soc-cpcap.o
 obj-$(CONFIG_SND_SOC_CS35L32)  += snd-soc-cs35l32.o
 obj-$(CONFIG_SND_SOC_CS35L33)  += snd-soc-cs35l33.o
 obj-$(CONFIG_SND_SOC_CS35L34)  += snd-soc-cs35l34.o
diff --git a/sound/soc/codecs/cpcap.c b/sound/soc/codecs/cpcap.c
new file mode 100644
index ..15ec732e0950
--- /dev/null
+++ b/sound/soc/codecs/cpcap.c
@@ -0,0 +1,1422 @@
+/*
+ * ALSA SoC CPCAP codec driver
+ *
+ * Copyright (C) 2017 Sebastian Reichel 
+ *
+ * Very loosely based on original driver from Motorola:
+ * Copyright (C) 2007 - 2009 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register 513 CPCAP_REG_CC --- CODEC */
+#define CPCAP_BIT_CDC_CLK215
+#define CPCAP_BIT_CDC_CLK114
+#define CPCAP_BIT_CDC_CLK013
+#define CPCAP_BIT_CDC_SR3 12
+#define CPCAP_BIT_CDC_SR2 11
+#define CPCAP_BIT_CDC_SR1 10
+#define CPCAP_BIT_CDC_SR0 9
+#define CPCAP_BIT_CDC_CLOCK_TREE_RESET8
+#define CPCAP_BIT_MIC2_CDC_EN 7
+#define CPCAP_BIT_CDC_EN_RX   6
+#define CPCAP_BIT_DF_RESET5
+#define CPCAP_BIT_MIC1_CDC_EN 4
+#define CPCAP_BIT_AUDOHPF_1  3
+#define CPCAP_BIT_AUDOHPF_0  2
+#define CPCAP_BIT_AUDIHPF_1  1
+#define CPCAP_BIT_AUDIHPF_0  0
+
+/* Register 514 CPCAP_REG_CDI--- CODEC Digital Audio Interface */
+#define 

[PATCH 1/3] ASoC: codec: cpcap: new codec

2017-07-07 Thread Sebastian Reichel
Motorola CPCAP is a PMIC with audio functionality, that can be
found on Motorola Droid 4 and probably a few other phones from
Motorola's Droid series.

The driver has been written from scratch using Motorola's Android
driver, register dumps from running Android and datasheet for NXP
MC13783UG (which is similar to Motorola CPCAP, but not the same).

The chip provides two audio interfaces, that can be muxed to two
different audio codecs. One provides support for stereo output
(named StDAC or HiFi), while the other only provides mono output
(named Voice). Only the Voice codec provides a Capture interface.

Signed-off-by: Sebastian Reichel 
---
 .../bindings/sound/motorola,cpcap-audio-codec.txt  |   19 +
 sound/soc/codecs/Kconfig   |3 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cpcap.c   | 1422 
 4 files changed, 1446 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
 create mode 100644 sound/soc/codecs/cpcap.c

diff --git 
a/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt 
b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
new file mode 100644
index ..6b8cd616bd46
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
@@ -0,0 +1,19 @@
+Motorola CPCAP audio CODEC
+--
+
+This module is part of the CPCAP. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
+
+Required properties:
+
+  - compatible : "motorola,cpcap-audio-codec"
+  - vdd-supply : Phandle to audio regulator
+
+Example:
+
+ {
+   audio-codec {
+   compatible = "motorola,cpcap-audio-codec";
+   vdd-supply = <>;
+   };
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 883ed4c8a551..e3d08ebeb37c 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -403,6 +403,9 @@ config SND_SOC_BT_SCO
 config SND_SOC_CQ0093VC
tristate
 
+config SND_SOC_CPCAP
+   tristate "Motorola CPCAP codec"
+
 config SND_SOC_CS35L32
tristate "Cirrus Logic CS35L32 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 28a63fdaf982..8750fd9c7dca 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -36,6 +36,7 @@ snd-soc-ak5386-objs := ak5386.o
 snd-soc-arizona-objs := arizona.o
 snd-soc-bt-sco-objs := bt-sco.o
 snd-soc-cq93vc-objs := cq93vc.o
+snd-soc-cpcap-objs := cpcap.o
 snd-soc-cs35l32-objs := cs35l32.o
 snd-soc-cs35l33-objs := cs35l33.o
 snd-soc-cs35l34-objs := cs35l34.o
@@ -271,6 +272,7 @@ obj-$(CONFIG_SND_SOC_ALC5632)   += snd-soc-alc5632.o
 obj-$(CONFIG_SND_SOC_ARIZONA)  += snd-soc-arizona.o
 obj-$(CONFIG_SND_SOC_BT_SCO)   += snd-soc-bt-sco.o
 obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o
+obj-$(CONFIG_SND_SOC_CPCAP)+= snd-soc-cpcap.o
 obj-$(CONFIG_SND_SOC_CS35L32)  += snd-soc-cs35l32.o
 obj-$(CONFIG_SND_SOC_CS35L33)  += snd-soc-cs35l33.o
 obj-$(CONFIG_SND_SOC_CS35L34)  += snd-soc-cs35l34.o
diff --git a/sound/soc/codecs/cpcap.c b/sound/soc/codecs/cpcap.c
new file mode 100644
index ..15ec732e0950
--- /dev/null
+++ b/sound/soc/codecs/cpcap.c
@@ -0,0 +1,1422 @@
+/*
+ * ALSA SoC CPCAP codec driver
+ *
+ * Copyright (C) 2017 Sebastian Reichel 
+ *
+ * Very loosely based on original driver from Motorola:
+ * Copyright (C) 2007 - 2009 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register 513 CPCAP_REG_CC --- CODEC */
+#define CPCAP_BIT_CDC_CLK215
+#define CPCAP_BIT_CDC_CLK114
+#define CPCAP_BIT_CDC_CLK013
+#define CPCAP_BIT_CDC_SR3 12
+#define CPCAP_BIT_CDC_SR2 11
+#define CPCAP_BIT_CDC_SR1 10
+#define CPCAP_BIT_CDC_SR0 9
+#define CPCAP_BIT_CDC_CLOCK_TREE_RESET8
+#define CPCAP_BIT_MIC2_CDC_EN 7
+#define CPCAP_BIT_CDC_EN_RX   6
+#define CPCAP_BIT_DF_RESET5
+#define CPCAP_BIT_MIC1_CDC_EN 4
+#define CPCAP_BIT_AUDOHPF_1  3
+#define CPCAP_BIT_AUDOHPF_0  2
+#define CPCAP_BIT_AUDIHPF_1  1
+#define CPCAP_BIT_AUDIHPF_0  0
+
+/* Register 514 CPCAP_REG_CDI--- CODEC Digital Audio Interface */
+#define CPCAP_BIT_CDC_PLL_SEL 15
+#define