Using the FIQ and Bell IRQ for the USB driver

[Gordon Hollingworth]

Hopefully this one will make it into the list...

Sorry, missing email (my fault gmail defaults to html!)

What I was saying is that what you've described is my new FIQ split branch
almost exactly!  What I do is use the FIQ to complete split transactions.
 This way I 'almost' guarantee that they go out on the right uframe and
therefore we don't drop packets from keyboards etc...

Previously with the fix to reduce the interrupt overhead what I did was to
use the FIQ to decide whether we actually wanted to trigger a start of
frame interrupt.  In this case I would disable the USB global interrupt in
the FIQ and trigger an MPHI interrupt (this is a parallel host port that we
used to use when we had an external ARM, but none of its pins make it out
of the chip and therefore it is redundant).  When the start of frame
interrupt was processed I'd then re-enable the global interrupt again.

Now what I've done is to actually change the code to process some of the
interrupts in the FIQ, such as the host channels interrupt pertaining to
split transactions.  Unfortunately it turns out this code (and the
hardware) is a nest of vipers waiting for you to stick your hand in!

I did make a start on making a FIQ implementation of the EHCI interface,
but gave up !  Only problem, would only support USB2.0 interface...  Plus
it's an absolute nightmare interfacing with the hardware (it's not the most
logical of hardware interfaces)...

Gordon

On 13 May 2013 18:53, Simon Arlott <simon at fire.lp0.eu> wrote:
> 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
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel