I'll restrict my terminology to SDHCI register and bit names, for simplicity, but I think the same concepts should apply to other host controllers.
How I expect the various states to progress is something like:
Start:
- let's assume again for simplicity that only one function interrupt enable (and the global interrupt enable) are set in the CCCR
-
Card Interrupt Status Enable is set in SDHCI Normal Interrupt Status Enable Register
- in SDIODriver,
sdio_int_state holds SDIO_STATE_WAIT_INT
Now let the WiFi chip receive a frame over the radio, so it wants to alert the host. This is completely asynchronous to the SD bus, which may be in the middle of a transaction - worst case, in the middle of a multi-block command, which can't be interrupted. The exact timings of the "interrupt period" in which the WiFi chip can use DAT1 are redacted from the public versions of the SDIO spec, but there are enough hints that we can say that such periods are available not just between commands but also between data blocks within a command. This means the maximum latency between the WiFi chip wanting to signal an interrupt and being able to do so is 1 block - although the host can't initiate a new command to do anything about it until any ongoing command has finished, potentially consisting of many blocks.
The host controller samples DAT1 at the appropriate times, and if it sees an interrupt, sets the Card Interrupt bit in Normal Interrupt Status Register and raises an interrupt to the CPU's interrupt controller.
When the CPU is next interruptible (i.e. not masked in the CPSR) we end up via interrupt dispatch at SDIODriver's op_poll() function. This checks for the Card Interrupt bit in Normal Interrupt Status Register and because it's set, calls nudge_sdio_state_machine(). This masks further card interrupts by calling enable_card_interrupt(false) which clears the Card Interrupt Status Enable bit. Then it transitions sdio_int_state to SDIO_STATE_WAIT_HANDLER_COMPLETE and calls the registered interrupt handler, which in your case will be sdiolib_interrupt_handler() from SDIOLib. That simply sets the pollword that it previously registered with RTSupport.
Now we have to wait until the outermost kernel interrupt dispatch unwinds, which is when RTSupport gets control. This resumes interrupt_thread() from inside the RT_Yield SWI. It then attempts to gain exclusive use of the SD bus by calling sdiolib_lock(). In the event that there was an ongoing transaction on the SD bus, this will sleep the thread again, only waking it when the current user of the bus has finished. At this point, SDIOLib calls the function that was registered with it.
Within that function, I'd expect you to read or write a few registers within the SDIO device's memory map, in order to fetch the frame contents and cause the device to stop asserting DAT1 during interrupt periods between blocks on the SD bus.
When your function returns to SDIOLib, SDIOLib calls SDIOControl_AckSDIOCardInt for you. (Remember, right up to this point, card interrupts have remained disabled in the host controller, so nothing should have been calling sdiolib_interrupt_handler()). What this SWI does is to call back into nudge_sdio_state_machine() in order to transition sdio_int_state back to SDIO_STATE_WAIT_INT and re-enable card interrupts using enable_card_interrupt(true).
I hope that explains why it should be impossible to get into the state you describe. I've even added a barrier() call to guard against a future where the interrupt handler and RTSupport thread might be executing on different CPUs! The only thing I can think of is maybe you're calling SDIOControl_AckSDIOCardInt yourself, in which case the answer is to stop doing that and let SDIOLib do it for you. It might also be worth logging any errors generated by SDIOControl_AckSDIOCardInt to ensure that the state machine isn't getting out of step somehow.
