From: Artur Petrosyan <Arthur.Petrosyan@synopsys.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
Felipe Balbi <felipe.balbi@linux.intel.com>,
"heiko@sntech.de" <heiko@sntech.de>,
"Alan Stern" <stern@rowland.harvard.edu>,
"amstan@chromium.org" <amstan@chromium.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
William Wu <william.wu@rock-chips.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Stefan Wahren <stefan.wahren@i2se.com>,
Randy Li <ayaka@soulik.info>,
"zyw@rock-chips.com" <zyw@rock-chips.com>,
"mka@chromium.org" <mka@chromium.org>,
"ryandcase@chromium.org" <ryandcase@chromium.org>,
Amelie Delaunay <amelie.delaunay@st.com>,
"jwerner@chromium.org" <jwerner@chromium.org>,
"dinguyen@opensource.altera.com" <dinguyen@opensource.altera.com>,
"Elaine Zhang" <zhangqing@rock-chips.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] usb: dwc2: bus suspend/resume for hosts with DWC2_POWER_DOWN_PARAM_NONE
Date: Tue, 30 Apr 2019 06:05:21 +0000 [thread overview]
Message-ID: <SN1PR12MB24317F315C5A4DFE70F9CB0DA73A0@SN1PR12MB2431.namprd12.prod.outlook.com> (raw)
Message-ID: <20190430060521.WgcfaEasQZfZ9WkCQ9cs5aeAKXXt9riu8D0Xw9hvN04@z> (raw)
In-Reply-To: CAD=FV=UOmfNeuZPrDcZRdwAkF4yRifCpBGUuZTsmmz0UVEZ+yA@mail.gmail.com
Hi,
On 4/29/2019 21:34, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 29, 2019 at 1:43 AM Artur Petrosyan
> <Arthur.Petrosyan@synopsys.com> wrote:
>>
>> Hi,
>>
>> On 4/18/2019 04:15, Douglas Anderson wrote:
>>> This is an attempt to rehash commit 0cf884e819e0 ("usb: dwc2: add bus
>>> suspend/resume for dwc2") on ToT. That commit was reverted in commit
>>> b0bb9bb6ce01 ("Revert "usb: dwc2: add bus suspend/resume for dwc2"")
>>> because apparently it broke the Altera SOCFPGA.
>>>
>>> With all the changes that have happened to dwc2 in the meantime, it's
>>> possible that the Altera SOCFPGA will just magically work with this
>>> change now. ...and it would be good to get bus suspend/resume
>>> implemented.
>>>
>>> This change is a forward port of one that's been living in the Chrome
>>> OS 3.14 kernel tree.
>>>
>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>> ---
>>> This patch was last posted at:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.kernel.org_r_1446237173-2D15263-2D1-2Dgit-2Dsend-2Demail-2Ddianders-40chromium.org&d=DwIDAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=9hPBFKCJ_nBjJhGVrrlYOeOQjP_HlVzYqrC_D7niMJI&m=MMfe-4lZePyty6F5zfQ54kiYGuJWNulyRat944LkOsc&s=nExFpAPP_0plZfO5LMG1B-mqt1vyCvE35elVcyVgs8Y&e=
>>>
>>> ...and appears to have died the death of silence. Maybe it could get
>>> some bake time in linuxnext if we can't find any proactive testing?
>>>
>>> I will also freely admit that I don't know tons about the theory
>>> behind this patch. I'm mostly just re-hashing the original commit
>>> from Kever that was reverted since:
>>> * Turning on partial power down on rk3288 doesn't "just work". I
>>> don't get hotplug events. This is despite dwc2 auto-detecting that
>>> we are power optimized.
>> What do you mean by doesn't "just work" ? It seem to me that even after
>> adding this patch you don't get issues fixed.
>> You mention that you don't get the hotplug events. Please provide dwc2
>> debug logs and register dumps on this issue.
>
> I mean that partial power down in the currently upstream driver
> doesn't work. AKA: if I turn on partial power down in the upstream
> driver then hotplug events break. I can try to provide some logs. On
> what exact version of the code do you want logs? Just your series?
> Just my series? Mainline? Some attempt at combining both series? As
> I said things seem to sorta work with the combined series. I can try
> to clarify if that's the series you want me to test with. ...or I can
> wait for your next version?
As I said this patch doesn't fix the issue with hotplug. With this patch
or without the hotplug behaves as it was. I have tested it on our setup.
Have you debugged your patch? Does it make any difference on your setup
? Does it fix the issue with hotplug?
Try to debug with the following steps.
1. Debug code with just your patch. Capture the logs and provide. So
that I can see what is difference with your patch.
2. Debug only with my series and see if those issues with hotplug are
still there.
>
>
>>> @@ -4506,21 +4507,35 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
>>> */
>>> if (!hsotg->bus_suspended) {
>>> hprt0 = dwc2_read_hprt0(hsotg);
>>> - hprt0 |= HPRT0_SUSP;
>>> - hprt0 &= ~HPRT0_PWR;
>>> - dwc2_writel(hsotg, hprt0, HPRT0);
>>> - spin_unlock_irqrestore(&hsotg->lock, flags);
>>> - dwc2_vbus_supply_exit(hsotg);
>>> - spin_lock_irqsave(&hsotg->lock, flags);
>>> + if (hprt0 & HPRT0_CONNSTS) { > + hprt0 |= HPRT0_SUSP;
>> Here you set "HPRT0_SUSP" bit but what if core doesn't support both
>> hibernation and Partial Power down assuming that
>> hsotg->params.power_down" value us equal to "DWC2_POWER_DOWN_PARAM_NONE"
>> which is 0.
>
> I am by no means an expert on dwc2, but an assumption made in my patch
> is that even cores that can't support partial power down can still
> save some amount of power when hcd_suspend is called.
Have you tried to debug dwc2 with power_down == DWC2_POWER_DOWN_PARAM_NONE ?
>
> Some evidence that this should be possible: looking at mainline Linux
> and at dwc2_port_suspend(), I see:
>
> * It is currently called even when we have DWC2_POWER_DOWN_PARAM_NONE
Currently (without your and my patches) (looking at mainline Linux) the
function dwc2_port_suspend() is called anyway because its call is issued
by the system. But it performs entering to suspend only in case of
DWC2_POWER_DOWN_PARAM_PARTIAL.
This is not an assumption. What I am pointing out is based on debugging
and before making assumptions without debugging for me seems not ok.
Currently without your patch and without my patches. In the
dwc2_port_suspend() it will enter to suspend only in case that
power_down == DWC2_POWER_DOWN_PARAM_PARTIAL. Because if you look at the
code more carefully you will see
if (hsotg->params.power_down != DWC2_POWER_DOWN_PARAM_PARTIAL)
goto skip_power_saving;
This says if power_down is not DWC2_POWER_DOWN_PARAM_PARTIAL then skip
power saving.
So but after your patch. If power_down is DWC2_POWER_DOWN_PARAM_NONE it
tries to suspend.
>
> * It currently sets HPRT0_SUSP
>
> * It currently sets PCGCTL_STOPPCLK specifically in the case where
> power down is DWC2_POWER_DOWN_PARAM_NONE.
It currently (without my and your patches) doesn't set PCGCTL_STOPPCLK
when power down is DWC2_POWER_DOWN_PARAM_NONE. Because again and again
when power down is DWC2_POWER_DOWN_PARAM_NONE power saving is skipped.
>
> ...I believe that the net effect of my patch ends up doing both those
> same two things in hcd_suspend. That is: when power_down is
> DWC2_POWER_DOWN_PARAM_NONE I believe my patch is really just doing the
> same thing that dwc2_port_suspend() would do in the same case. Is
> that not OK?
No if your patch is doing the same thing as it was doing before what is
the purpose of the patch ?
My testes show that your patch doesn't fix the issue related partial
power down.
>
>
>
>>> + if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_PARTIAL)
>> You make one checking of hsotg->params.power_down mode here.
>>> + hprt0 &= ~HPRT0_PWR;
>>> + dwc2_writel(hsotg, hprt0, HPRT0);
>>> + }
>>> + if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_PARTIAL) {
>> another checking of power_down mode here.
>
> Yeah, we can debate about how to best share/split code. I'm not in
> love with the current structure either. When I rebased your patches
> atop mine I changed this to more fully split them and I agree that was
> better.
>
>
>>> @@ -4592,10 +4612,12 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
>>> spin_unlock_irqrestore(&hsotg->lock, flags);
>>> dwc2_port_resume(hsotg);
>>> } else {
>>> - dwc2_vbus_supply_init(hsotg);
>>> + if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_PARTIAL) {
>>> + dwc2_vbus_supply_init(hsotg);
>>>
>>> - /* Wait for controller to correctly update D+/D- level */
>>> - usleep_range(3000, 5000);
>>> + /* Wait for controller to correctly update D+/D- level */
>>> + usleep_range(3000, 5000);
>>> + }
>>>
>>> /*
>>> * Clear Port Enable and Port Status changes.
>>>
>>
>> I have tested the patch on HAPS-DX. With this patch or without it when I
>> have a device connected core enters to partial power down and doesn't
>> exit from it. So I cannot use the device.
>
> Can you explain what HAPS-DX is?
It is the general setup to perform our use case testes.
For more information about the details you can google about it.
>
>
> -Doug
>
--
Regards,
Artur
next prev parent reply other threads:[~2019-04-30 6:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-18 0:13 [PATCH v2 0/5] USB: dwc2: Allow wakeup from suspend; enable for rk3288-veyron Douglas Anderson
2019-04-18 0:13 ` [v2,1/5] usb: dwc2: bus suspend/resume for hosts with DWC2_POWER_DOWN_PARAM_NONE Doug Anderson
2019-04-18 0:13 ` [PATCH v2 1/5] " Douglas Anderson
2019-04-29 8:43 ` [v2,1/5] " Artur Petrosyan
2019-04-29 8:43 ` [PATCH v2 1/5] " Artur Petrosyan
2019-04-29 17:33 ` [v2,1/5] " Doug Anderson
2019-04-29 17:33 ` [PATCH v2 1/5] " Doug Anderson
2019-04-30 6:05 ` Artur Petrosyan [this message]
2019-04-30 6:05 ` Artur Petrosyan
2019-05-01 1:51 ` [v2,1/5] " Doug Anderson
2019-05-01 1:51 ` [PATCH v2 1/5] " Doug Anderson
2019-05-03 8:20 ` [v2,1/5] " Artur Petrosyan
2019-05-03 8:20 ` [PATCH v2 1/5] " Artur Petrosyan
2019-05-03 15:03 ` [v2,1/5] " Doug Anderson
2019-05-03 15:03 ` [PATCH v2 1/5] " Doug Anderson
2019-05-07 7:26 ` Artur Petrosyan
2019-05-01 23:58 ` [v2,1/5] " Doug Anderson
2019-05-01 23:58 ` [PATCH v2 1/5] " Doug Anderson
2019-05-03 8:25 ` [v2,1/5] " Artur Petrosyan
2019-05-03 8:25 ` [PATCH v2 1/5] " Artur Petrosyan
2019-05-03 15:07 ` [v2,1/5] " Doug Anderson
2019-05-03 15:07 ` [PATCH v2 1/5] " Doug Anderson
2019-05-07 7:05 ` Artur Petrosyan
2019-04-18 0:13 ` [v2,2/5] USB: Export usb_wakeup_enabled_descendants() Doug Anderson
2019-04-18 0:13 ` [PATCH v2 2/5] " Douglas Anderson
2019-04-18 0:13 ` [v2,3/5] Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB Doug Anderson
2019-04-18 0:13 ` [PATCH v2 3/5] " Douglas Anderson
2019-04-25 12:40 ` [v2,3/5] " Felipe Balbi
2019-04-25 12:40 ` [PATCH v2 3/5] " Felipe Balbi
2019-04-25 18:09 ` [v2,3/5] " Doug Anderson
2019-04-25 18:09 ` [PATCH v2 3/5] " Doug Anderson
2019-04-25 19:58 ` [v2,3/5] " Doug Anderson
2019-04-25 19:58 ` [PATCH v2 3/5] " Doug Anderson
2019-05-02 18:36 ` [v2,3/5] " Doug Anderson
2019-05-02 18:36 ` [PATCH v2 3/5] " Doug Anderson
2019-04-30 1:23 ` [v2,3/5] " Rob Herring
2019-04-30 1:23 ` [PATCH v2 3/5] " Rob Herring
2019-04-30 5:25 ` [v2,3/5] " Doug Anderson
2019-04-30 5:25 ` [PATCH v2 3/5] " Doug Anderson
2019-04-18 0:13 ` [v2,4/5] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled Doug Anderson
2019-04-18 0:13 ` [PATCH v2 4/5] " Douglas Anderson
2019-04-25 12:41 ` [v2,4/5] " Felipe Balbi
2019-04-25 12:41 ` [PATCH v2 4/5] " Felipe Balbi
2019-04-18 0:13 ` [v2,5/5] ARM: dts: rockchip: Allow wakeup from rk3288-veyron's dwc2 USB ports Doug Anderson
2019-04-18 0:13 ` [PATCH v2 5/5] " Douglas Anderson
2019-04-18 12:40 ` [PATCH v2 0/5] USB: dwc2: Allow wakeup from suspend; enable for rk3288-veyron Minas Harutyunyan
2019-04-18 15:54 ` Doug Anderson
2019-04-19 11:43 ` Artur Petrosyan
2019-04-19 16:44 ` Artur Petrosyan
2019-04-22 15:50 ` Artur Petrosyan
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=SN1PR12MB24317F315C5A4DFE70F9CB0DA73A0@SN1PR12MB2431.namprd12.prod.outlook.com \
--to=arthur.petrosyan@synopsys.com \
--cc=Minas.Harutyunyan@synopsys.com \
--cc=amelie.delaunay@st.com \
--cc=amstan@chromium.org \
--cc=ayaka@soulik.info \
--cc=dianders@chromium.org \
--cc=dinguyen@opensource.altera.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=mka@chromium.org \
--cc=ryandcase@chromium.org \
--cc=stefan.wahren@i2se.com \
--cc=stern@rowland.harvard.edu \
--cc=william.wu@rock-chips.com \
--cc=zhangqing@rock-chips.com \
--cc=zyw@rock-chips.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).