RE: tsl2x7x driver Sampling frequency

[Jon Brenner]

Jonathon,
So are you saying that I should change (remove) the sampling_frequency
ABI, and implement 2 new (to this driver) ABIs called:
in_intensity0_thresh_period, and in_proximity0_thresh_period?

Since the minimum H/W filter time (based on an minimum ALS or Prox
integration resolution) we're working with here is 2.7ms, and a maximum
filter time of  up to 162ms (60 out of range * 2.7), the value is
adjusted in milliseconds  (Khz).
Is this acceptable?

What about _thresh_period_available?

I guess I could simply use the simple computed value of [ X = Atime *
Integration] and display the values from minimum up to [60 * X] - but
that seems kind of silly.
Could simply a min and a max period be presented?

Caveat:  A or P integration times could be changed 'post' selection of
the _thresh_period which would of course then impact the _thresh_period.

Oh what a tangled web..

Jon

> -----Original Message-----
> From: Jonathan Cameron [mailto:jic23@xxxxxxxxx]
> Sent: Wednesday, April 04, 2012 12:20 PM
> To: Jon Brenner
> Cc: jic23@xxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx;
linux-kernel@xxxxxxxxxxxxxxx;
> dg77.kim@xxxxxxxxxxx
> Subject: Re: tsl2x7x driver Sampling frequency
> 
> On 04/04/2012 05:40 PM, Jon Brenner wrote:
> > Jonathon,
> >
> > You wrote;
> > <snip>
> > Units don't look right for sampling frequency.  Sorry, but that's an
> > abi
> >
> > issue so even if it is
> > fiddly to do the conversion to Hz it needs to be done.
> > </snip>
> >
> > Need some help here.
> > In the tsl2x7x driver sampling frequency is being used for setting
> > "persistence register".
> > It's actually a H/W filter.
> Gah, you mentioned this before and I meant to look back at the
previous times
> we have hit this particular type of control (it's pretty common!)
> 
> > Here is an abstract from the data sheet:
> > --
> > Persistence Register (0x0C)
> > The persistence register controls the filtering interrupt
capabilities
> > of the device. Configurable filtering is provided to allow
interrupts
> > to be generated after each ADC integration cycle or if the ADC
> > integration has produced a result that is outside of the values
> > specified by threshold register for some specified amount of time.
> > Separate filtering is provided for proximity and ALS functions. ALS
> > interrupts are generated using C0DATA.
> > --
> > The value provided here by the ABI is actually the number of
> > 'consecutive values out of range'.
> >
> > The H/W takes care of counting the consecutive values out of range
and
> > issues and interrupt when reached.
> >
> > The timing (or frequency) of these out of range values are based on
> > the ALS or Prox integration time (determined by that respective
setting).
> > That being the case a fixed table of sampling "frequencies" cannot
be
> > reasonably defined - as the frequency can vary widely, based on
other
> > settings.
> >
> > So the register really is set to the desired number of 'values out
of
> > range'.
> > To add another slight twist, the value (number of out of range)
> > increases by 1 until 5, then by 5 until 60 - with the caveat that a
> > value of 0 generates an interrupt every ALS or Prox integration
cycle .
> >
> > Since the sysfs-bus-iio doc contained a close match with respect to
> > the
> > operation:
> > Description:
> > 		Some devices have internal clocks.  This parameter sets
the
> > 		resulting sampling frequency.  In many devices this
> > 		parameter has an effect on input filters etc rather than
> > 		simply controlling when the input is sampled.  As this
> > 		effects datardy triggers, hardware buffers and the sysfs
> > 		direct access interfaces, it may be found in any of the
> > 		relevant directories.  If it effects all of the above
> > 		then it is to be found in the base device directory.
> >
> > Thus we used "sampling_frequency" - but now I am wondering if it
> > should be something else.
> >
> > If this is better suited for a different ABI please tell me what
that
> > would be.
> I'd argue this should really be sampling frequency anyway.  It's
actually a
> common enough thing to see.
> I was sure we'd hit this before and indeed we did with the
> tmd277711 driver back in 2010 (hit the mailing list archives for that
one).
> Dongguen Kim was the author (cc'd).  Actually grep shows that my own
sca3000
> driver has this too (it's been a while!)
> 
> It's actually made it through in the abi docs for all sorts of event
types though I
> think the only correct user is the sca3000 accelerometer.
> Description is...
> 	Period of time (in seconds) for which the condition must be
> 	met before an event is generated. If direction is not
> 	specified then this period applies to both directions.
> 
> I know it is annoying that this parameter in side the device is very
heavily
> dependent on other controls (often the case with this sort of
> thing) but to have a remotely consistent interface we have to define a
standard
> unit.  Hence the 'right' way to handle this is to have a cached value
in seconds
> and then work out the nearest possible setting when ever anything else
that
> effects it is changed. Fiddly, but we are playing this game all over
the place in
> other drivers.
> 
> So here you are going to have
> 
> in_intensity0_thresh_period and in_proximity0_thresh_period
> 
> Both probably taking values as INT_PLUS_MICRO.
> 
> Note that we have other filters controls for events such as hysterisis
which is
> common on raw adc's.
> 
> 
> Jonathan
> >
> > Please help!
> >
> > Jon
> > --
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/