FelipeMdeO opened a new pull request, #20230:
URL: https://github.com/apache/nuttx/pull/20230
## Summary
`esp_gpio_irq()` registers per-pin GPIO interrupts through
`gpio_isr_handler_add()`, never through `esp_setup_irq()`, so
`esp_get_handle()` never finds them and `up_disable_irq()`/
`up_enable_irq()` silently no-op for any GPIO-derived IRQ number.
This surfaced through `drivers/sensors/lsm6ds3trc_uorb.c`: its ISR
schedules a worker to drain the sensor's FIFO over I2C and disables its
own IRQ until the worker re-enables it, so a level-triggered source left
in that state doesn't refire and starve every task, HPWORK included,
before the worker ever gets to run. That disable/enable only works now
that `up_disable_irq()`/`up_enable_irq()` actually do something for GPIO
IRQs.
Fix: in `arch/xtensa/src/common/espressif/esp_irq.c`, fall back to
`esp_gpioirqdisable()`/`esp_gpioirqenable()` (translating the IRQ number
back to a pin via `ESP_IRQ2PIN()`) when the normal interrupt-matrix lookup
misses.
## Impact
* Is new feature added? No — pure bug fix.
* Is existing feature changed? No behavior change for IRQ numbers already
routed through the interrupt matrix (`esp_setup_irq()`); only affects
GPIO-derived IRQ numbers, which previously silently did nothing.
* Impact on hardware? `arch/xtensa/src/common/espressif/esp_irq.c` is
shared code — affects every espressif board using GPIO-derived
interrupts (`CONFIG_ESPRESSIF_GPIO_IRQ`), not just the XIAO.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host: Ubuntu 24.04, x86_64, `xtensa-esp-elf-gcc`.
* Target: Xtensa, Seeed XIAO ESP32-S3 (esp32s3-xiao), LSM6DS3TR-C over I2C
with FIFO watermark interrupt on a level-triggered GPIO line.
Before the fix: disabling the GPIO IRQ from the driver's own ISR had no
effect — the line kept re-entering the worker, starving HPWORK. After the
fix, validated across a 12 h 25 continuous production run: zero FIFO
failures, zero faults, zero asserts over thousands of disable/enable
cycles around FIFO servicing, including through real sleep → GPIO-wake →
resume transitions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
