From: Herve Codina <herve.codina@bootlin.com>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
linux-iio@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Pascal Eberhard" <pascal.eberhard@se.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/4] iio: adc: Add support for the Renesas RZ/N1 ADC
Date: Fri, 17 Oct 2025 17:43:22 +0200 [thread overview]
Message-ID: <20251017174322.07997789@bootlin.com> (raw)
In-Reply-To: <10e119ee5a76f1c47d7eb6a15989c8ffc00ffc5f.camel@gmail.com>
I Nuno,
On Fri, 17 Oct 2025 09:26:26 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Fri, 2025-10-17 at 08:59 +0200, Herve Codina wrote:
> > Hi Nuno,
> >
> > On Thu, 16 Oct 2025 16:26:28 +0100
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > ...
> >
> > ...
> > > > > > > > +
> > > > > > > > + ret = rzn1_adc_core_get_regulators(rzn1_adc, &rzn1_adc-
> > > > > > > >
> > > > > > > > > adc_core[0],
> > > > > > > > + "adc1-avdd", "adc1-
> > > > > > > > vref");
> > > > > > > > + if (ret)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > + ret = rzn1_adc_core_get_regulators(rzn1_adc, &rzn1_adc-
> > > > > > > >
> > > > > > > > > adc_core[1],
> > > > > > > > + "adc2-avdd", "adc2-
> > > > > > > > vref");
> > > > > > > > + if (ret)
> > > > > > > > + return ret;
> > > > > > >
> > > > > > > Hmm, is avdd really an optional regulator? I mean can the ADC power
> > > > > > > up
> > > > > > > at
> > > > > > > all
> > > > > > > without a supply in AVDD? Even vref seems to be mandatory as we
> > > > > > > can't
> > > > > > > properly
> > > > > > > scale the sample without it.
> > > > > >
> > > > > > Where do you see that avdd is an optional regulator?
> > > > >
> > > > > You are using devm_regulator_get_optional(). That's for optional
> > > > > regulators.
> > > > >
> > > >
> > > > Indeed I use devm_regulator_get_optional().
> > > >
> > > > We have two similar function to get regulators:
> > > > - devm_regulator_get() and
> > > > - devm_regulator_get_optional().
> > > >
> > > > devm_regulator_get() returns a dummy regulator if the regulator is not
> > > > described in the device-tree. The calling code has no way to known if
> > > > the regulator was present or not.
> > >
> > > Yeah because it's mandatory and the part cannot work without power :). So we
> > > should not be allowed to operate without a regulator.
> > >
> > > >
> > > > On the other hand, devm_regulator_get_optional() returns -ENODEV when the
> > > > regulator is not described.
> > > >
> > > > That's pretty confusing but it is the reality.
> > > >
> > > > I use devm_regulator_get_optional() but check for -ENODEV to see if the
> > > > regulator is provided or not.
> > > >
> > > > In order to use the ADC core (is_used flag), I need both the AVDD and the
> > > > VREF regulator available.
> > >
> > > And that is why I don't get why are we allowed to proceed if there's no
> > > regulators? That seems wrong to me.
> > >
> > > So I think the regulators should be mandatory in the bindings and a dummy
> > > regulator should also not be allowed in this case because that should get
> > > you
> > > -EINVAL when calling regulator_get_voltage().
> > >
> >
> > I have 4 regulators: avdd1, vref1, avvd2, vref2.
> >
> > The ADC controller can work with 2 internal ADC core (adc_core[0] and
> > adc_core[1])
> > in the driver. Those internal core are not directly accessed by the driver.
> > Only
> > the ADC controller is accesses.
> >
> > Those cores have an AVDD and a VREF power supply.
> >
> > We can use either adc_core[0] only, adc_core[1] only or both adc cores.
> >
> > Depending on regulator described, the driver uses one or two adc cores.
> >
> > This choice is done by:
> > --- 8< ---
> > static int rzn1_adc_set_iio_dev_channels(struct rzn1_adc *rzn1_adc,
> > struct iio_dev *indio_dev)
> > {
> > int adc_used;
> >
> > adc_used = rzn1_adc->adc_core[0].is_used ? 0x01 : 0x00;
> > adc_used |= rzn1_adc->adc_core[1].is_used ? 0x02 : 0x00;
> >
> > switch (adc_used) {
> > case 0x01:
> > indio_dev->channels = rzn1_adc1_channels;
> > indio_dev->num_channels = ARRAY_SIZE(rzn1_adc1_channels);
> > return 0;
> > case 0x02:
> > indio_dev->channels = rzn1_adc2_channels;
> > indio_dev->num_channels = ARRAY_SIZE(rzn1_adc2_channels);
> > return 0;
> > case 0x03:
> > indio_dev->channels = rzn1_adc1_adc2_channels;
> > indio_dev->num_channels =
> > ARRAY_SIZE(rzn1_adc1_adc2_channels);
> > return 0;
> > default:
> > break;
> > }
> > --- 8< ---
> >
> > In rzn1_adc_core_get_regulators(), looking at one core I do the
> > following:
> > - Try to get AVDD (using get_optional)
> > - Try to get VREF (using get_optional)
> > - Core is used only if both regulators are present.
> >
> > For one core to be used, both regulators have to be present.
> >
> > Regulators are mandatory but adc core usage is optional.
> >
> > This optional usage depends on related regulator presence.
> >
>
> Ok, then we could flip the logic and have boolean properties for the adc core
> usage and depending on that, requesting the regulators. To me, the intent would
> be more clear (at the expense of more FW properties).
This introduces a new property and duplicates the information:
- flag to tell if adc core is used
- regulators described only if used
And so, the possible flag set to "adc core used" but regulators not
described. This is error prone.
I have chosen to rely only on regulators description to avoid the
information redundancy.
- regulators described -> adc core used
- regulators not described -> adc core not used
>
> Having said that, the above helps a lot in understanding what's going on and
> explains the get_optional() usage. I'm not still 100% convinced but bah, fine :)
>
> I would still argue that you should have a comment (likely in get_regulators())
> explaining the logic and the optional usage.
>
> Given the above I think you could also remove:
>
> if (!adc_core->vref)
> return -ENODEV;
>
> from rzn1_adc_core_get_vref_mv() since the channels are only exposed in case the
> regulators are present.
Yes indeed, I will remove the adc_core->vref check.
Best regards,
Hervé
next prev parent reply other threads:[~2025-10-17 15:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 14:28 [PATCH 0/4] Add support for the Renesas RZ/N1 ADC Herve Codina (Schneider Electric)
2025-10-15 14:28 ` [PATCH 1/4] dt-bindings: iio: adc: Add " Herve Codina (Schneider Electric)
2025-10-16 15:49 ` Krzysztof Kozlowski
2025-10-17 7:20 ` Herve Codina
2025-10-16 17:17 ` Wolfram Sang
2025-10-17 7:07 ` Herve Codina
2025-10-23 8:55 ` Herve Codina
2025-10-23 8:57 ` Wolfram Sang
2025-10-15 14:28 ` [PATCH 2/4] iio: adc: Add support for " Herve Codina (Schneider Electric)
2025-10-15 14:55 ` Andy Shevchenko
2025-10-15 15:21 ` Nuno Sá
2025-10-15 19:14 ` Herve Codina
2025-10-16 9:24 ` Nuno Sá
2025-10-16 14:02 ` Herve Codina
2025-10-16 15:26 ` Nuno Sá
2025-10-17 6:59 ` Herve Codina
2025-10-17 8:26 ` Nuno Sá
2025-10-17 15:43 ` Herve Codina [this message]
2025-10-17 16:29 ` Nuno Sá
2025-10-18 18:31 ` Jonathan Cameron
2025-10-16 13:13 ` kernel test robot
2025-10-16 14:47 ` kernel test robot
2025-10-17 6:28 ` Wolfram Sang
2025-10-17 7:36 ` Herve Codina
2025-10-17 7:40 ` Geert Uytterhoeven
2025-10-17 7:59 ` Herve Codina
2025-10-17 9:03 ` Wolfram Sang
2025-10-17 9:11 ` Wolfram Sang
2025-10-17 15:00 ` Herve Codina
2025-10-17 15:14 ` Wolfram Sang
2025-10-18 19:10 ` Jonathan Cameron
2025-10-15 14:28 ` [PATCH 3/4] ARM: dts: renesas: r9a06g032: Add the ADC device Herve Codina (Schneider Electric)
2025-10-17 6:36 ` Wolfram Sang
2025-10-15 14:28 ` [PATCH 4/4] MAINTAINERS: Add the Renesas RZ/N1 ADC driver entry Herve Codina (Schneider Electric)
2025-10-17 6:30 ` Wolfram Sang
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=20251017174322.07997789@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=andy@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=geert+renesas@glider.be \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.com \
--cc=pascal.eberhard@se.com \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa+renesas@sang-engineering.com \
/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.