On Sun, Aug 27, 2017 at 10:34 AM, Lukas Wunner <lukas@xxxxxxxxx> wrote: > 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.) 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. > 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@xxxxxxxxxx> > Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx> > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
