Hi, On Mon, Jul 6, 2015 at 12:02 PM, Felipe Balbi <balbi@xxxxxx> 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 <https://chromium-review.googlesource.com/196593>. He then used it in the tegra XHCI driver in <https://chromium-review.googlesource.com/196594>. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
