Openmoko Bug #2366: Missing accelerometer events

[Openmoko Public Trac]

#2366: Missing accelerometer events
---------------------+------------------------------------------------------
 Reporter:  mkburza  |          Owner:  openmoko-kernel     
     Type:  defect   |         Status:  new                 
 Priority:  highest  |      Milestone:  stable-kernel-2009.1
Component:  kernel   |        Version:  unspecified         
 Severity:  normal   |       Keywords:                      
 Haspatch:  0        |      Blockedby:                      
Estimated:           |    Patchreview:                      
 Blocking:           |   Reproducible:                      
---------------------+------------------------------------------------------
 I am using following version of the software:
 http://build.shr-project.org/shr-unstable/images/om-gta02/shr-full-eglibc-
 ipk--20100828-om-gta02.rootfs.jffs2
 http://build.shr-project.org/shr-unstable/images/om-
 gta02/uImage-2.6.32.21-oe3.3+gitr6+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0
 -om-gta02.bin

 I read accelerometer events with following C program:

 #include <stdio.h>
 #include <sys/select.h>
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/ioctl.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <stdlib.h>
 #include <time.h>
 #include <linux/input.h>
 #include <signal.h>
 #include <string.h>
 #include <errno.h>
 #include <assert.h>
 #include <sys/times.h>

 int read_all(int fd, char *buffer, int count){

     int got = 0;
     while(got != count) {

         int result = read(fd, buffer + got, count - got);
         if(result > 0){

             got += result;

         }

     }
     return got;

 }

 int grab = 2;

 int main(int argc, char *argv[]){

     int fd, i;
     struct input_event ev[128];

     if((fd = open("/dev/input/event3", O_RDONLY)) == -1){

         perror("Open");
         return 1;

     }
     int ioret = ioctl(fd, EVIOCGRAB, &grab); // Without this I also get
 missing events
     if(-1 == ioret){ // but I was hoping it would help

         perror("ioctl()"); //

     } //

     int got = read_all(fd, (char*)ev, 128 * sizeof(struct input_event));
     close(fd);
     for(i = 0; i < 128; i++){

         printf("type:%u code:%u value:%d\n", ev[i].type, ev[i].code,
 ev[i].value);

     }
     return 0;

 }

 As you can see I first collect all the events and then I print them out to
 avoid any waiting time which would result in missing events.
 In principle if everything is fine I would expect such pattern on the
 output:
 type:3 code:0 value:[whateverX]
 type:3 code:1 value:[whateverY]
 type:3 code:2 value:[whateverZ]
 type:0 code:0 value:0

 Here is a fragment of real output:
 type:3 code:0 value:-284
 type:3 code:1 value:355
 type:3 code:2 value:497
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:1 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0

 As you can see the pattern of having three consecutive events reporting
 each of the axis followed by sync event is broken and often events for
 some x, y or z are missing.

 I checked how the program behaves if I collect the events for several
 minutes (it is the same with randomly missing events). I tried to increase
 the priority with nice to see if that helps (thinking that maybe the
 processor is too busy) - it didn't help. I checked the CPU usage - it does
 not go over 20% overall (15% for the process which reads the events).

 Here is the configuration of the accelerometer:
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/sample_rate:
 100
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/full_scale:
 9.2
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/threshold:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/duration:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/dump:
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b
 a8 95 01 13 13 01 06 82 01 e3 0e 58 00 00 00 00
 20 00 a4 00 00 00 00 00 00 01 00 00 00 0d 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_threshold:
 off
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_duration:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/overruns:
 1

 This was checked on several Freerunners and all of them behave the same.
 Please let me know if you need further data/config info/etc.

 Best regards,
 Mark

 PS: I reported this at first on SHR's trac but after they looked into it
 they asked me to post it here as it concerns the kernel.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2366>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac