From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9AD0C433EF for ; Wed, 4 May 2022 18:19:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376945AbiEDSWu (ORCPT ); Wed, 4 May 2022 14:22:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376900AbiEDSWq (ORCPT ); Wed, 4 May 2022 14:22:46 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 148FF4B871 for ; Wed, 4 May 2022 10:46:33 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id n8so2084769plh.1 for ; Wed, 04 May 2022 10:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LtWHuThIe0dcxXuedbVwJNy12A4ZYyFgKdzHIm7dues=; b=Vfd0Sq+Wzp1oZDscK9nncqtb62H1YcTv5jc/nrwigR2VKbA6OkaPGroKpsj3kv+sQX CljNkT1bNmxMDGjq+o9fjKGuaLTIC4SyMK+odZjHhr3K0OYaEBpx/i/hY8xb5QBJQABp PGTH7AkFPEj6DI0rmw/JchSqtuazrYVhS9GOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LtWHuThIe0dcxXuedbVwJNy12A4ZYyFgKdzHIm7dues=; b=qOox/QrMx6X7usUC6u/hKlpkBaTr9Bvt5Bu9zlCxvnQCSsBjQ/MYZUldA7LqDEs4wI llUv2Dnl1Wu3lacmX6XXzzhGADOehdpBwuIbCf9i7nGFfGK8lgqZnSp6QR6VdGFGuPdl Ma8V0E392+1jHa6LDvv4LpoNa6E7ls/XD0eIFiz43AYaPGDJJ3ltydUlHdZyqmq1/VHU HJw6ATaWupGRGW/0aI26LoNcbShvZnD/1YAscwp7Ha4jJru1HFI9jLtmWKTQDDP+IR9D vb6Jv7NVX1gXFg0z4Thfa60i+qW39/dNa+BIiRqGM23jQlHDg1ay0rGUliYauEHNu33S UUFg== X-Gm-Message-State: AOAM533wam/PfuVkZBeThH4U7WCvsy+KzuA7jzm7vIkSMCqKnf+u5ySD uuXkODVa8XXs84hlN/EovYjfDQ== X-Google-Smtp-Source: ABdhPJzGjN/OiaZWZXI+A5qznvKAV8N/38y/N4mbFxjfX9tWUyAGv9EtHXHEYW/GLFF2lvfgq/eYSg== X-Received: by 2002:a17:90b:2249:b0:1dc:7905:c4bf with SMTP id hk9-20020a17090b224900b001dc7905c4bfmr730381pjb.62.1651686392625; Wed, 04 May 2022 10:46:32 -0700 (PDT) Received: from localhost ([2620:15c:202:201:35b6:c77b:be04:3bd5]) by smtp.gmail.com with UTF8SMTPSA id q26-20020a63505a000000b003aa8b87feb5sm15538347pgl.0.2022.05.04.10.46.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 May 2022 10:46:32 -0700 (PDT) Date: Wed, 4 May 2022 10:46:30 -0700 From: Matthias Kaehlcke To: Sandeep Maheswaram Cc: Rob Herring , Andy Gross , Bjorn Andersson , Greg Kroah-Hartman , Felipe Balbi , Stephen Boyd , Doug Anderson , Mathias Nyman , Krzysztof Kozlowski , "Rafael J . Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_pkondeti@quicinc.com, quic_ppratap@quicinc.com, quic_kriskura@quicinc.com, quic_vpulyala@quicinc.com Subject: Re: [PATCH v14 3/7] usb: dwc3: core: Host wake up support from system suspend Message-ID: References: <1650395470-31333-1-git-send-email-quic_c_sanm@quicinc.com> <1650395470-31333-4-git-send-email-quic_c_sanm@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1650395470-31333-4-git-send-email-quic_c_sanm@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Apr 20, 2022 at 12:41:06AM +0530, Sandeep Maheswaram wrote: > During suspend read the status of all port and set hs phy mode > based on current speed. Use this hs phy mode to configure wakeup > interrupts in qcom glue driver. > > Check wakeup-source property for dwc3 core node to set the > wakeup capability. Drop the device_init_wakeup call from > runtime suspend and resume. > > Also check during suspend if any wakeup capable devices are > connected to the controller (directly or through hubs), if there > are none set a flag to indicate that the PHY is powered > down during suspend. > > Signed-off-by: Sandeep Maheswaram > --- > v14: > Used device_children_wakeup_capable instead of usb_wakeup_enabled_descendants. > > v13: > Changed dwc3_set_phy_speed_mode to dwc3_check_phy_speed_mode. > Removed device_init_wakeup calls from dwc3_runtime_suspend and dwc3_runtime_resume > as we have a new dt property wakeup-source. > > > drivers/usb/dwc3/core.c | 33 ++++++++++++++++++++------------- > drivers/usb/dwc3/core.h | 4 ++++ > drivers/usb/dwc3/host.c | 24 ++++++++++++++++++++++++ > 3 files changed, 48 insertions(+), 13 deletions(-) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 1170b80..898aa66 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > > #include "core.h" > #include "gadget.h" > @@ -1723,6 +1724,7 @@ static int dwc3_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, dwc); > dwc3_cache_hwparams(dwc); > + device_init_wakeup(&pdev->dev, of_property_read_bool(dev->of_node, "wakeup-source")); > > spin_lock_init(&dwc->lock); > mutex_init(&dwc->mutex); > @@ -1865,6 +1867,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg) > { > unsigned long flags; > u32 reg; > + struct usb_hcd *hcd = platform_get_drvdata(dwc->xhci); > > switch (dwc->current_dr_role) { > case DWC3_GCTL_PRTCAP_DEVICE: > @@ -1877,10 +1880,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg) > dwc3_core_exit(dwc); > break; > case DWC3_GCTL_PRTCAP_HOST: > - if (!PMSG_IS_AUTO(msg)) { > - dwc3_core_exit(dwc); > - break; > - } > + dwc3_check_phy_speed_mode(dwc); > > /* Let controller to suspend HSPHY before PHY driver suspends */ > if (dwc->dis_u2_susphy_quirk || > @@ -1896,6 +1896,16 @@ static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg) > > phy_pm_runtime_put_sync(dwc->usb2_generic_phy); > phy_pm_runtime_put_sync(dwc->usb3_generic_phy); > + > + if (!PMSG_IS_AUTO(msg)) { > + if (device_may_wakeup(dwc->dev) && > + device_children_wakeup_capable(&hcd->self.root_hub->dev)) { > + dwc->phy_power_off = false; > + } else { > + dwc->phy_power_off = true; > + dwc3_core_exit(dwc); I found that shutting the PHYs down during suspend leads to high power consumption of a downstream hub (about 80mW vs 15mW when the PHYs are not shut down). It would be interesting to know if this also impacts other non-hub peripherals. Unfortunately I can't test that, the hub on my system is soldered to the board. I understand that shutting the PHYs down might be beneficial in terms of power on some systems, however on those I'm looking at we'd strongly prefer to save the 65mW of power consumed by the hub, rather than whatever smaller amount of power that is saved by powering down the PHYs. Could we introduce a sysfs attribute (or some other sort of knob) to allow the admin to configure whether the PHYs should remain on or off during suspend? That is assuming that it is actually desirable to power them off on some systems.