All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lu, Baolu" <baolu.lu@linux.intel.com>
To: Alan Stern <stern@rowland.harvard.edu>
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: Fri, 08 May 2015 09:14:38 +0800	[thread overview]
Message-ID: <554C0DFE.3070907@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1505071031200.2272-100000@iolanthe.rowland.org>



On 05/07/2015 10:34 PM, Alan Stern wrote:
> On Thu, 7 May 2015, Lu, Baolu wrote:
>
>>>> +	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?
>> This msg argument is valuable. XHCI spec defines a capability named FSC
>> (Force Save context Capability). When this capability is implemented, the
>> Save State operation (do during host suspend) shall save any cached Slot,
>> Endpoint, Stream or other Context information to memory. xHCI hcd could
>> use this "msg" to determine whether it needs to issue stop endpoint with
>> SP (suspend) bit set.
> I don't understand.  What is the advantage of using FSC?

I'm sorry, I didn't make it clear.

As part of host suspend, controller save state will be issued to save
host internal state in xhci_suspend():

         /* step 4: set CSS flag */
         command = readl(&xhci->op_regs->command);
         command |= CMD_CSS;
         writel(command, &xhci->op_regs->command);
         if (xhci_handshake(&xhci->op_regs->status,
                                 STS_SAVE, 0, 10 * 1000)) {
                 xhci_warn(xhci, "WARN: xHC save state timeout\n");
                 spin_unlock_irq(&xhci->lock);
                 return -ETIMEDOUT;
         }

If FSC is supported,  the cached Slot, Endpoint, Stream, or other
Context information are also saved.

Hence, when FSC is supported, software does not have to issue Stop
Endpoint Command to push public and private endpoint state into
memory as part of system suspend process.

The logic in xhci_device_suspend() will look like:

if xhci_device_suspend() callback was called due to system suspend,
(mesg.event & PM_EVENT_SUSPEND is true) and FSC is supported by
the xHC implementation, xhci_device_suspend() could ignore stop
endpoint command, since CSS will be done in xhc_suspend() later and
where all the endpoint caches will be pushed to memory.

>
> How would xhci-hcd use "msg" to determine this?  And why doesn't your
> 2/3 patch already do it?

xhci-hcd can use "msg" to determine which case the callback is called,
run-time suspend or system suspend.

FSC needs a separate patch, I already have it in Mathias' gate. I didn't
bring it together with this patch series because it's still not tested yet.

>
> Alan Stern

Thank you!
Baolu

>
>
>


  reply	other threads:[~2015-05-08  1:14 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
2015-05-07  0:27     ` Lu, Baolu
2015-05-07 14:34       ` Alan Stern
2015-05-08  1:14         ` Lu, Baolu [this message]
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=554C0DFE.3070907@linux.intel.com \
    --to=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 \
    --cc=stern@rowland.harvard.edu \
    /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.