Rockbox

These devices can spend alot of time in ISR's waiting to perform operations like reading the DBOP or waiting for it to go idle. AMSv2 has PMU read and write functions that keep interrupts disabled for a full two I2C transfer. This can prevent audio interrupts from being serviced in a timely manner resulting in occasional dropouts for playback or small bits of lost data for recording. The solutions are 1) Enable stack interrupts on all targets 2) Rewrite ascodec_read/write_pmu to disable interrupts only to place two consecutive requests in the queue but wait with interrupts enabled for completion.

Interrupts callbacks are in SVC mode on its own stack. I'm not certain what size is reasonable. Theoretically all enabled interrupts could happen up to the highest level, potentially consuming quite a bit of stack in the worst case and 1/2 the current IRQ stack just to save context.

I also disabled semaphore_release context switch for the moment. A different scheme that explicitely checks for thread execution context will be needed as interrupts being disabled won't be a way to discern whether or not interrupt context is executing.

One interesting issue on Fuze v2 that I have not been able to figure out is that if the GPIOA ISR is interrupted by a higher-priority interrupt, execution ends up in all sorts of strange places, with the concomitant fault screen or freeze. Unless the cause of that is remedied, GPIOA's ISR will have to be the highest priority or the enabling of IRQ during ISR selected on a per-handler basis. GPIOA's ISR is very short so shouldn't hurt latency very much.

Surprisingly, no other stacking I checked by running recording and delaying for a few thousand microseconds inside the ISR in order to force audio interrupts on top of another produced any sort of fault.