From: Matteo Martelli <matteomartelli3@gmail.com>
To: Conor Dooley <conor@kernel.org>,
Matteo Martelli <matteomartelli3@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: iio: adc: add binding for pac1921
Date: Thu, 04 Jul 2024 12:06:31 +0200 [thread overview]
Message-ID: <668674271f02d_92937078@njaxe.notmuch> (raw)
In-Reply-To: <20240703-bovine-thumping-c3747fd7caa1@spud>
Hi Conor, thanks for your feedback,
Conor Dooley wrote:
> > +
> > + microchip,dv-gain:
> > + description:
> > + Digital multiplier to control the effective bus voltage gain. The gain
> > + value of 1 is the setting for the full-scale range and it can be increased
> > + when the system is designed for a lower VBUS range.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [1, 2, 4, 8, 16, 32]
> > + default: 1
> > +
> > + microchip,di-gain:
>
> Why is this gain a fixed property in the devicetree, rather than
> something the user can control? Feels like it should be user
> controllable.
Gains are user controllable via the IIO_CHAN_INFO_HARDWAREGAIN. I also added
them as DT properties thinking that they could be pre-set depending on hardware
specifications: for instance by board design the monitored section is already
known to be in a particular voltage/current range (datasheet specifies
gains-ranges mapping at table 4-6 and table 4-7). Then, even if gains are
pre-set, the user can change them at runtime for instance by scaling them down
upon an overflow event. However, I can get rid of those gain properties if they
are out of the DT scope.
> > + description:
> > + Digital multiplier to control the effective current gain. The gain
> > + value of 1 is the setting for the full-scale range and it can be
> > + increased when the system is designed for a lower VSENSE range.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [1, 2, 4, 8, 16, 32, 64, 128]
> > + default: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - shunt-resistor-micro-ohms
>
> You're missing a vdd-supply btw and the !read/int pin isn't described
> here either. I think the latter needs a property to control it (probably
> a GPIO since it is intended for host control) and a default value for if
> the GPIO isn't provided?
The driver does not currently handle the vdd regulator nor the gpio for the
!read/int pin. Should they be added to the DT schema anyway?
I think I can add the vdd regulator handling with little effort, my guess is
that the "vdd-supply" property can be optional and defined as "vdd-supply: true"
in the DT schema. Then the driver, if the vdd-supply property is present in the
DT, would enable the regulator during device initialization and PM resume, and
disable it on driver removal and PM suspend.
Reguarding the !read/int pin, the current driver overrides it with a register
bit so it would not be considered at all by the device.
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + adc@4c {
> > + compatible = "microchip,pac1921";
> > + #io-channel-cells = <1>;
> > + label = "vbat";
> > + reg = <0x4c>;
>
> Order here should be compatible, reg, generic properties and then finally
> vendor ones.
Thanks, I will fix this in next patch version.
>
> Thanks for your patch,
> Conor.
>
Thanks again for you feedback,
Matteo
next prev parent reply other threads:[~2024-07-04 10:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 13:34 [PATCH 0/2] iio: adc: add support for pac1921 Matteo Martelli
2024-07-03 13:34 ` [PATCH 1/2] dt-bindings: iio: adc: add binding " Matteo Martelli
2024-07-03 15:10 ` Conor Dooley
2024-07-04 10:06 ` Matteo Martelli [this message]
2024-07-04 10:37 ` Conor Dooley
2024-07-04 17:50 ` Matteo Martelli
2024-07-03 13:34 ` [PATCH 2/2] iio: adc: add support " Matteo Martelli
[not found] ` <SN6PR11MB3167C48F19120E35862316FA99DE2@SN6PR11MB3167.namprd11.prod.outlook.com>
2024-07-05 8:39 ` Marius.Cristea
2024-07-08 13:45 ` Matteo Martelli
2024-07-13 10:09 ` Jonathan Cameron
2024-07-03 14:55 ` [PATCH 0/2] " Conor Dooley
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=668674271f02d_92937078@njaxe.notmuch \
--to=matteomartelli3@gmail.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).