On Tue, Dec 03, 2013 at 01:08:08PM -0800, Sarah Sharp wrote: > On Tue, Dec 03, 2013 at 03:49:45PM -0500, Alan Stern wrote: > > On Tue, 3 Dec 2013, Sarah Sharp wrote: > > > > > Hi Oliver and Takashi, > > > > > > In 3.12-rc5, I merged this patch from you: > > > > > > commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 > > > Author: Takashi Iwai <tiwai@xxxxxxx> > > > Date: Thu Sep 12 08:11:06 2013 +0200 > > > > ... > > > This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for > > > fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci > > > shutdown ops as done in xhci_stop(), and setting the device to PCI D3 > > > at shutdown and remove ops. > > ... > > > > > When testing with Intel BIOSes on Lynx Point LP systems, we found that > > > it increases the xHCI module load time by about 100ms (load time is > > > normally around 30ms). Load time is increased both when the module is > > > loaded at boot, and when the module is unloaded and reloaded with > > > modprobe. Measurements were taken by adding initcall_debug to the > > > kernel boot parameters, and looking at how long it took xhci_hcd_init to > > > return. > > > > > > I'd like to avoid a 3x increase in xHCI module load time at boot. Would > > > it be possible to narrow the quirk down to systems with the particular > > > BIOS installed that needs the host to be in D3 before S5? > > > > If all the commit does is change the behavior when the module is > > unloaded, why should it make any difference to the load time? That > > doesn't make any sense. > > Yeah, it doesn't make much sense to me either. But I can reproduce the > behavior on my Lenovo x230 if I add the PCI ID of my Intel Panther Point > xHCI host controller to the quirk. Without the quirk, when I load the > driver after boot with modprobe, xhci_init takes on average 44ms to > complete. With the quirk, it takes 74ms on average. I haven't measured > boot time too many times, but it also seems to be increased by around > 40ms. > > The patch only touches the PCI and platform remove function, adding a > host controller reset and putting the host in D3. Maybe on module > reload, it takes longer to get the host into D0? I don't see why that > would impact module load times at boot though. That might be true, try testing boot times from cold boot to get the "real" time here. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
