rp2: Fix lost CYW43 WiFi events when using both cores.

[projectgus]

Summary

Closes #16779. Thanks to @coencoensmeets for a clear and easy to reproduce bug report, and to @Gadgetoid for doing some deep digging to zero in on the root cause.

There's a very odd but predictable sequence of events that breaks Wi-Fi when using both cores:

1. CPU1 calls pendsv_suspend() - for example sleep() causes a softtimer node to be inserted, which calls pendsv_suspend().
2. CYW43 sends wakeup IRQ. CPU0 GPIO IRQ handler schedules PendSV and disables the GPIO IRQ on CPU0, to re-enable after cyw43_poll() runs and completes.
3. CPU0 PendSV_Handler runs, sees pendsv is suspended, exits.
4. CPU1 calls pendsv_resume() and pendsv_resume() sees PendSV is pending and triggers it on CPU1.
5. CPU1 runs PendSV_Handler, runs cyw43_poll(), and at the end it re-enables the pin IRQ but now on CPU1.

However CPU1 has the overall GPIO IRQ line disabled, so the CYW43 interrupt never runs again...

Fix is to specifically only enable the GPIO interrupt on CPU0. This isn't supported in pico-sdk but appears to be supported by the hardware.

Plus two follow-up commits:

• Refactor out the cyw43_has_pending global flag to instead be a check of the pendsv table. This was necessary for the previous version of this PR. Not necessary now, but seems like a worthwhile change.
• Enable PendSV interrupt at the correct priority on both CPUs, and even if CYW43 is not in use. Also adds some comments in PendSV explaining how it can run on either CPU.

This work was funded through GitHub Sponsors.

Testing

• Ran the test Python program from the linked issue on both RPI_PICO_W and RPI_PICO2_W boards, verified the problem goes away.
• Ran the multi_wlan test between RPI_PICO_W and RPI_PICO2_W and an ESP32, verified tests still pass.

Trade-offs and Alternatives

• First version of this PR instead changed the interrupt to rising edge, so it didn't need to be disabled. This appears to work fine, and simplifies the code, but actually the CYW43 interrupt pin on RP2 is muxed with the data pin so the GPIO edge interrupt was triggering spuriously at a very high frequency. Oops!
• @Gadgetoid has a PR rp2: pendsv add support for CPU affinity #16788 which adds support for CPU affinity in PendSV callbacks. We could add this support, although we don't really need the feature (everything that calls pendsv_schedule_dispatch() runs on CPU0).
• As @Gadgetoid also suggested in rp2: pendsv add support for CPU affinity #16788, we could change PendSV to only ever fire on CPU0. In fact, comments in pendsv.c suggest that's the current expectation. I actually implemented this fix first, see projectgus@47723da . That is still more complex than this fix as it needs a cross-core PendSV trigger for when CPU1 does pendsv_resume(). However it might be easier to reason about overall.

[github-actions]

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:   -12 -0.001% RPI_PICO_W[incl -4(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

[Gadgetoid]

Thank you for delving deeper into this and detailing the cause, I didn't quite understand why what I was seeing was happening, but now I do.

CYW43 never fails to surface the wildest bugs!

[projectgus]

New version pushed which keeps the level-triggered interrupt but hand-rolls a function to only ever enable it on CPU0.

Have also a raised a feature request in pico-sdk to have this in the GPIO API: raspberrypi/pico-sdk#2354

[dpgeorge]

The latest changes look really good. I will test them.

[dpgeorge]

I've done extensive tests of this PR:

• tested RPI_PICO_W, RPI_PICO2_W and RPI_PICO2_W-RISCV
• ran full test suite, all possible tests, including network and BLE
• ran iperf3 test on RPI_PICO2_W-RISCV

I didn't see any issues or regressions.

[dpgeorge]

Thanks for splitting this up into a set of very clean, independent commits.