From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755496AbbGFTji (ORCPT ); Mon, 6 Jul 2015 15:39:38 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:34927 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755040AbbGFTj3 (ORCPT ); Mon, 6 Jul 2015 15:39:29 -0400 MIME-Version: 1.0 In-Reply-To: <20150706190212.GN20779@saruman.tx.rr.com> References: <1436207224-21849-4-git-send-email-dianders@chromium.org> <20150706190212.GN20779@saruman.tx.rr.com> Date: Mon, 6 Jul 2015 12:39:27 -0700 X-Google-Sender-Auth: DQt08gBOvUhh96VNFmRnpXZ8QoY Message-ID: Subject: Re: [REPOST PATCH 3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled From: Doug Anderson To: Felipe Balbi Cc: Alan Stern , Greg Kroah-Hartman , John Youn , "linux-usb@vger.kernel.org" , Chris Zhong , Heiko Stuebner , Julius Werner , Andrew Bresticker , Alexandru Stan , lyz , "open list:ARM/Rockchip SoC..." , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jul 6, 2015 at 12:02 PM, Felipe Balbi wrote: > On Mon, Jul 06, 2015 at 02:58:16PM -0400, Alan Stern wrote: >> On Mon, 6 Jul 2015, Douglas Anderson wrote: >> >> > If the 'snps,need-phy-for-wake' is set in the device tree then: >> > >> > - We know that we can wakeup, so call device_set_wakeup_capable(). >> > The USB core will use this knowledge to enable wakeup by default. >> > - We know that we should keep the PHY on during suspend if something >> > on our root hub needs remote wakeup. This requires the patch (USB: >> > Export usb_wakeup_enabled_descendants()). Note that we don't keep >> > the PHY on at suspend time if it's not needed because it would be a >> > power draw. >> >> You know, this is the first time I've run across this optimization. >> >> In principle it applies to any USB host controller, not just to PHYs. >> There's no reason to enable wakeup for a controller if none of the >> attached devices can issue a wakeup request. >> >> I don't know if implementing this in other HCDs would save any power. >> Any ideas? > > most likely it would. Enabling wakeup usually boils down to keeping a > tiny part of the controller (or PHY) powered up. Sometimes that lies in > an always-on power domain, so there would be no difference. As per Andrew Bresticker (CCed on this email), the optimization made sense in Tegra. If you're willing to look into the chromeos-3.10 tree, you can see that Andrew added a usb_port_may_wakeup() call in . He then used it in the tegra XHCI driver in . Recently I talked to Andrew and he indicated that rather than add usb_port_may_wakeup() like he did it probably made sense to just export usb_wakeup_enabled_descendants(). -Doug