lirc_rpi module, possible bug in kernel > 3.6

[koromar]

Affected versions:
commit hashes newer than #8234d5148aded657760e9ecd622f324d140ae891

Details:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=62063

Sums it up best:
"by GeofP » Sun Feb 02, 2014 9:50 pm
...
My /etc/lirc/lircd.conf includes the following parameters:

........ pulse space

header 9590 4730
one 630 1755
zero 630 560
frequency was not defined but the default is 38KHz

The software version of the re-installed software is as follows:
Linux Geof-Pi-1 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 armv6l GNU/Linux

Measurements on the storage oscilloscope were as follows:
Header pulse = 9.7ms
frequency = 38KHz
These measurements show the timing for lirc is now correct.

Before the install of the mrgrey software version, my version was:
Linux Geof-Pi-1 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux

Measurements on the storage oscilloscope were as follows:
Header pulse = 8.2ms
frequency = 45KHz
These measurements show the timing for lirc is wrong. ..."

[GeofP]

I have checked the lirc timing problem on a number of versions of software.
These produce the correct timing: versions 3.6.11+ #363 through to 3.6.11+ #557 (the last in the 3.6.xx series I could find)
These produce the wrong timing: versions 3.10.13+ #555 through to 3.10.28+ #634 (latest release at time of writing).
The wrong timing is faster then the correct timing by about 15%

[popcornmix]

This driver was provided as a pull request, so I don't know much about it.
I can't think of any that we have changed that would affect timing, but there are many upstream commits between 3.6 and 3.10 kernels.

Can you confirm if the issue only affect transmission, or is there a problem with reception?

@ar0n @cleverca22 You were involved in the original driver - any suggestions?

[koromar]

Receiving works, but irrecord spit out a slightly different lircd.conf:

---

Linux host1 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 armv6l GNU/Linux

begin remote
  name OptSwitch
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9038  4443
  one           613  1632
  zero          613   510
  ptrail        612
  repeat       9038  2196
  pre_data_bits   16
  pre_data       0x61D6
  gap          107849
  toggle_bit_mask 0x0

      begin codes
          KEY_POWER                0x7887
          KEY_1                    0x40BF
          KEY_2                    0x609F
          KEY_3                    0x10EF
          KEY_4                    0x20DF
      end codes
end remote

---

Linux host2 3.10.28+ #634 PREEMPT Sun Feb 2 15:16:25 GMT 2014 armv6l GNU/Linux

begin remote
  name  OptSwitch
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9027  4452
  one           604  1642
  zero          604   519
  ptrail        600
  repeat       9030  2209
  pre_data_bits   16
  pre_data       0x61D6
  gap          107848
  toggle_bit_mask 0x0

      begin codes
          KEY_POWER                0x7887
          KEY_1                    0x40BF
          KEY_2                    0x609F
          KEY_3                    0x10EF
          KEY_4                    0x20DF
      end codes
end remote

[GeofP]

I performed the following experiment which confirms it is only a fault with the transmission. irrecord puts the correct parameters in the lircd.conf file for both 3.6.11 and 3.10.29. The timing produced in transmission is wrong in the 3.10.29 version. (which is the same as posted above, but I wanted to confirm the actual numbers and measurements.)

Starting with software version 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013

Using mode2 -d /dev/lirc0, recorded the pulses from the foxsat remote power button (key_power).

The header pulse was displayed as 8982
The header pulse measured 9.0ms on the oscilloscope (which is what is expected)

Using irrecord -d /dev/lirc0 ~/lircd.conf, recorded button presses from the humax remote
Output of irrecord as follows:

Found const length: 107290
Space/pulse encoded remote control found.
Signal length is 67.
Found possible header: 8981 4429
Found trail pulse: 589
Found repeat code: 8983 2214
Signals are space encoded.
Signal length is 32

The lircd.conf included the following line:
header 8981 4429

Changed the name in ~/lircd.conf to foxsat-hdr and copied the file to /etc/lirc

Started up lirc again with sudo /etc/init.d/lirc start
Ran the command irsend send_once foxsat-hdr key_power
A header pulse of 9.0ms was measured on the oscilloscope.

Performed a sudo rpi-update to:
3.10.29+ #636 PREEMPT Sun Feb 9 19:58:58 GMT 2014

Checked the header pulse
irsend send_once foxsat-hdr key_power
lirc ir header pulse measures 7.7ms, (before the rpi-update it had read 9.0ms)

Repeated the above experiment of learning the remote, making a new lircd.conf file and measuring the new header pulse.

Using mode2 -d /dev/lirc0, recorded the pulses from the foxsat remote power button (key_power).

The header pulse was displayed as 8980, (before was 8982, so effectivily the same)
The header pulse measured 9.0ms on the oscilloscope

Using irrecord -d /dev/lirc0 ~/lircd.conf, recorded button presses from the humax remote.
Output of irrecord as follows: (this was effectively the same as before)

Found const length: 107290
Space/pulse encoded remote control found.
Signal length is 67.
Found possible header: 8983 4427
Found trail pulse: 588
Found repeat code: 8985 2213
Signals are space encoded.
Signal length is 32

The lircd.conf included the following line: (this was effectively the same as before)
header 8983 4427

Ran the command irsend send_once foxsat-hdr key_power
A header pulse of 7.7ms was measured on the oscilloscope.

[ar0n]

I don't have the equipment to check this out now, but can somebody test it with this version: ar0n@69af0bf
This one directly writes the registers, so we can rule out a few things (but I think the problem is elsewhere). Thanks!

[GeofP]

I tried this a couple of weeks back and got a file not found error message.
My current software is : 3.10.29+ #636 PREEMPT Sun Feb 9 19:58:58 GMT 2014
Tried it again, this is the response:

sudo rpi-update 69af0bf
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
*** Performing self-update
--2014-02-17 07:45:09-- https://github.com/Hexxeh/rpi-update/raw/master/rpi-update
Resolving github.com (github.com)... 192.30.252.128
Connecting to github.com (github.com)|192.30.252.128|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.github.com/Hexxeh/rpi-update/master/rpi-update [following]
--2014-02-17 07:45:15-- https://raw.github.com/Hexxeh/rpi-update/master/rpi-update
Resolving raw.github.com (raw.github.com)... 185.31.18.133
Connecting to raw.github.com (raw.github.com)|185.31.18.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7174 (7.0K) [text/plain]
Saving to: `/usr/bin/rpi-update.tmp'

100%[======================================>] 7,174 --.-K/s in 0.02s

2014-02-17 07:45:20 (397 KB/s) - `/usr/bin/rpi-update.tmp' saved [7174/7174]

*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
*** ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
*** Downloading specific firmware revision (this will take a few minutes)
*** Decompressing downloaded firmware archive
--2014-02-17 07:45:20-- https://github.com/Hexxeh/rpi-firmware/tarball/69af0bf569f66fa3262f2b46e5e636742de48dcb
Resolving github.com (github.com)... 192.30.252.128
Connecting to github.com (github.com)|192.30.252.128|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-02-17 07:45:26 ERROR 404: Not Found.

[koromar]

finally set up a cross-compile toolchain to test the code aron mentioned. will post an update with my findings tonight.

[koromar]

@ar0n : doesn't work with ar0n@69af0bf

root@maggie:/etc/lirc> modinfo lirc_rpi
filename:       /lib/modules/3.10.30+/kernel/drivers/staging/media/lirc/lirc_rpi.ko
license:        GPL
author:         Aron Robert Szabo
description:    Infra-red receiver and blaster driver for Raspberry Pi GPIO.
srcversion:     EC5D51CA60B951B0F73222D
depends:        lirc_dev
staging:        Y
intree:         Y
vermagic:       3.10.30+ preempt mod_unload modversions ARMv6 p2v8
parm:           gpio_out_pin:GPIO output/transmitter pin number of the BCM processor. Valid pin number
s are: 0, 1, 4, 8, 7, 9, 10, 11, 14, 15, 17, 18, 21, 22, 23, 24, 25, default 17 (int)
parm:           gpio_in_pin:GPIO input pin number of the BCM processor. Valid pin numbers are: 0, 1, 4
, 8, 7, 9, 10, 11, 14, 15, 17, 18, 21, 22, 23, 24, 25, default 18 (int)
parm:           sense:Override autodetection of IR receiver circuit (0 = active high, 1 = active low )
 (bool)
parm:           softcarrier:Software carrier (0 = off, 1 = on, default on) (bool)

[jjmz]

I have the same kind of behavior with Raspbmc which is using a 3.10.24 kernel.
I am only using IR blasting, thus output only, and I have checked timing with a scope
When freq is 38khz, real output is almost 45Khz.
Timing off pulses is also shorter than expected (~480us instead of 533).
I came to the quick conclusion that it could be related to the overclocking factor (Raspbmc is using 800Mhz , whereas the regular RPi should run 700Mhz). Can someone confirm that ?

[GeofP]

I don't use Raspbmc and have not configured the Pi to be overclocked. Looking at my /boot/config.txt confirms the Pi is running at the default 700MHz. So, I think this not the cause of the problem.

[jjmz]

Ok, that's not the overclocking factor...

I made some tests replacing udelay (and rounding to nearest us) by ndelay in the code, and it seems to work pretty well

Here are the patched lines :

--- lirc_rpi.c-orig 2014-03-06 13:46:20.593073073 +0100
+++ lirc_rpi.c  2014-03-06 15:37:07.346448182 +0100
@@ -41,7 +41,7 @@

 #define LIRC_DRIVER_NAME "lirc_rpi"
 #define RBUF_LEN 256
-#define LIRC_TRANSMITTER_LATENCY 256
+#define LIRC_TRANSMITTER_LATENCY 20

 #ifndef MAX_UDELAY_MS
 #define MAX_UDELAY_US 5000
@@ -143,14 +143,13 @@
            gpiochip->set(gpiochip, gpio_out_pin, !invert);
            target += pulse_width;
        }
-       d = (target - actual -
-            LIRC_TRANSMITTER_LATENCY + 128) >> 8;
+       d = ((target - actual - LIRC_TRANSMITTER_LATENCY) * 1000)/256;
        /*
         * Note - we've checked in ioctl that the pulse/space
         * widths are big enough so that d is > 0
         */
-       udelay(d);
-       actual += (d << 8) + LIRC_TRANSMITTER_LATENCY;
+       ndelay(d);  /* ns instead of us */
+       actual += (d*256)/1000 + LIRC_TRANSMITTER_LATENCY;
        flag = !flag;
    }
    return (actual-length) >> 8;

[popcornmix]

@jjmz interesting. First can you just call ndelay(d * 1000) rather than udelay(d) just to rule out an issue with udelay not being accurate.
If it's just an issue with quantising to 1us resolution is introducing the error (measured at about 18%) that would suggest the delays being called are ~5us - are they really that short?
Can anyone else repeat their tests with this patch?

[koromar]

@jjmz :
I've patched the original version of 3.10.30+ I used to test ar0n@69af0bf with. So far receiving works but sending doesn't work at all. Not even the TV responded (and it did work in all kernel versions until now). I'll check my hardware-setup again now ..

[koromar]

replugged/rewired what was possible: now it's working with jjmz's patch. =)

[GeofP]

If someone could tell me how to do the "cross-compile toolchain" mentioned earlier by koromar, I will try to incorporate this patch and measure the timings on my system.