[PATCH v2 0/2] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[PATCH v2 0/2] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Douglas Anderson]

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit), which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

I've tested this series atop a bit of a conglomeration of Heiko's github
"somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
usb-next merged in.

===

I've posted up a bunch of patches recently but tried to keep them in
separate series where it makes sense.  A summary of known patches:
All patches can be found with: https://patchwork.kernel.org/patch/<ID>/

ACKed (thanks!) and not yet landed:
 7453801  usb: dwc2: host: Fix ahbcfg for rk3066
 7467521  usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Important, not yet reviewed:
 7421171  [1/2] usb: dwc2: host: Fix missing device insertions

Fixes no known issues, not yet reviewed:
 7421181  [2/2] usb: dwc2: host: Clear interrupts before handling them

Optimization to reduce probe time (may require simple rebase):
 7348131  [1/5] usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
 7348221  [2/5] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
 7348191  [3/5] CHROMIUM: usb: dwc2: Avoid double-reset at boot time
 7348211  [4/5] usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports
 7348201  [5/5] usb: dwc2: reduce dwc2 driver probe time
 7355241  usb: dwc2: Avoid more calls to dwc2_core_reset()

This series:
 usb: dwc2: optionally assert phy "full reset" when waking up
 ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

Coming soon:
 RFT: usb: dwc2: bus suspend/resume that's not hibernate

Abandoned for now (can't get wakeup to work on mainline):
 6727091  [REPOST,1/3] USB: Export usb_wakeup_enabled_descendants()
 6727101  [REPOST,2/3] Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
 6727121  [REPOST,3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled

Changes in v2:
- Use a full PHY reset for safety; no PHY changes needed for that.
- Cover letter explains outstanding patches

Doug Anderson (2):
  usb: dwc2: optionally assert phy "full reset" when waking up
  ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

 Documentation/devicetree/bindings/usb/dwc2.txt |  7 +++++++
 arch/arm/boot/dts/rk3288.dtsi                  |  5 +++++
 drivers/usb/dwc2/core.h                        |  5 +++++
 drivers/usb/dwc2/core_intr.c                   | 14 ++++++++++++++
 drivers/usb/dwc2/platform.c                    | 13 +++++++++++++
 5 files changed, 44 insertions(+)

-- 
2.6.0.rc2.230.g3dd15c0

[PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Douglas Anderson]

From: Doug Anderson <dianders@chromium.org>

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit), which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
---
Changes in v2:
- Use a full PHY reset for safety; no PHY changes needed for that.

 Documentation/devicetree/bindings/usb/dwc2.txt |  7 +++++++
 drivers/usb/dwc2/core.h                        |  5 +++++
 drivers/usb/dwc2/core_intr.c                   | 14 ++++++++++++++
 drivers/usb/dwc2/platform.c                    | 13 +++++++++++++
 4 files changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index fd132cbee70e..0de78c48c12d 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -17,6 +17,13 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties
 Optional properties:
 - phys: phy provider specifier
 - phy-names: shall be "usb2-phy"
+- snps,need-phy-full-reset-on-wake: if present indicates that we need to reset
+  the PHY when we detect a wakeup due to a hardware errata.  If present you
+  must specify a "phy-full-reset" reset.
+
+Resets:
+- phy-full-reset (optional): Fully resets the PHY.
+
 Refer to phy/phy-bindings.txt for generic phy consumer properties
 - dr_mode: shall be one of "host", "peripheral" and "otg"
   Refer to usb/generic.txt
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index a66d3cb62b65..ce1ef961ae6c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -582,8 +582,11 @@ struct dwc2_hregs_backup {
  * @hcd_enabled		Host mode sub-driver initialization indicator.
  * @gadget_enabled	Peripheral mode sub-driver initialization indicator.
  * @ll_hw_enabled	Status of low-level hardware resources.
+ * @need_phy_full_reset_on_wake: Quirk saying that we should assert
+ *                               phy_full_reset on a remote wakeup.
  * @phy:                The otg phy transceiver structure for phy control.
  * @uphy:               The otg phy transceiver structure for old USB phy control.
+ * @phy_full_reset:     Reset control for the PHY's "full reset".
  * @plat:               The platform specific configuration data. This can be removed once
  *                      all SoCs support usb transceiver.
  * @supplies:           Definition of USB power supplies
@@ -710,9 +713,11 @@ struct dwc2_hsotg {
 	unsigned int hcd_enabled:1;
 	unsigned int gadget_enabled:1;
 	unsigned int ll_hw_enabled:1;
+	unsigned int need_phy_full_reset_on_wake:1;
 
 	struct phy *phy;
 	struct usb_phy *uphy;
+	struct reset_control *phy_full_reset;
 	struct dwc2_hsotg_plat *plat;
 	struct regulator_bulk_data supplies[ARRAY_SIZE(dwc2_hsotg_supply_names)];
 	u32 phyif;
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 27daa42788b1..275484260192 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -45,6 +45,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/slab.h>
+#include <linux/reset.h>
 #include <linux/usb.h>
 
 #include <linux/usb/hcd.h>
@@ -378,6 +379,19 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
 			/* Restart the Phy Clock */
 			pcgcctl &= ~PCGCTL_STOPPCLK;
 			dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+			/*
+			 * If we've got this quirk then the PHY is stuck upon
+			 * wakeup.  Assert reset.  This will propagate out and
+			 * eventually we'll re-enumerate the device.  Not great
+			 * but the best we can do.
+			 */
+			if (hsotg->need_phy_full_reset_on_wake) {
+				reset_control_assert(hsotg->phy_full_reset);
+				udelay(50);
+				reset_control_deassert(hsotg->phy_full_reset);
+			}
+
 			mod_timer(&hsotg->wkp_timer,
 				  jiffies + msecs_to_jiffies(71));
 		} else {
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0fa19ee..1379b9cb0d39 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -45,6 +45,7 @@
 #include <linux/platform_device.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_data/s3c-hsotg.h>
+#include <linux/reset.h>
 
 #include <linux/usb/of.h>
 
@@ -376,6 +377,18 @@ static int dwc2_driver_probe(struct platform_device *dev)
 			"Configuration mismatch. Forcing peripheral mode\n");
 	}
 
+	hsotg->need_phy_full_reset_on_wake =
+		of_property_read_bool(dev->dev.of_node,
+				      "snps,need-phy-full-reset-on-wake");
+	hsotg->phy_full_reset = devm_reset_control_get(hsotg->dev,
+						       "phy-full-reset");
+	if (IS_ERR(hsotg->phy_full_reset) &&
+	    hsotg->need_phy_full_reset_on_wake) {
+		dev_warn(hsotg->dev, "Missing phy full reset (%ld); skipping\n",
+			 PTR_ERR(hsotg->phy_full_reset));
+		hsotg->need_phy_full_reset_on_wake = false;
+	}
+
 	retval = dwc2_lowlevel_hw_init(hsotg);
 	if (retval)
 		return retval;
-- 
2.6.0.rc2.230.g3dd15c0

[PATCH v2 2/2] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

[Douglas Anderson]

From: Doug Anderson <dianders@chromium.org>

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup.  We'll use the reset that's in the CRU to reset the
port when it's in a bad state.

Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata.  Only the host port gets the
quirk property, though.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Use a full PHY reset for safety; no PHY changes needed for that.

 arch/arm/boot/dts/rk3288.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938fb6bf..58773beb283f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -496,6 +496,9 @@
 		dr_mode = "host";
 		phys = <&usbphy2>;
 		phy-names = "usb2-phy";
+		resets = <&cru SRST_USBHOST1_PHY>;
+		reset-names = "phy-full-reset";
+		snps,need-phy-full-reset-on-wake;
 		status = "disabled";
 	};
 
@@ -513,6 +516,8 @@
 		g-use-dma;
 		phys = <&usbphy0>;
 		phy-names = "usb2-phy";
+		resets = <&cru SRST_USBOTG_PHY>;
+		reset-names = "phy-full-reset";
 		status = "disabled";
 	};
 
-- 
2.6.0.rc2.230.g3dd15c0

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Rob Herring]

On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson <dianders@chromium.org> wrote:
> From: Doug Anderson <dianders@chromium.org>
>
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).

I would think re-enumerating means autosuspend is broken.

> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
>
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit), which does a more full
> reset.  The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).

The reset from the CRU goes to the PHY, correct? Therefore, the
binding should reflect that. Connecting it to the host controller is a
hack.

So describe the reset connection properly and then add a .phy_reset()
hook to the phy subsystem. Then call that when flag property you added
is set.

Rob

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Doug Anderson]

Rob,

On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson <dianders@chromium.org> wrote:
>> From: Doug Anderson <dianders@chromium.org>
>>
>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>> port) the PHY can get into a bad state when a wakeup is asserted (not
>> just a wakeup from full system suspend but also a wakeup from
>> autosuspend).
>
> I would think re-enumerating means autosuspend is broken.

Yes, it is broken on this port.  I've been trying to figure out how to
disable autosuspend at the driver level.  Until then we can do it with
udev rules but that's much less ideal.

On our current system we have autosuispend turned off for most things
via udev and laptop-mode-tools.  ...so really the only case we see
this reset happen is if an empty hub is plugged in and then you plug
something into the hub.  The reset isn't terrible and is much better
than the device getting stuck.

You can also see the reset doing its thing if you fully suspend the
system and try to wake up from a keyboard or a mouse attached to the
port.  Being able to wake up (and then seeing a reset) is still better
than not being able to wake up.


>> We can get the PHY out of its bad state by asserting its "port reset",
>> but unfortunately that seems to assert a reset onto the USB bus so it
>> could confuse things if we don't actually deenumerate / reenumerate the
>> device.
>>
>> We can also get the PHY out of its bad state by fully resetting it using
>> the reset from the CRU (clock reset unit), which does a more full
>> reset.  The CRU-based reset appears to actually cause devices on the bus
>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>> way).
>
> The reset from the CRU goes to the PHY, correct? Therefore, the
> binding should reflect that. Connecting it to the host controller is a
> hack.
>
> So describe the reset connection properly and then add a .phy_reset()
> hook to the phy subsystem. Then call that when flag property you added
> is set.

As per previous email, I disagree.  The fact that there may be more
than one reset exposed from the PHY and that there is not a tightly
coupled relationship between a PHY driver and a USB driver means that
we would need to re-invent the reset API on top of the PHY API.  In my
case I am exposing a single reset at the moment, but there may be
reasons to expose additional "PHY" resets in the future.

http://www.gossamer-threads.com/lists/linux/kernel/2289780#2289780

...using the existing reset API seems better.

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Rob Herring]

On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson <dianders@chromium.org> wrote:
> Rob,
>
> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring <robh+dt@kernel.org> wrote:
>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson <dianders@chromium.org> wrote:
>>> From: Doug Anderson <dianders@chromium.org>

>>> We can get the PHY out of its bad state by asserting its "port reset",
>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>> could confuse things if we don't actually deenumerate / reenumerate the
>>> device.
>>>
>>> We can also get the PHY out of its bad state by fully resetting it using
>>> the reset from the CRU (clock reset unit), which does a more full
>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>> way).
>>
>> The reset from the CRU goes to the PHY, correct? Therefore, the
>> binding should reflect that. Connecting it to the host controller is a
>> hack.
>>
>> So describe the reset connection properly and then add a .phy_reset()
>> hook to the phy subsystem. Then call that when flag property you added
>> is set.
>
> As per previous email, I disagree.  The fact that there may be more
> than one reset exposed from the PHY and that there is not a tightly
> coupled relationship between a PHY driver and a USB driver means that
> we would need to re-invent the reset API on top of the PHY API.  In my
> case I am exposing a single reset at the moment, but there may be
> reasons to expose additional "PHY" resets in the future.

Your previous approach was completely different. I was not arguing
that the PHY driving reset to the host was wrong use of reset binding,
just that it was an overkill. Now, it is just flat wrong unless you
convince me that SRST_USBHOST1_PHY is a connection to the host rather
than the PHY.

Rob

Re: [PATCH v2 1/2] usb: dwc2: optionally assert phy "full reset" when waking up

[Doug Anderson]

Hi,

On Mon, Nov 2, 2015 at 9:16 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Mon, Nov 2, 2015 at 10:22 AM, Doug Anderson <dianders@chromium.org> wrote:
>> Rob,
>>
>> On Mon, Nov 2, 2015 at 8:12 AM, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Fri, Oct 30, 2015 at 3:17 PM, Douglas Anderson <dianders@chromium.org> wrote:
>>>> From: Doug Anderson <dianders@chromium.org>
>
>>>> We can get the PHY out of its bad state by asserting its "port reset",
>>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>>> could confuse things if we don't actually deenumerate / reenumerate the
>>>> device.
>>>>
>>>> We can also get the PHY out of its bad state by fully resetting it using
>>>> the reset from the CRU (clock reset unit), which does a more full
>>>> reset.  The CRU-based reset appears to actually cause devices on the bus
>>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>>> way).
>>>
>>> The reset from the CRU goes to the PHY, correct? Therefore, the
>>> binding should reflect that. Connecting it to the host controller is a
>>> hack.
>>>
>>> So describe the reset connection properly and then add a .phy_reset()
>>> hook to the phy subsystem. Then call that when flag property you added
>>> is set.
>>
>> As per previous email, I disagree.  The fact that there may be more
>> than one reset exposed from the PHY and that there is not a tightly
>> coupled relationship between a PHY driver and a USB driver means that
>> we would need to re-invent the reset API on top of the PHY API.  In my
>> case I am exposing a single reset at the moment, but there may be
>> reasons to expose additional "PHY" resets in the future.
>
> Your previous approach was completely different. I was not arguing
> that the PHY driving reset to the host was wrong use of reset binding,
> just that it was an overkill. Now, it is just flat wrong unless you
> convince me that SRST_USBHOST1_PHY is a connection to the host rather
> than the PHY.

It still seems to me that the argument that there can be multiple
types of "phy reset" is still a sane argument.  Just because we
currently happen to need the one that resets the whole PHY now doesn't
mean that we won't need other different resets later.

...and if you're exposing multiple different resets, then the reset
API is the best one to use.

I _could_ see the argument that perhaps the reset should pass through
the PHY driver so that it could possibly in the future be aware of the
reset.  That is: the SRST could use the reset API to expose the PHY
reset to the PHY driver and then the PHY driver could in turn expose
the PHY reset (using the reset API) to the dwc2 driver.  At the moment
this would be a complete pass through, but structuring it that way
would later allow the PHY to do something with the reset.  How about
that?

-Doug