From: Jonathan Cameron <jic23@kernel.org>
To: Mikael Gonella-Bolduc via B4 Relay
<devnull+mgonellabolduc.dimonoff.com@kernel.org>
Cc: mgonellabolduc@dimonoff.com, Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Mikael Gonella-Bolduc <m.gonella.bolduc@gmail.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
Hugo Villeneuve <hvilleneuve@dimonoff.com>,
Matti Vaittinen <mazziesaccount@gmail.com>
Subject: Re: [PATCH v3 2/2] iio: light: Add APDS9160 ALS & Proximity sensor driver
Date: Thu, 19 Dec 2024 16:34:54 +0000 [thread overview]
Message-ID: <20241219163454.09daa116@jic23-huawei> (raw)
In-Reply-To: <20241216-apds9160-driver-v3-2-c29f6c670bdb@dimonoff.com>
On Mon, 16 Dec 2024 17:55:41 -0500
Mikael Gonella-Bolduc via B4 Relay <devnull+mgonellabolduc.dimonoff.com@kernel.org> wrote:
> From: Mikael Gonella-Bolduc <mgonellabolduc@dimonoff.com>
>
> APDS9160 is a combination of ALS and proximity sensors.
>
> This patch add supports for:
> - Intensity clear data and illuminance data
> - Proximity data
> - Gain control, rate control
> - Event thresholds
>
> Signed-off-by: Mikael Gonella-Bolduc <mgonellabolduc@dimonoff.com>
Hi Mikael,
A couple of questions on the calib* parts. I hadn't looked closely those
before and the datasheet is not very helpful!
Jonathan
> diff --git a/drivers/iio/light/apds9160.c b/drivers/iio/light/apds9160.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..0c93ab847d9a36aac7aa6a1893bba0fe819d9e28
> --- /dev/null
> +++ b/drivers/iio/light/apds9160.c
> +
> +/*
> + * The PS intelligent cancellation level register allows
> + * for an on-chip substraction of the ADC count caused by
> + * unwanted reflected light from PS ADC output.
As it's subtraction, why calibscale? Sounds more suitable to make this to calibbias.
> + */
> +static int apds9160_set_ps_cancellation_level(struct apds9160_chip *data,
> + int val)
> +{
> + int ret;
> + __le16 buf;
> +
> + if (val < 0 || val > 0xFFFF)
> + return -EINVAL;
> +
> + buf = cpu_to_le16(val);
> + ret = regmap_bulk_write(data->regmap, APDS9160_REG_PS_CAN_LEVEL_DIG_LSB,
> + &buf, 2);
> + if (ret)
> + return ret;
> +
> + data->ps_cancellation_level = val;
> +
> + return ret;
> +}
> +
> +/*
> + * This parameter determines the cancellation pulse duration
> + * in each of the PWM pulse. The cancellation is applied during the
> + * integration phase of the PS measurement.
> + * Duration is programmed in half clock cycles
> + * A duration value of 0 or 1 will not generate any cancellation pulse
Perhaps add some details on why this is a calibbias type control?
Whilst I can sort of grasp it might have a similar affect to a conventional
calibration bias by removing some offset, it's not totally obvious.
> + */
> +static int apds9160_set_ps_analog_cancellation(struct apds9160_chip *data,
> + int val)
> +{
> + int ret;
> +
> + if (val < 0 || val > 0x7F)
> + return -EINVAL;
> +
> + ret = regmap_write(data->regmap, APDS9160_REG_PS_CAN_LEVEL_ANA_DUR,
> + val);
> + if (ret)
> + return ret;
> +
> + data->ps_cancellation_analog = val;
> +
> + return ret;
> +}
> +
> +/*
> + * This parameter works in conjunction with the cancellation pulse duration
> + * The value determines the current used for crosstalk cancellation
> + * B4-B5: The coarse value defines cancellation current in steps of 60nA
> + * B0-B3: The fine value adjusts the cancellation current in steps of 2.4nA
Whilst I'm failing to actually understand what this is doing and maybe never will
we can make the interface more intuitive by not using the encoded value.
Just use a value in nA with both the val and val2 parts.
it is rather odd given 15 * 2.4 is only 36 so there are holes.. PRobably a case
for getting as close as you can to the requested value.
Calibration parameters aren't guaranteed to have a simple interpretation but
this current case is worse that it needs to be.
> + */
> +static int apds9160_set_ps_cancellation_current(struct apds9160_chip *data,
> + int val)
> +{
> + int ret;
> +
> + if (val < 0 || val > 0x3F)
> + return -EINVAL;
> +
> + ret = regmap_write(data->regmap, APDS9160_REG_PS_CAN_LEVEL_ANA_CURRENT,
> + val);
> + if (ret)
> + return ret;
> +
> + data->ps_cancellation_current = val;
> +
> + return ret;
> +}
> +/*
> + * Setting the integration time ajusts resolution, rate, scale and gain
> + */
Single line comment syntax is fine here. Also drop the extra spaces before
Setting.
> +static int apds9160_set_als_int_time(struct apds9160_chip *data, int val)
> +{
> + int ret;
> + int idx;
> +
> + ret = apds9160_set_als_rate(data, val);
> + if (ret)
> + return ret;
> +
> + /* Match resolution register with rate */
> + ret = apds9160_set_als_resolution(data, val);
> + if (ret)
> + return ret;
> +
> + data->als_itime = val;
> +
> + /* Set the scale minimum gain */
> + for (idx = 0; idx < ARRAY_SIZE(apds9160_als_scale_map); idx++) {
> + if (data->als_itime != apds9160_als_scale_map[idx].itime)
> + continue;
> +
> + return apds9160_set_als_scale(data,
> + apds9160_als_scale_map[idx].scale1,
> + apds9160_als_scale_map[idx].scale2);
> + }
> +
> + return -EINVAL;
> +}
>
> +
> +static int apds9160_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val,
> + int val2, long mask)
> +{
> + struct apds9160_chip *data = iio_priv(indio_dev);
> +
> + guard(mutex)(&data->lock);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_INT_TIME:
> + if (val2 != 0)
> + return -EINVAL;
> + switch (chan->type) {
> + case IIO_PROXIMITY:
> + return apds9160_set_ps_rate(data, val);
> + case IIO_LIGHT:
> + return apds9160_set_als_int_time(data, val);
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_PROXIMITY:
> + return apds9160_set_ps_gain(data, val);
> + case IIO_LIGHT:
> + return apds9160_set_als_scale(data, val, val2);
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_CALIBSCALE:
> + if (val2 != 0)
> + return -EINVAL;
> + switch (chan->type) {
> + case IIO_PROXIMITY:
> + return apds9160_set_ps_cancellation_level(data, val);
> + case IIO_CURRENT:
> + return apds9160_set_ps_cancellation_current(data, val);
I can't figure out what this one actually is.
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_CALIBBIAS:
> + if (val2 != 0)
> + return -EINVAL;
> + switch (chan->type) {
> + case IIO_PROXIMITY:
> + return apds9160_set_ps_analog_cancellation(data, val);
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_RAW:
> + if (val2 != 0)
> + return -EINVAL;
> + switch (chan->type) {
> + case IIO_CURRENT:
> + return apds9160_set_ps_current(data, val);
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
next prev parent reply other threads:[~2024-12-19 16:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 22:55 [PATCH v3 0/2] Add support for Avago/Broadcom APDS9160 Mikael Gonella-Bolduc via B4 Relay
2024-12-16 22:55 ` [PATCH v3 1/2] dt-bindings: iio: light: Add APDS9160 binding Mikael Gonella-Bolduc via B4 Relay
2024-12-17 18:31 ` [PATCH 2/9] dt-bindings: media: clarify stm32 csi & simplify example Conor Dooley
2024-12-19 15:32 ` Jonathan Cameron
2024-12-19 18:26 ` Conor Dooley
2024-12-16 22:55 ` [PATCH v3 2/2] iio: light: Add APDS9160 ALS & Proximity sensor driver Mikael Gonella-Bolduc via B4 Relay
2024-12-19 16:34 ` Jonathan Cameron [this message]
2024-12-19 19:22 ` Mikael Gonella-Bolduc
2024-12-20 19:06 ` Jonathan Cameron
2025-01-06 22:32 ` Mikael Gonella-Bolduc
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=20241219163454.09daa116@jic23-huawei \
--to=jic23@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=devnull+mgonellabolduc.dimonoff.com@kernel.org \
--cc=hvilleneuve@dimonoff.com \
--cc=justinstitt@google.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=m.gonella.bolduc@gmail.com \
--cc=mazziesaccount@gmail.com \
--cc=mgonellabolduc@dimonoff.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=robh@kernel.org \
/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