Received-SPF: pass (google.com: domain of linux-kernel+bounces-207069-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 8 Jun 2024 15:32:31 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>, Kim Seer Paller
 <kimseer.paller@analog.com>, linux-kernel@vger.kernel.org,
 linux-iio@vger.kernel.org, devicetree@vger.kernel.org, Lars-Peter Clausen
 <lars@metafoo.de>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown
 <broonie@kernel.org>, Dimitri Fedrau <dima.fedrau@gmail.com>, Krzysztof
 Kozlowski <krzk+dt@kernel.org>, Rob Herring <robh@kernel.org>, Conor Dooley
 <conor+dt@kernel.org>, Michael Hennerich <michael.hennerich@analog.com>,
 Nuno =?UTF-8?B?U8Oh?= <noname.nuno@gmail.com>
Subject: Re: [PATCH v3 4/5] dt-bindings: iio: dac: Add adi,ltc2672.yaml
Message-ID: <20240608153231.02f839fd@jic23-huawei>
In-Reply-To: <3dadacf8-1349-483d-b264-dcb41d2cc3fc@baylibre.com>
References: <20240603012200.16589-1-kimseer.paller@analog.com>
	<20240603012200.16589-5-kimseer.paller@analog.com>
	<2942a938-19b9-4642-8ed0-8e17e4825bc5@baylibre.com>
	<c4651a18-316b-42e0-a67b-673fedb05b5a@kernel.org>
	<3dadacf8-1349-483d-b264-dcb41d2cc3fc@baylibre.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 4 Jun 2024 08:53:27 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 6/4/24 1:47 AM, Krzysztof Kozlowski wrote:
> > On 03/06/2024 21:59, David Lechner wrote:  
> >> On 6/2/24 8:21 PM, Kim Seer Paller wrote:  
> >>> Add documentation for ltc2672.
> >>>
> >>> Reported-by: Rob Herring (Arm) <robh@kernel.org>
> >>> Closes: https://lore.kernel.org/all/171643825573.1037396.2749703571529285460.robh@kernel.org/
> >>> Co-developed-by: Michael Hennerich <michael.hennerich@analog.com>
> >>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> >>> Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
> >>> ---
> >>>  .../bindings/iio/dac/adi,ltc2672.yaml         | 158 ++++++++++++++++++
> >>>  MAINTAINERS                                   |   1 +
> >>>  2 files changed, 159 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml
> >>> new file mode 100644
> >>> index 000000000000..d143a9db7010
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml
> >>> @@ -0,0 +1,158 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2672.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Analog Devices LTC2672 DAC
> >>> +
> >>> +maintainers:
> >>> +  - Michael Hennerich <michael.hennerich@analog.com>
> >>> +  - Kim Seer Paller <kimseer.paller@analog.com>
> >>> +
> >>> +description: |
> >>> +  Analog Devices LTC2672 5 channel, 16 bit, 300mA DAC
> >>> +  https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2672.pdf
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    enum:
> >>> +      - adi,ltc2672  
> >>
> >> The linked datasheet describes 12-bit and 16-bit versions, so should we have
> >> two compatibles here? adi,ltc2672-12, adi,ltc2672-16  
> > 
> > Is their programming model different?
> >   
> 
> I replied to myself already with the answer. After looking at it more it
> does not appear that is the case.
> 

For a DAC, this is an interesting question.  The wrong impressions of
precision might be a problem if someone is trying to tune the value.

Say they set it to +15 and look at some other sensor for the affect.
They expect to see something but get no change at all.  They might
assume the circuit is broken.

So I think yes the programming model is different and that should
be discoverable (ideally from hardware, but if not from the compatible)
To take an extreme example of extending the logic of these being
the 'same' from a programming model point of view, would we consider
a regulator that did 0 and 3V only different from one that did 0V,
1V, 2V, 3V just because the second bit in the register was ignored?
I think in that case we'd consider them to have an obviously different
programming model.

We have a few cases where we do paper over similar differences in
resolution, but within one part with different settings rather than
between devices (so that's a driver limitation, not a DT thing).

So I might be persuaded no one cares, but in my view the programming
model is different in a significant way.

Jonathan