Re: [PATCH 5/6] dt-bindings: iio: adc: mcp320x: Update for mcp3550/1/3
From: Rob Herring <hidden>
Date: 2017-09-05 18:49:06
Also in:
linux-iio
On Sun, Aug 27, 2017 at 10:34 AM, Lukas Wunner [off-list ref] wrote:
On Fri, Aug 25, 2017 at 02:59:41PM -0500, Rob Herring wrote:quoted
On Tue, Aug 22, 2017 at 03:33:00PM +0200, Lukas Wunner wrote:quoted
--- 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.)
Couldn't you have CS tied to a GPIO line and then it is a run-time decision?
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.
It depends. The question who decides the mode. If an end-user would want to, then yes sysfs is the right place. If the h/w setup dictates what the configuration should be, then in DT is fine.
quoted hunk
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 <redacted> Signed-off-by: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> --- 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.
Seems file, but start with the property names rather than buried in the paragraph.