RE: [PATCH] iio: light: STK3310: un-invert proximity values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx]
> Sent: Sunday, June 21, 2015 1:06 PM
> To: Breana, Tiberiu A; linux-iio@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] iio: light: STK3310: un-invert proximity values
> 
> On 17/06/15 12:09, Tiberiu Breana wrote:
> > In accordance with the recent ABI changes, STK3310's proximity
> > readings should be un-inversed in order to return low values for
> > far-away objects and high values for close ones.
> >

<snip>

> > -/*
> > - * Maximum PS values with regard to scale. Used to export the 'inverse'
> > - * PS value (high values for far objects, low values for near objects).
> > - */
> > +
> > +/* Estimate maximum proximity values with regard to measurement
> > +scale. */
> >  static const int stk3310_ps_max[4] = {
> > -	STK3310_PS_MAX_VAL / 64,
> > -	STK3310_PS_MAX_VAL / 16,
> > -	STK3310_PS_MAX_VAL /  4,
> > -	STK3310_PS_MAX_VAL,
> > +	STK3310_PS_MAX_VAL / 640,
> > +	STK3310_PS_MAX_VAL / 160,
> > +	STK3310_PS_MAX_VAL /  40,
> > +	STK3310_PS_MAX_VAL /  10
> >  };
> What's this change about?  All uses of this array as present in this patch have
> been removed.  It is used elsewhere for parameter sanity checking, but I
> can't follow why it now needs to be divided by 10.

Indeed, these values are still used in _write_event for setting proximity interrupt
threshold values. Truth is, they should have been divided by 10 from the start,
but since all values were relative to the pre-defined maximum values, it didn't
really matter. I used the higher max values because the readings would
sometimes go over the expected range (when I press down on the sensor with
my thumb), so the proximity readings became negative. But that shouldn't happen
in the case of a real device, as the sensor is covered by at least a screen layer.

For the default scale of 0.1 real proximity readings max out at around 6500,
roughly a tenth of the maximum theoretical value, as expected. Now that we're
using un-inverted measurements, we can't use the same reference values as
before - e.g. if the real maximum value is 6500, we can't allow setting a threshold
of 30000 - it will never be reached.
If you think this change warrants a separate patch, I'll split it.

Regards,
Tiberiu--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux