Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Paul Gazzillo <paul@pgazz.com>,
	Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v7 4/5] iio: light: ROHM BU27034 Ambient Light Sensor
Date: Sat, 8 Apr 2023 12:21:40 +0100	[thread overview]
Message-ID: <20230408122140.25332d15@jic23-huawei> (raw)
In-Reply-To: <2a7efb6f335da5526fbe34b95137c5e45db5c5d3.1680263956.git.mazziesaccount@gmail.com>

On Fri, 31 Mar 2023 15:41:58 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> ROHM BU27034 is an ambient light sensor with 3 channels and 3 photo diodes
> capable of detecting a very wide range of illuminance. Typical application
> is adjusting LCD and backlight power of TVs and mobile phones.
> 
> Add initial  support for the ROHM BU27034 ambient light sensor.
> 
> NOTE:
> 	- Driver exposes 4 channels. One IIO_LIGHT channel providing the
> 	  calculated lux values based on measured data from diodes #0 and
> 	  #1. In addition, 3 IIO_INTENSITY channels are emitting the raw
> 	  register data from all diodes for more intense user-space
> 	  computations.
> 	- Sensor has GAIN values that can be adjusted from 1x to 4096x.
> 	- Sensor has adjustible measurement times of 5, 55, 100, 200 and
> 	  400 mS. Driver does not support 5 mS which has special
> 	  limitations.
> 	- Driver exposes standard 'scale' adjustment which is
> 	  implemented by:
> 		1) Trying to adjust only the GAIN
> 		2) If GAIN adjustment alone can't provide requested
> 		   scale, adjusting both the time and the gain is
> 		   attempted.
> 	- Driver exposes writable INT_TIME property that can be used
> 	  for adjusting the measurement time. Time adjustment will also
> 	  cause the driver to try to adjust the GAIN so that the
> 	  overall scale is kept as close to the original as possible.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

A few trivial comments inline but nothing that stops me applying this version.

> 
> +static int bu27034_read_raw(struct iio_dev *idev,
> +			   struct iio_chan_spec const *chan,
> +			   int *val, int *val2, long mask)
> +{
> +	struct bu27034_data *data = iio_priv(idev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_INT_TIME:
> +		*val = bu27034_get_int_time(data);
> +		if (*val < 0)
> +			return *val;
> +
> +		return IIO_VAL_INT;
> +
> +	case IIO_CHAN_INFO_SCALE:
> +		return bu27034_get_scale(data, chan->channel, val, val2);
> +
> +	case IIO_CHAN_INFO_RAW:
> +	{
> +		int (*result_get)(struct bu27034_data *data, int chan, int *val);

I don't care that much about this, but the function pointer dance seems
unnecessary.

You could probably also drop the paranoid checking (or default to one of the
choices).

So at call sight of result_get() currently have
		if (chan->type == IIO_INTENSITY)
			ret = bu27034_get_single-result()...
		else
			ret = bu27034_get_mlux()

etc

meh. I didn't raise it earlier so I'll leave this alone.

> +
> +		if (chan->type == IIO_INTENSITY)
> +			result_get = bu27034_get_single_result;
> +		else if (chan->type == IIO_LIGHT)
> +			result_get = bu27034_get_mlux;
> +		else
> +			return -EINVAL;
> +
> +		/* Don't mess with measurement enabling while buffering */
> +		ret = iio_device_claim_direct_mode(idev);
> +		if (ret)
> +			return ret;
> +
> +		mutex_lock(&data->mutex);
> +		/*
> +		 * Reading one channel at a time is inefficient but we
> +		 * don't care here. Buffered version should be used if
> +		 * performance is an issue.
> +		 */
> +		ret = result_get(data, chan->channel, val);
> +
> +		mutex_unlock(&data->mutex);
> +		iio_device_release_direct_mode(idev);
> +
> +		if (ret)
> +			return ret;
> +
> +		return IIO_VAL_INT;
> +	}
> +	default:
> +		return -EINVAL;
> +
> +	}
> +}

I will fix the excess blank line above though.  Serves no purpose
so gone in the version I applied.

Thanks,

Jonathan



  reply	other threads:[~2023-04-08 11:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 12:40 [PATCH v7 0/5] Support ROHM BU27034 ALS sensor Matti Vaittinen
2023-03-31 12:40 ` [PATCH v7 1/5] iio: light: Add gain-time-scale helpers Matti Vaittinen
2023-03-31 12:41 ` [PATCH v7 2/5] MAINTAINERS: Add IIO " Matti Vaittinen
2023-04-01 17:58   ` Jonathan Cameron
2023-03-31 12:41 ` [PATCH v7 3/5] dt-bindings: iio: light: Support ROHM BU27034 Matti Vaittinen
2023-03-31 12:41 ` [PATCH v7 4/5] iio: light: ROHM BU27034 Ambient Light Sensor Matti Vaittinen
2023-04-08 11:21   ` Jonathan Cameron [this message]
2023-04-10 10:38     ` Matti Vaittinen
2023-04-12 11:55       ` Vaittinen, Matti
2023-03-31 12:42 ` [PATCH v7 5/5] MAINTAINERS: Add ROHM BU27034 Matti Vaittinen
2024-03-04 12:38 ` [PATCH v7 0/5] Support ROHM BU27034 ALS sensor Matti Vaittinen
2024-03-09 17:50   ` Jonathan Cameron
2024-03-11  9:15     ` 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=20230408122140.25332d15@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mazziesaccount@gmail.com \
    --cc=paul@pgazz.com \
    --cc=shreeya.patel@collabora.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