RISCOS' IRQ handler

it walks IRQsema to allow it to process any in-progress transfers if OS_IICOp is re-entered

Any hope, maybe, for an IIC driver that can work without disabling interrupts “for ages”? ;-)

I take it you’re talking about the Raspberry Pi here.

If you can find a way to make the IIC interface issue a repeated start condition but be freely interruptable, you can have an IIC driver that doesn’t need to disable interrupts.

Otherwise, your choice is either to leave it as is, or to risk not having a repeated start condition, in which case you’re outside the specification of at least some of the slave devices.

The IIC implementation in the BCM2835… how can we put it… leaves something to be desired.

It’s not as bad as the USB implementation; but it couldn’t be, as it’s much simpler, so there’s not as much scope for deficiencies.

If that’s not it, then it might be worth just searching the kernel source for IRQSTK and seeing what turns up.

Kernel\s\Attic\HAL,v:2431:        LDR     sp, =IRQSTK
Kernel\s\Attic\HAL,v:3435:        LDR     sp_irq, =IRQSTK
Kernel\s\Middle,v:1655:        LDR     SPIRQ, =IRQSTK
Kernel\s\Middle,v:4384:        LDR     r13_irq, =IRQSTK
Kernel\s\Middle,v:5613:        LDR     SPIRQ, =IRQSTK
Kernel\s\Middle,v:5667:        LDR     SPIRQ, =IRQSTK
Kernel\s\NewReset,v:1537:        LDR     sp_irq, =IRQSTK         ; set up sp_irq
Kernel\s\NewReset,v:6995:        LDR     sp_irq, =IRQSTK
Programmer\RTSupport\s\scheduler,v:738:        LDR     r13_irq, IRQStk ; flatten stack

Its reset in a few places although RTSupport seems to be the only one that’s resetting it outside of an error occurring.

I think I can ignore it though, as I’ve just realised I’ll be better off paravirtualizing the hardware IRQ, Device Vector handler and IRQ1V on IOMD, which will give ADFFS control of the CPU state.