From: ChiYuan Huang <u0084500@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Lars-Peter Clausen <lars@metafoo.de>,
cy_huang <cy_huang@richtek.com>,
linux-iio <linux-iio@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v7 3/3] Documentation: ABI: testing: rtq6056: Update ABI docs
Date: Tue, 19 Jul 2022 14:12:21 +0800 [thread overview]
Message-ID: <CADiBU3_Nb4Rio3Z7L-907TB1Gvq6d5_GSP6Av5ZjHzhoDtcEZA@mail.gmail.com> (raw)
In-Reply-To: <20220718180441.1363d2a6@jic23-huawei>
Jonathan Cameron <jic23@kernel.org> 於 2022年7月19日 週二 凌晨12:54寫道:
>
> On Mon, 18 Jul 2022 13:46:03 +0800
> cy_huang <u0084500@gmail.com> wrote:
>
> > From: ChiYuan Huang <cy_huang@richtek.com>
> >
> > Add documentation for the usage of voltage channel integration time.
> >
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> > index d4ccc68..1f7d327 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -2030,3 +2030,13 @@ Description:
> > Available range for the forced calibration value, expressed as:
> >
> > - a range specified as "[min step max]"
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_integration_time
> > +KernelVersion: 5.20
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For voltage sensing hardware, there may be different time between
> > + channel conversion and sample update. 'Integration time' is used to
> > + specify the channel internal conversion time. And sample update
> > + interval is equal to average sample count multiple integration time.
> > + Unit as microsecond.
>
> Whilst I did suggest moving this to this file, I also suggested that it was the
> wrong interface to use. For similar cases we've used in_voltageY_sampling_frequency
> in the past because this isn't really an integration time, but rather a reflection of
> a bunch of other stuff that makes up the conversion time. In IIO we chose a long
> time ago to use 1/conversion_time as the exposed interface == sampling_frequency
>
> So, unless there is a strong reason to do otherwise, drop the overall sampling_frequency
> attribute and use per channel ones instead. Then update the main documentation
> to make this usecase clear. Something in the block
> https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-iio#L89
> like adding the in_voltageY_sampling_frequency entry to the What: list and a
> sentence at the end that says something like:
>
> "Some devices have separate controls of sampling frequency for individual channels.
> If multiple channels are enabled in a scan, then the sampling_frequency of the the
> scan may be computed from the per channel sampling_frequencies."
>
From my case, I need to specify
in_voltageX_sampling_frequency/in_powerY_sampling_frequency/
in_currentZ_sampling_frequency.
And describe all in the same sentence.
Can I directly copy the sentence that you described above?
I read the comment. The sentence that you wrote seems more generic.
If any misunderstanding, please correct me.
> Not something to put in the documentation, but for devices which do simultaneous sampling
> it is very unlikely we'll have per channel sampling frequencies so there isn't an
> ambiguity. The alternative we 'could' consider is to allow both overall sampling_frequency
> and per channel in_voltageY_sampling_frequency but that is a bad idea because the
> ABI (and most userspace software) assumes that more specific attributes override the
> values of more generic ones (rather than them having different meanings as would be
> the case here).
>
> Jonathan
next prev parent reply other threads:[~2022-07-19 6:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 5:46 [PATCH v7 0/3] Add Richtek RTQ6056 support cy_huang
2022-07-18 5:46 ` [PATCH v7 1/3] dt-bindings: iio: adc: Add rtq6056 adc support cy_huang
2022-07-18 5:46 ` [PATCH v7 2/3] iio: adc: Add rtq6056 support cy_huang
2022-07-18 17:08 ` Jonathan Cameron
2022-07-18 5:46 ` [PATCH v7 3/3] Documentation: ABI: testing: rtq6056: Update ABI docs cy_huang
2022-07-18 17:04 ` Jonathan Cameron
2022-07-19 6:12 ` ChiYuan Huang [this message]
2022-07-18 16:52 ` [PATCH v7 0/3] Add Richtek RTQ6056 support 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=CADiBU3_Nb4Rio3Z7L-907TB1Gvq6d5_GSP6Av5ZjHzhoDtcEZA@mail.gmail.com \
--to=u0084500@gmail.com \
--cc=cy_huang@richtek.com \
--cc=devicetree@vger.kernel.org \
--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=robh+dt@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).