Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752439AbbEHBOp (ORCPT ); Thu, 7 May 2015 21:14:45 -0400 Received: from mga09.intel.com ([134.134.136.24]:26291 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbbEHBOl (ORCPT ); Thu, 7 May 2015 21:14:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,387,1427785200"; d="scan'208";a="722556796" Message-ID: <554C0DFE.3070907@linux.intel.com> Date: Fri, 08 May 2015 09:14:38 +0800 From: "Lu, Baolu" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alan Stern CC: Greg Kroah-Hartman , Mathias Nyman , 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 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2733 Lines: 76 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 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/