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

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

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