All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2024-05-29 16:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-27 17:02 [PATCH v3 0/6] Add support for AD411x Dumitru Ceclan
2024-05-27 17:02 ` Dumitru Ceclan via B4 Relay
2024-05-27 17:02 ` [PATCH v3 1/6] dt-bindings: adc: ad7173: add support for ad411x Dumitru Ceclan
2024-05-27 17:02   ` 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
2024-05-27 17:02   ` 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
2024-05-27 17:02   ` 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
2024-05-27 17:02   ` 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
2024-05-27 17:02   ` 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
2024-05-27 17:02   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.