linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Rob Herring <robh@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Mathias Duckeck <m.duckeck@kunbus.de>,
	Phil Elwell <phil@raspberrypi.org>,
	Oskar Andero <oskar.andero@gmail.com>,
	Andrea Galbusera <gizero@gmail.com>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Manfred Schlaegl <manfred.schlaegl@gmx.at>,
	Michael Welling <mwelling@ieee.org>,
	Soeren Andersen <san@rosetechnology.dk>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	Mark Rutland <mark.rutland@arm.com>,
	Abhisit Sangjan <s.abhisit@gmail.com>,
	Adriana Reus <adi.reus@gmail.com>
Subject: Re: [PATCH 5/6] dt-bindings: iio: adc: mcp320x: Update for mcp3550/1/3
Date: Sun, 27 Aug 2017 17:34:05 +0200	[thread overview]
Message-ID: <20170827153405.GA13399@wunner.de> (raw)
In-Reply-To: <20170825195941.iylf4w5hitjwniio@rob-hp-laptop>

On Fri, Aug 25, 2017 at 02:59:41PM -0500, Rob Herring wrote:
> On Tue, Aug 22, 2017 at 03:33:00PM +0200, Lukas Wunner wrote:
> > --- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
> > +Optional properties:
> > +	- microchip,continuous-conversion (boolean):
> > +			Only applicable to MCP3550/1/3:  These ADCs have long
> > +			conversion times and therefore support "continuous
> > +			conversion mode" to allow retrieval of conversions
> > +			at any time without observing a delay.  The mode is
> > +			enabled by permanently driving CS low, e.g. by wiring
> > +			it to ground.
> 
> Second binding I have seen today with a continuous property. Make this 
> common (or maybe we already have one).

The other one was the TI LMP92001 ADC driver posted by Abhisit Sangjan
(cc), however looking at the datasheet of that chip reveals that
continuous versus one-shot mode is selected by flipping a bit in the
chip's register map.

So it is configurable at run-time.  It's not something that's hardwired.
(Which is the case with the MCP3550 in my patch.)

My understanding was that run-time configurable options should not be
listed in the device-tree at all, only hardware features.  If that is
correct then that device-tree property should be dropped from Abhisit
Sangjan's patch.  Configuring the feature via sysfs is fine I guess.

However we do have another driver supporting continuous versus one-shot
mode and that is drivers/iio/light/us5182d.c by Adriana Reus (cc).
The feature was added with commit c3304c212326.  I'm not sure if it's
hardwired or runtime-configurable, the datasheet is gone from the
manufacturer's website.

I agree that a common "continuous" property makes sense.  We haven't
defined any common IIO properties so far and that has already led to
inconsistencies.  E.g. most ADC/DAC drivers name the reference regulator
"vref-supply", but e.g. drivers/iio/dac/ad7303.c calls it "REF-supply".

What do you think of this:

-- >8 --
Subject: [PATCH] dt-bindings: iio: Document common properties

It's about time we standardize on common names for frequently used IIO
properties.  For starters, document "vref-supply" and "continuous".

Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 Documentation/devicetree/bindings/iio/iio-bindings.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
index 68d6f8c..c3e87e15 100644
--- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -95,3 +95,18 @@ vdd channel is connected to output 0 of the &ref device.
 		io-channels = <&adc 10>, <&adc 11>;
 		io-channel-names = "adc1", "adc2";
 	};
+
+==Common IIO properties==
+
+Reference voltage:
+ADCs, DACs and several other IIO devices require a reference voltage.
+By convention the property specifying this regulator is named "vref-supply".
+If the chip lacks a dedicated Vref pin and instead uses its own power supply
+as reference, the property specifying the regulator is commonly named
+"vdd-supply" or "vcc-supply".
+
+Continuous mode:
+Some sensors can be configured to perform continuous (versus one-shot)
+measurements.  Continuous mode may require more energy in return for faster
+or more reliable measurements.  A boolean property named "continuous"
+signifies that the device is configured for this mode.
-- 
2.11.0

  reply	other threads:[~2017-08-27 15:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 13:33 [PATCH 0/6] IIO driver for MCP3550/1/3 Lukas Wunner
2017-08-22 13:33 ` [PATCH 6/6] iio: adc: mcp320x: Add support for mcp3550/1/3 Lukas Wunner
2017-09-03 14:22   ` Jonathan Cameron
2017-09-07  6:44     ` Lukas Wunner
2017-09-10 13:40       ` Jonathan Cameron
2017-08-22 13:33 ` [PATCH 5/6] dt-bindings: iio: adc: mcp320x: Update " Lukas Wunner
2017-08-25 19:59   ` Rob Herring
2017-08-27 15:34     ` Lukas Wunner [this message]
2017-08-29  7:21       ` Adriana Reus
2017-09-03 13:37         ` Jonathan Cameron
2017-09-03 18:20           ` Lukas Wunner
2017-09-04 12:36             ` Jonathan Cameron
2017-09-04 17:22           ` Mark Brown
2017-09-10 13:36             ` Jonathan Cameron
2017-09-05 18:49       ` Rob Herring
2017-08-22 13:33 ` [PATCH 1/6] iio: adc: mcp320x: Fix oops on module unload Lukas Wunner
2017-09-03 13:41   ` Jonathan Cameron
2017-08-22 13:33 ` [PATCH 2/6] iio: adc: mcp320x: Fix readout of negative voltages Lukas Wunner
2017-09-03 13:44   ` Jonathan Cameron
2017-08-22 13:33 ` [PATCH 4/6] iio: adc: mcp320x: Drop unnecessary of_device_id attributes Lukas Wunner
2017-09-03 13:59   ` Jonathan Cameron
2017-08-22 13:33 ` [PATCH 3/6] iio: adc: mcp320x: Speed up readout of single-channel ADCs Lukas Wunner
2017-09-03 13:48   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170827153405.GA13399@wunner.de \
    --to=lukas@wunner.de \
    --cc=adi.reus@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gizero@gmail.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=m.duckeck@kunbus.de \
    --cc=manfred.schlaegl@gmx.at \
    --cc=mark.rutland@arm.com \
    --cc=mwelling@ieee.org \
    --cc=oskar.andero@gmail.com \
    --cc=phil@raspberrypi.org \
    --cc=pmeerw@pmeerw.net \
    --cc=robh@kernel.org \
    --cc=s.abhisit@gmail.com \
    --cc=san@rosetechnology.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).