Motion Sensor Status

[Andy Green]

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

Somebody in the thread at some point said:

Hi folks -

Here is an update:

 - The hardware seems to be okay as it is unless we see that I2C
corruption thing soon :-)

 - Software is basically working but there is an apparent software bug
with the interrupt action right now which makes the machine very slow
due to excessive SPI activity.

I sent the patches out anyway due to the interest in the problem.
They're also in the kernel git tree at http://git.openmoko.org.

>  - INT1 and INT2 signals on the LIS302DL really don't seem to act as the
> datasheet states: nobody has ever seen those pins either stop driving
> low or drive high even though we definitely follow the rules as
> described.  Tying them together as they are shouldn't make a problem.
> We need to contact ST FAE and ask them to explain the behaviour.

INT1 and INT2 work fine now at least with a "golden" register init.  I
think the actual problem was due to broken SPI bitbang only talking to
one motion sensor, by bad luck it was the one with the least accessible
INT pins.  So I think we have been staring at the non-initialized
device.  The other problem is that the CS signal is inaccessible on the
chips.

Anyway INT is working as an INT pin now.

>  - I found the bitbang / platform code still only chooses one chip
> select all the time, I got too tired to fix it today, it can be fixed
> one way or another

This is resolved with patch 1/3 I sent -- we are talking properly to
both now.

>  - The bitbang code even in the cutting-edge git kernels we are using
> does not seem to allow to change the synthetic clock rate for bitbang
> SPI, it seems to be fixed at 5us / clock despite the LIS302DL can handle
> 50 x faster and we just waste time and power spinning.  Again we can fix
> it one way or another.

>  - Due to the above right now a sample from one sensor is ~1.5ms and is
> done every 10ms (= 100Hz)... pretty insane but it can be reduced down to
> ~1/10th of that by speeding the bitbang clock as above.  Still noticeable.

This is a bit more complicated.  First the bitbang SPI clock is at 3us
period at the moment despite I asked for 100ns.

Once I had the INT pin working I hooked a scope probe on it so I could
watch it.  I saw the latency from assertion to deassertion after
servicing was hugely variable, >=1.5ms but sometimes 50ms or more and in
granular lumps rather than completely random.  This is caused by having
a scheduled handler take care of the SPI action after the interrupt, and
that is caused by the Linux SPI API apparently not working in interrupt
context :-O

I think this will improve when the excessive SPI bug is fixed, but it
still might not be very good to add 200 actions/sec through the scheduler.

Right now because the scheduling can exceed a 10ms latency, it means it
can miss interrupts easily.  That in turn meant that trying to use edge
triggered interrupts to fix the slowness bug only works for a little
while and then since it missed an edge stops generating interrupts.

>  - Raw data for X Y Z looks good from the one chip I can really talk to
> right now: it seems consistent and responds well to changing the
> attitude of the device

Both sensors give different and consistent results without any obvious
corruption on a casual examination over a few minutes.

If you want to look closer apply the patch and uncomment the printk on
line 283 on ./drivers/input/misc/lis302dl.c - you'll get a console spew
with X Y Z from the two sensors, the pointer at the start lets you tell
them apart relatively anyway.

>  - Harald had set up /dev/input/event<n> input subsystem stuff for
> bringing this to userspace, one per motion sensor chip.  I did a hexdump

See patch 3/3 comment for more on that.

>  - If the interrupts can't be fixed on the chips then we have to read
> from them asynchronously.  Luckily the chips have a samples-ready bit,

This has gone away, the INT signals work with the patches.

>  - If we don't see corruption from the I2C / SPI problem tomorrow we
> probably won't ever see it.  It's because the I2C side SDA is hooked to

I didn't see any corruption yet.


Going to try to solve the SPI load problem now.

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

iD8DBQFHmLBTOjLpvpq7dMoRAjOCAJ9BQqcj3q4t1iV0p/4/BMCFD0Q5UQCeNV+N
k9pQBkgDqo3v8Vs4cxOArVw=
=f+yp
-----END PGP SIGNATURE-----