High number of USB interrupts/s on an idle system

[Martin Sperl]

Thanks - that explains it for the most parts.

I just thought it looked strange comparing it to an idle system with the 
foundation kernels/drivers and thus wanted to give a head-up about this 
"strange" observation on a totally idle system.

Martin


On 01.12.2013, at 21:21, Gordon Hollingworth wrote:

> 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
> 
>