[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3de10398-6521-4c8a-9af1-e8d15421b963@baylibre.com>
Date: Fri, 11 Jul 2025 12:43:09 -0500
From: David Lechner <dlechner@...libre.com>
To: Antoniu Miclaus <antoniu.miclaus@...log.com>, jic23@...nel.org,
robh@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: iio: adc: add ade9000
On 7/11/25 8:02 AM, Antoniu Miclaus wrote:
> Add devicetree bindings support for ade9000.
>
> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@...log.com>
> ---
> .../bindings/iio/adc/adi,ade9000.yaml | 157 ++++++++++++++++++
> 1 file changed, 157 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
> new file mode 100644
> index 000000000000..660dca4ea9b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2025 Analog Devices Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/iio/adc/adi,ade9000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADE9000 High Performance, Polyphase Energy Metering driver
> +
> +maintainers:
> + - Antoniu Miclaus <antoniu.miclaus@...log.com>
> +
> +description: |
> + The ADE9000 s a highly accurate, fully integrated, multiphase energy and power
> + quality monitoring device. Superior analog performance and a digital signal
> + processing (DSP) core enable accurate energy monitoring over a wide dynamic
> + range. An integrated high end reference ensures low drift over temperature
> + with a combined drift of less than ±25 ppm/°C maximum for the entire channel
> + including a programmable gain amplifier (PGA) and an analog-to- digital
> + converter (ADC).
> +
> + https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - adi,ade9000
> +
> + reg:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + spi-max-frequency:
> + maximum: 20000000
> +
> + interrupts:
> + maxItems: 2
Let's keep this together with interrupt-names.
> +
> + reset-gpios:
> + description: |
> + Must be the device tree identifier of the RESET pin. As the line is
> + active low, it should be marked GPIO_ACTIVE_LOW.
> + maxItems: 1
> +
> + interrupt-names:
> + items:
> + - const: irq0
> + - const: irq1
The C4/EVENT/DREADY pins can also be an output and would make sense
as a 3rd interrupt.
> +
> + adi,wf-cap-en:
> + description: Enable fixed data rate for waveform buffer instead of resampled data
> + type: boolean
This one sounds like a runtime setting depending on how you want to
configure sampling.
> +
> + adi,wf-mode:
> + description: |
> + Waveform buffer filling and trigger mode.
> + 0 - Stop when waveform buffer is full
> + 1 - Continuous fill, stop only on enabled trigger events
> + 2 - Continuous filling, center capture around enabled trigger events
> + 3 - Streaming mode
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
This one sounds like something that would be determined by how
a buffered read is setup in the IIO driver, not something that
should be in the devicetree.
> +
> + adi,wf-src:
> + description: |
> + Waveform buffer data source selection.
> + 0 - Sinc4 output, at 16 kSPS
> + 1 - Reserved
> + 2 - Sinc4 + IIR LPF output, at 4 kSPS
> + 3 - Current and voltage channel waveform samples, processed by the DSP at 4 kSPS
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 2, 3]
There is a standard filter_type attribute that should be used
for selecting the filter type rather than hard-coding it in the
devicetree.
> +
> + adi,wf-in-en:
> + description: Enable IN waveform samples readout from waveform buffer
> + type: boolean
This one also sounds like something that would be configured based
on how a scan is setup at runtime.
> +
> + adi,egy-time:
> + description: Energy accumulation time setting for energy registers
> + $ref: /schemas/types.yaml#/definitions/uint32
And another one that sounds like it would be more of a runtime
setting based on what type of data capture you are setting up.
> +
Power and reference voltage supplies are missing.
ref-supply, vdd-supply
And there is a clock input and a clock output that we could
add trivial bindings for.
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> + - interrupts
> + - interrupt-names
> + - adi,wf-mode
> + - adi,wf-src
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^phase@[0-2]$":
> + type: object
> + description: |
> + Represents the external phases which are externally connected. Each phase
> + has a current, voltage and power component
> +
> + properties:
> + reg:
> + description: |
> + The phase represented by a number
> + 0 - Phase A
> + 1 - Phase B
> + 2 - Phase C
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2]
If we are calling this an ADC, we should be using adc.yaml and
calling these channel@ rather than phase@. There could be a custom
adi,phase property for each channel if needed. But I'm guessing
IAP/IAN is always going to be phase A, IBP/IBN is always going to
be phase B, etc. so I'm not sure we actually need any special channel
properties at this point.
> +
> + required:
> + - reg
> +
> + additionalProperties: false
> +
Powered by blists - more mailing lists