Gpio-ir module does not work #5235

nandlab · 2022-10-31T22:11:37Z

Describe the bug

Although I enabled the gpio-ir dtoverlay, I cannot see any lirc device like /dev/lirc0.

Steps to reproduce the behaviour

Uncomment the line dtoverlay=gpio-ir,gpio_pin=17 in /boot/config.txt.

Device (s)

Raspberry Pi 4 Mod. B

System

cat /etc/rpi-issue:

Raspberry Pi reference 2022-01-28
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f01430c9d8f67a4b9719cc00e74a2079d3834d5d, stage4

vcgencmd version:

Oct 26 2022 11:09:05 
Copyright (c) 2012 Broadcom
version c72ad6b26ff40c91ef776b847436094ee63fabee (clean) (release) (start)

uname -a:

Linux nextpi 5.15.74-v7l+ #1595 SMP Wed Oct 26 11:05:08 BST 2022 armv7l GNU/Linux

Logs

dmesg:

[    5.396569] pinctrl-bcm2835 fe200000.gpio: pin gpio17 already requested by fe200000.gpio; cannot claim for ir-receiver@11
[    5.396600] pinctrl-bcm2835 fe200000.gpio: pin-17 (ir-receiver@11) status -22
[    5.396622] pinctrl-bcm2835 fe200000.gpio: could not request pin 17 (gpio17) from group gpio17  on device pinctrl-bcm2711
[    5.396643] gpio_ir_recv ir-receiver@11: Error applying setting, reverse things back

Additional context

No response

The text was updated successfully, but these errors were encountered:

nandlab · 2022-10-31T22:21:02Z

It works with gpio 18 though.

6by9 · 2022-11-01T08:23:18Z

It's told you
pin gpio17 already requested by fe200000.gpio; cannot claim for ir-receiver@11

Please quote the full contents of your /boot/config.txt file, as something else is configured to use GPIO 17. (Nothing is configured to use GPIO 18, and therefore it loads).

nandlab · 2022-11-01T20:20:27Z

/boot/config.txt:

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Disable compensation for displays with overscan
disable_overscan=1

dtoverlay=pisound

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]

How can I find out, which process uses a gpio pin?

6by9 · 2022-11-02T07:27:34Z

You can use gpioinfo or look in /sys/kernel/debug/pinctrl/fe200000.gpio-pinctrl-bcm2711, however in your case it is fairly obvious as there is only one line different from normal - dtoverlay=pisound

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/pisound-overlay.dts#L96 claims GPIO 17 for a button on the Pisound. If you don't actually have the Pisound connected, then remove the dtoverlay line.

pelwell · 2022-11-02T08:49:37Z

I'm pretty sure that this line (https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/pisound-overlay.dts#L104) is the reason the culprit isn't obvious, since it obscures what is really responsible for claiming the GPIO. I think the line could be deleted, since there is already another pinctrl reference associated with the sound card (https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/pisound-overlay.dts#L83), but it may also be necessary to move the pinctrl-names line (https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/pisound-overlay.dts#L83) as well.

pelwell · 2022-11-02T09:39:34Z

[ Comment typed into wrong issue deleted ]

6by9 · 2022-11-02T10:06:36Z

Suffice to say that you're trying to use a GPIO already claimed by the Pisound card.
Without the dtoverlay=pisound you should be able to load gpio-ir on GPIO 17.

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

See: https://forums.raspberrypi.com/viewtopic.php?p=2051557#p2051557 kernel: overlays: pisound: Make button pins owned by card See: raspberrypi/linux#5235 kernel: overlays: i2c-sensor: Add mcp980x support See: raspberrypi/linux#5234

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi#5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi#5235 Signed-off-by: Phil Elwell <[email protected]>

nandlab · 2022-12-01T11:35:27Z

I disabled dtoverlay=pisound and now gpio-ir works with GPIO 17. Thank you!

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi#5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi#5235 Signed-off-by: Phil Elwell <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

commit 557949a596bd4101cc88c2e48cdbdb55dac1e67e from https://github.com/raspberrypi/linux.git rpi-6.1.y The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi/linux#5235 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Meng Li <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

commit 557949a596bd4101cc88c2e48cdbdb55dac1e67e from https://github.com/raspberrypi/linux.git rpi-6.1.y The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi/linux#5235 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Meng Li <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: #5235 Signed-off-by: Phil Elwell <[email protected]>

commit 86a5b8068e41104e41556a946749e88de58639c3 from https://github.com/raspberrypi/linux.git rpi-6.1.y The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi/linux#5235 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Meng Li <[email protected]>

The pisound overlay claims a number of GPIOs using a pinctrl node, but for some reason hangs this claim on the main gpio node. This obscures the ownership of the pins (as shown by gpioinfo and in the kernel logs) and isn't scalable - only one overlay can use the trick at a time. Change the overlay to make the pin ownership clear and avoid any future conflicts, removing a bogus claim on pins_spi0 at the same time. See: raspberrypi#5235 Signed-off-by: Phil Elwell <[email protected]>

pelwell added the Close within 30 days Issue will be closed within 30 days unless requested to stay open label Nov 4, 2022

nandlab closed this as completed Dec 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Gpio-ir module does not work #5235

Gpio-ir module does not work #5235

nandlab commented Oct 31, 2022

nandlab commented Oct 31, 2022

Uh oh!

6by9 commented Nov 1, 2022

Uh oh!

nandlab commented Nov 1, 2022

Uh oh!

6by9 commented Nov 2, 2022

Uh oh!

pelwell commented Nov 2, 2022

Uh oh!

pelwell commented Nov 2, 2022 •

edited

Loading

Uh oh!

6by9 commented Nov 2, 2022

Uh oh!

nandlab commented Dec 1, 2022

Uh oh!

Gpio-ir module does not work #5235

Gpio-ir module does not work #5235

Comments

nandlab commented Oct 31, 2022

Describe the bug

Steps to reproduce the behaviour

Device (s)

System

Logs

Additional context

nandlab commented Oct 31, 2022

Uh oh!

6by9 commented Nov 1, 2022

Uh oh!

nandlab commented Nov 1, 2022

Uh oh!

6by9 commented Nov 2, 2022

Uh oh!

pelwell commented Nov 2, 2022

Uh oh!

pelwell commented Nov 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

6by9 commented Nov 2, 2022

Uh oh!

nandlab commented Dec 1, 2022

Uh oh!

pelwell commented Nov 2, 2022 •

edited

Loading