[PATCH 3/3] fix-lis302dl-/ threshold behaviour

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Somebody in the thread at some point said:
|
| | I don't quite remember, but I think it was that the threshold is
| | checked relative to the last time the filter was reset, so if you don't
| | reset it you won't get any more data.  Unfortunately the data sheet is
| not
| | overly clear about how the HP filter is actually supposed to work.
| |
| | It caused a bit of headache when developing since the HP filter is
| | reset when reading. Thus, the device would generate data once again
| | when the debug sysfs node is read.
|
| I wonder if something else is broken behind that to do with the reports
| about inverted threshold sense we can't reproduce.

Well, with some more patches cleaning things up, I find the threshold
stuff acts strangely for me.

If I pick the device up after setting threshold 100, I get some samples
then nothing.  If I continuously shake the device, I get nothing until I
stop shaking it, then nothing again while I hold it still.

I wonder if this is the meaning of the "high pass filter" being on the
threshold path?

It's not what I would have expected from the threshold action, is this
what its performance has been like up until now?  I can see why people
may be reporting this behaviour as inverted if so.

When I disable the highpass on the path, a nonzero threshold crashes the
GTA02 dead, presumably because the level interrupt is stuck asserted for
some reason.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmITNsACgkQOjLpvpq7dMoDYgCghzeZjOM/+qshRUHg08hLDR6E
ftgAnjs9iMkYVN79gzarq+uNhj1tffQ+
=mvfG
-----END PGP SIGNATURE-----