On Wed, 2016-12-14 at 11:36 -0500, Alan Stern wrote: > On Wed, 14 Dec 2016, Todd Brandt wrote: > > > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT > > and other hardcoded delay numbers with the USB spec minimums. > > > > The USB subsystem currently uses heavily padded values for TDRSMDN > > and TRSTRCY. This patch keeps the current values by default, but if > > the kernel is booted with usb_timing_minimum=1 they are set to the > > spec minimums with no padding. The result is significant performance > > improvement in usb device resume. > > > > Example analyze_suspend runs are provided here showing the benefits: > > https://01.org/suspendresume/blogs/tebrandt/2016/usb-resume-optimization-using-spec-minimum-delays > > > > Signed-off-by: Todd Brandt <todd.e.bra...@linux.intel.com> > > ... > > > --- a/drivers/usb/common/common.c > > +++ b/drivers/usb/common/common.c > > @@ -19,6 +19,13 @@ > > #include <linux/usb/otg.h> > > #include <linux/of_platform.h> > > > > +struct _usb_timing_config usb_timing = { > > Initial '_'? Ugh. How about just struct usb_timing_config? ok, will do.
> > > + .tdrsmdn = USB_TIMING_TDRSMDN_DEF, > > + .trsmrcy = USB_TIMING_TRSMRCY_DEF, > > + .trstrcy = USB_TIMING_TRSTRCY_DEF > > +}; > > +EXPORT_SYMBOL_GPL(usb_timing); > > > --- a/drivers/usb/host/uhci-hub.c > > +++ b/drivers/usb/host/uhci-hub.c > > > @@ -339,7 +339,7 @@ static int uhci_hub_control(struct usb_hcd *hcd, u16 > > typeReq, u16 wValue, > > > > /* USB v2.0 7.1.7.5 */ > > uhci->ports_timeout = jiffies + > > - msecs_to_jiffies(USB_RESUME_TIMEOUT); > > + msecs_to_jiffies(usb_timing.trstrcy); > > Actually this was wrong from the beginning (it was a bug). It should > be 50 ms (TDRSTR), not TRSTRCY. I suppose that could be fixed in a > separate patch. I could add tdrstr to the usb_timing struct itself. It has a minimum of 50ms, but it might be useful to tweak it upwards with the debugfs interface for buggy hardware. (I'll do a v5) > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
