Alan Stern wrote: >>> I'm running a 2.6.23-rc9-hrt1 kernel >>> (-rc8-hrt1 patch applied cleanly to -rc9). >>> >>> Is this expected? >>> > > It's hard to be precise. Here's a partial analysis: > > The interrupts for each driver fall into two categories. With uhci-hcd > they are labelled in your listing as usb_hcd_poll_rh_status and > uhci_hcd; with ehci-hcd they are labelled as ehci_watchdog and > ehci_hcd. > > Now in general you should expect the total uhci_hcd and ehci_hcd > numbers (not necessarily the averages!) to be roughly equal. The > uhci_hcd number might be somewhat higher. The poll_rh_status > interrupts will occur at a steady 4/second. The ehci_watchdog value is > harder to pin down. Bear in mind, however, that during the time when > those interrupts arrive, the EHCI controller is performing DMA, which > will prevent the CPU from entering a deep sleep state in any case. > (In fact, one of the purposes of the ehci_watchdog interrupt is to tell > the driver that it can turn off DMA.) > > Thanks for the explanation. > One other thing: EHCI transfers data 40 times faster than UHCI. All > else being equal, you would be justified in expecting it to generate 40 > times as many interrupts per second. The fact that it doesn't > indicates something -- perhaps that the real bottleneck isn't in these > controllers at all but somewhere else in the system. > This is on an idle system (for "desktop linux" values of idle). I'm not transferring data at maximum bus speed; in fact I'm not doing anything as a user that requires network access. So I wasn't particularly expecting more interrupts on ehci. >>> I notice that the number of interrupts is actually the same. The >>> difference is in the kernel polling routines - ehci_work vs >>> usb_hcd_poll_rh_status. Does ehci need to poll twice as often, or might >>> it be possible to tune or hack the polling interval? >>> > > ehci doesn't poll at all under normal circumstances, but it does use a > timer to disable the async schedule. As I mentioned above, uhci polls > at 4/second. > > Alan Stern So if I want to find out why ehci causes more wakeups on an idle system than uhci, I need to break down the ehci_watchdog timer into its component uses.
Um. So the ehci hardware is generating 10 interrupts a second on my idle desktop. Each ehci interrupt is associated with DMA activity. The driver sets timeouts to check whether DMA has finished and can be disabled. Assuming that DMA activity happens at regular intervals, it wouldn't make sense for the DMA activity _timeouts_ to happen any less frequently. So I also get 10 timeouts per second to go with the 10 interrupts. That accounts for the wakeups I'm seeing on powertop. So that's it then. autosuspend isn't supported for my device yet. I assume theres no way I could get the ehci hardware interrupts lower than 10 Hz in this case, and that it doesn't make sense to try and avoid the watchdog timeout. Thanks everyone! Alan P.S. I'll have another go tomorrow with the MP3 player I moaned about earlier, and describe what goes wrong a bit more rigorously. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
