[Workaround] lirc (IR) support

[s-kostyuk]

What it the correct way to enable support of IR receiver in the system? I.e. to enable support of irm-2638 receiver connected to GPIO2_A2 pin of RK3328

[s-kostyuk]

Updated for 4.4.167-1213-rockchip-ayufan-g34ae07687fce

---

So, for anyone who want to enable IR receiver on their devices (at least in 4.4 kernels): ~1. Download the current kernel source from https://github.com/ayufan-rock64/linux-kernel/releases~ ~2. Unpack the source, install all the needed tools for compilation~ ~3. run make menuconfig in the kernel's source directory, enable the GPIO IR receiver driver under "Device drivers" -> "Multimedia support" -> "Remote controller devices" -> "GPIO IR remote control"~ ~4. Compile the kernel and build an installation package if needed~ ~5. Install the new kernel and reboot~

6. Use dtoverlays OR proceed
7. Start dtedit from root
8. Add the new ir-receiver device tree section with the following content:

       ir-receiver {
               compatible = "gpio-ir-receiver";
               gpios = <0x48 2 1>;
       };

   where 0x48 is a handle for GPIO bank 2 and 2 is the number of pin in the bank (A2 == 2)

9. Reboot
10. Load the gpio_ir_recv and create a proper file in /etc/modules-load.d/ directory for auto-load if needed
11. Make sure that the module was successfully initialized (see image below)
12. Enjoy!

---

See also:

• How to build a kernel for Debian-based systems: https://wiki.debian.org/BuildADebianKernelPackage
• GPIO Port mappings: https://github.com/Leapo/Rock64-R64.GPIO/blob/master/docs/Rock64_GPIO_Reference.xlsx
• GPIO 2 bank has an 0x48 handle value, defined in gpio2@ff230000 section of device tree
• pin numbering formula for user-space (used in /sys/class/gpio) = (n_bank - 1) * 32 + (pin_letter * 8 + pin_digit)
• so in user-space programs you can use the following number: GPIO2_A2 = (2 - 1) * 32 + (A * 8 + 2) = 32 + (0 * 8 + 2) = pin 34 = 0x20
• IR driver source code: https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/rc/gpio-ir-recv.c
• Rock64 schematic with all connections depicted: http://files.pine64.org/doc/rock64/ROCK64_Schematic_v2.0_20171019.pdf

[s-kostyuk]

OK. Got a proper way to enable an IR receiver in device tree:

enable_dtoverlay gpio-ir-recv ir-receiver okay "gpios = <0x47 2 1>"

[s-kostyuk]

Additional info about device trees and overlays: https://www.raspberrypi.org/documentation/configuration/device-tree.md

[pfeerick]

So am I right in thinking that the main issue here is that the kernel hasn't been compiled with the necessary IR support? Meaning that if it were (compiled in as standard), it would just be a matter of turning on the right dt overlay if you want to use it?

[s-kostyuk]

So am I right in thinking that the main issue here is that the kernel hasn't been compiled with the necessary IR support? Meaning that if it were (compiled in as standard), it would just be a matter of turning on the right dt overlay if you want to use it?

As far as I remember - yes, you are right. The kernel must just to be built with ir-gpio support. Then the pin mappings may be set just with a proper dt overlay

[ayufan]

I think that we just miss proper dts entries

On Sat, 9 Mar 2019 at 19:57, Sergey Kostyuk notifications@github.com wrote:

So am I right in thinking that the main issue here is that the kernel hasn't been compiled with the necessary IR support? Meaning that if it were (compiled in as standard), it would just be a matter of turning on the right dt overlay if you want to use it?

As far as I remember - yes, you are right. The kernel must just to be built with ir-gpio support. Then the pin mappings may be set just with a proper dt overlay

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ayufan-rock64/linux-build/issues/225#issuecomment-471211668, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTpQZAJuX5FTCIqDgnNEEvHxTPcio_Yks5vVAQbgaJpZM4UuBJ6 .

[pfeerick]

I'm not so sure... I don't see any CONFIG_IR* or CONFIG_IR_GPIO_CIR in either the rockchip or mainline kernel configs... but I'll boot up a rock64 later to double check...

[KenH2000]

OK. Got a proper way to enable an IR receiver in device tree:

enable_dtoverlay gpio-ir-recv ir-receiver okay "gpios = <0x47 2 1>"

Did you mean gpios = "<0x48 2 1>" in the enable_dtoverlay command? I didn't notice the hex address was different until I failed at this command, and was successful with the dtedit method. Thank you for posting how to enable the IR.

[stefansundin]

Hey everyone. I am trying to enable the IR on RockPro64, but I need help with getting the device tree thing correct. I actually tried what was in this thread before I realized that this was for Rock64.

I found that they added it to the official linux git tree just a few months ago: https://github.com/torvalds/linux/commit/7c7f041309f73b05d21980f88f29305255e126ee

    ir-receiver {
        compatible = "gpio-ir-receiver";
        gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
        pinctrl-0 = <&ir_int>;
        pinctrl-names = "default";
    };

// ...

    ir {
        ir_int: ir-int {
            rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
        };
    };

But the &gpio0 label does not work with ayufan's release, and I do not know how to find the numeric value. And I am guessing that pinctrl-0 is optional (but what does it do?).

Instead of RK_PA6 I can use the value 6 (defined here), and instead of GPIO_ACTIVE_LOW I can use 1 (defined here). So now I just need to figure out what &gpio0 is. I don't think it is 0x48 as in Rock64, but I am not sure.

Then there's also the schematic which has IR_INT connected to P25 / GPIO0_A6/PWM3A_IR_d.

I am afraid to try values at random since I don't know if it can be risky or not. Please help me. Thank you!

[s-kostyuk]

Hello @stefansundin,

For the gpio handle I do not remember how exactly I determined the value. I think you can try running dtedit to view what is already present in the device tree and which handle is assigned to gpio0. Probably the handle is assigned when dts gets compiled because the source does not mention it: https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4.190/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L2256. I'm not positive about both rock64 and rockpro64 using the same handles because they are based on different SoCs.

Considering that the ayufan's distribution does not get any updates nowadays, I would rather look into ArchLinux ARM and Armbian. I'm personally planning to install ArchLinux on my Rock64 because it uses the latest software and the mainline kernel, but I'm not sure about whether it supports RockPro64.

[stefansundin]

Hi @s-kostyuk. Thank you for the reply.

That rk3399.dtsi file is interesting. I think this may be the answer:

        gpio0: gpio0@ff720000 {
            reg = <0x0 0xff720000 0x0 0x100>;

According to https://blog.modest-destiny.com/posts/linux-device-tree-pinctrl-tutorial/:

Here, let me explain about some magic numbers appearing in the device tree source.

1. gpio@48322000, reg = <0x48322000 0x1000>
   • The number 48322000 or 0x48322000 is the starting memory mapped address of GPIO5.

So if that is the case, then 0x0 may work instead of &gpio0. I may give it a try later.

I already tried official Debian (https://wiki.pine64.org/index.php/ROCKPro64_Software_Release#Official_Debian), but was disappointed that it didn't support video acceleration or wifi (at least I wasn't able to figure it out). ayufan's release does everything I want (besides IR, so far). There are some minor issues and the software is a bit dated, but it's the best option that I have tried so far.

[stefansundin]

I managed to figure it out. :)

I found this stackexchange answer which let me print the current device tree:

dtc -I fs /proc/device-tree > device-tree.txt

In there I found:

        gpio0@ff720000 {
            reg = <0x0 0xff720000 0x0 0x100>;
            interrupts = <0x0 0xe 0x4 0x0>;
            #gpio-cells = <0x2>;
            compatible = "rockchip,gpio-bank";
            clocks = <0x31 0x17>;
            #interrupt-cells = <0x2>;
            phandle = <0x3c>;
            interrupt-controller;
            gpio-controller;
        };

And the value I am looking for is phandle = <0x3c>;

Combine this with what I discovered earlier, this is what I added with sudo dtedit:

        ir-receiver {
                compatible = "gpio-ir-receiver";
                gpios = <0x3c 6 1>;
        };

I then rebooted and found this in dmesg:

[    9.243800] gpio_ir_recv ir-receiver: GPIO lookup for consumer (null)
[    9.243808] gpio_ir_recv ir-receiver: using device tree for GPIO lookup
[    9.243878] of_get_named_gpiod_flags: parsed 'gpios' property of node '/ir-receiver[0]' - status (0)
[    9.243926] Registered IR keymap rc-empty
[    9.243989] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[    9.244160] input: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0/input9
[    9.259007] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter

And I was able to use irrecord --device=/dev/lirc0 to record the remote that accompanies the sensor. Not sure if the remote config file is useful to anyone, but here it is: PINE64.lircd.conf.zip

The remote works but I have to learn more about lirc to get it to work the way I want.

I hope someone finds this post useful.