supporting binary (near-far) proximity sensors over gpio

supporting binary (near-far) proximity sensors over gpio

[Sicelo]

Hi

Some phones have 1-bit proximity sensors, which simply toggle a GPIO
line to indicate that an object is near or far. Thresholds are set at
hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
the Nokia N900.

It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
code [2].

So the question is: should a new, general purpose iio-gpio driver be
written, that would switch such a proximity sensor to the iio framework?
Or evdev is really the best place to support it?

There are a couple of people who are willing to write such an iio
driver, if iio is the way to go.

Regards,
Sicelo

[1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
[2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111

Re: supporting binary (near-far) proximity sensors over gpio

[David Lechner]

On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
>
> Hi
>
> Some phones have 1-bit proximity sensors, which simply toggle a GPIO
> line to indicate that an object is near or far. Thresholds are set at
> hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
> the Nokia N900.
>
> It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
> code [2].
>
> So the question is: should a new, general purpose iio-gpio driver be
> written, that would switch such a proximity sensor to the iio framework?
> Or evdev is really the best place to support it?
>
> There are a couple of people who are willing to write such an iio
> driver, if iio is the way to go.
>
> Regards,
> Sicelo
>
> [1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> [2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
>
Since this is really a proximity switch (it is either on or off)
rather than measuring a proximity value over a continuous range, it
doesn't seem like a good fit for the iio subsystem. If the sensor is
on a phone, then it is likely to detect human presence so the input
subsystem does seem like the right one for that application.

More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html

Re: supporting binary (near-far) proximity sensors over gpio

[Jonathan Cameron]

On Sat, 18 Nov 2023 18:09:18 -0600
David Lechner <dlechner@baylibre.com> wrote:

> On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> >
> > Hi
> >
> > Some phones have 1-bit proximity sensors, which simply toggle a GPIO
> > line to indicate that an object is near or far. Thresholds are set at
> > hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
> > the Nokia N900.
> >
> > It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
> > code [2].
> >
> > So the question is: should a new, general purpose iio-gpio driver be
> > written, that would switch such a proximity sensor to the iio framework?
> > Or evdev is really the best place to support it?
> >
> > There are a couple of people who are willing to write such an iio
> > driver, if iio is the way to go.
> >
> > Regards,
> > Sicelo
> >
> > [1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > [2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> >  
> Since this is really a proximity switch (it is either on or off)
> rather than measuring a proximity value over a continuous range, it
> doesn't seem like a good fit for the iio subsystem. If the sensor is
> on a phone, then it is likely to detect human presence so the input
> subsystem does seem like the right one for that application.
> 
> More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> 
Agreed.  This one at least has a working distance of 30mm sensor, so
definitely switch type usecases where input tends to be the right choice.

If we wanted to use proximity range sensor for this usecase, we'd probably
bridge it to input (maybe in userspace, maybe in kernel) from the
underlying IIO driver.

Jonathan

Re: supporting binary (near-far) proximity sensors over gpio

[Sicelo]

Hi

On Mon, Nov 20, 2023 at 05:31:31PM +0000, Jonathan Cameron wrote:
> > Since this is really a proximity switch (it is either on or off)
> > rather than measuring a proximity value over a continuous range, it
> > doesn't seem like a good fit for the iio subsystem. If the sensor is
> > on a phone, then it is likely to detect human presence so the input
> > subsystem does seem like the right one for that application.
> > 
> > More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> > 
> Agreed.  This one at least has a working distance of 30mm sensor, so
> definitely switch type usecases where input tends to be the right choice.
> 
> If we wanted to use proximity range sensor for this usecase, we'd probably
> bridge it to input (maybe in userspace, maybe in kernel) from the
> underlying IIO driver.
> 
> Jonathan

Thank you so much for the input. It makes sense.

Sincerely
Sicelo

Re: supporting binary (near-far) proximity sensors over gpio

[Jeff LaBundy]

Hi Sicelo and David,

On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> >
> > Hi
> >
> > Some phones have 1-bit proximity sensors, which simply toggle a GPIO
> > line to indicate that an object is near or far. Thresholds are set at
> > hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
> > the Nokia N900.
> >
> > It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
> > code [2].
> >
> > So the question is: should a new, general purpose iio-gpio driver be
> > written, that would switch such a proximity sensor to the iio framework?
> > Or evdev is really the best place to support it?
> >
> > There are a couple of people who are willing to write such an iio
> > driver, if iio is the way to go.
> >
> > Regards,
> > Sicelo
> >
> > [1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > [2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> >
> Since this is really a proximity switch (it is either on or off)
> rather than measuring a proximity value over a continuous range, it
> doesn't seem like a good fit for the iio subsystem. If the sensor is
> on a phone, then it is likely to detect human presence so the input
> subsystem does seem like the right one for that application.
> 
> More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> 

I tend to agree; if there are only two discrete states as is the case for a
GPIO, then this is technically a switch and not a sensor. Therefore, input
seems like a better fit; that is just my $.02.

FWIW, a similar discussion came up a few years ago in [1] and again the key
differentiator was whether the output is discrete or continuous.

Kind regards,
Jeff LaBundy

[1] https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/

Re: supporting binary (near-far) proximity sensors over gpio

[Philipp Jungkamp]

Hi,

would it make sense to move the HID human presence driver at
drivers/iio/light/hid-sensor-prox.c to the input system then? This
driver only checks for the "Biometric" (0x2004b0) and "Biometric: Human
Presence" (0x2004b1) HID usages. The former has a vendor defined value
range, the latter is defined as a boolean switch. See the HID Usage
Tables, section 21.1 and 21.6.

I take from this discussion that the input subsystem would make more
sense for the "Biometric: Human Presence" usage.

I just wanted to chime in as there seems to be some older precedent for
a binary sensor in the iio subsystem. I tried to get that sensor
working for the proximity sensor on my laptop last year.

Regards,
Philipp Jungkamp

On Sat, 2023-11-25 at 22:33 -0600, Jeff LaBundy wrote:
> Hi Sicelo and David,
> 
> On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> > On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> > > 
> > > Hi
> > > 
> > > Some phones have 1-bit proximity sensors, which simply toggle a
> > > GPIO
> > > line to indicate that an object is near or far. Thresholds are
> > > set at
> > > hardware level. One such sensor is OSRAM SFH 7741 [1], which is
> > > used on
> > > the Nokia N900.
> > > 
> > > It is currently exported over evdev, emitting the
> > > SW_FRONT_PROXIMITY key
> > > code [2].
> > > 
> > > So the question is: should a new, general purpose iio-gpio driver
> > > be
> > > written, that would switch such a proximity sensor to the iio
> > > framework?
> > > Or evdev is really the best place to support it?
> > > 
> > > There are a couple of people who are willing to write such an iio
> > > driver, if iio is the way to go.
> > > 
> > > Regards,
> > > Sicelo
> > > 
> > > [1]
> > > https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > > [2]
> > > https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> > > 
> > Since this is really a proximity switch (it is either on or off)
> > rather than measuring a proximity value over a continuous range, it
> > doesn't seem like a good fit for the iio subsystem. If the sensor
> > is
> > on a phone, then it is likely to detect human presence so the input
> > subsystem does seem like the right one for that application.
> > 
> > More at
> > https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> > 
> 
> I tend to agree; if there are only two discrete states as is the case
> for a
> GPIO, then this is technically a switch and not a sensor. Therefore,
> input
> seems like a better fit; that is just my $.02.
> 
> FWIW, a similar discussion came up a few years ago in [1] and again
> the key
> differentiator was whether the output is discrete or continuous.
> 
> Kind regards,
> Jeff LaBundy
> 
> [1]
> https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
> 

Re: supporting binary (near-far) proximity sensors over gpio

[Jonathan Cameron]

On Sun, 26 Nov 2023 11:59:05 +0100
Philipp Jungkamp <p.jungkamp@gmx.net> wrote:

> Hi,
> 
> would it make sense to move the HID human presence driver at
> drivers/iio/light/hid-sensor-prox.c to the input system then? This
> driver only checks for the "Biometric" (0x2004b0) and "Biometric: Human
> Presence" (0x2004b1) HID usages. The former has a vendor defined value
> range, the latter is defined as a boolean switch. See the HID Usage
> Tables, section 21.1 and 21.6.

These boundaries always get messy.  Given there is a value range, it
might get used for something else.
> 
> I take from this discussion that the input subsystem would make more
> sense for the "Biometric: Human Presence" usage.

Potentially yes
> 
> I just wanted to chime in as there seems to be some older precedent for
> a binary sensor in the iio subsystem. I tried to get that sensor
> working for the proximity sensor on my laptop last year.

I guess this one landed because it looked much like the hid light sensors
and no one raised the question at the time (that I recall).

Probably not worth moving it, but we may well have suggested putting
it in input if we'd noticed at the time!

Jonathan

> 
> Regards,
> Philipp Jungkamp
> 
> On Sat, 2023-11-25 at 22:33 -0600, Jeff LaBundy wrote:
> > Hi Sicelo and David,
> > 
> > On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:  
> > > On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:  
> > > > 
> > > > Hi
> > > > 
> > > > Some phones have 1-bit proximity sensors, which simply toggle a
> > > > GPIO
> > > > line to indicate that an object is near or far. Thresholds are
> > > > set at
> > > > hardware level. One such sensor is OSRAM SFH 7741 [1], which is
> > > > used on
> > > > the Nokia N900.
> > > > 
> > > > It is currently exported over evdev, emitting the
> > > > SW_FRONT_PROXIMITY key
> > > > code [2].
> > > > 
> > > > So the question is: should a new, general purpose iio-gpio driver
> > > > be
> > > > written, that would switch such a proximity sensor to the iio
> > > > framework?
> > > > Or evdev is really the best place to support it?
> > > > 
> > > > There are a couple of people who are willing to write such an iio
> > > > driver, if iio is the way to go.
> > > > 
> > > > Regards,
> > > > Sicelo
> > > > 
> > > > [1]
> > > > https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > > > [2]
> > > > https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> > > >   
> > > Since this is really a proximity switch (it is either on or off)
> > > rather than measuring a proximity value over a continuous range, it
> > > doesn't seem like a good fit for the iio subsystem. If the sensor
> > > is
> > > on a phone, then it is likely to detect human presence so the input
> > > subsystem does seem like the right one for that application.
> > > 
> > > More at
> > > https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> > >   
> > 
> > I tend to agree; if there are only two discrete states as is the case
> > for a
> > GPIO, then this is technically a switch and not a sensor. Therefore,
> > input
> > seems like a better fit; that is just my $.02.
> > 
> > FWIW, a similar discussion came up a few years ago in [1] and again
> > the key
> > differentiator was whether the output is discrete or continuous.
> > 
> > Kind regards,
> > Jeff LaBundy
> > 
> > [1]
> > https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
> >   
>