Message ID | 20230519160145.44208-2-marius.cristea@microchip.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1344101vqo; Fri, 19 May 2023 09:04:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7kbpBCXRs2V4F0YR8BN3AVJSg61DOr3myOgvCbaXCNVFK3SfAuRKVP6YfB5tV2GSS4IaBw X-Received: by 2002:a05:6a20:8e08:b0:100:ab42:5457 with SMTP id y8-20020a056a208e0800b00100ab425457mr3126851pzj.22.1684512296146; Fri, 19 May 2023 09:04:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684512296; cv=none; d=google.com; s=arc-20160816; b=qKhybLEvdTMYsFhcg2FGKhn+kEB9eRj6UG5sLlEnxhrSrZGdgBK2oRvhrPR+uLPw92 FXjybZozoCayaMCUZIiwOWfMhd4lDBwzHCkr1mvwz3hkpTBFrvU+kPU77sLuBe0DjC8o 8VNpkjx7a+5HqDopEDKoWoI5cYr4YvxlRaDaNxt2aq/OLFnmFsiaLohQjMCFAx1NwY+X zJkoKwxLOXNTrfD4n5dOuHiDtcveDv+8pzryUnS1L+u1nodrwhBN19lo35ttgoJDGLK6 e5RPXYH+PUXzkNZUbJtNF6ZYTC7FxfyrlhxoPz2fvolNCfmF9GyzG1pnNSUd5sg3QiQs 8QZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=d0w0Zmh2Aq1friOxIR+Xj7S4c2OO0xxdh7rf5eKDHe4=; b=lmEuFQnGwL4BsvslFoljg76/8/I0ROZ3aV5wMP+up2ZIJBzPj8v2EfWIP1DgAQ96Qt IRU0bLW9jOkAB1a3lgAwgezFBvoxjxdaQ4mj6b2c4DgZf2odB996hvkhhz1TspGdMgwc V/zeydlQTmaSHm6h2ywmBF7oSLKl97/EYE60I9T+K3hWy4jGLSf7Ojtv9lj2xh5s7I79 9Ign4lq7SJPSwOVdJgC5VTVhLhyLwEJVgcgXtB54M5YhqD1AyepdLvybiYH+5UihG//r sEAIaxwvfooBTy6ws0SfBLpBVw2gI0DoXd8dBFT1Jj0MnVtzNZuXmDOI85028cH0cRe7 pvZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=azY5NpTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a656687000000b005348977b5c5si1693057pgw.97.2023.05.19.09.04.40; Fri, 19 May 2023 09:04:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=azY5NpTz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232380AbjESQCA (ORCPT <rfc822;wlfightup@gmail.com> + 99 others); Fri, 19 May 2023 12:02:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232378AbjESQB5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 19 May 2023 12:01:57 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C31FFE; Fri, 19 May 2023 09:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1684512116; x=1716048116; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=VqXRgbG9sAVE8Xa7fYxgTwr3Vh6RDXRnIzLEJQPzD+c=; b=azY5NpTzgGSPm5reSQmugU/xmEfmRa6lIEWwfd0d3vyCCf+53bVgx3D5 IPpEmrdqPRnTJb3NkGc2eIdtWQDN3yV6TNdtpZ5+VSFpe54E1YxctwN19 wdm+kzzYvx/Bj9C/ip282kOoMrsrcTncPgrgyFL3L4avFH9VP2ofKUzOr H8gUZ0j4Ao4MQVDj41zuhKsG2TWHbMFdm86vwQsYhPRVFEiu6sFlaGhXy B0JqKurYUk9jC8dp85vA57XeI92KJjZ4H4PIWL5y+SGSDDs+brJFM3wcW ZI7ExcOa7o053vpkAEhgy8nN94MBvBFYdtz3DzknwpYKXwgbxObo3b8DN Q==; X-IronPort-AV: E=Sophos;i="6.00,177,1681196400"; d="scan'208";a="152988642" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 19 May 2023 09:01:55 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 19 May 2023 09:01:55 -0700 Received: from marius-VM.mshome.net (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.2507.21 via Frontend Transport; Fri, 19 May 2023 09:01:53 -0700 From: <marius.cristea@microchip.com> To: <jic23@kernel.org>, <lars@metafoo.de>, <robh+dt@kernel.org> CC: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <marius.cristea@microchip.com> Subject: [PATCH 1/2] dt-bindings: iio: adc: adding MCP3564 ADC Date: Fri, 19 May 2023 19:01:44 +0300 Message-ID: <20230519160145.44208-2-marius.cristea@microchip.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230519160145.44208-1-marius.cristea@microchip.com> References: <20230519160145.44208-1-marius.cristea@microchip.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766339165300230715?= X-GMAIL-MSGID: =?utf-8?q?1766339165300230715?= |
Series |
Adding support for Microchip MCP3564 ADC family
|
|
Commit Message
marius.cristea@microchip.com
May 19, 2023, 4:01 p.m. UTC
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> --- .../bindings/iio/adc/microchip,mcp3564.yaml | 88 +++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
Comments
Hey Marius, On Fri, May 19, 2023 at 07:01:44PM +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. Just one quick process bit, please try to CC all of the maintainers listed by get_maintainer.pl - you unfortunately managed to miss 2 of the 3 dt-binding maintainers :/ Perhaps you ran get_maintainer.pl using our vendor tree? > Signed-off-by: Marius Cristea <marius.cristea@microchip.com> > --- > + 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) Should this be marked as a required property for the non-r devices that do not have an internal reference? > + microchip,hw-device-address: Hopefully Rob or Jonathan etc can chime in as to whether a common property exists for this type of thing... > + $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. ..although if it doesn't, it'd be good, I think, to add here where the property crops up in spi transfers. And if not in the description, in the commit message instead? Thanks, Conor.
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>; > + }; > + }; > +...
On Fri, 19 May 2023 19:29:15 +0100 Conor Dooley <conor@kernel.org> wrote: > Hey Marius, > > On Fri, May 19, 2023 at 07:01:44PM +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. > > Just one quick process bit, please try to CC all of the maintainers > listed by get_maintainer.pl - you unfortunately managed to miss 2 of the > 3 dt-binding maintainers :/ Perhaps you ran get_maintainer.pl using our > vendor tree? > > > Signed-off-by: Marius Cristea <marius.cristea@microchip.com> > > --- > > > + 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) > > Should this be marked as a required property for the non-r devices that > do not have an internal reference? > > > + microchip,hw-device-address: > > Hopefully Rob or Jonathan etc can chime in as to whether a common > property exists for this type of thing... > Nope. This is a new one for me - there are devices that work on a daisy chain principle but I think this one works by encoding stuff in the actual message which is unusual for SPI. > > + $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. > > ..although if it doesn't, it'd be good, I think, to add here where the > property crops up in spi transfers. And if not in the description, in > the commit message instead? Agreed. Top two bits of COMMAND BYTE which is first one on the wire I think. Thanks, J > > Thanks, > Conor. >
On 19-05-2023 18:01, 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> > --- > .../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 > + > + 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) > + > + 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": That's a typo, "io" should be "iio", right? > + const: 1 > + > +dependencies: > + spi-cpol: [ spi-cpha ] > + spi-cpha: [ spi-cpol ] > + > +required: > + - compatible > + - microchip,hw-device-address Should be optional, as the default "1" is going to be what most people will be using. > + > +additionalProperties: false Missing properties: - Interrupt (even though the driver doesn't use it yet) - push-pull or open-drain config of interrupt pin - dvdd-supply - avdd-supply I suggest using this: + clocks: + description: + Phandle and clock identifier for external sampling clock. + If not specified, the internal crystal oscillator will be used. + maxItems: 1 + + interrupts: + description: IRQ line of the ADC + maxItems: 1 + + drive-open-drain: + description: + Whether to drive the IRQ signal as push-pull (default) or open-drain. Note + that the device requires this pin to become "high", otherwise it will stop + converting. + type: boolean > + > +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>; > + }; > + }; > +...
On Wed, 24 May 2023 12:37:43 +0200 Mike Looijmans <mike.looijmans@topic.nl> wrote: > On 19-05-2023 18:01, 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> > > --- > > .../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 > > + > > + 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) > > + > > + 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": > > That's a typo, "io" should be "iio", right? Nope. I honestly can't remember the history behind that, but it's just io. Probably to do with IIO being Linux specific and this needing to be generic, but its just an educated guess. Jonathan
On Sat, May 20, 2023 at 04:17:53PM +0100, Jonathan Cameron wrote: > On Fri, 19 May 2023 19:29:15 +0100 > Conor Dooley <conor@kernel.org> wrote: > > > Hey Marius, > > > > On Fri, May 19, 2023 at 07:01:44PM +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. > > > > Just one quick process bit, please try to CC all of the maintainers > > listed by get_maintainer.pl - you unfortunately managed to miss 2 of the > > 3 dt-binding maintainers :/ Perhaps you ran get_maintainer.pl using our > > vendor tree? > > > > > Signed-off-by: Marius Cristea <marius.cristea@microchip.com> > > > --- > > > > > + 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) > > > > Should this be marked as a required property for the non-r devices that > > do not have an internal reference? > > > > > + microchip,hw-device-address: > > > > Hopefully Rob or Jonathan etc can chime in as to whether a common > > property exists for this type of thing... > > > Nope. This is a new one for me - there are devices that work on a daisy chain > principle but I think this one works by encoding stuff in the actual message > which is unusual for SPI. Not something I've seen either. > > > > + $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. What's this going to look like with more than one device? It would need to be incorporated into 'reg' and the unit-address to work. Something like this is spi { device0@0 { reg = <0>; microchip,hw-device-address = <0>; }; device1@0 { reg = <0>; microchip,hw-device-address = <1>; }; }; That should throw warnings because you have 2 nodes at the same address which is not good practice. I think you need a spi mux in here with the mux addresses being the microchip,hw-device-address values. Rob
On Thu, 8 Jun 2023 13:34:43 -0600 Rob Herring <robh@kernel.org> wrote: > On Sat, May 20, 2023 at 04:17:53PM +0100, Jonathan Cameron wrote: > > On Fri, 19 May 2023 19:29:15 +0100 > > Conor Dooley <conor@kernel.org> wrote: > > > > > Hey Marius, > > > > > > On Fri, May 19, 2023 at 07:01:44PM +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. > > > > > > Just one quick process bit, please try to CC all of the maintainers > > > listed by get_maintainer.pl - you unfortunately managed to miss 2 of the > > > 3 dt-binding maintainers :/ Perhaps you ran get_maintainer.pl using our > > > vendor tree? > > > > > > > Signed-off-by: Marius Cristea <marius.cristea@microchip.com> > > > > --- > > > > > > > + 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) > > > > > > Should this be marked as a required property for the non-r devices that > > > do not have an internal reference? > > > > > > > + microchip,hw-device-address: > > > > > > Hopefully Rob or Jonathan etc can chime in as to whether a common > > > property exists for this type of thing... > > > > > Nope. This is a new one for me - there are devices that work on a daisy chain > > principle but I think this one works by encoding stuff in the actual message > > which is unusual for SPI. > > Not something I've seen either. > > > > > > > + $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. > > What's this going to look like with more than one device? It would need > to be incorporated into 'reg' and the unit-address to work. Something > like this is > > spi { > device0@0 { > reg = <0>; > microchip,hw-device-address = <0>; > }; > > device1@0 { > reg = <0>; > microchip,hw-device-address = <1>; > }; > }; > > That should throw warnings because you have 2 nodes at the same address > which is not good practice. > > I think you need a spi mux in here with the mux addresses being the > microchip,hw-device-address values. Something that looked like an spi-mux would be cute I'm not sure how easy it would be to make it work given need to modify the messages (rather sending extra ones before and after with a different chip select). It would be nice if it were somewhat generic - so binding included which bits would be replaced with the 'chip select' for the spi controller that represents the mux. Jonathan > > Rob >
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 + + 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) + + 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 + +additionalProperties: false + +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>; + }; + }; +...