Ticket #2145 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Debian: Reading of accelerometers broken

Reported by: Defiant Owned by: hardware
Priority: normal Milestone:
Component: hardware Version: unspecified
Severity: normal Keywords: debian event2 event3
Cc: erik@…, simon.kagstrom@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible: always

Description

Running Debian with Kernel 2.6.24-20081103.git7172ec57-1 I have the following problem reading the accelerometers.

-when the device is lying still /dev/input/event2 and 3 is producing output
-as soon as the is moved event2 & 3 are no longer producing any output.
-when the device is lying still again the device is producing output again.

I tested it with a simple
hexdump /dev/input/event2

Some people on #openmoko-debian were able to reproduce this bug.

This problem doesn't occur running the Om2008.9 kernel.

Change History

comment:1 Changed 5 years ago by andy

  • Cc simon.kagstrom@… added

It sounds a great deal like the wrong "polarity" of threshold interrupt is being selected, ie, interrupt when it's LESS than the threshold rather than more. lis302dl supports both "polarities".

cc-ing Simon Kagstrom since he wrote the threshold stuff.

comment:2 Changed 5 years ago by SimonKagstrom

I checked the source code and it looks correct. In enable_data_collection, we do this when enabling the data collection with a threshold:

reg_write(lis, LIS302DL_REG_FF_WU_CFG_1,

LIS302DL_FFWUCFG_XHIE | LIS302DL_FFWUCFG_YHIE |
LIS302DL_FFWUCFG_ZHIE);

So it should be "high" events. I also tested on my freerunner on stable-tracking, and for me it appears to work fine (although it's input devices 3 and 4 here). It's quiet when flat on the table, but as I pick it up, data starts flowing.

I set the threshold to 100.

Simon

comment:3 Changed 5 years ago by andy

Thanks for looking at it Simon, I guess a big difference is that Debian is still on some variant of stable branch.

Defiant, have a try of the same thing with the kernel you can find in http://people.openmoko.org/andy the one with andy-tracking in the name, see if it changes the behaviour. These are from today and quite similar to what Simon is testing with.

comment:4 Changed 5 years ago by Defiant

I tried the kernel from the 18th November and it looks it fixes the problem.

comment:5 Changed 5 years ago by andy

We can close this bug then?

comment:6 Changed 5 years ago by Defiant

Yes - thanks.

comment:7 Changed 5 years ago by andy

  • Status changed from new to closed
  • Resolution set to fixed

Great, thanks for the report and the resoluton.

comment:8 Changed 5 years ago by chgros

2008.12 appears to be affected by that bug.

comment:9 Changed 5 years ago by DigitalPioneer

I've got this in latest SHR (image uploaded to server on Dec 14 2008).

comment:10 Changed 5 years ago by SimonKagstrom

Personally I think it would be good if the distributions would move to andy-tracking, or at least start preparing for it. Apparently it fixes this issue. (Although I honestly cannot see what should be wrong in the 2.6.24 branch of the accelerometer code).

comment:11 Changed 5 years ago by Yorick

I have the same problem in SHR

comment:12 Changed 5 years ago by andy

Simon is there are sysfs we can get people to dump in order to see the interrupt source register state directly? If there isn't maybe you can just knock up a quick debug patch and I will apply it to the 2.6.24 tree.

In the meanwhile if somebody with the problem can try an andy-tracking kernel from http://people.openmoko.org/andy and confirm it's OK there that can give us a way forward too.

comment:13 Changed 5 years ago by Johannes

uImage-moredrivers-GTA02_andy-tracking_e142549d884a17b8.bin 18-Dec-2008 20:22 2.4M

has the problem, so using ...andy-tracking is NOT the solution per se.

Is there another kernel from 18th November as mentioned by Defiant? I would try that too, if it were available.

comment:14 Changed 5 years ago by Johannes

Not sure if this helps:

printing interrupt counts for lis302dl from /proc/interrupts does not change with movement of device but with reading from /dev/input/event3.

Running the script below it does not matter if the device is laying on the table or shaken like hell during the 10s pause, interrupt counts are increasing at the same slow rate of 2 counts per 10s.

debian-gta02:~# while [ 1 == 1 ] ; do dd if=/dev/input/event3 bs=16 count=6 > /dev/null ; cat /proc/interrupts |grep lis302dl ; sleep 10 ; done
6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.030005 s, 3.2 kB/s

16: 521 s3c-ext0 lis302dl
60: 19262 s3c-ext lis302dl

6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.036205 s, 2.7 kB/s

16: 521 s3c-ext0 lis302dl
60: 19264 s3c-ext lis302dl

6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.029541 s, 3.2 kB/s

16: 521 s3c-ext0 lis302dl
60: 19266 s3c-ext lis302dl

comment:15 Changed 5 years ago by DigitalPioneer

Using andy-tracking: uImage-moredrivers-GTA02_andy-tracking_e142549d884a17b8.bin
Getting a steady hexdump from both accelerometers regardless of whether the phone is moving or not. :)

comment:16 Changed 5 years ago by SimonKagstrom

There is a dump sysfs entry, that should give all registers of the device. I had a debug patch a while which offered more fine-granular access to the registers, but I don't think that's really needed in this case. It could, as always, be good to check the values of threshold etc.

I don't think there is any changes to the accelerometer code the last couple of weeks, so it's strange if it suddenly broke now. However, is this really the same issue? The original bug report suggest that the device produces values in the opposite way than it's supposed to - producing data while being still and not when being shaken.

The new reports seem to be a general low amount of traffic. Do the ruby/python scripts on

http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval

seem to output reasonable data at least?

Simon

comment:17 Changed 5 years ago by DigitalPioneer

For me, I only got data when the phone was still, from hexdump or they perl script on that page.

The andy-tracking kernel fixed the issue, but when I rotated the screen, it screwed something up and display went white with lines of yellow, gray, black.. across it. Not even x restart fixed it, had to reboot. I changed kernels again.

comment:18 Changed 5 years ago by Johannes

Running the ruby script from Accelerometer_data_retrieval produces this output (device is not moved, laying on the table).

   90   -36   954   958
   90   -36   972   976
   90   -36   954   958
   90   -36   954   958
   90   -36   954   958
   90   -36   954   958
   90   -36   972   976

Interrupt counts measured at the same time is giving this.

debian-gta02:~# while [ 1 == 1 ] ; do cat /proc/interrupts |grep lis302dl ; sleep 10 ; done
 16:        521    s3c-ext0  lis302dl
 60:      38414     s3c-ext  lis302dl
 16:        521    s3c-ext0  lis302dl
 60:      39456     s3c-ext  lis302dl
 16:        521    s3c-ext0  lis302dl
 60:      40503     s3c-ext  lis302dl

So constanly reading from /dev/input/event3 produces approx. 100 interrupts per 1s.

Also I modified the ruby script to select before reading, this does not change the behaviour at all. Again this looks like reading from /dev/input/event3 is triggering the interrupt.

...
File.open("/dev/input/event3") do |f|
  while true
    select([f],nil,nil,nil)
    event = f.read(16).unpack("llSSl")
...

comment:19 Changed 5 years ago by SimonKagstrom

A general comment first: Thanks to all for the testing and experiments, the messages here have been very clear and to the point!

Johannes: 100 interrupts per second sounds right when the threshold is 0 (so that new datums is signalled by the interrupt) - the data rate is set to 100Hz by default. With threshold 0, the interrupt rate should not change depending on if the device is shaken or not - it always interrupts at each datum in that case.

As for your earlier test: The interrupt is only enabled when the device file is opened - so if I understand that test correct, you are closing the device during the sleep and in that case the interrupt stream should stop.

DigitalPioneer?: Your first problem certainly sounds like the original issue, but as for the screen corruption I have no idea :-). To me it sounds like a more general problem. Andy: Could it have something to do with the "manual" bitbang used by the accelerometer code? (I'm thinking if it can somehow interfer with the Glamo).

comment:20 Changed 5 years ago by SimonKagstrom

I should also add that I've tried the accelerometers with uImage-moredrivers-GTA02_andy-tracking_e142549d884a17b8.bin, and everything seem to work fine for me. I ran the python test script from the wiki page with and without thresholds, and the device reacts as expected. I've not seen any "display crash" (although E crashed a few times during the test, but I see that always :-) ).

I'm using Om2008.12.

comment:21 Changed 5 years ago by Defiant

I had the display problem after waking up from suspend the current andy
tracking.
Also with the andy tracking powering bluetooth on/off is not visible in
dbus (probably because of an other dbus path, not sure)

comment:22 Changed 5 years ago by Johannes

I just tried Om2008.12-om-gta02.uImage.bin and can now see what the original reporter has observed.

Running the ruby script from Accelerometer_data_retrieval produces constant flow of data while the device is laying on the table. When I pick it up and start shaking it then the script stops outputting data. Display of interrupt count on second console now looks like this.

     1  debian-gta02:~# while [ 1 == 1 ] ; do cat /proc/interrupts | grep lis302dl ; sleep 10 ; done
     2   16:        124    s3c-ext0  lis302dl
     3   60:       2866     s3c-ext  lis302dl
     4   16:        124    s3c-ext0  lis302dl
     5   60:       3060     s3c-ext  lis302dl
     6   16:        124    s3c-ext0  lis302dl
 >>> 7   60:       3245     s3c-ext  lis302dl
     8   16:        124    s3c-ext0  lis302dl
 >>> 9   60:       3254     s3c-ext  lis302dl
    10   16:        124    s3c-ext0  lis302dl
    11   60:       3259     s3c-ext  lis302dl
    12   16:        124    s3c-ext0  lis302dl
    13   60:       3449     s3c-ext  lis302dl

Shaking took place between line 7 and line 9 above, there are only very few interrupts counted although the file is permanently open.

I must say that I'm confused now. Is this by design and expected behaviour?

comment:23 Changed 5 years ago by Defiant

Sorry, but no data from the acceleration sensor while the device is accelerated as expected behaviour?

comment:24 Changed 5 years ago by SimonKagstrom

No, that was a bug (although I can't really say what caused it). 2.6.24 has this behavior, but newer kernels have fixed it.

comment:25 Changed 5 years ago by DigitalPioneer

OK, this is weird. I had both accelerometers suffering from this bug. After playing with echoing values to /sys/devices/platform/lis302dl.(1 or 2)/full_scale (valid values appear to be 9.2 , or anything else which evaluates to 2.3) both acceleromters are now working correctly. How's that work? :\

Note: See TracTickets for help on using tickets.