iio: Fix integration time units for iio-gts

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 <[email protected]>

---
 drivers/iio/industrialio-core.c | 4 ++++
 include/linux/iio/types.h       | 1 +
 2 files changed, 5 insertions(+)

drivers/iio/industrialio-core.c +4 -0

index c117f50d0cf3..c5ae965e9961 100644
@@ -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;

include/linux/iio/types.h +1 -0

index 82faa98c719a..b4e316172c7f 100644
@@ -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,

Quoted 8 lines · On Wed, 12 Apr 2023 15:27:14 +0300 Matti Vaittinen <[email protected]>…

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.

Quoted 3 lines

Introduce IIO_VAL_INT_MICRO which allows omitting the always zero integer.

Signed-off-by Matti Vaittinen <[email protected]>

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.

Jonathan

Quoted 46 lines

---
  drivers/iio/industrialio-core.c | 4 ++++
  include/linux/iio/types.h       | 1 +
  2 files changed, 5 insertions(+)

drivers/iio/industrialio-core.c +4 -0

index c117f50d0cf3..c5ae965e9961 100644
@@ -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;

include/linux/iio/types.h +1 -0

index 82faa98c719a..b4e316172c7f 100644
@@ -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,

Hi Jonathan,

Quoted 16 lines · Jonathan Cameron

Quoted 11 lines · On Wed, 12 Apr 2023 15:27:14 +0300 Matti Vaittinen <[email protected]>…

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 <[email protected]>

Hi Matti,

Quoted 3 lines

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

Quoted 49 lines

Jonathan

Quoted 46 lines

---
  drivers/iio/industrialio-core.c | 4 ++++
  include/linux/iio/types.h       | 1 +
  2 files changed, 5 insertions(+)

drivers/iio/industrialio-core.c +4 -0

index c117f50d0cf3..c5ae965e9961 100644
@@ -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;

include/linux/iio/types.h +1 -0

index 82faa98c719a..b4e316172c7f 100644
@@ -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,