Using the FIQ and Bell IRQ for the USB driver

Simon Arlott simon at fire.lp0.eu
Mon May 13 13:53:02 EDT 2013


On 13/05/13 17:12, Stephen Warren wrote:
> On 05/12/2013 12:21 PM, Simon Arlott wrote:
>> 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).
> 
> Perhaps the locking can be simplified a bit by using FIQ just to make
> the HW look more like regular EHCI (so just queue management I guess)
> and then passing /all/ "normal" USB interrupts back to the regular USB
> driver. That should isolate all the locking entirely within the
> HW-specific driver, right?

You can't pass any USB interrupts to the normal USB interrupt handler
because the FIQ will just be called again while the interrupt is still
pending. Disabling and enabling the FIQ risks not enabling it again
quickly enough (interrupts may not be enabled, or the kernel may be
about to disable interrupts so that it can invoke the interrupt handler
for some unrelated device).

> Rather than re-purposing a bell interrupt, aren't there SW-generated
> interrupts that can be allocated/implemented for this purpose?

I assume that will require locking to access. Using a FIQ is so low
level that there just isn't a way to access the normal kernel subsystems
safely. The kernel could be *anywhere* when the FIQ handler is run.


Aaah... you haven't seen Gordon Hollingworth's email. This method of
FIQ-used-to-trigger-IRQ is already in development but I wasn't aware of
it. The mailing list moderator must be absent as I have a pending
message too.

-- 
Simon Arlott



More information about the linux-rpi-kernel mailing list