All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] usb: notify hcd when USB device suspend or resume
Date: Wed, 6 May 2015 10:35:06 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1505061031450.1094-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <1430898002-24748-2-git-send-email-baolu.lu@linux.intel.com>

On Wed, 6 May 2015, Lu Baolu wrote:

> This patch adds two new entries in hc_driver. With these new entries,
> USB core can notify host driver when a USB device is about to suspend
> or just resumed.
> 
> The xHCI spec is designed to allow an xHC implementation to cache the
> endpoint state. Caching endpoint state allows an xHC to reduce latency
> when handling ERDYs and other USB asynchronous events. However holding
> this state in xHC consumes resources and power. The xHCI spec designs
> some methods through which host controller driver can hint xHC about
> how to optimize its operation, e.g. to determine when it holds state
> internally or pushes it out to memory, when to power down logic, etc.
> 
> When a USB device is going to suspend, states of all endpoints cached
> in the xHC should be pushed out to memory to save power and resources.
> Vice versa, when a USB device resumes, those states should be brought
> back to the cache. USB core suspends or resumes a USB device by sending
> set/clear port feature requests to the parent hub where the USB device
> is connected. Unfortunately, these operations are transparent to xHCI
> driver unless the USB device is plugged in a root port. This patch
> utilizes the callback entries to notify xHCI driver whenever a USB
> device suspends or resumes.
> 
> It is harmless if a USB devices under USB 3.0 host controller suspends
> or resumes without a notification to hcd driver. However there may be
> less opportunities for power savings and there may be increased latency
> for restarting an endpoint. The precise impact will be different for
> each xHC implementation. It all depends on what an implementation does
> with the hints.
> 
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>


> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3144,6 +3144,14 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
>  			goto err_lpm3;
>  	}
>  
> +	/*
> +	 * Call back to hcd if it expects. xHCI compatible host controller
> +	 * driver expects to be notified prior to selectively suspending a
> +	 * device. xHCI hcd could optimize the endpoint cache for power
> +	 * saving purpose. Refer to 4.15.1.1 of xHCI 1.1 for more information.
> +	 */

Doesn't this comment belong in the xhci-hcd source code rather than the 
hub driver source code?

> +	hcd_suspend_notify(udev, msg);
> +
>  	/* see 7.1.7.6 */
>  	if (hub_is_superspeed(hub->hdev))
>  		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
> @@ -3169,6 +3177,8 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg)
>  	if (status) {
>  		dev_dbg(&port_dev->dev, "can't suspend, status %d\n", status);
>  
> +		hcd_resume_notify(udev, msg);
> +
>  		/* Try to enable USB3 LPM and LTM again */
>  		usb_unlocked_enable_lpm(udev);
>   err_lpm3:
> @@ -3422,6 +3432,12 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>  	}
>  
>   SuspendCleared:
> +	/* Call back to hcd if it expects. xHCI compatible host controller
> +	 * driver expects to be notified after a device is resumed. xHCI
> +	 * hcd could optimize the endpoint cache for latency reducing
> +	 * purpose. Refer to 4.15.1.1 of xHCI 1.1 for more information.
> +	 */

Same for this comment.

> +	hcd_resume_notify(udev, msg);
>  	if (status == 0) {
>  		udev->port_is_suspended = 0;
>  		if (hub_is_superspeed(hub->hdev)) {
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index 68b1e83..621d9b7 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -383,7 +383,13 @@ struct hc_driver {
>  	int	(*find_raw_port_number)(struct usb_hcd *, int);
>  	/* Call for power on/off the port if necessary */
>  	int	(*port_power)(struct usb_hcd *hcd, int portnum, bool enable);
> -
> +	/* Call back to hcd when a USB device is going to suspend or just
> +	 * resumed.
> +	 */
> +	void	(*device_suspend)(struct usb_hcd *, struct usb_device *udev,
> +			pm_message_t msg);
> +	void	(*device_resume)(struct usb_hcd *, struct usb_device *udev,
> +			pm_message_t msg);
>  };

Your callbacks don't use the msg argument.  What makes you think it is 
needed?

Alan Stern


  reply	other threads:[~2015-05-06 14:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06  7:39 [PATCH v2 0/3] usb: notify hcd when USB device suspend or resume Lu Baolu
2015-05-06  7:40 ` [PATCH v2 1/3] " Lu Baolu
2015-05-06 14:35   ` Alan Stern [this message]
2015-05-07  0:27     ` Lu, Baolu
2015-05-07 14:34       ` Alan Stern
2015-05-08  1:14         ` Lu, Baolu
2015-05-08 14:21           ` Alan Stern
2015-05-09  0:42             ` Lu, Baolu
2015-05-11 14:25               ` Alan Stern
2015-05-12  2:05                 ` Lu, Baolu
2015-05-12 15:54                   ` Alan Stern
2015-05-13  2:36                     ` Lu, Baolu
2015-05-13 14:14                       ` Alan Stern
2015-05-08  7:55     ` Lu, Baolu
2015-05-06  7:40 ` [PATCH v2 2/3] usb: xhci: implement device_suspend/device_resume entries Lu Baolu
2015-05-06 14:30   ` Alan Stern
2015-05-07  0:30     ` Lu, Baolu
2015-05-06  7:40 ` [PATCH v2 3/3] usb: xhci: remove stop device and ring doorbell in hub control and bus suspend Lu Baolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1505061031450.1094-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=baolu.lu@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.