failing to mark a gpio as an IRQ #2527
Comments
|
What was your previous version? It's not clear what has changed in that area to make a difference. As to whether it is erroneous or not, you'll have to argue the toss with the Linux GPIO devs - that is all upstream code that we'd rather not mess with. What is your use case? |
|
gpiolib.c is an unmodified file from upstream. Any request for modification to that core code needs to be taken up with the mainline Linux kernel developers - linux-gpio@vger.kernel.org Looking at 4.9, that check was present https://elixir.bootlin.com/linux/v4.9.95/source/drivers/gpio/gpiolib.c#L2757 |
|
my previous version is irrelevant. the change was to code that now prevents me from requesting an irq via a gpio device tree property and probably not gpiolib.c at all. however, now i am forced to use gpio lib. bottom line - all rabbit trails aside, why would a gpio need to be marked as an input in order to be used as an irq? I will attempt to remedy with "upstream" as you call it. |
|
It's not just us who call the mainline kernel development `upstream'. It's standard terminology for the mainline kernel development - i.e. that overseen by Linus Torvalds. ie THE canonical Linux. |
|
Attacking the problem from a different direction, can you not enabling the interrupt while the pin is an input, then change the direction afterwards? (And it turns out this issue has been raised before: #808) |
|
The answer to my own question appears to be no: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/gpio/gpiolib.c#L2303 |
|
i did not intent to disparage when quoting upstream. i wasn't sure entirely what it meant other than the developers at linux kernel.org. re: phil's posts - yes i tried to use gpiod_direction_input() directrly prior to the request_irq() call with no success. i'ma little miffed at the constraint since we had to resort to using gpio as a mailbox int (instantiated from a dma descriptor) because the dma ints on r-pi behaved so poorly. was there a functional issue that necessitated this? otherwise it seems a bit arbitrary. i'm still attempting to contact linux-gpio@vger.kernel.org. if no success reversing this decision, we will just have to modify our kernel to remove the offending check. thank you all for the help. |
|
Rereading my comments from three years ago - #808 (comment), #808 (comment) - perhaps my initial response in this thread could have been more sympathetic. The rpi- kernel branches already contain a number of patches to and reversions of bits of upstream policy code that we don't agree with. Given that this bit of code has been unchanged since 3.18, I'm prepared to take on the burden of maintaining a patch the disables these checks. |
|
that would be awesome |
pelwell
pushed a commit
that referenced
this issue
Apr 24, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
Noddy patch pushed to rpi-4.14.y. |
|
thanks Phil |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
Apr 26, 2018
kernel: BCM270X_DT: Add sdio_overclock parameter kernel: gpiolib: Don't prevent IRQ usage of output GPIOs See: raspberrypi/linux#2527 kernel: Driver for Allo Katana DAC See: raspberrypi/linux#2519 kernel: Prevent voltage low warnings from filling log See: raspberrypi/linux#2520 kernel: overlays: Add 'combine' option to i2c overlays See: #828 firmware: Extra reg writes to ensure the LCD display starts up at 800 wide firmware: platform: Lower temperature thresholds for extra pips to 50/60 firmware: video_encode: Add support for YVU420Planar and YVU420SemiPlanar firmware: video_decode: Support YV12, NV12, and NV21 output firmware: video_decode: Support reporting colour space firmware: IL rawcam: Fix copy/paste error on timing setup firmware: MMAL: Populate buffer header TYPE_SPECIFIC fields
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
Apr 26, 2018
kernel: BCM270X_DT: Add sdio_overclock parameter kernel: gpiolib: Don't prevent IRQ usage of output GPIOs See: raspberrypi/linux#2527 kernel: Driver for Allo Katana DAC See: raspberrypi/linux#2519 kernel: Prevent voltage low warnings from filling log See: raspberrypi/linux#2520 kernel: overlays: Add 'combine' option to i2c overlays See: raspberrypi/firmware#828 firmware: Extra reg writes to ensure the LCD display starts up at 800 wide firmware: platform: Lower temperature thresholds for extra pips to 50/60 firmware: video_encode: Add support for YVU420Planar and YVU420SemiPlanar firmware: video_decode: Support YV12, NV12, and NV21 output firmware: video_decode: Support reporting colour space firmware: IL rawcam: Fix copy/paste error on timing setup firmware: MMAL: Populate buffer header TYPE_SPECIFIC fields
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this issue
Apr 26, 2018
kernel: BCM270X_DT: Add sdio_overclock parameter kernel: gpiolib: Don't prevent IRQ usage of output GPIOs See: raspberrypi/linux#2527 kernel: Driver for Allo Katana DAC See: raspberrypi/linux#2519 kernel: Prevent voltage low warnings from filling log See: raspberrypi/linux#2520 kernel: overlays: Add 'combine' option to i2c overlays See: #828 firmware: Extra reg writes to ensure the LCD display starts up at 800 wide firmware: platform: Lower temperature thresholds for extra pips to 50/60 firmware: video_encode: Add support for YVU420Planar and YVU420SemiPlanar firmware: video_decode: Support YV12, NV12, and NV21 output firmware: video_decode: Support reporting colour space firmware: IL rawcam: Fix copy/paste error on timing setup firmware: MMAL: Populate buffer header TYPE_SPECIFIC fields
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this issue
Apr 26, 2018
kernel: BCM270X_DT: Add sdio_overclock parameter kernel: gpiolib: Don't prevent IRQ usage of output GPIOs See: raspberrypi/linux#2527 kernel: Driver for Allo Katana DAC See: raspberrypi/linux#2519 kernel: Prevent voltage low warnings from filling log See: raspberrypi/linux#2520 kernel: overlays: Add 'combine' option to i2c overlays See: raspberrypi/firmware#828 firmware: Extra reg writes to ensure the LCD display starts up at 800 wide firmware: platform: Lower temperature thresholds for extra pips to 50/60 firmware: video_encode: Add support for YVU420Planar and YVU420SemiPlanar firmware: video_decode: Support YV12, NV12, and NV21 output firmware: video_decode: Support reporting colour space firmware: IL rawcam: Fix copy/paste error on timing setup firmware: MMAL: Populate buffer header TYPE_SPECIFIC fields
pelwell
pushed a commit
that referenced
this issue
May 1, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
May 1, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 5, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 5, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 17, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
May 20, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
pelwell
pushed a commit
that referenced
this issue
May 20, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 21, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 25, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 29, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 5, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 11, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 13, 2018
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Sep 16, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 2, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 2, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 7, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 10, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 10, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 14, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 14, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 17, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 21, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 23, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Oct 28, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 1, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 5, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 6, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 8, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 11, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 25, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Nov 25, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 7, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 9, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 10, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 16, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 16, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Dec 20, 2024
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jan 2, 2025
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jan 2, 2025
Upstream Linux deems using output GPIOs to generate IRQs as a bogus use case, even though the BCM2835 GPIO controller is capable of doing so. A number of users would like to make use of this facility, so disable the checks. See: #2527 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
on version 4.14.30 - evidently the gpio i/f underwent some changes since my previous version. the crux of the matter is that .../drivers/gpio/gpiolib.c checks to make sure that a gpio is -not- marked as an output before flagging it as an IRQ. If we're going to attempt a universal interface to something as varied as gpio, then checking pin direction is erroneous. Specifically, if one is using a gpio as a mailbox interrupt, the pin must be set as an output. Could the check in gpiochip_lock_as_irq() be eliminated?
Dan
The text was updated successfully, but these errors were encountered: