From: Conor Dooley <conor@kernel.org>
To: "Ceclan, Dumitru" <mitrutzceclan@gmail.com>
Cc: dumitru.ceclan@analog.com, Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Jonathan Cameron <jic23@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
David Lechner <dlechner@baylibre.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/6] dt-bindings: adc: ad7173: add support for ad411x
Date: Wed, 29 May 2024 17:04:22 +0100 [thread overview]
Message-ID: <20240529-slit-verse-0fb06f3556fb@spud> (raw)
In-Reply-To: <a1c75105-6447-4b67-b7d2-326ad9b19b82@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5551 bytes --]
On Wed, May 29, 2024 at 04:38:53PM +0300, Ceclan, Dumitru wrote:
> On 28/05/2024 20:52, Conor Dooley wrote:
> > On Tue, May 28, 2024 at 03:16:07PM +0300, Ceclan, Dumitru wrote:
> >> On 27/05/2024 20:48, Conor Dooley wrote:
> >>> On Mon, May 27, 2024 at 08:02:34PM +0300, Dumitru Ceclan via B4 Relay wrote:
> >>>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
> >>>> + adi,channel-type:
> >>>> + description:
> >>>> + Used to differentiate between different channel types as the device
> >>>> + register configurations are the same for all usage types.
> >>>> + Both pseudo-differential and single-ended channels will use the
> >>>> + single-ended specifier.
> >>>> + $ref: /schemas/types.yaml#/definitions/string
> >>>> + enum:
> >>>> + - single-ended
> >>>> + - differential
> >>>> + default: differential
> >>>
> >>> I dunno if my brain just ain't workin' right today, or if this is not
> >>> sufficiently explained, but why is this property needed? You've got
> >>> diff-channels and single-channels already, why can you not infer the
> >>> information you need from them? What should software do with this
> >>> information?
> >>> Additionally, "pseudo-differential" is not explained in this binding.
> >>
> >> In previous thread we arrived to the conclusion single-ended and
> >> pseudo-differential channels should be marked with the flag
> >> "differential=false" in the IIO channel struct. This cannot
> >> really be inferred as any input pair could be used in that
> >> manner and the only difference would be in external wiring.
> >>
> >> Single-channels cannot be used to define such a channel as
> >> two voltage inputs need to be selected. Also, we are already
> >> using single-channel to define the current channels.
> >
> > If I understand correctly, the property could be simplified to a flag
> > then, since it's only the pseudo differential mode that you cannot be
> > sure of?
> > You know when you're single-ended based on single-channel, so the
> > additional info you need is only in the pseudo-differential case.
> >
> Yes, it could just be a boolean flag. The only thing I have against
> that is the awkwardness of having both diff-channels and
> differential=false within a channel definition.
What I was suggesting was more like "adi,pseudo-differential" (you don't
need to set the =false or w/e, flag properties work based on present/not
present). I think that would avoid the awkwardness?
> >> As for explaining the pseudo-differential, should it be explained?
> >> A voltage channel within the context of these families is actually
> >> differential(as there are always two inputs selected).
> >> The single-ended and pseudo-diff use case is actually wiring up a
> >> constant voltage to the selected negative input.
> >>
> >> I did not consider that this should be described, as there is no
> >> need for an attribute to describe it.
> >
> > I dunno, adding an explanation of it in the text for the channel type
> > seems trivial to do. "Both pseudo-differential mode (where the
> > one of differential inputs is connected to a constant voltage) and
> > single-ended channels will..."
> >
> >>> Also, what does "the device register configurations are the same for
> >>> all uses types" mean? The description here implies that you'd be reading
> >>> the registers to determine the configuration, but as far as I understand
> >>> it's the job of drivers to actually configure devices.
> >>> The only way I could interpret this that makes sense to me is that you're
> >>> trying to say that the device doesn't have registers that allow you to
> >>> do runtime configuration detection - but that's the norm and I would not
> >>> call it out here.
> >>
> >> No, I meant that the same register configuration will be set for
> >> both fully differential and single-ended.
> >>
> >> The user will set diff-channels = <0, 1>, bipolar(or not) and
> >> then they can wire whatever to those pins:
> >> - a differential signal
> >> - AVSS to 1 and a single-ended signal to 0
> >> - AVSS+offset to 1 and a single-ended signal to 0
> >> (which is called pseudo-differential in some datasheets)
> >>
> >> All these cases will look the same in terms of configuration
> >
> > In that case, I'd just remove this sentence from the description then.
> > How you configure the registers to use the device doesn't really have
> > anything to do with describing the configuration of the hardware.
> > Given it isn't related to configuration detection at runtime, what
> > you've got written here just makes it seem like the property is
> > redundant because the register settings do not change.
> >
> > Instead, use the description to talk about when the property should be
> > used and what software should use it to determine, e.g. "Software can
> > use vendor,channel-type to determine whether or not the measured voltage
> > is absolute or relative". I pulled that outta my ass, it might not
> > be what you're actually doing, but I figure you just want to know if
> > you're measuring from the origin or either side of it.
> >It's more to the "software can this property to correctly mark the channel
Your quoting is scuffed here, I didn't write this!
> as differential or not". Hope this is acceptable. But got it, thanks.
As long as you've got a description that tells the OS what the property
actually represents, I'm happy.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-05-29 16:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 17:02 [PATCH v3 0/6] Add support for AD411x Dumitru Ceclan via B4 Relay
2024-05-27 17:02 ` [PATCH v3 1/6] dt-bindings: adc: ad7173: add support for ad411x Dumitru Ceclan via B4 Relay
2024-05-27 17:48 ` Conor Dooley
2024-05-28 12:16 ` Ceclan, Dumitru
2024-05-28 17:52 ` Conor Dooley
2024-05-29 13:38 ` Ceclan, Dumitru
2024-05-29 16:04 ` Conor Dooley [this message]
2024-05-30 7:50 ` Nuno Sá
2024-05-30 11:55 ` Ceclan, Dumitru
2024-05-29 22:04 ` David Lechner
2024-05-30 7:12 ` Nuno Sá
2024-05-27 17:02 ` [PATCH v3 2/6] iio: adc: ad7173: refactor channel configuration parsing Dumitru Ceclan via B4 Relay
2024-05-29 12:24 ` Nuno Sá
2024-05-27 17:02 ` [PATCH v3 3/6] iio: adc: ad7173: refactor ain and vref selection Dumitru Ceclan via B4 Relay
2024-05-29 12:27 ` Nuno Sá
2024-05-29 12:49 ` Nuno Sá
2024-05-30 14:45 ` Ceclan, Dumitru
2024-05-31 7:10 ` Nuno Sá
2024-06-01 18:40 ` Jonathan Cameron
2024-05-27 17:02 ` [PATCH v3 4/6] iio: adc: ad7173: add support for special inputs Dumitru Ceclan via B4 Relay
2024-05-29 12:29 ` Nuno Sá
2024-05-27 17:02 ` [PATCH v3 5/6] iio: adc: ad7173: Add support for AD411x devices Dumitru Ceclan via B4 Relay
2024-05-29 12:46 ` Nuno Sá
2024-05-29 14:03 ` Ceclan, Dumitru
2024-05-29 20:59 ` David Lechner
2024-05-30 6:19 ` Nuno Sá
2024-06-01 18:43 ` Jonathan Cameron
2024-05-27 17:02 ` [PATCH v3 6/6] iio: adc: ad7173: Reduce device info struct size Dumitru Ceclan via B4 Relay
2024-05-29 12:23 ` Nuno Sá
2024-05-29 20:32 ` David Lechner
2024-05-30 6:17 ` Nuno Sá
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=20240529-slit-verse-0fb06f3556fb@spud \
--to=conor@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=dumitru.ceclan@analog.com \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mitrutzceclan@gmail.com \
--cc=robh@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