Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1477253 > unrolled thread

[PATCH] iio: light: acpi-als: Add a tuning parameter interface.

Started byEnric Balletbo i Serra <enric.balletbo@collabora.com>
First post2016-09-06 12:30 +0200
Last post2016-09-06 18:50 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] iio: light: acpi-als: Add a tuning parameter interface. Enric Balletbo i Serra <enric.balletbo@collabora.com> - 2016-09-06 12:30 +0200
    Re: [PATCH] iio: light: acpi-als: Add a tuning parameter interface. Lars-Peter Clausen <lars@metafoo.de> - 2016-09-06 12:40 +0200
      Re: [PATCH] iio: light: acpi-als: Add a tuning parameter interface. Enric Balletbo Serra <eballetbo@gmail.com> - 2016-09-06 18:50 +0200

#1477253 — [PATCH] iio: light: acpi-als: Add a tuning parameter interface.

FromEnric Balletbo i Serra <enric.balletbo@collabora.com>
Date2016-09-06 12:30 +0200
Subject[PATCH] iio: light: acpi-als: Add a tuning parameter interface.
Message-ID<selNE-MN-13@gated-at.bofh.it>
From: Bryan Freed <bfreed@chromium.org>

Add IIO_CHAN_INFO_CALIBSCALE to the channel to scale up or down
the raw measurements through the IIO framework.

Add IIO_CHAN_INFO_PROCESSED to provide the interface to read the
scaled measurements through the in_illuminance_input file.

Signed-off-by: Bryan Freed <bfreed@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 drivers/iio/light/acpi-als.c | 59 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 50 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/light/acpi-als.c b/drivers/iio/light/acpi-als.c
index f0b47c5..40837bc 100644
--- a/drivers/iio/light/acpi-als.c
+++ b/drivers/iio/light/acpi-als.c
@@ -56,7 +56,8 @@ static const struct iio_chan_spec acpi_als_channels[] = {
 		},
 		/* _RAW is here for backward ABI compatibility */
 		.info_mask_separate	= BIT(IIO_CHAN_INFO_RAW) |
-					  BIT(IIO_CHAN_INFO_PROCESSED),
+					  BIT(IIO_CHAN_INFO_PROCESSED) |
+					  BIT(IIO_CHAN_INFO_CALIBSCALE),
 	},
 };
 
@@ -76,6 +77,9 @@ struct acpi_als {
 	struct mutex		lock;
 
 	s32			evt_buffer[ACPI_ALS_EVT_BUFFER_SIZE];
+
+	uint			als_scale;
+	uint			als_uscale;
 };
 
 /*
@@ -154,25 +158,60 @@ static int acpi_als_read_raw(struct iio_dev *indio_dev,
 	s32 temp_val;
 	int ret;
 
-	if ((mask != IIO_CHAN_INFO_PROCESSED) && (mask != IIO_CHAN_INFO_RAW))
-		return -EINVAL;
-
 	/* we support only illumination (_ALI) so far. */
 	if (chan->type != IIO_LIGHT)
 		return -EINVAL;
 
-	ret = acpi_als_read_value(als, ACPI_ALS_ILLUMINANCE, &temp_val);
-	if (ret < 0)
-		return ret;
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = acpi_als_read_value(als, ACPI_ALS_ILLUMINANCE, &temp_val);
+		if (ret < 0)
+			return ret;
+		if (mask == IIO_CHAN_INFO_PROCESSED) {
+			/* use u64 to avoid overflow */
+			u64 ulux = (u64) temp_val * 1000000;
+
+			mutex_lock(&als->lock);
+			ulux = ulux * als->als_scale +
+			       div_u64(ulux * als->als_uscale, 1000000U);
+			mutex_unlock(&als->lock);
+			*val = div_u64(ulux, 1000000U);
+		} else {
+			*val = temp_val;
+		}
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_CALIBSCALE:
+		mutex_lock(&als->lock);
+		*val = als->als_scale;
+		*val2 = als->als_uscale;
+		mutex_unlock(&als->lock);
+		return IIO_VAL_INT_PLUS_MICRO;
+	default:
+		return -EINVAL;
+	}
+}
 
-	*val = temp_val;
+static int acpi_als_write_raw(struct iio_dev *iio,
+			      struct iio_chan_spec const *chan, int val,
+			      int val2, long mask)
+{
+	struct acpi_als *als = iio_priv(iio);
+
+	if (mask != IIO_CHAN_INFO_CALIBSCALE || chan->type != IIO_LIGHT)
+		return -EINVAL;
 
-	return IIO_VAL_INT;
+	mutex_lock(&als->lock);
+	als->als_scale = val;
+	als->als_uscale = val2;
+	mutex_unlock(&als->lock);
+	return 0;
 }
 
 static const struct iio_info acpi_als_info = {
 	.driver_module		= THIS_MODULE,
 	.read_raw		= acpi_als_read_raw,
+	.write_raw		= acpi_als_write_raw,
 };
 
 static int acpi_als_add(struct acpi_device *device)
@@ -189,6 +228,8 @@ static int acpi_als_add(struct acpi_device *device)
 
 	device->driver_data = indio_dev;
 	als->device = device;
+	als->als_scale = 1;
+	als->als_uscale = 0;
 	mutex_init(&als->lock);
 
 	indio_dev->name = ACPI_ALS_DEVICE_NAME;
-- 
2.1.0

[toc] | [next] | [standalone]


#1477265

FromLars-Peter Clausen <lars@metafoo.de>
Date2016-09-06 12:40 +0200
Message-ID<selXj-PI-21@gated-at.bofh.it>
In reply to#1477253
On 09/06/2016 12:25 PM, Enric Balletbo i Serra wrote:
> From: Bryan Freed <bfreed@chromium.org>
> 
> Add IIO_CHAN_INFO_CALIBSCALE to the channel to scale up or down
> the raw measurements through the IIO framework.
> 
> Add IIO_CHAN_INFO_PROCESSED to provide the interface to read the
> scaled measurements through the in_illuminance_input file.

What is the use-case for this, how is this interface supposed to be used?

[toc] | [prev] | [next] | [standalone]


#1477618

FromEnric Balletbo Serra <eballetbo@gmail.com>
Date2016-09-06 18:50 +0200
Message-ID<serJo-4tA-29@gated-at.bofh.it>
In reply to#1477265
Hi Lars,

2016-09-06 12:31 GMT+02:00 Lars-Peter Clausen <lars@metafoo.de>:
> On 09/06/2016 12:25 PM, Enric Balletbo i Serra wrote:
>> From: Bryan Freed <bfreed@chromium.org>
>>
>> Add IIO_CHAN_INFO_CALIBSCALE to the channel to scale up or down
>> the raw measurements through the IIO framework.
>>
>> Add IIO_CHAN_INFO_PROCESSED to provide the interface to read the
>> scaled measurements through the in_illuminance_input file.
>
> What is the use-case for this, how is this interface supposed to be used?

The idea behind this is be able to do a per-device calibration. The
use case we're thinking is:

 1. Read raw measurements from sensor in controlled environment (at
30, 500 and 1000 lux)
 2. do some math to calculate the calibration value.
 3. write the value to calibscale (in_illuminance_calibscale)
 4. read the calibrated measurement (in_illuminance_input)

Regards,
  Enric

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web