From: Jonathan Cameron <jic23@kernel.org>
To: <marius.cristea@microchip.com>
Cc: <lars@metafoo.de>, <robh+dt@kernel.org>,
<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: iio: adc: adding MCP3564 ADC
Date: Sat, 20 May 2023 14:20:32 +0100 [thread overview]
Message-ID: <20230520142032.1dc7d593@jic23-huawei> (raw)
In-Reply-To: <20230519160145.44208-2-marius.cristea@microchip.com>
On Fri, 19 May 2023 19:01:44 +0300
<marius.cristea@microchip.com> wrote:
> From: Marius Cristea <marius.cristea@microchip.com>
>
> This is the device tree schema for iio driver for
> Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
> Delta-Sigma ADCs with an SPI interface.
>
> Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
Hi Marius,
A few comments inline
> ---
> .../bindings/iio/adc/microchip,mcp3564.yaml | 88 +++++++++++++++++++
> 1 file changed, 88 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
> new file mode 100644
> index 000000000000..407a125e3776
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3564.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip MCP346X and MCP356X ADC Family
> +
> +maintainers:
> + - Marius Cristea <marius.cristea@microchip.com>
> +
> +description: |
> + Bindings for the Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
> + Delta-Sigma ADCs with an SPI interface.
> +
> +properties:
> + compatible:
> + enum:
> + - microchip,mcp3461
> + - microchip,mcp3462
> + - microchip,mcp3464
> + - microchip,mcp3461r
> + - microchip,mcp3462r
> + - microchip,mcp3464r
> + - microchip,mcp3561
> + - microchip,mcp3562
> + - microchip,mcp3564
> + - microchip,mcp3561r
> + - microchip,mcp3562r
> + - microchip,mcp3564r
> +
> + reg:
> + maxItems: 1
> +
> + spi-max-frequency: true
If there is a device constraint on this (normally is) then good to enforce it
from the binding. Naturally wiring / host side limits may constrain it more.
> +
> + spi-cpha: true
> +
> + spi-cpol: true
> +
> + vref-supply:
> + description:
> + Some devices have a specific reference voltage supplied on a different
> + pin to the other supplies. Needed to be able to establish channel scaling
> + unless there is also an internal reference available (e.g. mcp3564r)
> +
From a quick glance at a random datasheet, looks like there additional power supplies
that should be required.
If this is required for some devices, I'd expect to see the binding enforce
that with some required entries conditioned on the compatibles rather than as
documentation. If there are devices where it isn't even optional then the binding
should enforce that as well.
> + microchip,hw-device-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 3
> + description:
> + The address is set on a per-device basis by fuses in the factory,
> + configured on request. If not requested, the fuses are set for 0x1.
> + The device address is part of the device markings to avoid
> + potential confusion. This address is coded on two bits, so four possible
> + addresses are available when multiple devices are present on the same
> + SPI bus with only one Chip Select line for all devices.
> +
> + "#io-channel-cells":
> + const: 1
> +
> +dependencies:
> + spi-cpol: [ spi-cpha ]
> + spi-cpha: [ spi-cpol ]
> +
> +required:
> + - compatible
> + - microchip,hw-device-address
Supplies should also be required (unless optional like vref seems to sometimes
be for these parts - where it's required I expect the binding to enforce that.)
> +
> +additionalProperties: false
For SPI devices, the newer way of providing standard SPI properties is:
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml#L33
for example
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@0 {
> + compatible = "microchip,mcp3564r";
> + reg = <0>;
> + vref-supply = <&vref_reg>;
> + spi-cpha;
> + spi-cpol;
> + spi-max-frequency = <10000000>;
> + microchip,hw-device-address = <1>;
> + };
> + };
> +...
next prev parent reply other threads:[~2023-05-20 13:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 16:01 [PATCH 0/2] Adding support for Microchip MCP3564 ADC family marius.cristea
2023-05-19 16:01 ` [PATCH 1/2] dt-bindings: iio: adc: adding MCP3564 ADC marius.cristea
2023-05-19 18:29 ` Conor Dooley
2023-05-20 15:17 ` Jonathan Cameron
2023-06-08 19:34 ` Rob Herring
2023-06-09 17:41 ` Jonathan Cameron
2023-05-20 13:20 ` Jonathan Cameron [this message]
2023-05-24 10:37 ` Mike Looijmans
2023-05-28 19:16 ` Jonathan Cameron
2023-05-19 16:01 ` [PATCH 2/2] iio: adc: adding support for " marius.cristea
2023-05-20 15:15 ` Jonathan Cameron
2023-06-22 11:32 ` Marius.Cristea
2023-07-02 10:28 ` Jonathan Cameron
2023-05-24 11:05 ` Mike Looijmans
2023-05-28 19:20 ` Jonathan Cameron
2023-06-20 14:34 ` Mike Looijmans
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=20230520142032.1dc7d593@jic23-huawei \
--to=jic23@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marius.cristea@microchip.com \
--cc=robh+dt@kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).