From: Ezequiel Garcia <ezequiel@collabora.com>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
linux-kernel@vger.kernel.org
Cc: briannorris@chromium.org, kernel@collabora.com, heiko@sntech.de,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, Felipe Balbi <balbi@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] usb: dwc3: of-simple: reset host controller at suspend/resume
Date: Mon, 09 Jul 2018 19:09:21 -0300 [thread overview]
Message-ID: <d9ea42a39a80c12b9d5730376d2f8e5a953771ef.camel@collabora.com> (raw)
In-Reply-To: <536642654ca55f08877497c86a5cb106d5458384.camel@collabora.com>
Sigh, now actually Cc devicetree folks
On Mon, 2018-07-09 at 19:04 -0300, Ezequiel Garcia wrote:
> (Cc devicetree folks)
>
> Hi Enric,
>
> Thanks for the patch.
>
> On Mon, 2018-07-09 at 17:08 +0200, Enric Balletbo i Serra wrote:
> > If we power off the SoC logic rail in S3, we can find that the
> > Type-C
> > PHY can't initialize correctly after system resume. We need to
> > toggle
> > the USB3-OTG reset before trying to initialize the PHY, or else it
> > times out.
> >
> > phy phy-ff800000.phy.9: phy poweron failed --> -110
> > dwc3 fe900000.dwc3: failed to initialize core
> > dwc3: probe of fe900000.dwc3 failed with error -110
> >
> > Note that the RK3399 TRM suggests that we should keep the whole
> > usb3
> > controller in reset for the duration of the Type-C PHY
> > initialization.
> > However, it's hard to assert the reset in the current framework of
> > reset. We're still skeptical about that, and we haven't yet found a
> > case where this seems to have mattered. This approach is much
> > easier,
> > it
> > simply holds the USB3-OTG reset while device is supended.
> >
> > The dwc3 core is going to reinitialize the controller at
> > suspend/resume
> > anyway (including a "soft reset"), so it should be safe to do this.
> >
> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com
> > >
> > ---
> > Dear all,
> >
> > Now that the usb3-phy otg port support for rk3399 has been merged
> > [1]
> > we
> > found that suspend/resume is broken. The problem is well known for
> > ChromeOS kernels, they solved it in a similar way adding a reset
> > pulse on
> > resume in the specific usb glue layer (dwc3-rockchip). In mainline,
> > though, we use the dwc3-of-simple glue layer instead of a specific
> > layer
> > for rockchip. The patch is based on the Brian Norris work but
> > slightly
> > different, it holds the reset while device is suspended. It was
> > tested
> > on a Samsung Chromebook Plus with usbc docking station attached by
> > doing
> > different suspend/resume cycles and checking no usb devices has
> > been
> > lost.
> >
> > I am not sure this is the better way to solve this but I did not
> > find
> > any other way, and, as I am not sure this can be generic, the reset
> > is only
> > done on rockchip platforms.
> >
>
> I don't really understand why there are per-platform hacks in glue
> drivers, instead of having per-platform glue drivers, or some other
> pluggable hooks.
>
> > Best regards,
> > Enric
> >
> > [1] bfdca1736ea76345071bbc5607d18928e54909ac ('arm64: dts:
> > rockchip:
> > add
> > usb3-phy otg-port support for rk3399')
> >
> > drivers/usb/dwc3/dwc3-of-simple.c | 21 +++++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
> > b/drivers/usb/dwc3/dwc3-of-simple.c
> > index dbeff5e6ad14..1d1ece99ed94 100644
> > --- a/drivers/usb/dwc3/dwc3-of-simple.c
> > +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> > @@ -201,9 +201,30 @@ static int
> > dwc3_of_simple_runtime_resume(struct
> > device *dev)
> >
> > return 0;
> > }
> > +
> > +static int dwc3_of_simple_suspend(struct device *dev)
> > +{
> > + struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> > +
> > + if (of_device_is_compatible(dev->of_node,
> > "rockchip,rk3399-
> > dwc3"))
> >
>
> Instead of calling of_device_is_compatible in each suspend/resume,
> which seems quite expensive, how about having a per-device boolean
> 'needs_reset' or something like that?
>
> Or maybe just have a boolean devicetree property for this?
>
> Regards,
> Eze
>
next parent reply other threads:[~2018-07-09 22:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180709150844.32505-1-enric.balletbo@collabora.com>
[not found] ` <536642654ca55f08877497c86a5cb106d5458384.camel@collabora.com>
2018-07-09 22:09 ` Ezequiel Garcia [this message]
2018-07-13 8:14 ` [PATCH] usb: dwc3: of-simple: reset host controller at suspend/resume Enric Balletbo Serra
2018-07-16 7:02 ` Felipe Balbi
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=d9ea42a39a80c12b9d5730376d2f8e5a953771ef.camel@collabora.com \
--to=ezequiel@collabora.com \
--cc=balbi@kernel.org \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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).