All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
@ 2014-02-12 12:01 Paul Cercueil
  2014-02-12 12:01 ` [PATCH 2/3] iio: ad5064: Allow choosing external supply from device tree Paul Cercueil
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 12:01 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Lars-Peter Clausen, linux-iio, Paul Cercueil

Previously the driver would revert to internal supply if the
external supply couldn't be found. This had multiple problems:
- it caused silently ignored errors when a regulator was intended
  to be supplied, but was not specified correctly.
- if CONFIG_REGULATOR is disabled, regulator_get() will always
  return a dummy regulator, which caused a device to always use
  the external vref mode, even though there is none.

This patch addresses the issue by adding a platform data structure,
containing a boolean field use_external_ref. If the platform data
structure is present and if that boolean is set, the external vref
is used; otherwise the internal vref is used.

In the case where an external vref is wanted but regulator_get()
fails, the driver no longer reverts to using the internal vref,
but returns an error instead.

Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
---
 drivers/iio/dac/ad5064.c             |   26 +++++++++++++++++---------
 include/linux/platform_data/ad5064.h |   21 +++++++++++++++++++++
 2 files changed, 38 insertions(+), 9 deletions(-)
 create mode 100644 include/linux/platform_data/ad5064.h

diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
index f03b92f..fbb836a 100644
--- a/drivers/iio/dac/ad5064.c
+++ b/drivers/iio/dac/ad5064.c
@@ -2,7 +2,7 @@
  * AD5024, AD5025, AD5044, AD5045, AD5064, AD5064-1, AD5065, AD5628, AD5629R,
  * AD5648, AD5666, AD5668, AD5669R Digital to analog converters driver
  *
- * Copyright 2011 Analog Devices Inc.
+ * Copyright 2011, 2014 Analog Devices Inc.
  *
  * Licensed under the GPL-2.
  */
@@ -21,6 +21,8 @@
 #include <linux/iio/iio.h>
 #include <linux/iio/sysfs.h>
 
+#include <linux/platform_data/ad5064.h>
+
 #define AD5064_MAX_DAC_CHANNELS			8
 #define AD5064_MAX_VREFS			4
 
@@ -441,6 +443,7 @@ static const char * const ad5064_vref_name(struct ad5064_state *st,
 static int ad5064_probe(struct device *dev, enum ad5064_type type,
 			const char *name, ad5064_write_func write)
 {
+	struct ad5064_platform_data *pdata = dev->platform_data;
 	struct iio_dev *indio_dev;
 	struct ad5064_state *st;
 	unsigned int midscale;
@@ -461,11 +464,20 @@ static int ad5064_probe(struct device *dev, enum ad5064_type type,
 	for (i = 0; i < ad5064_num_vref(st); ++i)
 		st->vref_reg[i].supply = ad5064_vref_name(st, i);
 
-	ret = devm_regulator_bulk_get(dev, ad5064_num_vref(st),
-		st->vref_reg);
-	if (ret) {
-		if (!st->chip_info->internal_vref)
+	if (pdata && pdata->use_external_ref) {
+		ret = devm_regulator_bulk_get(dev, ad5064_num_vref(st),
+					st->vref_reg);
+		if (ret)
 			return ret;
+		ret = regulator_bulk_enable(ad5064_num_vref(st), st->vref_reg);
+		if (ret)
+			return ret;
+	} else {
+		if (!st->chip_info->internal_vref) {
+			dev_err(dev, "No vref available\n");
+			return -ENXIO;
+		}
+
 		st->use_internal_vref = true;
 		ret = ad5064_write(st, AD5064_CMD_CONFIG, 0,
 			AD5064_CONFIG_INT_VREF_ENABLE, 0);
@@ -474,10 +486,6 @@ static int ad5064_probe(struct device *dev, enum ad5064_type type,
 				ret);
 			return ret;
 		}
-	} else {
-		ret = regulator_bulk_enable(ad5064_num_vref(st), st->vref_reg);
-		if (ret)
-			return ret;
 	}
 
 	indio_dev->dev.parent = dev;
diff --git a/include/linux/platform_data/ad5064.h b/include/linux/platform_data/ad5064.h
new file mode 100644
index 0000000..8a87a94
--- /dev/null
+++ b/include/linux/platform_data/ad5064.h
@@ -0,0 +1,21 @@
+/*
+ * Analog Devices AD5064 DAC driver
+ *
+ * Copyright 2014 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#ifndef __IIO_ADC_AD5064_H__
+#define __IIO_ADC_AD5064_H__
+
+/**
+ * struct ad5064_platform_data - AD5064 platform data
+ * @use_external_ref: If set to true use an external voltage reference connected
+ * to the VREF pin, otherwise use the internal reference derived from Vdd.
+ */
+struct ad5064_platform_data {
+	bool use_external_ref;
+};
+
+#endif
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 2/3] iio: ad5064: Allow choosing external supply from device tree
  2014-02-12 12:01 [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Paul Cercueil
@ 2014-02-12 12:01 ` Paul Cercueil
       [not found] ` <1392206518-1457-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 12:01 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Lars-Peter Clausen, linux-iio, Paul Cercueil

Using the boolean property "adi,use-external-reference" it is
now possible to select the external supply from the device tree.

Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
---
 drivers/iio/dac/ad5064.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
index fbb836a..615790a 100644
--- a/drivers/iio/dac/ad5064.c
+++ b/drivers/iio/dac/ad5064.c
@@ -449,6 +449,7 @@ static int ad5064_probe(struct device *dev, enum ad5064_type type,
 	unsigned int midscale;
 	unsigned int i;
 	int ret;
+	bool ext_vref;
 
 	indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
 	if (indio_dev == NULL)
@@ -464,7 +465,13 @@ static int ad5064_probe(struct device *dev, enum ad5064_type type,
 	for (i = 0; i < ad5064_num_vref(st); ++i)
 		st->vref_reg[i].supply = ad5064_vref_name(st, i);
 
-	if (pdata && pdata->use_external_ref) {
+	if (dev->of_node)
+		ext_vref = of_property_read_bool(dev->of_node,
+				"adi,use-external-reference");
+	else
+		ext_vref = pdata && pdata->use_external_ref;
+
+	if (ext_vref) {
 		ret = devm_regulator_bulk_get(dev, ad5064_num_vref(st),
 					st->vref_reg);
 		if (ret)
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
  2014-02-12 12:01 [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Paul Cercueil
@ 2014-02-12 12:01     ` Paul Cercueil
       [not found] ` <1392206518-1457-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 12:01 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Lars-Peter Clausen, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	Paul Cercueil, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA

Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt

diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
new file mode 100644
index 0000000..e5997b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
@@ -0,0 +1,49 @@
+Analog Devices AD5064 DAC device driver
+
+Required properties:
+	- compatible: Must be one of:
+		* "adi,ad5024"
+		* "adi,ad5025"
+		* "adi,ad5044"
+		* "adi,ad5045"
+		* "adi,ad5064"
+		* "adi,ad5064-1"
+		* "adi,ad5065"
+		* "adi,ad5628-1"
+		* "adi,ad5628-2"
+		* "adi,ad5648-1"
+		* "adi,ad5648-2"
+		* "adi,ad5666-1"
+		* "adi,ad5666-2"
+		* "adi,ad5668-1"
+		* "adi,ad5668-2"
+		* "adi,ad5668-3"
+	- reg: SPI chip select number for the device
+	- spi-max-frequency: Max SPI frequency to use (< 30000000)
+	- vrefA-supply, vrefB-supply: phandles to external reference voltage
+	  supplies for channels 0 and 1 respectively.
+	  This property must be present for ad5024, ad5025, ad5044, ad5045,
+	  ad5064, ad5065.
+	- vrefC-supply, vrefD-supply: phandles to external reference voltage
+	  supplies for channels 2 and 3 respectively.
+	  This property must be present for ad5024, ad5044, ad5064.
+
+Optional properties:
+	- adi,use-external-reference: If set, the external reference voltage
+	  supply is used. This should only be set if there is an external
+	  reference voltage connected to the vref or vref[A-D] pins.
+	  If the property is not set, the internal reference voltage supply
+	  is used if present, or an error is issued by the driver.
+	- vref-supply: phandle to the external reference voltage supply.
+	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
+	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
+
+Example:
+
+		ad5668-2@4 {
+			compatible = "adi,ad5668-2";
+			reg = <4>;
+			spi-max-frequency = <10000000>;
+			adi,use-external-reference;
+			vref-supply = <&vref_supply>;
+		};
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
@ 2014-02-12 12:01     ` Paul Cercueil
  0 siblings, 0 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 12:01 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Lars-Peter Clausen, linux-iio, Paul Cercueil, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree

Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: devicetree@vger.kernel.org
---
 .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt

diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
new file mode 100644
index 0000000..e5997b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
@@ -0,0 +1,49 @@
+Analog Devices AD5064 DAC device driver
+
+Required properties:
+	- compatible: Must be one of:
+		* "adi,ad5024"
+		* "adi,ad5025"
+		* "adi,ad5044"
+		* "adi,ad5045"
+		* "adi,ad5064"
+		* "adi,ad5064-1"
+		* "adi,ad5065"
+		* "adi,ad5628-1"
+		* "adi,ad5628-2"
+		* "adi,ad5648-1"
+		* "adi,ad5648-2"
+		* "adi,ad5666-1"
+		* "adi,ad5666-2"
+		* "adi,ad5668-1"
+		* "adi,ad5668-2"
+		* "adi,ad5668-3"
+	- reg: SPI chip select number for the device
+	- spi-max-frequency: Max SPI frequency to use (< 30000000)
+	- vrefA-supply, vrefB-supply: phandles to external reference voltage
+	  supplies for channels 0 and 1 respectively.
+	  This property must be present for ad5024, ad5025, ad5044, ad5045,
+	  ad5064, ad5065.
+	- vrefC-supply, vrefD-supply: phandles to external reference voltage
+	  supplies for channels 2 and 3 respectively.
+	  This property must be present for ad5024, ad5044, ad5064.
+
+Optional properties:
+	- adi,use-external-reference: If set, the external reference voltage
+	  supply is used. This should only be set if there is an external
+	  reference voltage connected to the vref or vref[A-D] pins.
+	  If the property is not set, the internal reference voltage supply
+	  is used if present, or an error is issued by the driver.
+	- vref-supply: phandle to the external reference voltage supply.
+	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
+	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
+
+Example:
+
+		ad5668-2@4 {
+			compatible = "adi,ad5668-2";
+			reg = <4>;
+			spi-max-frequency = <10000000>;
+			adi,use-external-reference;
+			vref-supply = <&vref_supply>;
+		};
-- 
1.7.10.4



^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
  2014-02-12 12:01     ` Paul Cercueil
@ 2014-02-12 12:18         ` Mark Rutland
  -1 siblings, 0 replies; 13+ messages in thread
From: Mark Rutland @ 2014-02-12 12:18 UTC (permalink / raw)
  To: Paul Cercueil
  Cc: Jonathan Cameron, Lars-Peter Clausen,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Pawel Moll, Ian Campbell,
	Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA

On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> new file mode 100644
> index 0000000..e5997b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> @@ -0,0 +1,49 @@
> +Analog Devices AD5064 DAC device driver

It would be nice to have a short description here, with useful facts
(e.g. this is an SPI device).

Is there any public documentation? It might not need to go in the
document, but having a link really helps with review.

> +
> +Required properties:
> +	- compatible: Must be one of:
> +		* "adi,ad5024"
> +		* "adi,ad5025"
> +		* "adi,ad5044"
> +		* "adi,ad5045"
> +		* "adi,ad5064"
> +		* "adi,ad5064-1"
> +		* "adi,ad5065"
> +		* "adi,ad5628-1"
> +		* "adi,ad5628-2"
> +		* "adi,ad5648-1"
> +		* "adi,ad5648-2"
> +		* "adi,ad5666-1"
> +		* "adi,ad5666-2"
> +		* "adi,ad5668-1"
> +		* "adi,ad5668-2"
> +		* "adi,ad5668-3"

How do these differ? Are these just different revisions of the same
chip?

Are particular strings expected to be used as fallbacks in the
compatible list?

> +	- reg: SPI chip select number for the device
> +	- spi-max-frequency: Max SPI frequency to use (< 30000000)
> +	- vrefA-supply, vrefB-supply: phandles to external reference voltage
> +	  supplies for channels 0 and 1 respectively.
> +	  This property must be present for ad5024, ad5025, ad5044, ad5045,
> +	  ad5064, ad5065.

Does ad5064 also imply ad5604-1 here?

> +	- vrefC-supply, vrefD-supply: phandles to external reference voltage
> +	  supplies for channels 2 and 3 respectively.
> +	  This property must be present for ad5024, ad5044, ad5064.

Likewise.

These seem oddly named given the description. Are these named A B C D in
the documentation? If not, vref-channel-X-supply would seem to be
clearer.

Why are these grouped in pairs rather than listed individually?

> +
> +Optional properties:
> +	- adi,use-external-reference: If set, the external reference voltage
> +	  supply is used. This should only be set if there is an external
> +	  reference voltage connected to the vref or vref[A-D] pins.
> +	  If the property is not set, the internal reference voltage supply
> +	  is used if present, or an error is issued by the driver.

When would you want to do this, and when would you want to use the
internal reference? Could the driver not choose to do this based on
whether a supply is listed in the dt?

Strip the part about the error, that's not a description of the device
and not a matter for the binding.

> +	- vref-supply: phandle to the external reference voltage supply.
> +	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
> +	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.

Just to check, on some versions (e.g. ad5668-3), this can work without
any supply listed at all, yes?

Cheers,
Mark.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
@ 2014-02-12 12:18         ` Mark Rutland
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Rutland @ 2014-02-12 12:18 UTC (permalink / raw)
  To: Paul Cercueil
  Cc: Jonathan Cameron, Lars-Peter Clausen, linux-iio, rob.herring,
	Pawel Moll, Ian Campbell, Kumar Gala, devicetree

On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: devicetree@vger.kernel.org
> ---
>  .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> new file mode 100644
> index 0000000..e5997b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> @@ -0,0 +1,49 @@
> +Analog Devices AD5064 DAC device driver

It would be nice to have a short description here, with useful facts
(e.g. this is an SPI device).

Is there any public documentation? It might not need to go in the
document, but having a link really helps with review.

> +
> +Required properties:
> +	- compatible: Must be one of:
> +		* "adi,ad5024"
> +		* "adi,ad5025"
> +		* "adi,ad5044"
> +		* "adi,ad5045"
> +		* "adi,ad5064"
> +		* "adi,ad5064-1"
> +		* "adi,ad5065"
> +		* "adi,ad5628-1"
> +		* "adi,ad5628-2"
> +		* "adi,ad5648-1"
> +		* "adi,ad5648-2"
> +		* "adi,ad5666-1"
> +		* "adi,ad5666-2"
> +		* "adi,ad5668-1"
> +		* "adi,ad5668-2"
> +		* "adi,ad5668-3"

How do these differ? Are these just different revisions of the same
chip?

Are particular strings expected to be used as fallbacks in the
compatible list?

> +	- reg: SPI chip select number for the device
> +	- spi-max-frequency: Max SPI frequency to use (< 30000000)
> +	- vrefA-supply, vrefB-supply: phandles to external reference voltage
> +	  supplies for channels 0 and 1 respectively.
> +	  This property must be present for ad5024, ad5025, ad5044, ad5045,
> +	  ad5064, ad5065.

Does ad5064 also imply ad5604-1 here?

> +	- vrefC-supply, vrefD-supply: phandles to external reference voltage
> +	  supplies for channels 2 and 3 respectively.
> +	  This property must be present for ad5024, ad5044, ad5064.

Likewise.

These seem oddly named given the description. Are these named A B C D in
the documentation? If not, vref-channel-X-supply would seem to be
clearer.

Why are these grouped in pairs rather than listed individually?

> +
> +Optional properties:
> +	- adi,use-external-reference: If set, the external reference voltage
> +	  supply is used. This should only be set if there is an external
> +	  reference voltage connected to the vref or vref[A-D] pins.
> +	  If the property is not set, the internal reference voltage supply
> +	  is used if present, or an error is issued by the driver.

When would you want to do this, and when would you want to use the
internal reference? Could the driver not choose to do this based on
whether a supply is listed in the dt?

Strip the part about the error, that's not a description of the device
and not a matter for the binding.

> +	- vref-supply: phandle to the external reference voltage supply.
> +	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
> +	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.

Just to check, on some versions (e.g. ad5668-3), this can work without
any supply listed at all, yes?

Cheers,
Mark.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
  2014-02-12 12:01 [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Paul Cercueil
  2014-02-12 12:01 ` [PATCH 2/3] iio: ad5064: Allow choosing external supply from device tree Paul Cercueil
       [not found] ` <1392206518-1457-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
@ 2014-02-12 12:19 ` Lars-Peter Clausen
  2014-02-12 12:35   ` Lars-Peter Clausen
  2014-07-22 23:06 ` Gregory Fong
  3 siblings, 1 reply; 13+ messages in thread
From: Lars-Peter Clausen @ 2014-02-12 12:19 UTC (permalink / raw)
  To: Paul Cercueil; +Cc: Jonathan Cameron, linux-iio

On 02/12/2014 01:01 PM, Paul Cercueil wrote:
> Previously the driver would revert to internal supply if the
> external supply couldn't be found. This had multiple problems:
> - it caused silently ignored errors when a regulator was intended
>    to be supplied, but was not specified correctly.
> - if CONFIG_REGULATOR is disabled, regulator_get() will always
>    return a dummy regulator, which caused a device to always use
>    the external vref mode, even though there is none.
>
> This patch addresses the issue by adding a platform data structure,
> containing a boolean field use_external_ref. If the platform data
> structure is present and if that boolean is set, the external vref
> is used; otherwise the internal vref is used.
>
> In the case where an external vref is wanted but regulator_get()
> fails, the driver no longer reverts to using the internal vref,
> but returns an error instead.
>
> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>

All three patches:

Acked-by: Lars-Peter Clausen <lars@metafoo.de>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
  2014-02-12 12:19 ` [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Lars-Peter Clausen
@ 2014-02-12 12:35   ` Lars-Peter Clausen
  2014-02-18  8:57     ` Jonathan Cameron
  0 siblings, 1 reply; 13+ messages in thread
From: Lars-Peter Clausen @ 2014-02-12 12:35 UTC (permalink / raw)
  To: Paul Cercueil; +Cc: Jonathan Cameron, linux-iio

On 02/12/2014 01:19 PM, Lars-Peter Clausen wrote:
> On 02/12/2014 01:01 PM, Paul Cercueil wrote:
>> Previously the driver would revert to internal supply if the
>> external supply couldn't be found. This had multiple problems:
>> - it caused silently ignored errors when a regulator was intended
>>    to be supplied, but was not specified correctly.
>> - if CONFIG_REGULATOR is disabled, regulator_get() will always
>>    return a dummy regulator, which caused a device to always use
>>    the external vref mode, even though there is none.
>>
>> This patch addresses the issue by adding a platform data structure,
>> containing a boolean field use_external_ref. If the platform data
>> structure is present and if that boolean is set, the external vref
>> is used; otherwise the internal vref is used.
>>
>> In the case where an external vref is wanted but regulator_get()
>> fails, the driver no longer reverts to using the internal vref,
>> but returns an error instead.
>>
>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
>
> All three patches:
>
> Acked-by: Lars-Peter Clausen <lars@metafoo.de>

Uhm, actually no. I think for devices without an internal reference we 
should default to using the external reference if no platform data is 
specified. Everything else doesn't make too much sense.

- Lars

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
  2014-02-12 12:18         ` Mark Rutland
@ 2014-02-12 14:07             ` Paul Cercueil
  -1 siblings, 0 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 14:07 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Jonathan Cameron, Lars-Peter Clausen,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Pawel Moll, Ian Campbell,
	Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA

On 02/12/14 13:18, Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
>> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>>   .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
>>   1 file changed, 49 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> new file mode 100644
>> index 0000000..e5997b0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> @@ -0,0 +1,49 @@
>> +Analog Devices AD5064 DAC device driver
>
> It would be nice to have a short description here, with useful facts
> (e.g. this is an SPI device).
>
> Is there any public documentation? It might not need to go in the
> document, but having a link really helps with review.

Allright, I will add a short description. I didn't add a link to the 
documentation as it moves every once in a while...

>> +
>> +Required properties:
>> +	- compatible: Must be one of:
>> +		* "adi,ad5024"
>> +		* "adi,ad5025"
>> +		* "adi,ad5044"
>> +		* "adi,ad5045"
>> +		* "adi,ad5064"
>> +		* "adi,ad5064-1"
>> +		* "adi,ad5065"
>> +		* "adi,ad5628-1"
>> +		* "adi,ad5628-2"
>> +		* "adi,ad5648-1"
>> +		* "adi,ad5648-2"
>> +		* "adi,ad5666-1"
>> +		* "adi,ad5666-2"
>> +		* "adi,ad5668-1"
>> +		* "adi,ad5668-2"
>> +		* "adi,ad5668-3"
>
> How do these differ? Are these just different revisions of the same
> chip?
>
> Are particular strings expected to be used as fallbacks in the
> compatible list?

All of those chips are different, but are handled by the ad5064 driver. 
They differ in the number of channels available, in the presence of an 
internal vref and/or its voltage. Some of those use a shared vref, some 
others have a vref per channel. The only similar chips are the ad5668-2 
and ad5668-3.

>> +	- reg: SPI chip select number for the device
>> +	- spi-max-frequency: Max SPI frequency to use (< 30000000)
>> +	- vrefA-supply, vrefB-supply: phandles to external reference voltage
>> +	  supplies for channels 0 and 1 respectively.
>> +	  This property must be present for ad5024, ad5025, ad5044, ad5045,
>> +	  ad5064, ad5065.
>
> Does ad5064 also imply ad5604-1 here?
>
>> +	- vrefC-supply, vrefD-supply: phandles to external reference voltage
>> +	  supplies for channels 2 and 3 respectively.
>> +	  This property must be present for ad5024, ad5044, ad5064.
>
> Likewise.

The ad5064 and ad5064-1 chips are actually different; the first one has 
one vref per channel, the second one use a shared vref.

> These seem oddly named given the description. Are these named A B C D in
> the documentation? If not, vref-channel-X-supply would seem to be
> clearer.

They are named after the pin names on the datasheets: vrefA, vrefB, 
vrefC, vrefD.

> Why are these grouped in pairs rather than listed individually?

All the chips featuring separate vref per channel, have either 2 or 4 
channels, which means that some chips have only the vrefA/vrefB pins, 
while others have them all. These properties were grouped in pairs 
because the description and the list of supported chips are the same, 
but I can list them individually if it's preferred.

>> +
>> +Optional properties:
>> +	- adi,use-external-reference: If set, the external reference voltage
>> +	  supply is used. This should only be set if there is an external
>> +	  reference voltage connected to the vref or vref[A-D] pins.
>> +	  If the property is not set, the internal reference voltage supply
>> +	  is used if present, or an error is issued by the driver.
>
> When would you want to do this, and when would you want to use the
> internal reference? Could the driver not choose to do this based on
> whether a supply is listed in the dt?

Using or not the internal reference is up to the platform. But you make 
a valid point, it would be better for the driver to use the external 
reference if specified in the dt and revert to the internal one 
otherwise. I will fix that in the driver.

> Strip the part about the error, that's not a description of the device
> and not a matter for the binding.

Allright.

>> +	- vref-supply: phandle to the external reference voltage supply.
>> +	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
>> +	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
>
> Just to check, on some versions (e.g. ad5668-3), this can work without
> any supply listed at all, yes?

All of those chips except for ad5064-1 have an internal vref, which will 
be used if no external regulator is specified, so yes.

> Cheers,
> Mark.
>

Thanks for your comments!

Regards,
Paul

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
@ 2014-02-12 14:07             ` Paul Cercueil
  0 siblings, 0 replies; 13+ messages in thread
From: Paul Cercueil @ 2014-02-12 14:07 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Jonathan Cameron, Lars-Peter Clausen, linux-iio, rob.herring,
	Pawel Moll, Ian Campbell, Kumar Gala, devicetree

On 02/12/14 13:18, Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: devicetree@vger.kernel.org
>> ---
>>   .../devicetree/bindings/iio/dac/ad5064.txt         |   49 ++++++++++++++++++++
>>   1 file changed, 49 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> new file mode 100644
>> index 0000000..e5997b0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
>> @@ -0,0 +1,49 @@
>> +Analog Devices AD5064 DAC device driver
>
> It would be nice to have a short description here, with useful facts
> (e.g. this is an SPI device).
>
> Is there any public documentation? It might not need to go in the
> document, but having a link really helps with review.

Allright, I will add a short description. I didn't add a link to the 
documentation as it moves every once in a while...

>> +
>> +Required properties:
>> +	- compatible: Must be one of:
>> +		* "adi,ad5024"
>> +		* "adi,ad5025"
>> +		* "adi,ad5044"
>> +		* "adi,ad5045"
>> +		* "adi,ad5064"
>> +		* "adi,ad5064-1"
>> +		* "adi,ad5065"
>> +		* "adi,ad5628-1"
>> +		* "adi,ad5628-2"
>> +		* "adi,ad5648-1"
>> +		* "adi,ad5648-2"
>> +		* "adi,ad5666-1"
>> +		* "adi,ad5666-2"
>> +		* "adi,ad5668-1"
>> +		* "adi,ad5668-2"
>> +		* "adi,ad5668-3"
>
> How do these differ? Are these just different revisions of the same
> chip?
>
> Are particular strings expected to be used as fallbacks in the
> compatible list?

All of those chips are different, but are handled by the ad5064 driver. 
They differ in the number of channels available, in the presence of an 
internal vref and/or its voltage. Some of those use a shared vref, some 
others have a vref per channel. The only similar chips are the ad5668-2 
and ad5668-3.

>> +	- reg: SPI chip select number for the device
>> +	- spi-max-frequency: Max SPI frequency to use (< 30000000)
>> +	- vrefA-supply, vrefB-supply: phandles to external reference voltage
>> +	  supplies for channels 0 and 1 respectively.
>> +	  This property must be present for ad5024, ad5025, ad5044, ad5045,
>> +	  ad5064, ad5065.
>
> Does ad5064 also imply ad5604-1 here?
>
>> +	- vrefC-supply, vrefD-supply: phandles to external reference voltage
>> +	  supplies for channels 2 and 3 respectively.
>> +	  This property must be present for ad5024, ad5044, ad5064.
>
> Likewise.

The ad5064 and ad5064-1 chips are actually different; the first one has 
one vref per channel, the second one use a shared vref.

> These seem oddly named given the description. Are these named A B C D in
> the documentation? If not, vref-channel-X-supply would seem to be
> clearer.

They are named after the pin names on the datasheets: vrefA, vrefB, 
vrefC, vrefD.

> Why are these grouped in pairs rather than listed individually?

All the chips featuring separate vref per channel, have either 2 or 4 
channels, which means that some chips have only the vrefA/vrefB pins, 
while others have them all. These properties were grouped in pairs 
because the description and the list of supported chips are the same, 
but I can list them individually if it's preferred.

>> +
>> +Optional properties:
>> +	- adi,use-external-reference: If set, the external reference voltage
>> +	  supply is used. This should only be set if there is an external
>> +	  reference voltage connected to the vref or vref[A-D] pins.
>> +	  If the property is not set, the internal reference voltage supply
>> +	  is used if present, or an error is issued by the driver.
>
> When would you want to do this, and when would you want to use the
> internal reference? Could the driver not choose to do this based on
> whether a supply is listed in the dt?

Using or not the internal reference is up to the platform. But you make 
a valid point, it would be better for the driver to use the external 
reference if specified in the dt and revert to the internal one 
otherwise. I will fix that in the driver.

> Strip the part about the error, that's not a description of the device
> and not a matter for the binding.

Allright.

>> +	- vref-supply: phandle to the external reference voltage supply.
>> +	  This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
>> +	  ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
>
> Just to check, on some versions (e.g. ad5668-3), this can work without
> any supply listed at all, yes?

All of those chips except for ad5064-1 have an internal vref, which will 
be used if no external regulator is specified, so yes.

> Cheers,
> Mark.
>

Thanks for your comments!

Regards,
Paul


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
  2014-02-12 12:35   ` Lars-Peter Clausen
@ 2014-02-18  8:57     ` Jonathan Cameron
  0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2014-02-18  8:57 UTC (permalink / raw)
  To: Lars-Peter Clausen, Paul Cercueil; +Cc: linux-iio

On 12/02/14 12:35, Lars-Peter Clausen wrote:
> On 02/12/2014 01:19 PM, Lars-Peter Clausen wrote:
>> On 02/12/2014 01:01 PM, Paul Cercueil wrote:
>>> Previously the driver would revert to internal supply if the
>>> external supply couldn't be found. This had multiple problems:
>>> - it caused silently ignored errors when a regulator was intended
>>>    to be supplied, but was not specified correctly.
>>> - if CONFIG_REGULATOR is disabled, regulator_get() will always
>>>    return a dummy regulator, which caused a device to always use
>>>    the external vref mode, even though there is none.
>>>
>>> This patch addresses the issue by adding a platform data structure,
>>> containing a boolean field use_external_ref. If the platform data
>>> structure is present and if that boolean is set, the external vref
>>> is used; otherwise the internal vref is used.
>>>
>>> In the case where an external vref is wanted but regulator_get()
>>> fails, the driver no longer reverts to using the internal vref,
>>> but returns an error instead.
>>>
>>> Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
>>
>> All three patches:
>>
>> Acked-by: Lars-Peter Clausen <lars@metafoo.de>
>
> Uhm, actually no. I think for devices without an internal reference we should default to using the external reference if no platform data is specified. Everything else doesn't make too much sense.

Agreed. If present, we default to the internal reference ifan external
one is not provided.  The logic in the driver can check if one is specified,
whether or not config_regulator is enabled.

Jonathan




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
  2014-02-12 12:01 [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Paul Cercueil
                   ` (2 preceding siblings ...)
  2014-02-12 12:19 ` [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Lars-Peter Clausen
@ 2014-07-22 23:06 ` Gregory Fong
  2014-07-23 19:23   ` Lars-Peter Clausen
  3 siblings, 1 reply; 13+ messages in thread
From: Gregory Fong @ 2014-07-22 23:06 UTC (permalink / raw)
  To: linux-iio

Hi Paul,

Paul Cercueil <paul.cercueil@...> writes:
> 
> [snip]
> - if CONFIG_REGULATOR is disabled, regulator_get() will always
>   return a dummy regulator, which caused a device to always use
>   the external vref mode, even though there is none.

I noticed that this is still a problem in the current driver in the iio
staging tree, are you planning to resubmit the fix for this part?

Best regards,
Gregory




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply
  2014-07-22 23:06 ` Gregory Fong
@ 2014-07-23 19:23   ` Lars-Peter Clausen
  0 siblings, 0 replies; 13+ messages in thread
From: Lars-Peter Clausen @ 2014-07-23 19:23 UTC (permalink / raw)
  To: Gregory Fong; +Cc: linux-iio

On 07/23/2014 01:06 AM, Gregory Fong wrote:
> Hi Paul,
>
> Paul Cercueil <paul.cercueil@...> writes:
>>
>> [snip]
>> - if CONFIG_REGULATOR is disabled, regulator_get() will always
>>    return a dummy regulator, which caused a device to always use
>>    the external vref mode, even though there is none.
>
> I noticed that this is still a problem in the current driver in the iio
> staging tree, are you planning to resubmit the fix for this part?

Yes. Although Paul is away for a few weeks, so this may take a while.

- Lars


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2014-07-23 19:24 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-12 12:01 [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Paul Cercueil
2014-02-12 12:01 ` [PATCH 2/3] iio: ad5064: Allow choosing external supply from device tree Paul Cercueil
     [not found] ` <1392206518-1457-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
2014-02-12 12:01   ` [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation Paul Cercueil
2014-02-12 12:01     ` Paul Cercueil
     [not found]     ` <1392206518-1457-3-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
2014-02-12 12:18       ` Mark Rutland
2014-02-12 12:18         ` Mark Rutland
     [not found]         ` <20140212121832.GF21992-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-02-12 14:07           ` Paul Cercueil
2014-02-12 14:07             ` Paul Cercueil
2014-02-12 12:19 ` [PATCH 1/3] iio: ad5064: Explicitly configure whether to use external supply Lars-Peter Clausen
2014-02-12 12:35   ` Lars-Peter Clausen
2014-02-18  8:57     ` Jonathan Cameron
2014-07-22 23:06 ` Gregory Fong
2014-07-23 19:23   ` Lars-Peter Clausen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.