[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <307f93f9-2a41-4704-ac4f-8d1e427e5060@tweaklogic.com>
Date: Mon, 6 Nov 2023 22:34:40 +1030
From: Subhajit Ghosh <subhajit.ghosh@...aklogic.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Matti Vaittinen <mazziesaccount@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Paul Gazzillo <paul@...zz.com>,
Matt Ranostay <matt@...ostay.sg>,
Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@...s.com>,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] iio: light: Add support for APDS9306 Light Sensor
On 6/11/23 21:43, Jonathan Cameron wrote:
> On Tue, 31 Oct 2023 19:08:08 +1030
> Subhajit Ghosh <subhajit.ghosh@...aklogic.com> wrote:
>
>>>
>>>> +static struct iio_event_spec apds9306_event_spec_als[] = {
>>>> + {
>>>> + .type = IIO_EV_TYPE_THRESH,
>>>> + .dir = IIO_EV_DIR_RISING,
>>>> + .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE),
>>>> + }, {
>>>> + .type = IIO_EV_TYPE_THRESH,
>>>> + .dir = IIO_EV_DIR_FALLING,
>>>> + .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE),
>>>> + }, {
>>>> + .type = IIO_EV_TYPE_THRESH,
>>>> + .mask_shared_by_all = BIT(IIO_EV_INFO_PERIOD),
>>>> + }, {
>>>> + .type = IIO_EV_TYPE_THRESH_ADAPTIVE,
>>>> + .mask_shared_by_all = BIT(IIO_EV_INFO_VALUE) |
>>>> + BIT(IIO_EV_INFO_ENABLE),
>>>> + }, {
>>>> + .type = IIO_EV_TYPE_THRESH,
>>>> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
>>> This matches an entry above for type. Don't have separate entries.
>>>> + },
>>>> +};
>>>> +
>>>> +static struct iio_event_spec apds9306_event_spec_clear[] = {
>>>> + {
>>>> + .type = IIO_EV_TYPE_THRESH,
>>>> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
>>>> + },
>>>> +};
>>>> +
>>>> +#define APDS9306_CHANNEL(_type) \
>>>> + .type = _type, \
>>>> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME) | \
>>>> + BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
>>>> + .info_mask_shared_by_all_available = BIT(IIO_CHAN_INFO_INT_TIME) | \
>>>> + BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
>>>
>>> Scale on the intensity channel is interesting... What are the units?
>>> There tend not to be any well defined units for intensity (as opposed
>>> to illuminance). There may be gain on the signal, but it won't be in untils
>>> that map directly to a scale userspace should apply. This is one of the
>>> rare reasons for using the HARDWARE_GAIN element of the ABI.
>>>
>>> A tricky corner however as relationship between raw value and hardwaregain
>>> is not tightly defined (as it can be really weird!)
>> Hi Jonathan,
>>
>> Thank you for taking time for reviewing and clearing all my tiny doubts and
>> queries especially for the dt and versioning part. Much appreciated.
>>
>> In the above case, should I not expose scale for the "clear" channel? Rather,
>> how should I expose the "clear" channel to userspace?
> What is the scale? What units to you get after applying it?
The scale is in Lux. The output after applying is Lux.
>
> I suspect it's not well defined.
>
> Not sure what we've done in similar cases in the past. Perhaps have
> a look at those. There may be precedence for still using scale.
Sure, I'll look it up.
>
> I'm about to jump on a long haul flight (delayed - sigh) so don't have
> time to look myself!
>
No worries. I will update notes and application in next version.
Have a good trip to where ever you are going. Are you coming to Australia
by any chance?
Thanks for the reply.
Regards,
Subhajit Ghosh
Powered by blists - more mailing lists