High number of USB interrupts/s on an idle system

[Gordon Hollingworth]

There is a start of frame interrupt that is normally enabled 100% of the
time giving you 8000 interrupts per second even when idle.  The reason it
is enabled is that at each interrupt the driver checks the schedule to see
if there are any transactions that need scheduling in the next uframe.

The FIQ code on the downstream driver was originally inserted (by yours
truly!) to reduce this interrupt overhead by only tripping a FIQ (which
can be processed much quicker and with far less code than the interrupt
handler) which will check to see if any scheduling needs to take place.
If it does then the FIQ triggers an IRQ to actually process the start of
frame interrupt and send the transaction.

In terms of the MMC controller, in the linux kernel the mmc driver sends a
SEND_STATUS command around twice a secondŠ  I don't think you should see
more than a couple of interrupts to process that

Gordon


On 01/12/2013 18:47, "Stephen Warren" <swarren at wwwdotorg.org> wrote:

>On 11/29/2013 04:09 AM, martin sperl wrote:
>> Hi!
>> 
>> I have done the setup of the RPI using Stephens "vanilla" tree (commit:
>> d5d9894) and the steps from his blog with regards to uboot, the usb
>> power-on hack in uboot, ...
>> 
>> The thing is that I see high interrupt rates on the board even when the
>> system is totally idle.
>
>The USB HW block requires SW to service an interrupt for every USB
>frame(?). Whether that should be needed when the HW is idle, I have no
>idea. I guess it's quite possible the interrupt needs to stay enabled in
>order to e.g. interrupts to be delivered back up the chain.
>
>...
>> I also wonder why I would have 1 MMC interrupt/s, when there is nothing
>> happening really on the SD-card...
>
>There are probably many possible reasons; swap, flushing disk buffers,
>polling the card to make sure it's still present(?), ... I imagine you'd
>need to explicitly instrument the driver to dump commands to tell if you
>really want to know.
>
>_______________________________________________
>linux-rpi-kernel mailing list
>linux-rpi-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel