All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Marius.Cristea@microchip.com>
To: <jic23@kernel.org>, <matteomartelli3@gmail.com>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<robh@kernel.org>, <lars@metafoo.de>,
	<linux-kernel@vger.kernel.org>, <krzk+dt@kernel.org>,
	<Jonathan.Cameron@Huawei.com>, <conor+dt@kernel.org>
Subject: Re: [PATCH v2 2/2] iio: adc: add support for pac1921
Date: Tue, 16 Jul 2024 11:19:53 +0000	[thread overview]
Message-ID: <483de34b3a74a2981fac89a8232e3ef2448f57ef.camel@microchip.com> (raw)
In-Reply-To: <66963b764ac3c_706370bd@njaxe.notmuch>

Hi Matteo,

On Tue, 2024-07-16 at 11:20 +0200, Matteo Martelli wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> Jonathan Cameron wrote:
> > On Tue, 09 Jul 2024 10:21:07 +0200
> > Matteo Martelli <matteomartelli3@gmail.com> wrote:
> > 
> > > Jonathan Cameron wrote:
> > > ...
> > > > > I could add the shunt-resistor controls to allow calibration
> > > > > as Marius
> > > > > suggested, but that's also a custom ABI, what are your
> > > > > thoughts on this?
> > > > 
> > > > This would actually be a generalization of existing device
> > > > specific ABI
> > > > that has been through review in the past.
> > > > See Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
> > > > for example (similar in other places).
> > > > So if you want to do this move that ABI up a level to cover
> > > > multiple devices
> > > > (removing the entries in specific files as you do so).
> > > > 
> > > I would do this in a separate commit, would you prefer it in this
> > > same patch
> > > set or in another separate patch?
> > 
> > Separate commit in this series as otherwise it's not obvious why we
> > are
> > doing it. In theory should be before this patch as then what you
> > use here
> > is already documented, but I don't care that much on the order.
> > 
> Just a few more questions about this point.
> 
> * I see 3 other drivers exposing the shunt resistor attribute:
> ina2xx, max9611
> and pac1934. While the unit for first two is in Ohms, for the latter
> it's in
> micro-Ohms. What should be the unit for the generalized ABI? I would
> guess Ohms

For measuring current the usual "scale" is part of miliOhms in order to
reduce the power dissipation. As a rule of thumb 0.1 miliOhms is a
usual value for shunt resistors. I think the "correct" way is to setup
the  value in sub units of Ohms. Like the current is in miliAmps and
the voltage is in miliVolts.


> as /sys/bus/iio/devices/iio:deviceX/in_resistance_raw.
> 
> * If for instance the generalized ABI unit is going to be Ohms,
> should I still
> remove the entry from the pac1934 even though it would not be fully
> compliant
> with the generalized ABI?
> 
> * To cover the current exposed attributes, the "What" fields would
> look like:
> from max9611:
> What:         /sys/.../iio:deviceX/in_current_shunt_resistor
> What:         /sys/.../iio:deviceX/in_power_shunt_resistor
> from ina2xx:
> What:         /sys/.../iio:deviceX/in_shunt_resistor
> from pac1934:
> What:         /sys/.../iio:deviceX/in_shunt_resistorY
> Does this look correct? I think that for the first two drivers the
> shunt_resistor can be considered as a channel info property, shared
> by type for
> max9611 case and shared by direction for ina2xx case (maybe better to
> remove
> "in_" from the What field if the type is not specified?).
> What seems odd to me is the pac1934 case, since it doesn't fit in the
> format
> <type>[Y_]shunt_resistor referred in many other attributes (where I
> assume
> <type> is actually [dir_][type_]?).
> Doesn't it look like pac1934 is exposing additional input channels,
> that are
> also writeable? Maybe such case would more clear if the shunt
> resistor would be
> an info property of specific channels? For example:
> in_currentY_shunt_resistor,
> in_powerY_shunt_resistor and in_engergyY_shunt_resitor.
> 

I don't think it will be a good idea to duplicate the same information
into multiple attributes like: in_currentY_shunt_resistor,
in_powerY_shunt_resistor and in_engergyY_shunt_resitor.

The pac1934 device could be viewed like 4 devices that have only one
measurement hardware. Changing the shunt for a hardware channel will
impact multiple software measurements for that particular channel.

For example "sampling_frequency" is only one property per device and
not one property per channel.

Also I'm not felling comfortable to remove the [dir_] from the name,
because this value is dependent of the hardware and we can't have a
"available" properties for it.



> * I would go for a simple and generic description such as:
> "The value of current sense resistor in Ohms." like it is in
> Documentation/devicetree/bindings/hwmon/hwmon-common.yaml. Should it
> include
> any additional detail?
> 
> * I am assuming the generalized API would have Date and KernelVersion
> of
> today even though the original attributes are older.
> 
> * Should this ABI be inserted at any particular place of
> Documentation/ABI/testing/sysfs-bus-iio or just appended at its end?
> 
> Thanks,
> Matteo
> 


  reply	other threads:[~2024-07-16 11:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-04 17:42 [PATCH v2 0/2] iio: adc: add support for pac1921 Matteo Martelli
2024-07-04 17:42 ` [PATCH v2 1/2] dt-bindings: iio: adc: add binding " Matteo Martelli
2024-07-09 16:05   ` Rob Herring (Arm)
2024-07-04 17:42 ` [PATCH v2 2/2] iio: adc: add support " Matteo Martelli
2024-07-07 15:04   ` Jonathan Cameron
2024-07-08 13:39     ` Matteo Martelli
2024-07-08 16:34       ` Jonathan Cameron
2024-07-09  8:21         ` Matteo Martelli
2024-07-10 15:25           ` Marius.Cristea
2024-07-13 10:21           ` Jonathan Cameron
2024-07-16  9:20             ` Matteo Martelli
2024-07-16 11:19               ` Marius.Cristea [this message]
2024-07-16 17:00                 ` Jonathan Cameron
2024-07-17 14:22                   ` Matteo Martelli
2024-07-20  9:48                     ` Jonathan Cameron
2024-07-10 16:01       ` Marius.Cristea
2024-07-11  7:08         ` Matteo Martelli
2024-07-12 14:41           ` Marius.Cristea
2024-07-12 17:02             ` Conor Dooley
2024-07-13 10:36               ` Jonathan Cameron

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=483de34b3a74a2981fac89a8232e3ef2448f57ef.camel@microchip.com \
    --to=marius.cristea@microchip.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=conor+dt@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=matteomartelli3@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.