[PATCH v2 0/5] Arizona Extcon Update Device Bindings

[PATCH v2 0/5] Arizona Extcon Update Device Bindings

[Charles Keepax]

This patch chain adds device bindings for the jack and
microphone detection system specific settings.

Mark, I have added you on the chain as getting a DT ack is
proving challenging and Lee said he would appreciate your
opinion on these, hope that is ok. Note that some of the
changes backing the DT doc updates in the first of the two
MFD changes have already been merged hence why they are
not in this series.

Changes since v1:
 - I have removed the stuff for the second jack detect pin
   from the series. It seems that it will probably be better
   to get these bindings in first as I can't see anyway they
   could be contentious then we can deal with that and if it
   needs to be a pinmux/gpio thing later.

Thanks,
Charles

Charles Keepax (5):
  extcon: arizona: Add device binding to enable ADC mode micdet
  extcon: arizona: Add device binding for the general purpose switch
  extcon: arizona: Add device binding for jack detect polarity
    inversion
  mfd: arizona: Update DT binding documentation for mic detection
  mfd: arizona: Update DT binding document for jack detection invert

 Documentation/devicetree/bindings/mfd/arizona.txt |   23 +++++++++++++++++++++
 drivers/extcon/extcon-arizona.c                   |    8 +++++++
 include/dt-bindings/mfd/arizona.h                 |    5 ++++
 3 files changed, 36 insertions(+), 0 deletions(-)

-- 
1.7.2.5

[PATCH v2 0/5] Arizona Extcon Update Device Bindings

[Charles Keepax]

This patch chain adds device bindings for the jack and
microphone detection system specific settings.

Mark, I have added you on the chain as getting a DT ack is
proving challenging and Lee said he would appreciate your
opinion on these, hope that is ok. Note that some of the
changes backing the DT doc updates in the first of the two
MFD changes have already been merged hence why they are
not in this series.

Changes since v1:
 - I have removed the stuff for the second jack detect pin
   from the series. It seems that it will probably be better
   to get these bindings in first as I can't see anyway they
   could be contentious then we can deal with that and if it
   needs to be a pinmux/gpio thing later.

Thanks,
Charles

Charles Keepax (5):
  extcon: arizona: Add device binding to enable ADC mode micdet
  extcon: arizona: Add device binding for the general purpose switch
  extcon: arizona: Add device binding for jack detect polarity
    inversion
  mfd: arizona: Update DT binding documentation for mic detection
  mfd: arizona: Update DT binding document for jack detection invert

 Documentation/devicetree/bindings/mfd/arizona.txt |   23 +++++++++++++++++++++
 drivers/extcon/extcon-arizona.c                   |    8 +++++++
 include/dt-bindings/mfd/arizona.h                 |    5 ++++
 3 files changed, 36 insertions(+), 0 deletions(-)

-- 
1.7.2.5

[PATCH v2 1/5] extcon: arizona: Add device binding to enable ADC mode micdet

[Charles Keepax]

Add a simple boolean binding to turn on and off the use of ADC
microphone detection mode to determine 3/4 pole jack.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
 drivers/extcon/extcon-arizona.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index a1ab0a5..6d2f5f3 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1236,6 +1236,9 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_force_micbias = device_property_read_bool(arizona->dev,
 						"wlf,micd-force-micbias");
 
+	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
+						"wlf,micd-software-compare");
+
 	return 0;
 }
 
-- 
1.7.2.5

[PATCH v2 1/5] extcon: arizona: Add device binding to enable ADC mode micdet

[Charles Keepax]

Add a simple boolean binding to turn on and off the use of ADC
microphone detection mode to determine 3/4 pole jack.

Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Acked-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 drivers/extcon/extcon-arizona.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index a1ab0a5..6d2f5f3 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1236,6 +1236,9 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_force_micbias = device_property_read_bool(arizona->dev,
 						"wlf,micd-force-micbias");
 
+	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
+						"wlf,micd-software-compare");
+
 	return 0;
 }
 
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] extcon: arizona: Add device binding for the general purpose switch

[Charles Keepax]

The switch is generally used in conjunction with the MICDET clamp to
suppress pops and clicks associated with jack insertion. This patch adds
a binding that allows the user to select the mode of operation for this
switch.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
 drivers/extcon/extcon-arizona.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 6d2f5f3..e8dd19cb 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1239,6 +1239,8 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
 						"wlf,micd-software-compare");
 
+	device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
+
 	return 0;
 }
 
-- 
1.7.2.5

[PATCH v2 2/5] extcon: arizona: Add device binding for the general purpose switch

[Charles Keepax]

The switch is generally used in conjunction with the MICDET clamp to
suppress pops and clicks associated with jack insertion. This patch adds
a binding that allows the user to select the mode of operation for this
switch.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
 drivers/extcon/extcon-arizona.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 6d2f5f3..e8dd19cb 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1239,6 +1239,8 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
 						"wlf,micd-software-compare");
 
+	device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
+
 	return 0;
 }
 
-- 
1.7.2.5

[PATCH v2 3/5] extcon: arizona: Add device binding for jack detect polarity inversion

[Charles Keepax]

By default the driver expects the jackdet pin to be pulled low when a
jack is inserted. This patch adds a device binding that allows the user
to specify that the jackdet pin will be pulled high when a jack is
inserted.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
 drivers/extcon/extcon-arizona.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index e8dd19cb..58e4dc9 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1239,6 +1239,9 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
 						"wlf,micd-software-compare");
 
+	pdata->jd_invert = device_property_read_bool(arizona->dev,
+						     "wlf,jd-invert");
+
 	device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
 
 	return 0;
-- 
1.7.2.5

[PATCH v2 3/5] extcon: arizona: Add device binding for jack detect polarity inversion

[Charles Keepax]

By default the driver expects the jackdet pin to be pulled low when a
jack is inserted. This patch adds a device binding that allows the user
to specify that the jackdet pin will be pulled high when a jack is
inserted.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
 drivers/extcon/extcon-arizona.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index e8dd19cb..58e4dc9 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1239,6 +1239,9 @@ static int arizona_extcon_device_get_pdata(struct arizona *arizona)
 	pdata->micd_software_compare = device_property_read_bool(arizona->dev,
 						"wlf,micd-software-compare");
 
+	pdata->jd_invert = device_property_read_bool(arizona->dev,
+						     "wlf,jd-invert");
+
 	device_property_read_u32(arizona->dev, "wlf,gpsw", &pdata->gpsw);
 
 	return 0;
-- 
1.7.2.5

[PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

Add additional bindings to allow configuration of the system specific
microphone detection settings.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..b98a11b 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,
+    specified as per the ARIZONA_MICD_TIME_XXX defines.
+  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
+    number of measurements to take, valid values being 2 and 4.
+  - wlf,micd-timeout : Timeout for microphone detection, specified in
+    milliseconds.
+  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
+    detection.
+
+  - wlf,gpsw : Settings for the general purpose switch, set as one of the
+    ARIZONA_GPSW_XXX defines.
+
   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
     they are being externally supplied. As covered in
     Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/include/dt-bindings/mfd/arizona.h b/include/dt-bindings/mfd/arizona.h
index c40f665..dedf46f 100644
--- a/include/dt-bindings/mfd/arizona.h
+++ b/include/dt-bindings/mfd/arizona.h
@@ -110,4 +110,9 @@
 #define ARIZONA_ACCDET_MODE_HPM 4
 #define ARIZONA_ACCDET_MODE_ADC 7
 
+#define ARIZONA_GPSW_OPEN           0
+#define ARIZONA_GPSW_CLOSED         1
+#define ARIZONA_GPSW_CLAMP_ENABLED  2
+#define ARIZONA_GPSW_CLAMP_DISABLED 3
+
 #endif
-- 
1.7.2.5

[PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

Add additional bindings to allow configuration of the system specific
microphone detection settings.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
 include/dt-bindings/mfd/arizona.h                 |    5 +++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..b98a11b 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -73,6 +73,27 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,micd-software-compare : Use a software comparison to determine mic
+    presence
+  - wlf,micd-detect-debounce : Additional software microphone detection
+    debounce specified in milliseconds.
+  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
+    polarity if one exists.
+  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
+    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
+    defines.
+  - wlf,micd-rate : Delay between successive microphone detection measurements,
+    specified as per the ARIZONA_MICD_TIME_XXX defines.
+  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
+    number of measurements to take, valid values being 2 and 4.
+  - wlf,micd-timeout : Timeout for microphone detection, specified in
+    milliseconds.
+  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
+    detection.
+
+  - wlf,gpsw : Settings for the general purpose switch, set as one of the
+    ARIZONA_GPSW_XXX defines.
+
   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
     they are being externally supplied. As covered in
     Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/include/dt-bindings/mfd/arizona.h b/include/dt-bindings/mfd/arizona.h
index c40f665..dedf46f 100644
--- a/include/dt-bindings/mfd/arizona.h
+++ b/include/dt-bindings/mfd/arizona.h
@@ -110,4 +110,9 @@
 #define ARIZONA_ACCDET_MODE_HPM 4
 #define ARIZONA_ACCDET_MODE_ADC 7
 
+#define ARIZONA_GPSW_OPEN           0
+#define ARIZONA_GPSW_CLOSED         1
+#define ARIZONA_GPSW_CLAMP_ENABLED  2
+#define ARIZONA_GPSW_CLAMP_DISABLED 3
+
 #endif
-- 
1.7.2.5

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Fri, 02 Oct 2015, Charles Keepax wrote:

> Add additional bindings to allow configuration of the system specific
> microphone detection settings.
> 
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
>  include/dt-bindings/mfd/arizona.h                 |    5 +++++
>  2 files changed, 26 insertions(+), 0 deletions(-)

You either need a sound guy or a DT guy or both to Ack this.

> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..b98a11b 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,27 @@ Optional properties:
>      If this node is not mentioned or if the value is unknown, then
>      headphone detection mode is set to HPDETL.
>  
> +  - wlf,micd-software-compare : Use a software comparison to determine mic
> +    presence
> +  - wlf,micd-detect-debounce : Additional software microphone detection
> +    debounce specified in milliseconds.
> +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> +    polarity if one exists.
> +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> +    defines.
> +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> +    number of measurements to take, valid values being 2 and 4.
> +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> +    milliseconds.
> +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> +    detection.
> +
> +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> +    ARIZONA_GPSW_XXX defines.
> +
>    - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
>      they are being externally supplied. As covered in
>      Documentation/devicetree/bindings/regulator/regulator.txt
> diff --git a/include/dt-bindings/mfd/arizona.h b/include/dt-bindings/mfd/arizona.h
> index c40f665..dedf46f 100644
> --- a/include/dt-bindings/mfd/arizona.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -110,4 +110,9 @@
>  #define ARIZONA_ACCDET_MODE_HPM 4
>  #define ARIZONA_ACCDET_MODE_ADC 7
>  
> +#define ARIZONA_GPSW_OPEN           0
> +#define ARIZONA_GPSW_CLOSED         1
> +#define ARIZONA_GPSW_CLAMP_ENABLED  2
> +#define ARIZONA_GPSW_CLAMP_DISABLED 3
> +
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> Add additional bindings to allow configuration of the system specific
> microphone detection settings.

This all seems pretty much fine to me - the things it is controlling are
fairly specific to the way the former Wolfson devices do, they only
really make sense with a fairly particular algorithm which isn't widely
implemented.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 07 Oct 2015, Mark Brown wrote:

> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> > Add additional bindings to allow configuration of the system specific
> > microphone detection settings.
> 
> This all seems pretty much fine to me - the things it is controlling are
> fairly specific to the way the former Wolfson devices do, they only
> really make sense with a fairly particular algorithm which isn't widely
> implemented.

Is that an Ack?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 07 Oct 2015, Mark Brown wrote:

> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> > Add additional bindings to allow configuration of the system specific
> > microphone detection settings.
> 
> This all seems pretty much fine to me - the things it is controlling are
> fairly specific to the way the former Wolfson devices do, they only
> really make sense with a fairly particular algorithm which isn't widely
> implemented.

Is that an Ack?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> On Wed, 07 Oct 2015, Mark Brown wrote:
> 
> > On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> > > Add additional bindings to allow configuration of the system specific
> > > microphone detection settings.
> > 
> > This all seems pretty much fine to me - the things it is controlling are
> > fairly specific to the way the former Wolfson devices do, they only
> > really make sense with a fairly particular algorithm which isn't widely
> > implemented.
> 
> Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably
doesn't want to add reviewing all our jack detection bindings to
his already fairly sizable work load and doing so here likely
means it will be expected in the future. From talking to people at
LinuxCon it looks like it is pretty unlikely the DT maintainers
will be acking individual bindings as well, basically they are
only really looking at major/framework things and leaving the
rest to subsystem maintainers.

Given that these patches only touch MFD/Extcon and extcon
is a subsystem designed to handle things like jack detection
isn't it really sufficient that you and Chanwoo have looked this
and are happy with it? Otherwise I really don't see anyway to
move this forward and would appreciate any suggestions?

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> On Wed, 07 Oct 2015, Mark Brown wrote:
> 
> > On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> > > Add additional bindings to allow configuration of the system specific
> > > microphone detection settings.
> > 
> > This all seems pretty much fine to me - the things it is controlling are
> > fairly specific to the way the former Wolfson devices do, they only
> > really make sense with a fairly particular algorithm which isn't widely
> > implemented.
> 
> Is that an Ack?

I am guessing Mark is slightly hesitant to ack as he probably
doesn't want to add reviewing all our jack detection bindings to
his already fairly sizable work load and doing so here likely
means it will be expected in the future. From talking to people at
LinuxCon it looks like it is pretty unlikely the DT maintainers
will be acking individual bindings as well, basically they are
only really looking at major/framework things and leaving the
rest to subsystem maintainers.

Given that these patches only touch MFD/Extcon and extcon
is a subsystem designed to handle things like jack detection
isn't it really sufficient that you and Chanwoo have looked this
and are happy with it? Otherwise I really don't see anyway to
move this forward and would appreciate any suggestions?

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

Hi Charles,

On 2015년 10월 12일 17:45, Charles Keepax wrote:
> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>
>>> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
>>>> Add additional bindings to allow configuration of the system specific
>>>> microphone detection settings.
>>>
>>> This all seems pretty much fine to me - the things it is controlling are
>>> fairly specific to the way the former Wolfson devices do, they only
>>> really make sense with a fairly particular algorithm which isn't widely
>>> implemented.
>>
>> Is that an Ack?
> 
> I am guessing Mark is slightly hesitant to ack as he probably
> doesn't want to add reviewing all our jack detection bindings to
> his already fairly sizable work load and doing so here likely
> means it will be expected in the future. From talking to people at
> LinuxCon it looks like it is pretty unlikely the DT maintainers
> will be acking individual bindings as well, basically they are
> only really looking at major/framework things and leaving the
> rest to subsystem maintainers.
> 
> Given that these patches only touch MFD/Extcon and extcon
> is a subsystem designed to handle things like jack detection
> isn't it really sufficient that you and Chanwoo have looked this
> and are happy with it? Otherwise I really don't see anyway to
> move this forward and would appreciate any suggestions?

I'm positive about your patches. After receiving the ack from MFD maintainer
I want to apply this patch-set on extcon git repository.

Also, I reviewed this patch on previous patch[1].
[1]https://lkml.org/lkml/2015/9/11/81

Thanks,
Chanwoo Choi

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

On 2015년 10월 12일 19:16, Chanwoo Choi wrote:
> Hi Charles,
> 
> On 2015년 10월 12일 17:45, Charles Keepax wrote:
>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>
>>>> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
>>>>> Add additional bindings to allow configuration of the system specific
>>>>> microphone detection settings.
>>>>
>>>> This all seems pretty much fine to me - the things it is controlling are
>>>> fairly specific to the way the former Wolfson devices do, they only
>>>> really make sense with a fairly particular algorithm which isn't widely
>>>> implemented.
>>>
>>> Is that an Ack?
>>
>> I am guessing Mark is slightly hesitant to ack as he probably
>> doesn't want to add reviewing all our jack detection bindings to
>> his already fairly sizable work load and doing so here likely
>> means it will be expected in the future. From talking to people at
>> LinuxCon it looks like it is pretty unlikely the DT maintainers
>> will be acking individual bindings as well, basically they are
>> only really looking at major/framework things and leaving the
>> rest to subsystem maintainers.
>>
>> Given that these patches only touch MFD/Extcon and extcon
>> is a subsystem designed to handle things like jack detection
>> isn't it really sufficient that you and Chanwoo have looked this
>> and are happy with it? Otherwise I really don't see anyway to
>> move this forward and would appreciate any suggestions?
> 
> I'm positive about your patches. After receiving the ack from MFD maintainer
> I want to apply this patch-set on extcon git repository.
> 
> Also, I reviewed this patch on previous patch[1].
> [1]https://lkml.org/lkml/2015/9/11/81

As you said, this patch touch MFD and EXTCON subsystem.
If you get the Ack or agreement from MFD maintainer,
I'm willing to apply it on extcon git.

Also, If this patch dont receive the additional ack message
unitl the end of this week, I'll merge patch1-3 on extcon-next branch
for Linux 4.4.

Thanks,
Chanwoo Choi

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Mon, 12 Oct 2015, Chanwoo Choi wrote:

> On 2015년 10월 12일 19:16, Chanwoo Choi wrote:
> > Hi Charles,
> > 
> > On 2015년 10월 12일 17:45, Charles Keepax wrote:
> >> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> >>> On Wed, 07 Oct 2015, Mark Brown wrote:
> >>>
> >>>> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
> >>>>> Add additional bindings to allow configuration of the system specific
> >>>>> microphone detection settings.
> >>>>
> >>>> This all seems pretty much fine to me - the things it is controlling are
> >>>> fairly specific to the way the former Wolfson devices do, they only
> >>>> really make sense with a fairly particular algorithm which isn't widely
> >>>> implemented.
> >>>
> >>> Is that an Ack?
> >>
> >> I am guessing Mark is slightly hesitant to ack as he probably
> >> doesn't want to add reviewing all our jack detection bindings to
> >> his already fairly sizable work load and doing so here likely
> >> means it will be expected in the future. From talking to people at
> >> LinuxCon it looks like it is pretty unlikely the DT maintainers
> >> will be acking individual bindings as well, basically they are
> >> only really looking at major/framework things and leaving the
> >> rest to subsystem maintainers.
> >>
> >> Given that these patches only touch MFD/Extcon and extcon
> >> is a subsystem designed to handle things like jack detection
> >> isn't it really sufficient that you and Chanwoo have looked this
> >> and are happy with it? Otherwise I really don't see anyway to
> >> move this forward and would appreciate any suggestions?
> > 
> > I'm positive about your patches. After receiving the ack from MFD maintainer
> > I want to apply this patch-set on extcon git repository.
> > 
> > Also, I reviewed this patch on previous patch[1].
> > [1]https://lkml.org/lkml/2015/9/11/81
> 
> As you said, this patch touch MFD and EXTCON subsystem.
> If you get the Ack or agreement from MFD maintainer,
> I'm willing to apply it on extcon git.
> 
> Also, If this patch dont receive the additional ack message
> unitl the end of this week, I'll merge patch1-3 on extcon-next branch
> for Linux 4.4.

Absolutely not!

I should be extremely cross if you 'go over my head' and apply MFD
patches without the correct Acks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

On 2015년 10월 13일 17:03, Lee Jones wrote:
> On Mon, 12 Oct 2015, Chanwoo Choi wrote:
> 
>> On 2015년 10월 12일 19:16, Chanwoo Choi wrote:
>>> Hi Charles,
>>>
>>> On 2015년 10월 12일 17:45, Charles Keepax wrote:
>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>>>
>>>>>> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
>>>>>>> Add additional bindings to allow configuration of the system specific
>>>>>>> microphone detection settings.
>>>>>>
>>>>>> This all seems pretty much fine to me - the things it is controlling are
>>>>>> fairly specific to the way the former Wolfson devices do, they only
>>>>>> really make sense with a fairly particular algorithm which isn't widely
>>>>>> implemented.
>>>>>
>>>>> Is that an Ack?
>>>>
>>>> I am guessing Mark is slightly hesitant to ack as he probably
>>>> doesn't want to add reviewing all our jack detection bindings to
>>>> his already fairly sizable work load and doing so here likely
>>>> means it will be expected in the future. From talking to people at
>>>> LinuxCon it looks like it is pretty unlikely the DT maintainers
>>>> will be acking individual bindings as well, basically they are
>>>> only really looking at major/framework things and leaving the
>>>> rest to subsystem maintainers.
>>>>
>>>> Given that these patches only touch MFD/Extcon and extcon
>>>> is a subsystem designed to handle things like jack detection
>>>> isn't it really sufficient that you and Chanwoo have looked this
>>>> and are happy with it? Otherwise I really don't see anyway to
>>>> move this forward and would appreciate any suggestions?
>>>
>>> I'm positive about your patches. After receiving the ack from MFD maintainer
>>> I want to apply this patch-set on extcon git repository.
>>>
>>> Also, I reviewed this patch on previous patch[1].
>>> [1]https://lkml.org/lkml/2015/9/11/81
>>
>> As you said, this patch touch MFD and EXTCON subsystem.
>> If you get the Ack or agreement from MFD maintainer,
>> I'm willing to apply it on extcon git.
>>
>> Also, If this patch dont receive the additional ack message
>> unitl the end of this week, I'll merge patch1-3 on extcon-next branch
>> for Linux 4.4.
> 
> Absolutely not!
> 
> I should be extremely cross if you 'go over my head' and apply MFD
> patches without the correct Acks.
> 

Just I mean that if there is any reply or opinion about patch.
But, You're right. It is misconception of me. We should check them cross before applying them.

Thanks,
Chanwoo Choi

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

On 2015년 10월 13일 17:03, Lee Jones wrote:
> On Mon, 12 Oct 2015, Chanwoo Choi wrote:
> 
>> On 2015년 10월 12일 19:16, Chanwoo Choi wrote:
>>> Hi Charles,
>>>
>>> On 2015년 10월 12일 17:45, Charles Keepax wrote:
>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>>>
>>>>>> On Fri, Oct 02, 2015 at 05:29:22PM +0100, Charles Keepax wrote:
>>>>>>> Add additional bindings to allow configuration of the system specific
>>>>>>> microphone detection settings.
>>>>>>
>>>>>> This all seems pretty much fine to me - the things it is controlling are
>>>>>> fairly specific to the way the former Wolfson devices do, they only
>>>>>> really make sense with a fairly particular algorithm which isn't widely
>>>>>> implemented.
>>>>>
>>>>> Is that an Ack?
>>>>
>>>> I am guessing Mark is slightly hesitant to ack as he probably
>>>> doesn't want to add reviewing all our jack detection bindings to
>>>> his already fairly sizable work load and doing so here likely
>>>> means it will be expected in the future. From talking to people at
>>>> LinuxCon it looks like it is pretty unlikely the DT maintainers
>>>> will be acking individual bindings as well, basically they are
>>>> only really looking at major/framework things and leaving the
>>>> rest to subsystem maintainers.
>>>>
>>>> Given that these patches only touch MFD/Extcon and extcon
>>>> is a subsystem designed to handle things like jack detection
>>>> isn't it really sufficient that you and Chanwoo have looked this
>>>> and are happy with it? Otherwise I really don't see anyway to
>>>> move this forward and would appreciate any suggestions?
>>>
>>> I'm positive about your patches. After receiving the ack from MFD maintainer
>>> I want to apply this patch-set on extcon git repository.
>>>
>>> Also, I reviewed this patch on previous patch[1].
>>> [1]https://lkml.org/lkml/2015/9/11/81
>>
>> As you said, this patch touch MFD and EXTCON subsystem.
>> If you get the Ack or agreement from MFD maintainer,
>> I'm willing to apply it on extcon git.
>>
>> Also, If this patch dont receive the additional ack message
>> unitl the end of this week, I'll merge patch1-3 on extcon-next branch
>> for Linux 4.4.
> 
> Absolutely not!
> 
> I should be extremely cross if you 'go over my head' and apply MFD
> patches without the correct Acks.
> 

Just I mean that if there is any reply or opinion about patch.
But, You're right. It is misconception of me. We should check them cross before applying them.

Thanks,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > On Wed, 07 Oct 2015, Mark Brown wrote:

> > > This all seems pretty much fine to me - the things it is controlling are
> > > fairly specific to the way the former Wolfson devices do, they only
> > > really make sense with a fairly particular algorithm which isn't widely
> > > implemented.

> > Is that an Ack?

> I am guessing Mark is slightly hesitant to ack as he probably
> doesn't want to add reviewing all our jack detection bindings to
> his already fairly sizable work load and doing so here likely
> means it will be expected in the future. From talking to people at

Pretty much (plus generally being busy at ELC-E last week) - if there's
specific questions that's one thing but if it's just general requests to
look at bindings then it seems like the relevant subsystem maintainers
should have the confidence to review straightfoward device properties
like this.

> LinuxCon it looks like it is pretty unlikely the DT maintainers
> will be acking individual bindings as well, basically they are
> only really looking at major/framework things and leaving the
> rest to subsystem maintainers.
> 
> Given that these patches only touch MFD/Extcon and extcon
> is a subsystem designed to handle things like jack detection
> isn't it really sufficient that you and Chanwoo have looked this
> and are happy with it? Otherwise I really don't see anyway to
> move this forward and would appreciate any suggestions?
> 
> Thanks,
> Charles
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > On Wed, 07 Oct 2015, Mark Brown wrote:

> > > This all seems pretty much fine to me - the things it is controlling are
> > > fairly specific to the way the former Wolfson devices do, they only
> > > really make sense with a fairly particular algorithm which isn't widely
> > > implemented.

> > Is that an Ack?

> I am guessing Mark is slightly hesitant to ack as he probably
> doesn't want to add reviewing all our jack detection bindings to
> his already fairly sizable work load and doing so here likely
> means it will be expected in the future. From talking to people at

Pretty much (plus generally being busy at ELC-E last week) - if there's
specific questions that's one thing but if it's just general requests to
look at bindings then it seems like the relevant subsystem maintainers
should have the confidence to review straightfoward device properties
like this.

> LinuxCon it looks like it is pretty unlikely the DT maintainers
> will be acking individual bindings as well, basically they are
> only really looking at major/framework things and leaving the
> rest to subsystem maintainers.
> 
> Given that these patches only touch MFD/Extcon and extcon
> is a subsystem designed to handle things like jack detection
> isn't it really sufficient that you and Chanwoo have looked this
> and are happy with it? Otherwise I really don't see anyway to
> move this forward and would appreciate any suggestions?
> 
> Thanks,
> Charles
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Mon, 12 Oct 2015, Mark Brown wrote:

> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > On Wed, 07 Oct 2015, Mark Brown wrote:
> 
> > > > This all seems pretty much fine to me - the things it is controlling are
> > > > fairly specific to the way the former Wolfson devices do, they only
> > > > really make sense with a fairly particular algorithm which isn't widely
> > > > implemented.
> 
> > > Is that an Ack?
> 
> > I am guessing Mark is slightly hesitant to ack as he probably
> > doesn't want to add reviewing all our jack detection bindings to
> > his already fairly sizable work load and doing so here likely
> > means it will be expected in the future. From talking to people at

Providing Acks should not (and has not to my knowledge) be a binding
contract to continue providing Acks.  However, should more bindings be
submitted which appear as though they are related to a particular
maintainer, then sure, you'll be asked for your expert eye again.

> Pretty much (plus generally being busy at ELC-E last week) - if there's
> specific questions that's one thing but if it's just general requests to
> look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point.  I am not the 'relevant subsystem
maintainer' for these properties and subsequently know nothing of
microphone detection, headsets, bias', etc.  These look like Audio
related properties to me (the uninitiated), which is why you were
asked.

> should have the confidence to review straightfoward device properties
> like this.

I don't think these bindings are particularly straightforward.  The
contain many terms which I'm unfamiliar with, and again, to me (the
uninitiated) this looks like way too many bindings just to see if an
audio jack is plugged in or not.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Mon, 12 Oct 2015, Mark Brown wrote:

> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > On Wed, 07 Oct 2015, Mark Brown wrote:
> 
> > > > This all seems pretty much fine to me - the things it is controlling are
> > > > fairly specific to the way the former Wolfson devices do, they only
> > > > really make sense with a fairly particular algorithm which isn't widely
> > > > implemented.
> 
> > > Is that an Ack?
> 
> > I am guessing Mark is slightly hesitant to ack as he probably
> > doesn't want to add reviewing all our jack detection bindings to
> > his already fairly sizable work load and doing so here likely
> > means it will be expected in the future. From talking to people at

Providing Acks should not (and has not to my knowledge) be a binding
contract to continue providing Acks.  However, should more bindings be
submitted which appear as though they are related to a particular
maintainer, then sure, you'll be asked for your expert eye again.

> Pretty much (plus generally being busy at ELC-E last week) - if there's
> specific questions that's one thing but if it's just general requests to
> look at bindings then it seems like the relevant subsystem maintainers

This is exactly my point.  I am not the 'relevant subsystem
maintainer' for these properties and subsequently know nothing of
microphone detection, headsets, bias', etc.  These look like Audio
related properties to me (the uninitiated), which is why you were
asked.

> should have the confidence to review straightfoward device properties
> like this.

I don't think these bindings are particularly straightforward.  The
contain many terms which I'm unfamiliar with, and again, to me (the
uninitiated) this looks like way too many bindings just to see if an
audio jack is plugged in or not.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> On Mon, 12 Oct 2015, Mark Brown wrote:
> 
> > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > > On Wed, 07 Oct 2015, Mark Brown wrote:
> > 
> > > > > This all seems pretty much fine to me - the things it is controlling are
> > > > > fairly specific to the way the former Wolfson devices do, they only
> > > > > really make sense with a fairly particular algorithm which isn't widely
> > > > > implemented.
> > 
> > > > Is that an Ack?
> > 
> > > I am guessing Mark is slightly hesitant to ack as he probably
> > > doesn't want to add reviewing all our jack detection bindings to
> > > his already fairly sizable work load and doing so here likely
> > > means it will be expected in the future. From talking to people at
> 
> Providing Acks should not (and has not to my knowledge) be a binding
> contract to continue providing Acks.  However, should more bindings be
> submitted which appear as though they are related to a particular
> maintainer, then sure, you'll be asked for your expert eye again.

Its not a binding contract to continue providing them but we are
making that a condition of merging any patches, which means I
will need to chase Mark for Acks, as it seems the DT maintainers
won't have any interest in reviewing/acking these.

> 
> > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > specific questions that's one thing but if it's just general requests to
> > look at bindings then it seems like the relevant subsystem maintainers
> 
> This is exactly my point.  I am not the 'relevant subsystem
> maintainer' for these properties and subsequently know nothing of
> microphone detection, headsets, bias', etc.  These look like Audio
> related properties to me (the uninitiated), which is why you were
> asked.

It would be sensible I guess to define whether I should be
including audio people on jack detection patches even if they
don't touch audio subsystems. I was treating jack detection
as an extcon thing and thus assuming that the extcon maintainer
would be sufficient, but perhaps that is an incorrect assumption.

> 
> > should have the confidence to review straightfoward device properties
> > like this.
> 
> I don't think these bindings are particularly straightforward.  The
> contain many terms which I'm unfamiliar with, and again, to me (the
> uninitiated) this looks like way too many bindings just to see if an
> audio jack is plugged in or not.

I also wish our designers would make less complex hardware sigh.

Apologies I didn't mean to cause any offense here, I am just
getting a bit concerned about how I can get any DT support for
jack detection upstreamed. I am more than happy to fix up any
comments anyone has or answer any questions about what things
are or why they are required.

The jack detection on these chips is fairly complex and there are
going to be plenty more patches before we have full support for
it in DT. So I think it would be good for everyone if we can
agree some process for how to handle this type of patch.

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> On Mon, 12 Oct 2015, Mark Brown wrote:
> 
> > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > > On Wed, 07 Oct 2015, Mark Brown wrote:
> > 
> > > > > This all seems pretty much fine to me - the things it is controlling are
> > > > > fairly specific to the way the former Wolfson devices do, they only
> > > > > really make sense with a fairly particular algorithm which isn't widely
> > > > > implemented.
> > 
> > > > Is that an Ack?
> > 
> > > I am guessing Mark is slightly hesitant to ack as he probably
> > > doesn't want to add reviewing all our jack detection bindings to
> > > his already fairly sizable work load and doing so here likely
> > > means it will be expected in the future. From talking to people at
> 
> Providing Acks should not (and has not to my knowledge) be a binding
> contract to continue providing Acks.  However, should more bindings be
> submitted which appear as though they are related to a particular
> maintainer, then sure, you'll be asked for your expert eye again.

Its not a binding contract to continue providing them but we are
making that a condition of merging any patches, which means I
will need to chase Mark for Acks, as it seems the DT maintainers
won't have any interest in reviewing/acking these.

> 
> > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > specific questions that's one thing but if it's just general requests to
> > look at bindings then it seems like the relevant subsystem maintainers
> 
> This is exactly my point.  I am not the 'relevant subsystem
> maintainer' for these properties and subsequently know nothing of
> microphone detection, headsets, bias', etc.  These look like Audio
> related properties to me (the uninitiated), which is why you were
> asked.

It would be sensible I guess to define whether I should be
including audio people on jack detection patches even if they
don't touch audio subsystems. I was treating jack detection
as an extcon thing and thus assuming that the extcon maintainer
would be sufficient, but perhaps that is an incorrect assumption.

> 
> > should have the confidence to review straightfoward device properties
> > like this.
> 
> I don't think these bindings are particularly straightforward.  The
> contain many terms which I'm unfamiliar with, and again, to me (the
> uninitiated) this looks like way too many bindings just to see if an
> audio jack is plugged in or not.

I also wish our designers would make less complex hardware sigh.

Apologies I didn't mean to cause any offense here, I am just
getting a bit concerned about how I can get any DT support for
jack detection upstreamed. I am more than happy to fix up any
comments anyone has or answer any questions about what things
are or why they are required.

The jack detection on these chips is fairly complex and there are
going to be plenty more patches before we have full support for
it in DT. So I think it would be good for everyone if we can
agree some process for how to handle this type of patch.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Charles Keepax wrote:

> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > On Mon, 12 Oct 2015, Mark Brown wrote:
> > 
> > > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > > > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > > > On Wed, 07 Oct 2015, Mark Brown wrote:
> > > 
> > > > > > This all seems pretty much fine to me - the things it is controlling are
> > > > > > fairly specific to the way the former Wolfson devices do, they only
> > > > > > really make sense with a fairly particular algorithm which isn't widely
> > > > > > implemented.
> > > 
> > > > > Is that an Ack?
> > > 
> > > > I am guessing Mark is slightly hesitant to ack as he probably
> > > > doesn't want to add reviewing all our jack detection bindings to
> > > > his already fairly sizable work load and doing so here likely
> > > > means it will be expected in the future. From talking to people at
> > 
> > Providing Acks should not (and has not to my knowledge) be a binding
> > contract to continue providing Acks.  However, should more bindings be
> > submitted which appear as though they are related to a particular
> > maintainer, then sure, you'll be asked for your expert eye again.
> 
> Its not a binding contract to continue providing them but we are
> making that a condition of merging any patches, which means I
> will need to chase Mark for Acks, as it seems the DT maintainers
> won't have any interest in reviewing/acking these.

I've already made it a condition, as I refuse to blindly accept
unknown bindings.  Taking a sea of bindings I have no knowledge of
would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
Linus for help, likewise if they were I2C, I'd be asking Wolfram.

> > > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > > specific questions that's one thing but if it's just general requests to
> > > look at bindings then it seems like the relevant subsystem maintainers
> > 
> > This is exactly my point.  I am not the 'relevant subsystem
> > maintainer' for these properties and subsequently know nothing of
> > microphone detection, headsets, bias', etc.  These look like Audio
> > related properties to me (the uninitiated), which is why you were
> > asked.
> 
> It would be sensible I guess to define whether I should be
> including audio people on jack detection patches even if they
> don't touch audio subsystems. I was treating jack detection
> as an extcon thing and thus assuming that the extcon maintainer
> would be sufficient, but perhaps that is an incorrect assumption.

Now I know that jack detection is an Extcon thing and Extcon Ack will
do just nicely.  However, that begs the question; if they are an
Extcon thing, why aren't they in the Extcon binding document?

> > > should have the confidence to review straightfoward device properties
> > > like this.
> > 
> > I don't think these bindings are particularly straightforward.  The
> > contain many terms which I'm unfamiliar with, and again, to me (the
> > uninitiated) this looks like way too many bindings just to see if an
> > audio jack is plugged in or not.
> 
> I also wish our designers would make less complex hardware sigh.
> 
> Apologies I didn't mean to cause any offense here, I am just
> getting a bit concerned about how I can get any DT support for
> jack detection upstreamed. I am more than happy to fix up any
> comments anyone has or answer any questions about what things
> are or why they are required.

Hopefully there won't be too many more bindings to come?

My issue is that as they are not MFD related, I need some advice from
my colleagues to whom they are related to.

> The jack detection on these chips is fairly complex and there are
> going to be plenty more patches before we have full support for
> it in DT. So I think it would be good for everyone if we can
> agree some process for how to handle this type of patch.

Put them in the subsystem where they pertain to -- job done.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Charles Keepax wrote:

> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > On Mon, 12 Oct 2015, Mark Brown wrote:
> > 
> > > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > > > On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > > > > On Wed, 07 Oct 2015, Mark Brown wrote:
> > > 
> > > > > > This all seems pretty much fine to me - the things it is controlling are
> > > > > > fairly specific to the way the former Wolfson devices do, they only
> > > > > > really make sense with a fairly particular algorithm which isn't widely
> > > > > > implemented.
> > > 
> > > > > Is that an Ack?
> > > 
> > > > I am guessing Mark is slightly hesitant to ack as he probably
> > > > doesn't want to add reviewing all our jack detection bindings to
> > > > his already fairly sizable work load and doing so here likely
> > > > means it will be expected in the future. From talking to people at
> > 
> > Providing Acks should not (and has not to my knowledge) be a binding
> > contract to continue providing Acks.  However, should more bindings be
> > submitted which appear as though they are related to a particular
> > maintainer, then sure, you'll be asked for your expert eye again.
> 
> Its not a binding contract to continue providing them but we are
> making that a condition of merging any patches, which means I
> will need to chase Mark for Acks, as it seems the DT maintainers
> won't have any interest in reviewing/acking these.

I've already made it a condition, as I refuse to blindly accept
unknown bindings.  Taking a sea of bindings I have no knowledge of
would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
Linus for help, likewise if they were I2C, I'd be asking Wolfram.

> > > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > > specific questions that's one thing but if it's just general requests to
> > > look at bindings then it seems like the relevant subsystem maintainers
> > 
> > This is exactly my point.  I am not the 'relevant subsystem
> > maintainer' for these properties and subsequently know nothing of
> > microphone detection, headsets, bias', etc.  These look like Audio
> > related properties to me (the uninitiated), which is why you were
> > asked.
> 
> It would be sensible I guess to define whether I should be
> including audio people on jack detection patches even if they
> don't touch audio subsystems. I was treating jack detection
> as an extcon thing and thus assuming that the extcon maintainer
> would be sufficient, but perhaps that is an incorrect assumption.

Now I know that jack detection is an Extcon thing and Extcon Ack will
do just nicely.  However, that begs the question; if they are an
Extcon thing, why aren't they in the Extcon binding document?

> > > should have the confidence to review straightfoward device properties
> > > like this.
> > 
> > I don't think these bindings are particularly straightforward.  The
> > contain many terms which I'm unfamiliar with, and again, to me (the
> > uninitiated) this looks like way too many bindings just to see if an
> > audio jack is plugged in or not.
> 
> I also wish our designers would make less complex hardware sigh.
> 
> Apologies I didn't mean to cause any offense here, I am just
> getting a bit concerned about how I can get any DT support for
> jack detection upstreamed. I am more than happy to fix up any
> comments anyone has or answer any questions about what things
> are or why they are required.

Hopefully there won't be too many more bindings to come?

My issue is that as they are not MFD related, I need some advice from
my colleagues to whom they are related to.

> The jack detection on these chips is fairly complex and there are
> going to be plenty more patches before we have full support for
> it in DT. So I think it would be good for everyone if we can
> agree some process for how to handle this type of patch.

Put them in the subsystem where they pertain to -- job done.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

Hi Lee,

On 2015년 10월 13일 22:50, Lee Jones wrote:
> On Tue, 13 Oct 2015, Charles Keepax wrote:
> 
>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
>>> On Mon, 12 Oct 2015, Mark Brown wrote:
>>>
>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>>
>>>>>>> This all seems pretty much fine to me - the things it is controlling are
>>>>>>> fairly specific to the way the former Wolfson devices do, they only
>>>>>>> really make sense with a fairly particular algorithm which isn't widely
>>>>>>> implemented.
>>>>
>>>>>> Is that an Ack?
>>>>
>>>>> I am guessing Mark is slightly hesitant to ack as he probably
>>>>> doesn't want to add reviewing all our jack detection bindings to
>>>>> his already fairly sizable work load and doing so here likely
>>>>> means it will be expected in the future. From talking to people at
>>>
>>> Providing Acks should not (and has not to my knowledge) be a binding
>>> contract to continue providing Acks.  However, should more bindings be
>>> submitted which appear as though they are related to a particular
>>> maintainer, then sure, you'll be asked for your expert eye again.
>>
>> Its not a binding contract to continue providing them but we are
>> making that a condition of merging any patches, which means I
>> will need to chase Mark for Acks, as it seems the DT maintainers
>> won't have any interest in reviewing/acking these.
> 
> I've already made it a condition, as I refuse to blindly accept
> unknown bindings.  Taking a sea of bindings I have no knowledge of
> would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
> Linus for help, likewise if they were I2C, I'd be asking Wolfram.
> 
>>>> Pretty much (plus generally being busy at ELC-E last week) - if there's
>>>> specific questions that's one thing but if it's just general requests to
>>>> look at bindings then it seems like the relevant subsystem maintainers
>>>
>>> This is exactly my point.  I am not the 'relevant subsystem
>>> maintainer' for these properties and subsequently know nothing of
>>> microphone detection, headsets, bias', etc.  These look like Audio
>>> related properties to me (the uninitiated), which is why you were
>>> asked.
>>
>> It would be sensible I guess to define whether I should be
>> including audio people on jack detection patches even if they
>> don't touch audio subsystems. I was treating jack detection
>> as an extcon thing and thus assuming that the extcon maintainer
>> would be sufficient, but perhaps that is an incorrect assumption.
> 
> Now I know that jack detection is an Extcon thing and Extcon Ack will
> do just nicely.  However, that begs the question; if they are an
> Extcon thing, why aren't they in the Extcon binding document?

As I knew, the arizona-extcon is one device of the MFD devices 
for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
driver needs the some property for dt support, some property should be
included in MFD device tree node. There is no separate device tree node for
arizona-extcon driver.

Thanks,
Chanwoo Choi

> 
>>>> should have the confidence to review straightfoward device properties
>>>> like this.
>>>
>>> I don't think these bindings are particularly straightforward.  The
>>> contain many terms which I'm unfamiliar with, and again, to me (the
>>> uninitiated) this looks like way too many bindings just to see if an
>>> audio jack is plugged in or not.
>>
>> I also wish our designers would make less complex hardware sigh.
>>
>> Apologies I didn't mean to cause any offense here, I am just
>> getting a bit concerned about how I can get any DT support for
>> jack detection upstreamed. I am more than happy to fix up any
>> comments anyone has or answer any questions about what things
>> are or why they are required.
> 
> Hopefully there won't be too many more bindings to come?
> 
> My issue is that as they are not MFD related, I need some advice from
> my colleagues to whom they are related to.
> 
>> The jack detection on these chips is fairly complex and there are
>> going to be plenty more patches before we have full support for
>> it in DT. So I think it would be good for everyone if we can
>> agree some process for how to handle this type of patch.
> 
> Put them in the subsystem where they pertain to -- job done.
> 

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> Hi Lee,
> 
> On 2015년 10월 13일 22:50, Lee Jones wrote:
>> On Tue, 13 Oct 2015, Charles Keepax wrote:
>>
>>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
>>>> On Mon, 12 Oct 2015, Mark Brown wrote:
>>>>
>>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
>>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>>>
>>>>>>>> This all seems pretty much fine to me - the things it is controlling are
>>>>>>>> fairly specific to the way the former Wolfson devices do, they only
>>>>>>>> really make sense with a fairly particular algorithm which isn't widely
>>>>>>>> implemented.
>>>>>
>>>>>>> Is that an Ack?
>>>>>
>>>>>> I am guessing Mark is slightly hesitant to ack as he probably
>>>>>> doesn't want to add reviewing all our jack detection bindings to
>>>>>> his already fairly sizable work load and doing so here likely
>>>>>> means it will be expected in the future. From talking to people at
>>>>
>>>> Providing Acks should not (and has not to my knowledge) be a binding
>>>> contract to continue providing Acks.  However, should more bindings be
>>>> submitted which appear as though they are related to a particular
>>>> maintainer, then sure, you'll be asked for your expert eye again.
>>>
>>> Its not a binding contract to continue providing them but we are
>>> making that a condition of merging any patches, which means I
>>> will need to chase Mark for Acks, as it seems the DT maintainers
>>> won't have any interest in reviewing/acking these.
>>
>> I've already made it a condition, as I refuse to blindly accept
>> unknown bindings.  Taking a sea of bindings I have no knowledge of
>> would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
>> Linus for help, likewise if they were I2C, I'd be asking Wolfram.
>>
>>>>> Pretty much (plus generally being busy at ELC-E last week) - if there's
>>>>> specific questions that's one thing but if it's just general requests to
>>>>> look at bindings then it seems like the relevant subsystem maintainers
>>>>
>>>> This is exactly my point.  I am not the 'relevant subsystem
>>>> maintainer' for these properties and subsequently know nothing of
>>>> microphone detection, headsets, bias', etc.  These look like Audio
>>>> related properties to me (the uninitiated), which is why you were
>>>> asked.
>>>
>>> It would be sensible I guess to define whether I should be
>>> including audio people on jack detection patches even if they
>>> don't touch audio subsystems. I was treating jack detection
>>> as an extcon thing and thus assuming that the extcon maintainer
>>> would be sufficient, but perhaps that is an incorrect assumption.
>>
>> Now I know that jack detection is an Extcon thing and Extcon Ack will
>> do just nicely.  However, that begs the question; if they are an
>> Extcon thing, why aren't they in the Extcon binding document?
> 
> As I knew, the arizona-extcon is one device of the MFD devices 
> for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> driver needs the some property for dt support, some property should be
> included in MFD device tree node. There is no separate device tree node for
> arizona-extcon driver.

If creating the separate extcon doc for extcon-arizona.c driver, it is possible
to make the child device tree node which is located at the below of arizona MFD
device tree node.

I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

[snip]

Thanks,
Chanwoo Choi

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Chanwoo Choi]

On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> Hi Lee,
> 
> On 2015년 10월 13일 22:50, Lee Jones wrote:
>> On Tue, 13 Oct 2015, Charles Keepax wrote:
>>
>>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
>>>> On Mon, 12 Oct 2015, Mark Brown wrote:
>>>>
>>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
>>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
>>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
>>>>>
>>>>>>>> This all seems pretty much fine to me - the things it is controlling are
>>>>>>>> fairly specific to the way the former Wolfson devices do, they only
>>>>>>>> really make sense with a fairly particular algorithm which isn't widely
>>>>>>>> implemented.
>>>>>
>>>>>>> Is that an Ack?
>>>>>
>>>>>> I am guessing Mark is slightly hesitant to ack as he probably
>>>>>> doesn't want to add reviewing all our jack detection bindings to
>>>>>> his already fairly sizable work load and doing so here likely
>>>>>> means it will be expected in the future. From talking to people at
>>>>
>>>> Providing Acks should not (and has not to my knowledge) be a binding
>>>> contract to continue providing Acks.  However, should more bindings be
>>>> submitted which appear as though they are related to a particular
>>>> maintainer, then sure, you'll be asked for your expert eye again.
>>>
>>> Its not a binding contract to continue providing them but we are
>>> making that a condition of merging any patches, which means I
>>> will need to chase Mark for Acks, as it seems the DT maintainers
>>> won't have any interest in reviewing/acking these.
>>
>> I've already made it a condition, as I refuse to blindly accept
>> unknown bindings.  Taking a sea of bindings I have no knowledge of
>> would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
>> Linus for help, likewise if they were I2C, I'd be asking Wolfram.
>>
>>>>> Pretty much (plus generally being busy at ELC-E last week) - if there's
>>>>> specific questions that's one thing but if it's just general requests to
>>>>> look at bindings then it seems like the relevant subsystem maintainers
>>>>
>>>> This is exactly my point.  I am not the 'relevant subsystem
>>>> maintainer' for these properties and subsequently know nothing of
>>>> microphone detection, headsets, bias', etc.  These look like Audio
>>>> related properties to me (the uninitiated), which is why you were
>>>> asked.
>>>
>>> It would be sensible I guess to define whether I should be
>>> including audio people on jack detection patches even if they
>>> don't touch audio subsystems. I was treating jack detection
>>> as an extcon thing and thus assuming that the extcon maintainer
>>> would be sufficient, but perhaps that is an incorrect assumption.
>>
>> Now I know that jack detection is an Extcon thing and Extcon Ack will
>> do just nicely.  However, that begs the question; if they are an
>> Extcon thing, why aren't they in the Extcon binding document?
> 
> As I knew, the arizona-extcon is one device of the MFD devices 
> for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> driver needs the some property for dt support, some property should be
> included in MFD device tree node. There is no separate device tree node for
> arizona-extcon driver.

If creating the separate extcon doc for extcon-arizona.c driver, it is possible
to make the child device tree node which is located at the below of arizona MFD
device tree node.

I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

[snip]

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Chanwoo Choi wrote:
> On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> > On 2015년 10월 13일 22:50, Lee Jones wrote:
> >> On Tue, 13 Oct 2015, Charles Keepax wrote:
> >>
> >>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> >>>> On Mon, 12 Oct 2015, Mark Brown wrote:
> >>>>
> >>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> >>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> >>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
> >>>>>
> >>>>>>>> This all seems pretty much fine to me - the things it is controlling are
> >>>>>>>> fairly specific to the way the former Wolfson devices do, they only
> >>>>>>>> really make sense with a fairly particular algorithm which isn't widely
> >>>>>>>> implemented.
> >>>>>
> >>>>>>> Is that an Ack?
> >>>>>
> >>>>>> I am guessing Mark is slightly hesitant to ack as he probably
> >>>>>> doesn't want to add reviewing all our jack detection bindings to
> >>>>>> his already fairly sizable work load and doing so here likely
> >>>>>> means it will be expected in the future. From talking to people at
> >>>>
> >>>> Providing Acks should not (and has not to my knowledge) be a binding
> >>>> contract to continue providing Acks.  However, should more bindings be
> >>>> submitted which appear as though they are related to a particular
> >>>> maintainer, then sure, you'll be asked for your expert eye again.
> >>>
> >>> Its not a binding contract to continue providing them but we are
> >>> making that a condition of merging any patches, which means I
> >>> will need to chase Mark for Acks, as it seems the DT maintainers
> >>> won't have any interest in reviewing/acking these.
> >>
> >> I've already made it a condition, as I refuse to blindly accept
> >> unknown bindings.  Taking a sea of bindings I have no knowledge of
> >> would be a bad-thing(tm).  If these were GPIO bindings, I'd be asking
> >> Linus for help, likewise if they were I2C, I'd be asking Wolfram.
> >>
> >>>>> Pretty much (plus generally being busy at ELC-E last week) - if there's
> >>>>> specific questions that's one thing but if it's just general requests to
> >>>>> look at bindings then it seems like the relevant subsystem maintainers
> >>>>
> >>>> This is exactly my point.  I am not the 'relevant subsystem
> >>>> maintainer' for these properties and subsequently know nothing of
> >>>> microphone detection, headsets, bias', etc.  These look like Audio
> >>>> related properties to me (the uninitiated), which is why you were
> >>>> asked.
> >>>
> >>> It would be sensible I guess to define whether I should be
> >>> including audio people on jack detection patches even if they
> >>> don't touch audio subsystems. I was treating jack detection
> >>> as an extcon thing and thus assuming that the extcon maintainer
> >>> would be sufficient, but perhaps that is an incorrect assumption.
> >>
> >> Now I know that jack detection is an Extcon thing and Extcon Ack will
> >> do just nicely.  However, that begs the question; if they are an
> >> Extcon thing, why aren't they in the Extcon binding document?
> > 
> > As I knew, the arizona-extcon is one device of the MFD devices 
> > for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> > driver needs the some property for dt support, some property should be
> > included in MFD device tree node. There is no separate device tree node for
> > arizona-extcon driver.
> 
> If creating the separate extcon doc for extcon-arizona.c driver, it is possible
> to make the child device tree node which is located at the below of arizona MFD
> device tree node.
> 
> I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

This is how we normally document MFDs.  Extcon doesn't even need to
have it's own child-node (it can if you want though -- it's however
you want to represent it), you can just put something like this in the
MFD binding doc:

Optional properties
this		: Does this
that		: Does that

Also any child device specific property:
	GPIO    See: ../extcon/arizona.txt
	Extcon  See: ../gpio/arizona.txt

Etc.  Or words to that effect.  See some other MFDs for examples.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 03:18:22PM +0100, Lee Jones wrote:
> On Tue, 13 Oct 2015, Chanwoo Choi wrote:
> > On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> > > On 2015년 10월 13일 22:50, Lee Jones wrote:
> > >> On Tue, 13 Oct 2015, Charles Keepax wrote:
> > >>
> > >>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > >>>> On Mon, 12 Oct 2015, Mark Brown wrote:
> > >>>>
> > >>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > >>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > >>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
> > >> Now I know that jack detection is an Extcon thing and Extcon Ack will
> > >> do just nicely.  However, that begs the question; if they are an
> > >> Extcon thing, why aren't they in the Extcon binding document?
> > > 
> > > As I knew, the arizona-extcon is one device of the MFD devices 
> > > for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> > > driver needs the some property for dt support, some property should be
> > > included in MFD device tree node. There is no separate device tree node for
> > > arizona-extcon driver.
> > 
> > If creating the separate extcon doc for extcon-arizona.c driver, it is possible
> > to make the child device tree node which is located at the below of arizona MFD
> > device tree node.
> > 
> > I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.
> 
> This is how we normally document MFDs.  Extcon doesn't even need to
> have it's own child-node (it can if you want though -- it's however
> you want to represent it), you can just put something like this in the
> MFD binding doc:
> 
> Optional properties
> this		: Does this
> that		: Does that
> 
> Also any child device specific property:
> 	GPIO    See: ../extcon/arizona.txt
> 	Extcon  See: ../gpio/arizona.txt
> 
> Etc.  Or words to that effect.  See some other MFDs for examples.

More accident of history than anything else I will send a patch
to split the binding up into the seperate subsystems shortly.

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 03:18:22PM +0100, Lee Jones wrote:
> On Tue, 13 Oct 2015, Chanwoo Choi wrote:
> > On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> > > On 2015년 10월 13일 22:50, Lee Jones wrote:
> > >> On Tue, 13 Oct 2015, Charles Keepax wrote:
> > >>
> > >>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > >>>> On Mon, 12 Oct 2015, Mark Brown wrote:
> > >>>>
> > >>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> > >>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> > >>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
> > >> Now I know that jack detection is an Extcon thing and Extcon Ack will
> > >> do just nicely.  However, that begs the question; if they are an
> > >> Extcon thing, why aren't they in the Extcon binding document?
> > > 
> > > As I knew, the arizona-extcon is one device of the MFD devices 
> > > for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> > > driver needs the some property for dt support, some property should be
> > > included in MFD device tree node. There is no separate device tree node for
> > > arizona-extcon driver.
> > 
> > If creating the separate extcon doc for extcon-arizona.c driver, it is possible
> > to make the child device tree node which is located at the below of arizona MFD
> > device tree node.
> > 
> > I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.
> 
> This is how we normally document MFDs.  Extcon doesn't even need to
> have it's own child-node (it can if you want though -- it's however
> you want to represent it), you can just put something like this in the
> MFD binding doc:
> 
> Optional properties
> this		: Does this
> that		: Does that
> 
> Also any child device specific property:
> 	GPIO    See: ../extcon/arizona.txt
> 	Extcon  See: ../gpio/arizona.txt
> 
> Etc.  Or words to that effect.  See some other MFDs for examples.

More accident of history than anything else I will send a patch
to split the binding up into the seperate subsystems shortly.

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> On Mon, 12 Oct 2015, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:

> > > I am guessing Mark is slightly hesitant to ack as he probably
> > > doesn't want to add reviewing all our jack detection bindings to
> > > his already fairly sizable work load and doing so here likely
> > > means it will be expected in the future. From talking to people at

> Providing Acks should not (and has not to my knowledge) be a binding
> contract to continue providing Acks.  However, should more bindings be
> submitted which appear as though they are related to a particular
> maintainer, then sure, you'll be asked for your expert eye again.

It's a bit concerning when it seems like my review is becoming a blocker
for something and I don't understand why.

> > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > specific questions that's one thing but if it's just general requests to
> > look at bindings then it seems like the relevant subsystem maintainers

> This is exactly my point.  I am not the 'relevant subsystem
> maintainer' for these properties and subsequently know nothing of
> microphone detection, headsets, bias', etc.  These look like Audio
> related properties to me (the uninitiated), which is why you were
> asked.

They're extcon things (and there are accompanying driver changes to the
extcon driver parsing them).

> > should have the confidence to review straightfoward device properties
> > like this.

> I don't think these bindings are particularly straightforward.  The
> contain many terms which I'm unfamiliar with, and again, to me (the
> uninitiated) this looks like way too many bindings just to see if an
> audio jack is plugged in or not.

When your power budget is in the low double digit microamps and you're
trying to respond promptly and reliably to rapidly changing and variable
physical inputs it gets complicated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Mark Brown wrote:
> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > On Mon, 12 Oct 2015, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> 
> > > > I am guessing Mark is slightly hesitant to ack as he probably
> > > > doesn't want to add reviewing all our jack detection bindings to
> > > > his already fairly sizable work load and doing so here likely
> > > > means it will be expected in the future. From talking to people at
> 
> > Providing Acks should not (and has not to my knowledge) be a binding
> > contract to continue providing Acks.  However, should more bindings be
> > submitted which appear as though they are related to a particular
> > maintainer, then sure, you'll be asked for your expert eye again.
> 
> It's a bit concerning when it seems like my review is becoming a blocker
> for something and I don't understand why.

Not necessarily _your_ review.  Just someone, other than the
submitter, who I trust and knows about this stuff.  You just happen 
to tick those boxes this time.  Cross pollination and knowledge sharing
is one of the characteristics of MLs which I'm particularly proud of.

> > > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > > specific questions that's one thing but if it's just general requests to
> > > look at bindings then it seems like the relevant subsystem maintainers
> 
> > This is exactly my point.  I am not the 'relevant subsystem
> > maintainer' for these properties and subsequently know nothing of
> > microphone detection, headsets, bias', etc.  These look like Audio
> > related properties to me (the uninitiated), which is why you were
> > asked.
> 
> They're extcon things (and there are accompanying driver changes to the
> extcon driver parsing them).

Yes, I'm aware of that now.  Hence the "(uninitiated)" part.

> > > should have the confidence to review straightfoward device properties
> > > like this.
> 
> > I don't think these bindings are particularly straightforward.  The
> > contain many terms which I'm unfamiliar with, and again, to me (the
> > uninitiated) this looks like way too many bindings just to see if an
> > audio jack is plugged in or not.
> 
> When your power budget is in the low double digit microamps and you're
> trying to respond promptly and reliably to rapidly changing and variable
> physical inputs it gets complicated.

This is exactly why I asked you.

Thanks for adding structure to my PoV. ;) 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Wed, Oct 14, 2015 at 08:28:12AM +0100, Lee Jones wrote:
> On Tue, 13 Oct 2015, Mark Brown wrote:
> > On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:

> > > Providing Acks should not (and has not to my knowledge) be a binding
> > > contract to continue providing Acks.  However, should more bindings be
> > > submitted which appear as though they are related to a particular
> > > maintainer, then sure, you'll be asked for your expert eye again.

> > It's a bit concerning when it seems like my review is becoming a blocker
> > for something and I don't understand why.

> Not necessarily _your_ review.  Just someone, other than the
> submitter, who I trust and knows about this stuff.  You just happen 
> to tick those boxes this time.  Cross pollination and knowledge sharing
> is one of the characteristics of MLs which I'm particularly proud of.

That was what it read like.

> > When your power budget is in the low double digit microamps and you're
> > trying to respond promptly and reliably to rapidly changing and variable
> > physical inputs it gets complicated.

> This is exactly why I asked you.

> Thanks for adding structure to my PoV. ;) 

So, a more specific question would have helped - just a general "any
thoughts" type question isn't very clear.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 14 Oct 2015, Mark Brown wrote:

> On Wed, Oct 14, 2015 at 08:28:12AM +0100, Lee Jones wrote:
> > On Tue, 13 Oct 2015, Mark Brown wrote:
> > > On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> 
> > > > Providing Acks should not (and has not to my knowledge) be a binding
> > > > contract to continue providing Acks.  However, should more bindings be
> > > > submitted which appear as though they are related to a particular
> > > > maintainer, then sure, you'll be asked for your expert eye again.
> 
> > > It's a bit concerning when it seems like my review is becoming a blocker
> > > for something and I don't understand why.
> 
> > Not necessarily _your_ review.  Just someone, other than the
> > submitter, who I trust and knows about this stuff.  You just happen 
> > to tick those boxes this time.  Cross pollination and knowledge sharing
> > is one of the characteristics of MLs which I'm particularly proud of.
> 
> That was what it read like.
> 
> > > When your power budget is in the low double digit microamps and you're
> > > trying to respond promptly and reliably to rapidly changing and variable
> > > physical inputs it gets complicated.
> 
> > This is exactly why I asked you.
> 
> > Thanks for adding structure to my PoV. ;) 
> 
> So, a more specific question would have helped - just a general "any
> thoughts" type question isn't very clear.

To both comments -- this is how I phrased it:

"I either need an Ack from the DT folks, or at least someone who knows
about this stuff.  Mark perhaps."

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 14 Oct 2015, Mark Brown wrote:

> On Wed, Oct 14, 2015 at 08:28:12AM +0100, Lee Jones wrote:
> > On Tue, 13 Oct 2015, Mark Brown wrote:
> > > On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> 
> > > > Providing Acks should not (and has not to my knowledge) be a binding
> > > > contract to continue providing Acks.  However, should more bindings be
> > > > submitted which appear as though they are related to a particular
> > > > maintainer, then sure, you'll be asked for your expert eye again.
> 
> > > It's a bit concerning when it seems like my review is becoming a blocker
> > > for something and I don't understand why.
> 
> > Not necessarily _your_ review.  Just someone, other than the
> > submitter, who I trust and knows about this stuff.  You just happen 
> > to tick those boxes this time.  Cross pollination and knowledge sharing
> > is one of the characteristics of MLs which I'm particularly proud of.
> 
> That was what it read like.
> 
> > > When your power budget is in the low double digit microamps and you're
> > > trying to respond promptly and reliably to rapidly changing and variable
> > > physical inputs it gets complicated.
> 
> > This is exactly why I asked you.
> 
> > Thanks for adding structure to my PoV. ;) 
> 
> So, a more specific question would have helped - just a general "any
> thoughts" type question isn't very clear.

To both comments -- this is how I phrased it:

"I either need an Ack from the DT folks, or at least someone who knows
about this stuff.  Mark perhaps."

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Wed, Oct 14, 2015 at 01:30:14PM +0100, Lee Jones wrote:
> On Wed, 14 Oct 2015, Mark Brown wrote:

> > > Not necessarily _your_ review.  Just someone, other than the
> > > submitter, who I trust and knows about this stuff.  You just happen 
> > > to tick those boxes this time.  Cross pollination and knowledge sharing
> > > is one of the characteristics of MLs which I'm particularly proud of.

> > That was what it read like.

...

> > So, a more specific question would have helped - just a general "any
> > thoughts" type question isn't very clear.

> To both comments -- this is how I phrased it:

> "I either need an Ack from the DT folks, or at least someone who knows
> about this stuff.  Mark perhaps."

I'd have expected something that says why you're looking for this -
something saying what you were unclear on, something more like "It seems
like there's an awful lot of properties for something that just checks
if a jack".  From the above (especially with the request for the DT
people to review) it seems like more just a review because there's DT
properties.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Wed, Oct 14, 2015 at 01:30:14PM +0100, Lee Jones wrote:
> On Wed, 14 Oct 2015, Mark Brown wrote:

> > > Not necessarily _your_ review.  Just someone, other than the
> > > submitter, who I trust and knows about this stuff.  You just happen 
> > > to tick those boxes this time.  Cross pollination and knowledge sharing
> > > is one of the characteristics of MLs which I'm particularly proud of.

> > That was what it read like.

...

> > So, a more specific question would have helped - just a general "any
> > thoughts" type question isn't very clear.

> To both comments -- this is how I phrased it:

> "I either need an Ack from the DT folks, or at least someone who knows
> about this stuff.  Mark perhaps."

I'd have expected something that says why you're looking for this -
something saying what you were unclear on, something more like "It seems
like there's an awful lot of properties for something that just checks
if a jack".  From the above (especially with the request for the DT
people to review) it seems like more just a review because there's DT
properties.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Wed, 14 Oct 2015, Mark Brown wrote:

> On Wed, Oct 14, 2015 at 01:30:14PM +0100, Lee Jones wrote:
> > On Wed, 14 Oct 2015, Mark Brown wrote:
> 
> > > > Not necessarily _your_ review.  Just someone, other than the
> > > > submitter, who I trust and knows about this stuff.  You just happen 
> > > > to tick those boxes this time.  Cross pollination and knowledge sharing
> > > > is one of the characteristics of MLs which I'm particularly proud of.
> 
> > > That was what it read like.
> 
> ...
> 
> > > So, a more specific question would have helped - just a general "any
> > > thoughts" type question isn't very clear.
> 
> > To both comments -- this is how I phrased it:
> 
> > "I either need an Ack from the DT folks, or at least someone who knows
> > about this stuff.  Mark perhaps."
> 
> I'd have expected something that says why you're looking for this -
> something saying what you were unclear on, something more like "It seems
> like there's an awful lot of properties for something that just checks
> if a jack".  From the above (especially with the request for the DT
> people to review) it seems like more just a review because there's DT
> properties.

Your perception is not correct.  I always used to ask for a DT review
if there are more than a couple being added.  These days I'm happy to
apply either complex properties, or just ones I'm not 100% on with a
suitable Maintainer Ack.  That continues to be the case.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Fri, 02 Oct 2015, Charles Keepax wrote:

> Add additional bindings to allow configuration of the system specific
> microphone detection settings.
> 
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
>  include/dt-bindings/mfd/arizona.h                 |    5 +++++
>  2 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..b98a11b 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,27 @@ Optional properties:
>      If this node is not mentioned or if the value is unknown, then
>      headphone detection mode is set to HPDETL.
>  
> +  - wlf,micd-software-compare : Use a software comparison to determine mic
> +    presence
> +  - wlf,micd-detect-debounce : Additional software microphone detection
> +    debounce specified in milliseconds.
> +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> +    polarity if one exists.
> +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> +    defines.
> +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> +    number of measurements to take, valid values being 2 and 4.
> +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> +    milliseconds.
> +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> +    detection.
> +
> +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> +    ARIZONA_GPSW_XXX defines.

Where are all of these bindings to be consumed?

>    - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
>      they are being externally supplied. As covered in
>      Documentation/devicetree/bindings/regulator/regulator.txt
> diff --git a/include/dt-bindings/mfd/arizona.h b/include/dt-bindings/mfd/arizona.h
> index c40f665..dedf46f 100644
> --- a/include/dt-bindings/mfd/arizona.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -110,4 +110,9 @@
>  #define ARIZONA_ACCDET_MODE_HPM 4
>  #define ARIZONA_ACCDET_MODE_ADC 7
>  
> +#define ARIZONA_GPSW_OPEN           0
> +#define ARIZONA_GPSW_CLOSED         1
> +#define ARIZONA_GPSW_CLAMP_ENABLED  2
> +#define ARIZONA_GPSW_CLAMP_DISABLED 3
> +
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 09:08:00AM +0100, Lee Jones wrote:
> On Fri, 02 Oct 2015, Charles Keepax wrote:
> 
> > Add additional bindings to allow configuration of the system specific
> > microphone detection settings.
> > 
> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
> >  include/dt-bindings/mfd/arizona.h                 |    5 +++++
> >  2 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index a8fee60..b98a11b 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -73,6 +73,27 @@ Optional properties:
> >      If this node is not mentioned or if the value is unknown, then
> >      headphone detection mode is set to HPDETL.
> >  
> > +  - wlf,micd-software-compare : Use a software comparison to determine mic
> > +    presence
> > +  - wlf,micd-detect-debounce : Additional software microphone detection
> > +    debounce specified in milliseconds.
> > +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> > +    polarity if one exists.
> > +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> > +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> > +    defines.
> > +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> > +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> > +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> > +    number of measurements to take, valid values being 2 and 4.
> > +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> > +    milliseconds.
> > +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> > +    detection.
> > +
> > +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> > +    ARIZONA_GPSW_XXX defines.
> 
> Where are all of these bindings to be consumed?

In the extcon driver it handles all jack detection in the Arizona
devices.

Thanks,
Charles

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Charles Keepax]

On Tue, Oct 13, 2015 at 09:08:00AM +0100, Lee Jones wrote:
> On Fri, 02 Oct 2015, Charles Keepax wrote:
> 
> > Add additional bindings to allow configuration of the system specific
> > microphone detection settings.
> > 
> > Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
> >  include/dt-bindings/mfd/arizona.h                 |    5 +++++
> >  2 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index a8fee60..b98a11b 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -73,6 +73,27 @@ Optional properties:
> >      If this node is not mentioned or if the value is unknown, then
> >      headphone detection mode is set to HPDETL.
> >  
> > +  - wlf,micd-software-compare : Use a software comparison to determine mic
> > +    presence
> > +  - wlf,micd-detect-debounce : Additional software microphone detection
> > +    debounce specified in milliseconds.
> > +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> > +    polarity if one exists.
> > +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> > +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> > +    defines.
> > +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> > +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> > +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> > +    number of measurements to take, valid values being 2 and 4.
> > +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> > +    milliseconds.
> > +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> > +    detection.
> > +
> > +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> > +    ARIZONA_GPSW_XXX defines.
> 
> Where are all of these bindings to be consumed?

In the extcon driver it handles all jack detection in the Arizona
devices.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Charles Keepax wrote:

> On Tue, Oct 13, 2015 at 09:08:00AM +0100, Lee Jones wrote:
> > On Fri, 02 Oct 2015, Charles Keepax wrote:
> > 
> > > Add additional bindings to allow configuration of the system specific
> > > microphone detection settings.
> > > 
> > > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > > ---
> > >  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
> > >  include/dt-bindings/mfd/arizona.h                 |    5 +++++
> > >  2 files changed, 26 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > index a8fee60..b98a11b 100644
> > > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > @@ -73,6 +73,27 @@ Optional properties:
> > >      If this node is not mentioned or if the value is unknown, then
> > >      headphone detection mode is set to HPDETL.
> > >  
> > > +  - wlf,micd-software-compare : Use a software comparison to determine mic
> > > +    presence
> > > +  - wlf,micd-detect-debounce : Additional software microphone detection
> > > +    debounce specified in milliseconds.
> > > +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> > > +    polarity if one exists.
> > > +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> > > +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> > > +    defines.
> > > +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> > > +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> > > +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> > > +    number of measurements to take, valid values being 2 and 4.
> > > +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> > > +    milliseconds.
> > > +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> > > +    detection.
> > > +
> > > +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> > > +    ARIZONA_GPSW_XXX defines.
> > 
> > Where are all of these bindings to be consumed?
> 
> In the extcon driver it handles all jack detection in the Arizona
> devices.

Okay, perfect.  Please move them to the Extcon doc. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Charles Keepax wrote:

> On Tue, Oct 13, 2015 at 09:08:00AM +0100, Lee Jones wrote:
> > On Fri, 02 Oct 2015, Charles Keepax wrote:
> > 
> > > Add additional bindings to allow configuration of the system specific
> > > microphone detection settings.
> > > 
> > > Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxiMEWR6Nv5iY@public.gmane.orgm>
> > > ---
> > >  Documentation/devicetree/bindings/mfd/arizona.txt |   21 +++++++++++++++++++++
> > >  include/dt-bindings/mfd/arizona.h                 |    5 +++++
> > >  2 files changed, 26 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > index a8fee60..b98a11b 100644
> > > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > @@ -73,6 +73,27 @@ Optional properties:
> > >      If this node is not mentioned or if the value is unknown, then
> > >      headphone detection mode is set to HPDETL.
> > >  
> > > +  - wlf,micd-software-compare : Use a software comparison to determine mic
> > > +    presence
> > > +  - wlf,micd-detect-debounce : Additional software microphone detection
> > > +    debounce specified in milliseconds.
> > > +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> > > +    polarity if one exists.
> > > +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> > > +    performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX
> > > +    defines.
> > > +  - wlf,micd-rate : Delay between successive microphone detection measurements,
> > > +    specified as per the ARIZONA_MICD_TIME_XXX defines.
> > > +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as the
> > > +    number of measurements to take, valid values being 2 and 4.
> > > +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> > > +    milliseconds.
> > > +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> > > +    detection.
> > > +
> > > +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> > > +    ARIZONA_GPSW_XXX defines.
> > 
> > Where are all of these bindings to be consumed?
> 
> In the extcon driver it handles all jack detection in the Arizona
> devices.

Okay, perfect.  Please move them to the Extcon doc. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Charles Keepax]

Add additional binding for inverting the polarity of the detection on
the jack detection pins.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
index b98a11b..ef59696 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -73,6 +73,8 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,jd-invert : Invert the polarity of the jack detection switch
+
   - wlf,micd-software-compare : Use a software comparison to determine mic
     presence
   - wlf,micd-detect-debounce : Additional software microphone detection
-- 
1.7.2.5

[PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Charles Keepax]

Add additional binding for inverting the polarity of the detection on
the jack detection pins.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
 Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
index b98a11b..ef59696 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -73,6 +73,8 @@ Optional properties:
     If this node is not mentioned or if the value is unknown, then
     headphone detection mode is set to HPDETL.
 
+  - wlf,jd-invert : Invert the polarity of the jack detection switch
+
   - wlf,micd-software-compare : Use a software comparison to determine mic
     presence
   - wlf,micd-detect-debounce : Additional software microphone detection
-- 
1.7.2.5

Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Lee Jones]

On Fri, 02 Oct 2015, Charles Keepax wrote:

> Add additional binding for inverting the polarity of the detection on
> the jack detection pins.
> 
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> index b98a11b..ef59696 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,8 @@ Optional properties:
>      If this node is not mentioned or if the value is unknown, then
>      headphone detection mode is set to HPDETL.
>  
> +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> +

There are other jack detection properties in the bindings docs.

Please generify.

>    - wlf,micd-software-compare : Use a software comparison to determine mic
>      presence
>    - wlf,micd-detect-debounce : Additional software microphone detection

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Charles Keepax]

On Mon, Oct 05, 2015 at 11:01:05AM +0100, Lee Jones wrote:
> On Fri, 02 Oct 2015, Charles Keepax wrote:
> 
> > Add additional binding for inverting the polarity of the detection on
> > the jack detection pins.
> > 
> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index b98a11b..ef59696 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -73,6 +73,8 @@ Optional properties:
> >      If this node is not mentioned or if the value is unknown, then
> >      headphone detection mode is set to HPDETL.
> >  
> > +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> > +
> 
> There are other jack detection properties in the bindings docs.
> 
> Please generify.

Apologies but not sure I follow what you want me to do here? Do
you just want me to drop the wlf, prefix on this one?

Thanks,
Charles

Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Charles Keepax]

On Mon, Oct 05, 2015 at 11:01:05AM +0100, Lee Jones wrote:
> On Fri, 02 Oct 2015, Charles Keepax wrote:
> 
> > Add additional binding for inverting the polarity of the detection on
> > the jack detection pins.
> > 
> > Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index b98a11b..ef59696 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -73,6 +73,8 @@ Optional properties:
> >      If this node is not mentioned or if the value is unknown, then
> >      headphone detection mode is set to HPDETL.
> >  
> > +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> > +
> 
> There are other jack detection properties in the bindings docs.
> 
> Please generify.

Apologies but not sure I follow what you want me to do here? Do
you just want me to drop the wlf, prefix on this one?

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Lee Jones]

On Mon, 12 Oct 2015, Charles Keepax wrote:

> On Mon, Oct 05, 2015 at 11:01:05AM +0100, Lee Jones wrote:
> > On Fri, 02 Oct 2015, Charles Keepax wrote:
> > 
> > > Add additional binding for inverting the polarity of the detection on
> > > the jack detection pins.
> > > 
> > > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > > ---
> > >  Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > index b98a11b..ef59696 100644
> > > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > @@ -73,6 +73,8 @@ Optional properties:
> > >      If this node is not mentioned or if the value is unknown, then
> > >      headphone detection mode is set to HPDETL.
> > >  
> > > +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> > > +
> > 
> > There are other jack detection properties in the bindings docs.
> > 
> > Please generify.
> 
> Apologies but not sure I follow what you want me to do here? Do
> you just want me to drop the wlf, prefix on this one?

I'm trying to avoid every vendor having their own audio jack
properties, when many of them have exactly the same function.

Please take a look at each of your bindings and make an informed
decision on which you think are unique to you and which you think
others can/will make use of.

Of course, if you have a unique requirement for a property and can
justify its existence, then it should be submitted with your vendor
prefix.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog