Linux IIO development
 help / color / mirror / Atom feed
From: Shardul Deshpande <iamsharduld@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>,
	Javier Carrasco <javier.carrasco.cruz@gmail.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Shardul Deshpande" <iamsharduld@gmail.com>
Subject: [PATCH v2] iio: light: veml6075: fix UV index reported at half value
Date: Sat, 27 Jun 2026 14:23:13 +0530	[thread overview]
Message-ID: <20260627085313.7507-1-iamsharduld@gmail.com> (raw)
In-Reply-To: <20260626110400.68885-1-iamsharduld@gmail.com>

veml6075_get_uvi_micro() normalises the UV index for the configured
integration time. The raw UVA/UVB counts scale linearly with the
integration time, so the responsivity-weighted sum must be divided by the
integration-time scale factor relative to the 50 ms base case (which is
returned undivided).

Per the VEML6075 datasheet the UV_IT field selects the integration time
as 50, 100, 200, 400 and 800 ms for field values 0..4, i.e.
(50 << int_index) ms: each step doubles the integration time and hence
the accumulated counts. The correct scale factor relative to the 50 ms
base is therefore 2^int_index == (1 << int_index). (See also the Vishay
application note "Designing the VEML6075 Into an Application" for the
UV-index responsivity calculation that these constants implement.)

The code instead divided by (2 << int_index) == 2^(int_index + 1), i.e.
twice the correct value, so the reported UV index was half of the true
value for every integration time except 50 ms. As the driver powers up
with VEML6075_IT_100_MS, the UV index was reported at half value out of
the box.

Divide by (1 << int_index) instead. int_index is already bounded to 0..4
by veml6075_read_int_time_index(), and (1 << 0) == 1 reproduces the
undivided 50 ms case, so the per-integration-time switch collapses to a
single expression.

Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Deshpande <iamsharduld@gmail.com>
---
Changes in v2:
- Collapse the per-integration-time switch into a single divide now that
  all cases share the same expression -- int_index is bounded to 0..4 by
  veml6075_read_int_time_index() and (1 << 0) reproduces the 50 ms case.
  (Javier Carrasco)
- Add VEML6075 datasheet (UV_IT integration-time table) and application-
  note references for the integration-time scaling in the changelog.

Link to v1:
https://lore.kernel.org/linux-iio/20260626110400.68885-1-iamsharduld@gmail.com/

 drivers/iio/light/veml6075.c | 18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/light/veml6075.c b/drivers/iio/light/veml6075.c
index 59187244a..d0ec06eeb 100644
--- a/drivers/iio/light/veml6075.c
+++ b/drivers/iio/light/veml6075.c
@@ -237,17 +237,13 @@ static int veml6075_get_uvi_micro(struct veml6075_data *data, int uva_comp,
 	if (int_index < 0)
 		return int_index;
 
-	switch (int_index) {
-	case VEML6075_IT_50_MS:
-		return uvia_micro + uvib_micro;
-	case VEML6075_IT_100_MS:
-	case VEML6075_IT_200_MS:
-	case VEML6075_IT_400_MS:
-	case VEML6075_IT_800_MS:
-		return (uvia_micro + uvib_micro) / (2 << int_index);
-	default:
-		return -EINVAL;
-	}
+	/*
+	 * The raw counts scale linearly with the integration time, which
+	 * doubles at each step (50, 100, 200, 400, 800 ms == 50 << int_index
+	 * ms; int_index is bounded to 0..4 above). Normalise to the 50 ms
+	 * base by dividing by 2^int_index; (1 << 0) == 1 leaves 50 ms as-is.
+	 */
+	return (uvia_micro + uvib_micro) / (1 << int_index);
 }
 
 static int veml6075_read_uvi(struct veml6075_data *data, int *val, int *val2)
-- 
2.50.1 (Apple Git-155)


  parent reply	other threads:[~2026-06-27  8:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 11:04 [PATCH] iio: light: veml6075: fix UV index reported at half value Shardul Deshpande
2026-06-26 12:21 ` Andy Shevchenko
2026-06-26 13:39 ` Javier Carrasco
2026-06-27  8:53 ` Shardul Deshpande [this message]
2026-06-27  9:14   ` [PATCH v2] " Javier Carrasco

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=20260627085313.7507-1-iamsharduld@gmail.com \
    --to=iamsharduld@gmail.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=javier.carrasco.cruz@gmail.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.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