Using the FIQ and Bell IRQ for the USB driver

[Simon Arlott]

As the USB driver needs to handle 8000+ interrupts/s without wasting
CPU, one option is to use the FIQ handler to filter out and handle most
of the interrupts. This is complicated by the need to be able to write
a readable driver that interacts with the rest of the USB subsystem,
which will require proper use of locking.

Locking that depends on being able to disable interrupts won't easily
work because the FIQ is enabled independently of the normal interrupts.
The USB host only generates one interrupt, so the FIQ can only handle
all or none of these. Some process is required to convert the FIQ to a
normal IRQ (that can be disabled for locking to work correctly).

There is an undocumented (except in the original kernel patches) "bell"
interface that allows the ARM and the VC components to send interrupts
to each other. Nominally there are 2 interrupts each for the ARM and VC
intended to be used in one direction only, but it is possible to trigger
your own bell interrupt with a single MMIO write.

This could be used to allow the FIQ to pass the less frequent USB host
interrupts that require more complex handling (and interaction with the
kernel's USB subsystem) to the normal IRQ handler of the driver (which
would be on the bell IRQ).

As long as the VC still only uses one of the bell interrupts, there's
one available for this. It doesn't help non-BCM2835 hardware that uses
the same USB chip but it might make the Raspberry Pi responsive enough
to not lose key presses on USB keyboards.

Something to think about for anyone working on an USB host driver...

-- 
Simon Arlott