| Message ID | 1472939729-15187-4-git-send-email-ayaka@soulik.info (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/04/2016 12:55 AM, Randy Li wrote: > 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) in chip, 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: Randy Li <ayaka@soulik.info> > --- > drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c > index d85c5c9..08485b7 100644 > --- a/drivers/usb/dwc2/core_intr.c > +++ b/drivers/usb/dwc2/core_intr.c [...] > @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) > /* Restart the Phy Clock */ > pcgcctl &= ~PCGCTL_STOPPCLK; > dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); > + > + /* > + * It is a quirk in Rockchip RK3288, causing by > + * a hardware bug. This will propagate out and > + * eventually we'll re-enumerate the device. > + * Not great but the best we can do > + */ > + if (of_device_is_compatible(np, "rockchip,rk3288-usb") > + && (NULL != hsotg->phy->ops->reset)) Don't reverse the operands of !=, please. [...] MBR, Sergei
From: Randy Li > Sent: 03 September 2016 22:55 ... > + if (of_device_is_compatible(np, "rockchip,rk3288-usb") > + && (NULL != hsotg->phy->ops->reset)) > + hsotg->phy->ops->reset(hsotg->phy); > + Is this the only place ops->reset() is called? Probably much better to check it first. if (hsotg->phy->ops->reset && of_device_is_compatible(np, "rockchip,rk3288-usb") hsotg->phy->ops->reset(hsotg->phy); David
從我的 iPad 傳送 > David Laight <David.Laight@ACULAB.COM> 於 2016年9月5日 下午9:35 寫道： > > From: Randy Li >> Sent: 03 September 2016 22:55 > ... >> + if (of_device_is_compatible(np, "rockchip,rk3288-usb") >> + && (NULL != hsotg->phy->ops->reset)) >> + hsotg->phy->ops->reset(hsotg->phy); >> + > > Is this the only place ops->reset() is called? Yes. > Probably much better to check it first. Sure. > > if (hsotg->phy->ops->reset > && of_device_is_compatible(np, "rockchip,rk3288-usb") > hsotg->phy->ops->reset(hsotg->phy); I see, if there is no the other review request for this version, I would submit a new version to fix this problem tonight. > > David
Hi, On Sunday 04 September 2016 03:25 AM, Randy Li wrote: > 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) in chip, 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: Randy Li <ayaka@soulik.info> > --- > drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c > index d85c5c9..08485b7 100644 > --- a/drivers/usb/dwc2/core_intr.c > +++ b/drivers/usb/dwc2/core_intr.c > @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg) > static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) > { > int ret; > + struct device_node *np = hsotg->dev->of_node; > > /* Clear interrupt */ > dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS); > @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) > /* Restart the Phy Clock */ > pcgcctl &= ~PCGCTL_STOPPCLK; > dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); > + > + /* > + * It is a quirk in Rockchip RK3288, causing by > + * a hardware bug. This will propagate out and > + * eventually we'll re-enumerate the device. > + * Not great but the best we can do > + */ > + if (of_device_is_compatible(np, "rockchip,rk3288-usb") > + && (NULL != hsotg->phy->ops->reset)) > + hsotg->phy->ops->reset(hsotg->phy); never call the phy ops directly from the controller driver. It has to be protected as well. Thanks Kishon
On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Sunday 04 September 2016 03:25 AM, Randy Li wrote: >> 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) in chip, 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: Randy Li <ayaka@soulik.info> >> --- >> drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c >> index d85c5c9..08485b7 100644 >> --- a/drivers/usb/dwc2/core_intr.c >> +++ b/drivers/usb/dwc2/core_intr.c >> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg) >> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >> { >> int ret; >> + struct device_node *np = hsotg->dev->of_node; >> >> /* Clear interrupt */ >> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS); >> @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >> /* Restart the Phy Clock */ >> pcgcctl &= ~PCGCTL_STOPPCLK; >> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); >> + >> + /* >> + * It is a quirk in Rockchip RK3288, causing by >> + * a hardware bug. This will propagate out and >> + * eventually we'll re-enumerate the device. >> + * Not great but the best we can do >> + */ >> + if (of_device_is_compatible(np, "rockchip,rk3288-usb") >> + && (NULL != hsotg->phy->ops->reset)) >> + hsotg->phy->ops->reset(hsotg->phy); > > never call the phy ops directly from the controller driver. It has to be > protected as well. It looks like we should be calling an API function instead, correct? Similar to the wrappers for the other ops. Regards, John
從我的 iPad 傳送 > John Youn <John.Youn@synopsys.com> 於 2016年9月7日 上午2:54 寫道： > >> On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >>> On Sunday 04 September 2016 03:25 AM, Randy Li wrote: >>> 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) in chip, 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: Randy Li <ayaka@soulik.info> >>> --- >>> drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c >>> index d85c5c9..08485b7 100644 >>> --- a/drivers/usb/dwc2/core_intr.c >>> +++ b/drivers/usb/dwc2/core_intr.c >>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg) >>> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >>> { >>> int ret; >>> + struct device_node *np = hsotg->dev->of_node; >>> >>> /* Clear interrupt */ >>> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS); >>> @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >>> /* Restart the Phy Clock */ >>> pcgcctl &= ~PCGCTL_STOPPCLK; >>> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); >>> + >>> + /* >>> + * It is a quirk in Rockchip RK3288, causing by >>> + * a hardware bug. This will propagate out and >>> + * eventually we'll re-enumerate the device. >>> + * Not great but the best we can do >>> + */ >>> + if (of_device_is_compatible(np, "rockchip,rk3288-usb") >>> + && (NULL != hsotg->phy->ops->reset)) >>> + hsotg->phy->ops->reset(hsotg->phy); >> >> never call the phy ops directly from the controller driver. It has to be >> protected as well. > > It looks like we should be calling an API function instead, correct? > Could you give me a example for the wrapper of phy ops? > Similar to the wrappers for the other ops. > > Regards, > John
On 9/6/2016 6:19 PM, Ayaka wrote: > > > 從我的 iPad 傳送 > >> John Youn <John.Youn@synopsys.com> 於 2016年9月7日 上午2:54 寫道： >> >>> On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>>> On Sunday 04 September 2016 03:25 AM, Randy Li wrote: >>>> 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) in chip, 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: Randy Li <ayaka@soulik.info> >>>> --- >>>> drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c >>>> index d85c5c9..08485b7 100644 >>>> --- a/drivers/usb/dwc2/core_intr.c >>>> +++ b/drivers/usb/dwc2/core_intr.c >>>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg) >>>> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >>>> { >>>> int ret; >>>> + struct device_node *np = hsotg->dev->of_node; >>>> >>>> /* Clear interrupt */ >>>> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS); >>>> @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) >>>> /* Restart the Phy Clock */ >>>> pcgcctl &= ~PCGCTL_STOPPCLK; >>>> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); >>>> + >>>> + /* >>>> + * It is a quirk in Rockchip RK3288, causing by >>>> + * a hardware bug. This will propagate out and >>>> + * eventually we'll re-enumerate the device. >>>> + * Not great but the best we can do >>>> + */ >>>> + if (of_device_is_compatible(np, "rockchip,rk3288-usb") >>>> + && (NULL != hsotg->phy->ops->reset)) >>>> + hsotg->phy->ops->reset(hsotg->phy); >>> >>> never call the phy ops directly from the controller driver. It has to be >>> protected as well. >> >> It looks like we should be calling an API function instead, correct? >> > Could you give me a example for the wrapper of phy ops? Check these files: * include/linux/phy/phy.h * drivers/phy/phy-core.c Search for "phy_set_mode". I'm thinking there should be a "phy_reset" API function which calls the phy->ops->reset in a similar manner. With the same runtime checks and stub function if CONFIG_GENERIC_PHY is not enabled. Regards, John
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c index d85c5c9..08485b7 100644 --- a/drivers/usb/dwc2/core_intr.c +++ b/drivers/usb/dwc2/core_intr.c @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg) static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) { int ret; + struct device_node *np = hsotg->dev->of_node; /* Clear interrupt */ dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS); @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg) /* Restart the Phy Clock */ pcgcctl &= ~PCGCTL_STOPPCLK; dwc2_writel(pcgcctl, hsotg->regs + PCGCTL); + + /* + * It is a quirk in Rockchip RK3288, causing by + * a hardware bug. This will propagate out and + * eventually we'll re-enumerate the device. + * Not great but the best we can do + */ + if (of_device_is_compatible(np, "rockchip,rk3288-usb") + && (NULL != hsotg->phy->ops->reset)) + hsotg->phy->ops->reset(hsotg->phy); + mod_timer(&hsotg->wkp_timer, jiffies + msecs_to_jiffies(71)); } else {
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) in chip, 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: Randy Li <ayaka@soulik.info> --- drivers/usb/dwc2/core_intr.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)