-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No interrupts on MCP23017 following changes from #3207 #3449
Comments
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The bug was introduced in the second commit of #3211, the part that made interrupt support optional. Splitting the DT node in two, as this does, then requires that any renaming is done to both parts otherwise one comes adrift from the other - which is what causes the error message (the kernel is basically complaining that the I2C device has no However, that ignores another problem with this overlay that prevents it from being loaded at runtime. The kernel's dynamic overlay application logic won't permit an overlay to overwrite an existing node; it can overwrite all the properties within a node, but not the node itself. This means that fragment four is breaking the rules. It would be nice if the fragment could actually be made to add to the node already created by fragment 2, and you can. The technique is already used by fragment 3 to patch the
One solution would be to embed multiple versions of the overlay and select the required variant (interrupts on or off, mcp23008 on or off), but this is ugly. There are some new overlay syntax features that could probably be used to make this overlay universally applicable without bloating it, but the result would be ugly. Instead, the overlay application logic needs to be improved to take care of the "in-overlay" fragments before applying the remainder to the base DTB. I'm sure there will be gotchas in the implementation but it ought to be possible and would solve the runtime problems - I'll add it to the To Do list. In the meantime I've pushed 11ef396 which should fix this issue. |
Thank you for the update. |
Thanks - I'm going to close this issue, but the runtime overlay change is on the list. |
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
kernel: configs: Add NFS 4.2 support See: raspberrypi/linux#3397 kernel: overlays: dwc2: Increase RX FIFO size See: raspberrypi/linux#3447 kernel: overlays: Fix mcp23017's addr parameter See: raspberrypi/linux#3449 kernel: Fix a sh1106-spi, ssd1306-spi, ssd1351-spi overlays See: raspberrypi/linux#3451 kernel: overlays: add hdmi-backlight-hwhack-gpio-overlay See: raspberrypi/linux#3453 kernel: Revert brcmfmac: Disable power management kernel: brcmfmac: Increase power saving delay to 2s firmware: platform: 2711: Support overclocking gpu frequencies See: #1290
kernel: configs: Add NFS 4.2 support See: raspberrypi/linux#3397 kernel: overlays: dwc2: Increase RX FIFO size See: raspberrypi/linux#3447 kernel: overlays: Fix mcp23017's addr parameter See: raspberrypi/linux#3449 kernel: Fix a sh1106-spi, ssd1306-spi, ssd1351-spi overlays See: raspberrypi/linux#3451 kernel: overlays: add hdmi-backlight-hwhack-gpio-overlay See: raspberrypi/linux#3453 kernel: Revert brcmfmac: Disable power management kernel: brcmfmac: Increase power saving delay to 2s firmware: platform: 2711: Support overclocking gpu frequencies See: raspberrypi/firmware#1290
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
Source: kernel.org MR: 103889 Type: Enhancement Disposition: Merged from https://github.com/raspberrypi/linux.git rpi-5.4.y ChangeID: 050892f8b5c8f24706b7d6535087e7f0a57ca505 Description: The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: raspberrypi/linux#3449 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Corey Minyard <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
The addr parameter of the mcp23017 overlay was broken by the addition of the noints parameter; splitting the mcp node in two without also modifying the second half from the addr parameter would cause the two halves to separate. Change the implementation strategy to patch fragment 2 (as was originally proposed). This will prevent the overlay from being applied at runtime until the "dtoverlay" command is improved, but the overlay already has this restriction due to fragment 3 so this isn't a step backwards. See: #3449 Signed-off-by: Phil Elwell <[email protected]>
Describe the bug
With the latest device tree overlay for the MCP23017 on kernel 4.19, loading the overlay as specified in the documentation only partially works.
The device is present and shows up in /sys/class/gpio but exporting a pin yields an entry with no edge detection.
Kernel logs also indicate a failure upon boot.
[ 3.487510] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@7e804000/mcp@20 [ 3.487526] i2c i2c-1: Failed to create I2C device for /soc/i2c@7e804000/mcp@20
Replacing the overlay with the one from kernel 4.14 (prior to the changes from #3207) , the error goes away and interrupts work again.
To reproduce
You will require an MCP2307 connected to the i2c bus and a interrupt line connected to a GPIO pin.
In my case, the MCP is at address 0x25 and is connected to gpiopin 27 for interrupts
Install Raspbian buster (or any raspberry pi linux distribution) with kernel 4.19
Modify the config.txt file to load the mcp23017 overlay (dtoverlay=mcp23017,gpiopin=27,addr=0x25)
Expected behaviour
Running "dmesg | grep mcp" should show no failure message regarding the mcp23017 module
Exporting a gpio pin from the MCP with ' echo "488" > /sys/class/gpio/export ' will yield an entry with interrupt handling (edge) :
root@raspberrypi:~# ls /sys/class/gpio/gpio488/ active_low device direction edge power subsystem uevent value
And interrupt should be registered for the BCM's GPIO pin
`
root@raspberrypi:~# cat /proc/interrupts
...
56: 1 0 0 0 pinctrl-bcm2835 9 Edge gpio-ir-recv-irq
57: 0 0 0 0 pinctrl-bcm2835 27 Level 1-0025
...
`
Actual behaviour
Running "dmesg | grep mcp" will show
[ 3.487510] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@7e804000/mcp@20 [ 3.487526] i2c i2c-1: Failed to create I2C device for /soc/i2c@7e804000/mcp@20
Tryint to export a gpio pin from the MCP with ' echo "488" > /sys/class/gpio/export ' will yield an entry with no interrupt handling
root@raspberrypi:~# ls /sys/class/gpio/gpio488/ active_low device direction power subsystem uevent value
And no interrupt is registered for the GPIO pin on the BCM
root@raspberrypi:~# cat /proc/interrupts ... 56: 1 0 0 0 pinctrl-bcm2835 9 Edge gpio-ir-recv-irq ...
System
Which model of Raspberry Pi? Pi4B
Which OS and version (
cat /etc/rpi-issue
)?Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage2
Which firmware version (
vcgencmd version
)?Jan 10 2020 16:52:04
Copyright (c) 2012 Broadcom
version fdb5c37e330e7cb3027ac4fcc5b1cd5f244b351f (clean) (release) (start)
Which kernel version (
uname -a
)?Linux raspberrypi 4.19.93-v7l+ __DWC_DMA_FREE warning in dwc_otg (kernel 4.4) #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux
Workaround
Pulling the dts from prior the changes in #3207 and compiling it yields a dtb that fixes the issue (or at least bypasses it).
The dts used was
https://github.com/raspberrypi/linux/blob/34ae8ccc3d4c72b95aae68f2bd150246e44d6a5d/arch/arm/boot/dts/overlays/mcp23017-overlay.dts
Additional context
I suspect there might be an issue between the kernel driver and the dtbo ?
The text was updated successfully, but these errors were encountered: