-----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-----
