diff mbox series

[v2,1/2] dt-bindings: iio: adc: add ad7944 ADCs

Message ID 20240216-ad7944-mainline-v2-1-7eb69651e592@baylibre.com (mailing list archive)
State Changes Requested
Headers show
Series iio: adc: ad7944: new driver | expand

Commit Message

David Lechner Feb. 16, 2024, 7:46 p.m. UTC
This adds a new binding for the Analog Devices, Inc. AD7944, AD7985, and
AD7986 ADCs.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
 .../devicetree/bindings/iio/adc/adi,ad7944.yaml    | 204 +++++++++++++++++++++
 MAINTAINERS                                        |   8 +
 2 files changed, 212 insertions(+)

Comments

Conor Dooley Feb. 20, 2024, 7:47 p.m. UTC | #1
On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:
> This adds a new binding for the Analog Devices, Inc. AD7944, AD7985, and
> AD7986 ADCs.

I think this binding is overall pretty well written, especially
considering the interproperty dependencies.

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Cheers,
Conor.
Rob Herring (Arm) Feb. 21, 2024, 3:22 p.m. UTC | #2
On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:
> This adds a new binding for the Analog Devices, Inc. AD7944, AD7985, and
> AD7986 ADCs.
> 
> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
>  .../devicetree/bindings/iio/adc/adi,ad7944.yaml    | 204 +++++++++++++++++++++
>  MAINTAINERS                                        |   8 +
>  2 files changed, 212 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
> new file mode 100644
> index 000000000000..61ee81326660
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
> @@ -0,0 +1,204 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad7944.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices PulSAR LFCSP Analog to Digital Converters
> +
> +maintainers:
> +  - Michael Hennerich <Michael.Hennerich@analog.com>
> +  - Nuno Sá <nuno.sa@analog.com>
> +
> +description: |
> +  A family of pin-compatible single channel differential analog to digital
> +  converters with SPI support in a LFCSP package.
> +
> +  * https://www.analog.com/en/products/ad7944.html
> +  * https://www.analog.com/en/products/ad7985.html
> +  * https://www.analog.com/en/products/ad7986.html
> +
> +$ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - adi,ad7944
> +      - adi,ad7985
> +      - adi,ad7986
> +
> +  reg:
> +    maxItems: 1
> +
> +  spi-max-frequency:
> +    maximum: 111111111
> +
> +  spi-cpol: true
> +  spi-cpha: true
> +
> +  adi,spi-mode:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    enum: [ single, multi, chain ]
> +    default: multi
> +    description: |
> +      * single: The datasheet calls this "3-wire mode". It is often used when
> +        the ADC is the only device on the bus. In this mode, SDI is tied to VIO,
> +        and the CNV line can be connected to the CS line of the SPI controller
> +        or to a GPIO, in which case the CS line of the controller is unused.

We have a standard property for this.

> +      * multi: The datasheet calls this "4-wire mode". This is the convential
> +        SPI mode used when there are multiple devices on the same bus. In this
> +        mode, the CNV line is used to initiate the conversion and the SDI line
> +        is connected to CS on the SPI controller.

That's "normal" mode.

> +      * chain: The datasheet calls this "chain mode". This mode is used to save
> +        on wiring when multiple ADCs are used. In this mode, the SDI line of
> +        one chip is tied to the SDO of the next chip in the chain and the SDI of
> +        the last chip in the chain is tied to GND. Only the first chip in the
> +        chain is connected to the SPI bus. The CNV line of all chips are tied
> +        together. The CS line of the SPI controller is unused.

Don't you need to know how many chips are chained? In any case, you just 
need a property for chain mode. There's some existing properties for 
chained devices I think. Standard logic shift register based GPIO IIRC.

CNV are tied together, but must be driven by something? I suppose 
cnv-gpios? But wouldn't that be the same as the SPI controller GPIO CS? 
Does a SPI controller CS line connected to CNV not work in this case?

Rob
David Lechner Feb. 21, 2024, 3:44 p.m. UTC | #3
On Wed, Feb 21, 2024 at 9:22 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:

...

> > +  adi,spi-mode:
> > +    $ref: /schemas/types.yaml#/definitions/string
> > +    enum: [ single, multi, chain ]
> > +    default: multi
> > +    description: |
> > +      * single: The datasheet calls this "3-wire mode". It is often used when
> > +        the ADC is the only device on the bus. In this mode, SDI is tied to VIO,
> > +        and the CNV line can be connected to the CS line of the SPI controller
> > +        or to a GPIO, in which case the CS line of the controller is unused.
>
> We have a standard property for this.

As discussed in v1 [1], the datasheet's definition of "3-wire mode" is
_not_ the same as the standard spi-3wire property. I can add that to
the description here to clarify (I hoped changing the enum name was
enough, but perhaps not). Or is there a different property you are
referring to?

[1]: https://lore.kernel.org/all/20240216140826.58b3318d@jic23-huawei/

>
> > +      * multi: The datasheet calls this "4-wire mode". This is the convential
> > +        SPI mode used when there are multiple devices on the same bus. In this
> > +        mode, the CNV line is used to initiate the conversion and the SDI line
> > +        is connected to CS on the SPI controller.
>
> That's "normal" mode.

That was my first choice, but the datasheet uses the term "normal
mode" to mean not TURBO mode which is something else unrelated to the
SPI mode.


>
> > +      * chain: The datasheet calls this "chain mode". This mode is used to save
> > +        on wiring when multiple ADCs are used. In this mode, the SDI line of
> > +        one chip is tied to the SDO of the next chip in the chain and the SDI of
> > +        the last chip in the chain is tied to GND. Only the first chip in the
> > +        chain is connected to the SPI bus. The CNV line of all chips are tied
> > +        together. The CS line of the SPI controller is unused.
>
> Don't you need to know how many chips are chained? In any case, you just
> need a property for chain mode. There's some existing properties for
> chained devices I think. Standard logic shift register based GPIO IIRC.

Thanks, I see #daisy-chained-devices now. I missed that before.

>
> CNV are tied together, but must be driven by something? I suppose
> cnv-gpios?

Yes.

> But wouldn't that be the same as the SPI controller GPIO CS?
> Does a SPI controller CS line connected to CNV not work in this case?

Maybe technically possible if CS is inverted on the bus since the line
has to be high to trigger the conversion and during the xfer.
Rob Herring (Arm) Feb. 22, 2024, 3:34 p.m. UTC | #4
On Wed, Feb 21, 2024 at 8:44 AM David Lechner <dlechner@baylibre.com> wrote:
>
> On Wed, Feb 21, 2024 at 9:22 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:
>
> ...
>
> > > +  adi,spi-mode:
> > > +    $ref: /schemas/types.yaml#/definitions/string
> > > +    enum: [ single, multi, chain ]
> > > +    default: multi
> > > +    description: |
> > > +      * single: The datasheet calls this "3-wire mode". It is often used when
> > > +        the ADC is the only device on the bus. In this mode, SDI is tied to VIO,
> > > +        and the CNV line can be connected to the CS line of the SPI controller
> > > +        or to a GPIO, in which case the CS line of the controller is unused.
> >
> > We have a standard property for this.
>
> As discussed in v1 [1], the datasheet's definition of "3-wire mode" is
> _not_ the same as the standard spi-3wire property. I can add that to
> the description here to clarify (I hoped changing the enum name was
> enough, but perhaps not). Or is there a different property you are
> referring to?
>
> [1]: https://lore.kernel.org/all/20240216140826.58b3318d@jic23-huawei/
>
> >
> > > +      * multi: The datasheet calls this "4-wire mode". This is the convential

Also, typo.

> > > +        SPI mode used when there are multiple devices on the same bus. In this
> > > +        mode, the CNV line is used to initiate the conversion and the SDI line
> > > +        is connected to CS on the SPI controller.
> >
> > That's "normal" mode.
>
> That was my first choice, but the datasheet uses the term "normal
> mode" to mean not TURBO mode which is something else unrelated to the
> SPI mode.

What I mean is this should be conveyed by the absence of any property.
You don't need a property for "normal SPI mode".

> >
> > > +      * chain: The datasheet calls this "chain mode". This mode is used to save
> > > +        on wiring when multiple ADCs are used. In this mode, the SDI line of
> > > +        one chip is tied to the SDO of the next chip in the chain and the SDI of
> > > +        the last chip in the chain is tied to GND. Only the first chip in the
> > > +        chain is connected to the SPI bus. The CNV line of all chips are tied
> > > +        together. The CS line of the SPI controller is unused.
> >
> > Don't you need to know how many chips are chained? In any case, you just
> > need a property for chain mode. There's some existing properties for
> > chained devices I think. Standard logic shift register based GPIO IIRC.
>
> Thanks, I see #daisy-chained-devices now. I missed that before.
>
> >
> > CNV are tied together, but must be driven by something? I suppose
> > cnv-gpios?
>
> Yes.
>
> > But wouldn't that be the same as the SPI controller GPIO CS?
> > Does a SPI controller CS line connected to CNV not work in this case?
>
> Maybe technically possible if CS is inverted on the bus since the line
> has to be high to trigger the conversion and during the xfer.

That's supported by the binding. Seems like it would simplify the
driver if you went that route and better support other devices on the
SPI bus. Also, we require 'reg', so I don't know what you'd put in it
in the no CS case. Though, we probably already have that case with CS
tied active. Shrug.

Rob
David Lechner Feb. 27, 2024, 7:15 p.m. UTC | #5
On Thu, Feb 22, 2024 at 9:34 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Feb 21, 2024 at 8:44 AM David Lechner <dlechner@baylibre.com> wrote:
> >
> > On Wed, Feb 21, 2024 at 9:22 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:
> >
> > ...
> >
> > > > +  adi,spi-mode:
> > > > +    $ref: /schemas/types.yaml#/definitions/string
> > > > +    enum: [ single, multi, chain ]
> > > > +    default: multi
> > > > +    description: |
> > > > +      * single: The datasheet calls this "3-wire mode". It is often used when
> > > > +        the ADC is the only device on the bus. In this mode, SDI is tied to VIO,
> > > > +        and the CNV line can be connected to the CS line of the SPI controller
> > > > +        or to a GPIO, in which case the CS line of the controller is unused.
> > >
> > > We have a standard property for this.
> >
> > As discussed in v1 [1], the datasheet's definition of "3-wire mode" is
> > _not_ the same as the standard spi-3wire property. I can add that to
> > the description here to clarify (I hoped changing the enum name was
> > enough, but perhaps not). Or is there a different property you are
> > referring to?
> >
> > [1]: https://lore.kernel.org/all/20240216140826.58b3318d@jic23-huawei/
> >
> > >
> > > > +      * multi: The datasheet calls this "4-wire mode". This is the convential
>
> Also, typo.
>
> > > > +        SPI mode used when there are multiple devices on the same bus. In this
> > > > +        mode, the CNV line is used to initiate the conversion and the SDI line
> > > > +        is connected to CS on the SPI controller.
> > >
> > > That's "normal" mode.
> >
> > That was my first choice, but the datasheet uses the term "normal
> > mode" to mean not TURBO mode which is something else unrelated to the
> > SPI mode.
>
> What I mean is this should be conveyed by the absence of any property.
> You don't need a property for "normal SPI mode".

The binding already has `default: multi` to cover this case. But I
suppose we can just leave out the option altogether if you prefer.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
new file mode 100644
index 000000000000..61ee81326660
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
@@ -0,0 +1,204 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7944.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices PulSAR LFCSP Analog to Digital Converters
+
+maintainers:
+  - Michael Hennerich <Michael.Hennerich@analog.com>
+  - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+  A family of pin-compatible single channel differential analog to digital
+  converters with SPI support in a LFCSP package.
+
+  * https://www.analog.com/en/products/ad7944.html
+  * https://www.analog.com/en/products/ad7985.html
+  * https://www.analog.com/en/products/ad7986.html
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+  compatible:
+    enum:
+      - adi,ad7944
+      - adi,ad7985
+      - adi,ad7986
+
+  reg:
+    maxItems: 1
+
+  spi-max-frequency:
+    maximum: 111111111
+
+  spi-cpol: true
+  spi-cpha: true
+
+  adi,spi-mode:
+    $ref: /schemas/types.yaml#/definitions/string
+    enum: [ single, multi, chain ]
+    default: multi
+    description: |
+      * single: The datasheet calls this "3-wire mode". It is often used when
+        the ADC is the only device on the bus. In this mode, SDI is tied to VIO,
+        and the CNV line can be connected to the CS line of the SPI controller
+        or to a GPIO, in which case the CS line of the controller is unused.
+      * multi: The datasheet calls this "4-wire mode". This is the convential
+        SPI mode used when there are multiple devices on the same bus. In this
+        mode, the CNV line is used to initiate the conversion and the SDI line
+        is connected to CS on the SPI controller.
+      * chain: The datasheet calls this "chain mode". This mode is used to save
+        on wiring when multiple ADCs are used. In this mode, the SDI line of
+        one chip is tied to the SDO of the next chip in the chain and the SDI of
+        the last chip in the chain is tied to GND. Only the first chip in the
+        chain is connected to the SPI bus. The CNV line of all chips are tied
+        together. The CS line of the SPI controller is unused.
+
+  avdd-supply:
+    description: A 2.5V supply that powers the analog circuitry.
+
+  dvdd-supply:
+    description: A 2.5V supply that powers the digital circuitry.
+
+  vio-supply:
+    description:
+      A 1.8V to 2.7V supply for the digital inputs and outputs.
+
+  bvdd-supply:
+    description:
+      A voltage supply for the buffered power. When using an external reference
+      without an internal buffer (PDREF high, REFIN low), this should be
+      connected to the same supply as ref-supply. Otherwise, when using an
+      internal reference or an external reference with an internal buffer, this
+      is connected to a 5V supply.
+
+  ref-supply:
+    description:
+      Voltage regulator for the external reference voltage (REF). This property
+      is omitted when using an internal reference.
+
+  refin-supply:
+    description:
+      Voltage regulator for the reference buffer input (REFIN). When using an
+      external buffer with internal reference, this should be connected to a
+      1.2V external reference voltage supply. Otherwise, this property is
+      omitted.
+
+  cnv-gpios:
+    description:
+      The Convert Input (CNV). This input has multiple functions. It initiates
+      the conversions and selects the SPI mode of the device (chain or CS). In
+      'single' mode, this property is omitted if the CNV pin is connected to the
+      CS line of the SPI controller.
+    maxItems: 1
+
+  turbo-gpios:
+    description:
+      GPIO connected to the TURBO line. If omitted, it is assumed that the TURBO
+      line is hard-wired and the state is determined by the adi,always-turbo
+      property.
+    maxItems: 1
+
+  adi,always-turbo:
+    type: boolean
+    description:
+      When present, this property indicates that the TURBO line is hard-wired
+      and the state is always high. If neither this property nor turbo-gpios is
+      present, the TURBO line is assumed to be hard-wired and the state is
+      always low.
+
+  interrupts:
+    description:
+      The SDO pin can also function as a busy indicator. This node should be
+      connected to an interrupt that is triggered when the SDO line goes low
+      while the SDI line is high and the CNV line is low ('single' mode) or the
+      SDI line is low and the CNV line is high ('multi' mode); or when the SDO
+      line goes high while the SDI and CNV lines are high (chain mode),
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - avdd-supply
+  - dvdd-supply
+  - vio-supply
+  - bvdd-supply
+
+allOf:
+  # ref-supply and refin-supply are mutually exclusive (neither is also valid)
+  - if:
+      required:
+        - ref-supply
+    then:
+      properties:
+        refin-supply: false
+  - if:
+      required:
+        - refin-supply
+    then:
+      properties:
+        ref-supply: false
+  # in 'single' mode, cnv-gpios is optional, for other modes it is required
+  - if:
+      required:
+        - adi,spi-mode
+    then:
+      if:
+        properties:
+          adi,spi-mode:
+            enum: [ multi, chain ]
+      then:
+        required:
+          - cnv-gpios
+    else:
+      required:
+        - cnv-gpios
+  # chain mode has lower SCLK max rate and doesn't work when TURBO is enabled
+  - if:
+      required:
+        - adi,spi-mode
+      properties:
+        adi,spi-mode:
+          const: chain
+    then:
+      properties:
+        spi-max-frequency:
+          maximum: 90909090
+        adi,always-turbo: false
+  # turbo-gpios and adi,always-turbo are mutually exclusive
+  - if:
+      required:
+        - turbo-gpios
+    then:
+      properties:
+        adi,always-turbo: false
+  - if:
+      required:
+        - adi,always-turbo
+    then:
+      properties:
+        turbo-gpios: false
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    spi {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        adc@0 {
+            compatible = "adi,ad7944";
+            reg = <0>;
+            spi-cpha;
+            spi-max-frequency = <111111111>;
+            avdd-supply = <&supply_2_5V>;
+            dvdd-supply = <&supply_2_5V>;
+            vio-supply = <&supply_1_8V>;
+            bvdd-supply = <&supply_5V>;
+            cnv-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+            turbo-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 00d354af10f5..4f1e658e1e0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -451,6 +451,14 @@  W:	http://wiki.analog.com/AD7879
 W:	https://ez.analog.com/linux-software-drivers
 F:	drivers/input/touchscreen/ad7879.c
 
+AD7944 ADC DRIVER (AD7944/AD7985/AD7986)
+M:	Michael Hennerich <michael.hennerich@analog.com>
+M:	Nuno Sá <nuno.sa@analog.com>
+R:	David Lechner <dlechner@baylibre.com>
+S:	Supported
+W:	https://ez.analog.com/linux-software-drivers
+F:	Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
+
 ADAFRUIT MINI I2C GAMEPAD
 M:	Anshul Dalal <anshulusr@gmail.com>
 L:	linux-input@vger.kernel.org