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

  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 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.