Linux IIO development
 help / color / mirror / Atom feed
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-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Mutanen, Mikko" <Mikko.Mutanen@fi.rohmeurope.com>
Subject: Re: [PATCH 1/3] iio: core: add IIO_VAL_INT_MICRO
Date: Thu, 13 Apr 2023 08:48:08 +0300	[thread overview]
Message-ID: <6b0e2cd2-b419-8474-c53c-81449b8f6325@gmail.com> (raw)
In-Reply-To: <20230412213208.49912897@jic23-huawei>

Hi Jonathan,

On 4/12/23 23:32, Jonathan Cameron wrote:
> On Wed, 12 Apr 2023 15:27:14 +0300
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> There are a few cases like light sensor integration times, where values
>> returned from *_available() and read_raw() are smaller than 1 and often
>> in the units of micro. (Like micro second scale integration times,
>> always smaller than 1 second). Currently those are often handled using
>> IIO_VAL_INT_PLUS_MICRO, which requires drivers to initialize the integer
>> part to zero. Furthermore, using IIO_VAL_INT_PLUS_MICRO in iio lists
>> requires one to always allocate the 'dummy' integer part too.
>>
>> Introduce IIO_VAL_INT_MICRO which allows omitting the always zero integer.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Hi Matti,
> 
> I'm not keen on adding yet another case just to avoid having to
> have the integer part for IIO_VAL_INT_PLUS_MICRO.
> Seems like the wrong trade off of maintainability vs ease of use.

I see your point. I would still argue that adding the IIO_VAL_INT_MICRO 
was not really an intrusive change and I'd expect the maintenance effort 
should not be increased that much.

While the inconvenience for users in read_raw (initializing the *val = 
0) is minor (meaning the benefit of adding IIO_VAL_INT_MICRO is also 
minor in this regard), iio_lists are stronger reason to consider this. 
With IIO_VAL_INT_MICRO the iio-list memory footprint will be halved. In 
my opinion, this benefit would exceed the cost of maintenance effort 
increase - sure thing it's easy for me to say as I am not the maintainer 
;) (And as I wrote, this series was cooked in a hurry - I had no time to 
go through existing drivers to see how many could benefit from the new 
IIO_VAL_INT_MICRO. I may do this later when I get some pretty urgent 
things off my shoulders - assuming you're not opposing this change so 
strongly that this is out of the question no matter how many existing 
users could benefit from IIO_VAL_INT_MICRO).

Anyways, if this is your final stance, then I need to rework the 
integration time list allocations in the gts helper, but I am most 
likely not able to do this until a week or two from now - meaning it 
might be better to revert the bu27034 and iio-gts-helpers until this 
gets fixed. (I reserve the right to do this during some night if I can't 
get sleep though.)

Yours,
	-- Matti

> Jonathan
> 
>> ---
>>   drivers/iio/industrialio-core.c | 4 ++++
>>   include/linux/iio/types.h       | 1 +
>>   2 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
>> index c117f50d0cf3..c5ae965e9961 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -628,6 +628,8 @@ static ssize_t __iio_format_value(char *buf, size_t offset, unsigned int type,
>>   	switch (type) {
>>   	case IIO_VAL_INT:
>>   		return sysfs_emit_at(buf, offset, "%d", vals[0]);
>> +	case IIO_VAL_INT_MICRO:
>> +		return sysfs_emit_at(buf, offset, "0.%06u", vals[0]);
>>   	case IIO_VAL_INT_PLUS_MICRO_DB:
>>   		scale_db = true;
>>   		fallthrough;
>> @@ -758,6 +760,7 @@ static ssize_t iio_format_list(char *buf, const int *vals, int type, int length,
>>   
>>   	switch (type) {
>>   	case IIO_VAL_INT:
>> +	case IIO_VAL_INT_MICRO:
>>   		stride = 1;
>>   		break;
>>   	default:
>> @@ -952,6 +955,7 @@ static ssize_t iio_write_channel_info(struct device *dev,
>>   		case IIO_VAL_INT_PLUS_MICRO_DB:
>>   			scale_db = true;
>>   			fallthrough;
>> +		case IIO_VAL_INT_MICRO:
>>   		case IIO_VAL_INT_PLUS_MICRO:
>>   			fract_mult = 100000;
>>   			break;
>> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
>> index 82faa98c719a..b4e316172c7f 100644
>> --- a/include/linux/iio/types.h
>> +++ b/include/linux/iio/types.h
>> @@ -30,6 +30,7 @@ enum iio_event_info {
>>   #define IIO_VAL_FRACTIONAL 10
>>   #define IIO_VAL_FRACTIONAL_LOG2 11
>>   #define IIO_VAL_CHAR 12
>> +#define IIO_VAL_INT_MICRO 13 /* val is micro <units>. Integer part is 0 */
>>   
>>   enum iio_available_type {
>>   	IIO_AVAIL_LIST,
> 

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~


  reply	other threads:[~2023-04-13  5:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 12:26 [PATCH 0/3] iio: Fix integration time units for iio-gts Matti Vaittinen
2023-04-12 12:27 ` [PATCH 1/3] iio: core: add IIO_VAL_INT_MICRO Matti Vaittinen
2023-04-12 20:32   ` Jonathan Cameron
2023-04-13  5:48     ` Matti Vaittinen [this message]
2023-04-15 16:48       ` Jonathan Cameron
2023-04-12 12:28 ` [PATCH 2/3] iio: gts: fix units of available integration times Matti Vaittinen
2023-04-12 12:29 ` [PATCH 3/3] iio: bu27034: Fix integration time units 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=6b0e2cd2-b419-8474-c53c-81449b8f6325@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=Mikko.Mutanen@fi.rohmeurope.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