Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3700179pxb; Mon, 30 Aug 2021 08:37:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw12r2//40JCKP6GqxXz6cIBtmcd3jGwun0D48UO8Bz9fJFONlH5My3hZVI91iX4cF64YeD X-Received: by 2002:a17:906:60c2:: with SMTP id f2mr25734290ejk.531.1630337834331; Mon, 30 Aug 2021 08:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630337834; cv=none; d=google.com; s=arc-20160816; b=yuibvAUfYJKosBcVqop8gwGdM8Of3w8WhhFBuMEEUkj2Xgdqnq0m0CfWJNbKvyHax8 FKyh1Y4PjeHyiAEpM7bVnP0f5rog80ZwCnYzOoGSO62OVSJYHHEckLV3nrqaMjAC7e13 E9bWThybFUNNRfKbeazDxTXUx9SjXfQuOWptTGDolchDGijMmj8GWLgc08isFllDbNCE 7PO72FwavRSl9a8cdqfSFwcAty4SQBZtA5zbMRH58uDks0zUT7+15fcHJPQMa2bSNEDo /0PG0ccwHl95PhCEgeuMudkGlJ00C49WqQZfRmlcHQQcrbp9n/QJPtShaniDg5HdmrTD Zd4g== 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:subject:cc:to:from:date; bh=bfm9kOMkbBthHn6fnThuv8QR2h6AoqVpJciEsD8zfRQ=; b=pxKcBP//gsOsinE1fqr8FMhZu5+II22jJBRzdiuVjikoEdCOr1F8aNxH8ZDgXYsbz3 ev/GV8B/JSrjwMEm5DQuI5gXGul/fhM+4X3IIvnpHYEMnuBchcIeSutd1r3wmU7SkVK6 mMF2EDc16IK6hW6mIHuGbJVCvBUIaUAj44YIPXHRCmxnBihrmhNNVaDd+eSjHjkGCWyy JeJVtTBqvYSOHSCEy9AnhdHNwpdhGThtcG+S/wE7XWdbeaIwOhSgvHANyOr+OElxStYt 0/9B4Q9chFq0L3ks27nLaqyZNQCqWCIbU22YO+aLKFkk69uVIOhyNltWC8p747TmjHdq 0J8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb3si13494589edb.528.2021.08.30.08.36.45; Mon, 30 Aug 2021 08:37:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237508AbhH3Pfm (ORCPT + 99 others); Mon, 30 Aug 2021 11:35:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:47986 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237085AbhH3Pfl (ORCPT ); Mon, 30 Aug 2021 11:35:41 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D044560E98; Mon, 30 Aug 2021 15:34:44 +0000 (UTC) Date: Mon, 30 Aug 2021 16:37:53 +0100 From: Jonathan Cameron To: Mihail Chindris Cc: , , , , , , , Mark Brown Subject: Re: [PATCH v4 5/6] dt-bindings: iio: dac: Add adi,ad3552r.yaml Message-ID: <20210830163753.45b2ea6d@jic23-huawei> In-Reply-To: <20210820165927.4524-6-mihail.chindris@analog.com> References: <20210820165927.4524-1-mihail.chindris@analog.com> <20210820165927.4524-6-mihail.chindris@analog.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Aug 2021 16:59:26 +0000 Mihail Chindris wrote: > Add documentation for ad3552r > > Signed-off-by: Mihail Chindris +CC Mark for all the fun SPI stuff in here. > --- > .../bindings/iio/dac/adi,ad3552r.yaml | 185 ++++++++++++++++++ > 1 file changed, 185 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml > > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml > new file mode 100644 > index 000000000000..82ad8335aed8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml > @@ -0,0 +1,185 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +# Copyright 2020 Analog Devices Inc. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/iio/dac/adi,ad3552r.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Analog Devices AD2552R DAC device driver > + > +maintainers: > + - Mihail Chindris > + > +description: | > + Bindings for the Analog Devices AD3552R DAC device. Datasheet can be > + found here: > + https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf > + > +properties: > + compatible: > + enum: > + - adi,ad3552r you could use const: adi,ad3552r unless you are expecting to shortly add more compatibles to this binding. > + > + reg: > + maxItems: 1 > + > + spi-max-frequency: > + maximum: 30000000 > + > + interrupts: > + maxItems: 1 > + > + reset-gpios: > + maxItems: 1 > + > + ldac-gpios: > + description: | > + If a LDAC gpio is specified it will generate a LDAC pulse each time the > + trigger handler sends data to the chip. > + maxItems: 1 > + > + adi,synch_channels: | > + If set to true, data will be written to the input registers. When a pulse > + is generated on the LDAC pin data will update the output voltage of both > + channels if enabled. If ldac-gpios is specified the pulse will be > + generated by the driver in the interrupt handler. If adi,synch_channels > + is set to false, data will be written to the DAC registers and the output > + is updated imediatly after each register is written. > + type: bool This feels like policy to me rather than about device wiring. Annoyingly this would probably require custom ABI but I think we should still consider whether to expose it (with a sensible default which is probably synchronous if ldac-gpios is available). > + > + adi,vref-select: > + description: Selection of the voltage reference. > + The options are > + - 0 internal source with Vref I/O floating > + - 1 internal source with Vref I/O at 2.5V. > + - 2 external source with Vref I/O as input. Normally we take the view that if vref-supply is present someone put down a high precision reference and will definitely want to use it. So case 2 should be just dependent on such a regulator. Then this just becomes a control on whether to expose the internal vref if the supply isn't present. Hence it should be an appropriately named flag rather than a set of 3 magic values which require people to look at the doc to understand what is going on. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2] > + > + adi,spi-multi-io-mode: > + description: | > + Select SPI operating mode: > + - 0: standard. > + - 1: dual. > + - 2: quad. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2] Interesting that there isn't a generic spi form of this given this is pretty common for fast SPI devices. Oh well, this will have to do. Given we are using an enum, can we have enum: ["single", "dual", "quad"] perhaps to make it more human readable? Rob what do you think for this? I can't immediately find precedence. > + > + adi,ddr: > + description: Enable or disable double data rate SPI > + type: boolean > + > + adi,synchronous-mode: > + description: Enable or disable synchronous dual SPI mode > + type: boolean Get's better and better. Do we have any spi controller drivers that support these more 'exciting' modes? > + > + adi,sdo-drive-strength: > + description: | > + Configure SDIO0 and SDIO1 strength levels: > + - 0: low SDO drive strength. > + - 1: medium low SDO drive strength. > + - 2: medium high SDO drive strength. > + - 3: high SDO drive strength > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2, 3] > + > +patternProperties: > + "^channel@([0-1])$": > + type: object > + description: Configurations of the DAC Channels > + properties: > + reg: > + description: Channel number > + minimum: 0 > + maximum: 1 enum: [0, 1] perhaps? > + > + adi,output-range: > + description: | > + Output range of the channel > + 0: 0 V to 2.5 V > + 1: 0 V to 5 V > + 2: 0 V to 10 V > + 3: -5 V to 5 V > + 4: -10 V to 10 V > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2, 3, 4] I rather dislike magic numbers, but it gets tricky to specify ranges. You could probably do something with 2 element arrays in millivolts though which would be nicer than this. > + > + custom-output-range-config: > + type: object > + description: Configuration of custom range when adi,output-range is set > + to custom How do you do that? Seems from below that you mean it is not present. > + properties: > + adi,gain-offset: > + description: Gain offset What does gain offset mean here? > + $ref: /schemas/types.yaml#/definitions/int32 > + maximum: 511 > + minimum: -511 > + adi,gain-scaling-p: > + description: | > + Scaling p: > + 0: 1.0 > + 1: 0.5 > + 2: 0.25 > + 3: 0.125 > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2, 3] > + adi,gain-scaling-n: > + description: | > + Scaling p: > + 0: 1.0 > + 1: 0.5 > + 2: 0.25 > + 3: 0.125 > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2, 3] > + adi,rfb-ohms: > + description: Feedback Resistor > + required: > + - adi,gain-offset > + - adi,gain-sacling-p > + - adi,gain-sacling-n > + - adi,rfb-ohms > + required: > + - reg > + > + oneOf: > + # If adi,output-range is missing, custom-output-range-config must be used > + - required: > + - adi,output-range > + - required: > + - custom-output-range-config > + > +required: > + - compatible > + - reg > + - spi-max-frequency > + > +additionalProperties: false > + > +examples: > + - | > + ad3552r { > + compatible = "adi,ad3552r"; > + reg = <0 0 0 0>; > + spi-max-frequency = <20000000>; > + interrupt-parent = <&gpio0>; > + interrupts = <87 0>; > + pwms = <&axi_pwm 0 50>; > + reset-gpios = <&gpio 86 0>; > + adi,synch_channels; > + adi,vref-select = <0>; > + channel@0 { > + reg = <0>; > + adi,output-range = <0>; > + }; > + channel@1 { > + reg = <1>; > + custom-output-range-config { > + adi,gain-offset = <5>; > + adi,gain-sacling-p = <1>; > + adi,gain-sacling-n = <2>; > + adi,rfb-ohms = <1>; > + }; > + }; > + }; > +...