From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Lars-Peter Clausen <lars@metafoo.de>,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v4 4/8] iio: light: Add gain-time-scale helpers
Date: Wed, 22 Mar 2023 11:10:16 +0200 [thread overview]
Message-ID: <4cbc8d6a-c8e0-68a0-e1a4-a552c3a968d7@gmail.com> (raw)
In-Reply-To: <5ba4ab3d-90ab-113e-1b95-86118d3a7392@gmail.com>
On 3/20/23 14:01, Matti Vaittinen wrote:
> On 3/19/23 20:08, Jonathan Cameron wrote:
>> On Fri, 17 Mar 2023 16:43:23 +0200
>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>
>> I think a bit more care is need with storage of time (unsigned) + decide
>> whether to allow for negative gains.
>
> My approach was just pretty simple "int is big enough for the times"
> (2000+ seconds when using usec as time units felt like more than enough
> for light sensors) and "gains are always positive".
>
> I have not tested the negative gains at all - but I agree this should've
> been documented. Currently there is no gts-helper users who need
> negative gain (or large times for that matter) - so I was not handling
> them.
>
> I'll try to check what it would mean code-wise if we converted times to
> unsigned. Negative times make no sense but allowing negative error
> values is a simple way to go.
>
> As for the negative gains - I have no problem of someone adding a
> support for those if needed, but I don't currently see much point in
> investing time in that...
>
>> Whilst they happen I'm not that bothered
>> if that subtlety becomes a device driver problem when calling this.
>> I'm not
>> sure I've seen a sensor that does both positive and negative gains for
>> a single
>> channel.
>
> I agree. If driver needs negative gains, then the driver needs to deal
> with it. I have no objections if driver authors want to improve these
> helpers by adding support for negative gains, but if they don't, then
> they have the exactly same problem they would have without these helpers :)
Back at this. I started reworking things to use unsigned times / gains
but I am not really happy about how it starts to look like. Using the
int values but reserving negative values to denote errors keeps things
cleaner. Also, I don't think we need the extra bit for extending the
range of supported values - It's hard for me to think we would really
need gains or times exceeding the maximum signed int. I think negative
gains are actually more likely so keeping int as type may help one who
wants to add support for negative gains.
(Although, I assume the integration time multiplying logic with negative
gains would not work in a same way as with positive gains - so
supporting negative gains would probably require more than that, or work
only as a dummy selector <=> gain converter without the time tables).
So, the v5 will likely still use int as type for times and gain but also
have a check in initialization enforcing this. I will also document this
restriction in the gain/time struct and init function documentation.
I don't think the v5 is final version, especially because it will be the
first version looping in the Kunit people. So we can keep iterating this
for v6 if you still feel using ints is unacceptable :)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
next prev parent reply other threads:[~2023-03-22 9:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 14:40 [PATCH v4 0/8] Support ROHM BU27034 ALS sensor Matti Vaittinen
2023-03-17 14:42 ` [PATCH v4 3/8] dt-bindings: iio: light: Support ROHM BU27034 Matti Vaittinen
2023-03-17 14:43 ` [PATCH v4 4/8] iio: light: Add gain-time-scale helpers Matti Vaittinen
2023-03-19 18:08 ` Jonathan Cameron
2023-03-20 12:01 ` Matti Vaittinen
2023-03-22 9:10 ` Matti Vaittinen [this message]
2023-03-25 18:29 ` Jonathan Cameron
2023-03-27 6:47 ` Vaittinen, Matti
2023-03-17 14:43 ` [PATCH v4 5/8] iio: test: test " Matti Vaittinen
2023-03-17 17:16 ` kernel test robot
2023-03-19 18:18 ` Jonathan Cameron
2023-03-17 14:44 ` [PATCH v4 7/8] iio: light: ROHM BU27034 Ambient Light Sensor Matti Vaittinen
2023-03-17 14:48 ` Matti Vaittinen
2023-03-19 18:29 ` Jonathan Cameron
2023-03-19 16:57 ` [PATCH v4 0/8] Support ROHM BU27034 ALS sensor Jonathan Cameron
2023-03-20 10:10 ` Matti Vaittinen
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=4cbc8d6a-c8e0-68a0-e1a4-a552c3a968d7@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.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 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).