Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Vlad Dogaru <vlad.dogaru@intel.com>]

On Wed, Nov 19, 2014 at 03:57:38PM +0200, Vlad Dogaru wrote:
> On Tue, Nov 18, 2014 at 10:12:32PM +0000, Jonathan Cameron wrote:
> > On 18/11/14 22:02, Jonathan Cameron wrote:
> > > On 17/11/14 15:25, Peter Meerwald wrote:
> > >>
> > >>> The device does not estimate distance, it only outputs a single bit which
> > >>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
> > >>> sort of an uncalibrated distance.  From what I understand in the ABI
> > >>> specification, this is allowed.
> > >>
> > >> perhaps the input subsystem would be a better fit for this driver/device?
> > >> what is it typically used for?
> 
> We have this part listed under "proximity sensors", so I thought it
> belongs in iio.  We don't have a device that actually uses the SX9500,
> I'm using an evaluation board and an I2C bridge right now :)
> 
> > > Whilst it may be the case that this particular one might have a reasonable
> > > home in input, these are often integrated with ambient light sensors
> > > and as such we already have a quite a few proximity sensors in IIO...
> > > 
> > > Interestingly there is one obvious proximity sensor in input and that
> > > is a dual ambient light/ proximity part though I can't see any way
> > > of reading the light side of it.  Interesting...
> > Note that, given it describes itself as a button trip I can entirely see
> > your point with this one!  I wrote my reply before opening the datasheet.
> > oops.
> > 
> > The device does seem to provide access to measurements related to
> > the capacitance sensed so might be rather more flexible than just
> > a button though.
> 
> I kept away from the measurements because they look like uncalibrated
> information.  Then again, so is "0/1", as I mentioned initially.

To add to this:  the device senses proximity, not just touch.  I figured
it would be used in mobile devices, e.g. for shutting off the screen
when talking on the phone.  Moreover, Android supports proximity sensors
that only report "near/far" values.

> Would you find it acceptable to expose the raw measures through
> in_priximity0_raw, and keep the events as they are?  That way the raw
> readings can give some basic indication of distance, while still being
> able to use the events for near/far notification.