Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi Manu, On 21 July 2017 at 10:32, Baolin Wang wrote: > Hi Manu, > > On 20 July 2017 at 19:12, Manu Gautam wrote: >> Hi, >> >> >> On 7/13/2017 1:13 PM, Baolin Wang wrote: >>> Hi, >>> >>> On 13 July 2017 at 15:26, Manu Gautam wrote: On 7/13/2017 11:33 AM, Baolin Wang wrote: > On 12 July 2017 at 16:58, Manu Gautam wrote: >> On 7/12/2017 2:06 PM, Baolin Wang wrote: >>> Hi, >>> >>> On 12 July 2017 at 15:25, Manu Gautam wrote: On 7/12/2017 12:19 PM, Baolin Wang wrote: > Hi, > > On 3 July 2017 at 19:25, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >> bus as part of bus_suspend/resume is not correct which could affect >> (or disconnect) connected devices. >> Fix this by not reinitializing core on suspend/resume in host mode >> for HOST only and OTG/drd configurations. > But for some mobile devices, they also need suspend/resume in host > mode which will power off dwc3 controller in glue layer. If we remove > dwc3_core_init() for host mode, I am afraid it can not work well in > host mode after resuming dwc3. Can you point me to a glue driver doing that? >>> Yes, now there are no glue driver doing that, but for many vendor >>> trees they will do that. (Our platform will power off dwc3 when >>> suspending dwc3, but have not upstreamed yet) >> Fine, but glue driver still need to take care of re-initialization on >> resume >> with current design. > Yes. > If dwc3 is powered off on suspend then Xhci level initialization also needed after performing dwc3_core_init on resume which is currently not present. So this seems to me broken anyway. >>> Since we've add runtime PM for xhci-plat driver [1], which means we >>> can runtime suspend/resume xhci device from dwc3 [2]. >>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html >>> [2] https://patchwork.kernel.org/patch/9471869/ >> Sure. We can discuss this patch once you re-submit. >> One concern I have with the patch is marking ignore_children for dwc3 >> and as >> part of >> dwc3 suspend/resume invoking > Suppose we will suspend xhci device as dwc3's child, but now dwc3 > device is not suspend yet, which will block to suspend xhci device. > Thus we should set ignore children flag to remove the parent > dependency. I may not have understood the issue. In any case children must be suspended first. Example sequence is: external hub/device (if any) suspend -> root hub -> xhci -> dwc3 core -> dwc3 glue. xhci device's runtime/pm suspend should happen before dwc3 gets suspended. >>> Since the [2] patch will get/put xhci usage counter to avoid affecting >>> other controller's runtime PM, then we need ignore child. But now >>> xhci-plat driver has done this (by issuing pm_runtime_forbid() >>> default), we can remove the get/put counter in dwc3, then we do not >>> need ignore child flag any more. >>> >> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. >> suspending dwc3 >> once xhci gets suspended and pm_stay_awake/relax can be used to block >> pm_suspend >> until runtime suspend of glue driver happens. >> >>> But [2] has not applied yet now, I will try to upstream it again. Then >>> we can suspend xhci device--> suspend dwc3 host---> glue layer can >>> power off, and it is similar when resuming in host mode. >> Do you see any issues with this patch? >> I am able to get runtime suspend/resume happening fine with XHCI on my >> platform. >> It involves runtime suspend/resume of USB HUB and dwc3 glue driver >> without >> any other >> change. > Great, I will try this patch again. >> >> Baolin, just checking if you were able to test this? > > Yes, I will test this and resubmit again next week. I've resubmit this patch and we still need the ignore children flag from my testing. As I explained in the commit message, we will resume the child device (xHCI device) in dwc3 device's runtime resume callback, and now dwc3 device is not ACTIVE state which will block to resume its child device (xHCI device), then we should need this ignore child flag. It can work well on my platform, would you like to test this patch on your platform? Thanks. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi Manu, On 20 July 2017 at 19:12, Manu Gautam wrote: > Hi, > > > On 7/13/2017 1:13 PM, Baolin Wang wrote: >> Hi, >> >> On 13 July 2017 at 15:26, Manu Gautam wrote: >>> >>> On 7/13/2017 11:33 AM, Baolin Wang wrote: On 12 July 2017 at 16:58, Manu Gautam wrote: > On 7/12/2017 2:06 PM, Baolin Wang wrote: >> Hi, >> >> On 12 July 2017 at 15:25, Manu Gautam wrote: >>> On 7/12/2017 12:19 PM, Baolin Wang wrote: Hi, On 3 July 2017 at 19:25, Manu Gautam wrote: > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also, resetting > bus as part of bus_suspend/resume is not correct which could affect > (or disconnect) connected devices. > Fix this by not reinitializing core on suspend/resume in host mode > for HOST only and OTG/drd configurations. But for some mobile devices, they also need suspend/resume in host mode which will power off dwc3 controller in glue layer. If we remove dwc3_core_init() for host mode, I am afraid it can not work well in host mode after resuming dwc3. >>> Can you point me to a glue driver doing that? >> Yes, now there are no glue driver doing that, but for many vendor >> trees they will do that. (Our platform will power off dwc3 when >> suspending dwc3, but have not upstreamed yet) > Fine, but glue driver still need to take care of re-initialization on > resume > with current design. Yes. >>> If dwc3 is powered off on suspend then Xhci level initialization also >>> needed >>> after >>> performing dwc3_core_init on resume which is currently not present. So >>> this >>> seems >>> to me broken anyway. >> Since we've add runtime PM for xhci-plat driver [1], which means we >> can runtime suspend/resume xhci device from dwc3 [2]. >> [1] https://www.spinics.net/lists/linux-usb/msg156077.html >> [2] https://patchwork.kernel.org/patch/9471869/ > Sure. We can discuss this patch once you re-submit. > One concern I have with the patch is marking ignore_children for dwc3 and > as > part of > dwc3 suspend/resume invoking Suppose we will suspend xhci device as dwc3's child, but now dwc3 device is not suspend yet, which will block to suspend xhci device. Thus we should set ignore children flag to remove the parent dependency. >>> I may not have understood the issue. In any case children must be suspended >>> first. >>> Example sequence is: >>> external hub/device (if any) suspend -> root hub -> xhci -> dwc3 core -> >>> dwc3 glue. >>> xhci device's runtime/pm suspend should happen before dwc3 gets suspended. >> Since the [2] patch will get/put xhci usage counter to avoid affecting >> other controller's runtime PM, then we need ignore child. But now >> xhci-plat driver has done this (by issuing pm_runtime_forbid() >> default), we can remove the get/put counter in dwc3, then we do not >> need ignore child flag any more. >> > runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. > suspending dwc3 > once xhci gets suspended and pm_stay_awake/relax can be used to block > pm_suspend > until runtime suspend of glue driver happens. > >> But [2] has not applied yet now, I will try to upstream it again. Then >> we can suspend xhci device--> suspend dwc3 host---> glue layer can >> power off, and it is similar when resuming in host mode. > Do you see any issues with this patch? > I am able to get runtime suspend/resume happening fine with XHCI on my > platform. > It involves runtime suspend/resume of USB HUB and dwc3 glue driver without > any other > change. Great, I will try this patch again. > > Baolin, just checking if you were able to test this? Yes, I will test this and resubmit again next week. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi, On 7/13/2017 1:13 PM, Baolin Wang wrote: > Hi, > > On 13 July 2017 at 15:26, Manu Gautam wrote: >> >> On 7/13/2017 11:33 AM, Baolin Wang wrote: >>> On 12 July 2017 at 16:58, Manu Gautam wrote: On 7/12/2017 2:06 PM, Baolin Wang wrote: > Hi, > > On 12 July 2017 at 15:25, Manu Gautam wrote: >> On 7/12/2017 12:19 PM, Baolin Wang wrote: >>> Hi, >>> >>> On 3 July 2017 at 19:25, Manu Gautam wrote: Driver powers-off PHYs and reinitializes DWC3 core and gadget on resume. While this works fine for gadget mode but in host mode there is not re-initialization of host stack. Also, resetting bus as part of bus_suspend/resume is not correct which could affect (or disconnect) connected devices. Fix this by not reinitializing core on suspend/resume in host mode for HOST only and OTG/drd configurations. >>> But for some mobile devices, they also need suspend/resume in host >>> mode which will power off dwc3 controller in glue layer. If we remove >>> dwc3_core_init() for host mode, I am afraid it can not work well in >>> host mode after resuming dwc3. >> Can you point me to a glue driver doing that? > Yes, now there are no glue driver doing that, but for many vendor > trees they will do that. (Our platform will power off dwc3 when > suspending dwc3, but have not upstreamed yet) Fine, but glue driver still need to take care of re-initialization on resume with current design. >>> Yes. >>> >> If dwc3 is powered off on suspend then Xhci level initialization also >> needed >> after >> performing dwc3_core_init on resume which is currently not present. So >> this >> seems >> to me broken anyway. > Since we've add runtime PM for xhci-plat driver [1], which means we > can runtime suspend/resume xhci device from dwc3 [2]. > [1] https://www.spinics.net/lists/linux-usb/msg156077.html > [2] https://patchwork.kernel.org/patch/9471869/ Sure. We can discuss this patch once you re-submit. One concern I have with the patch is marking ignore_children for dwc3 and as part of dwc3 suspend/resume invoking >>> Suppose we will suspend xhci device as dwc3's child, but now dwc3 >>> device is not suspend yet, which will block to suspend xhci device. >>> Thus we should set ignore children flag to remove the parent >>> dependency. >> I may not have understood the issue. In any case children must be suspended >> first. >> Example sequence is: >> external hub/device (if any) suspend -> root hub -> xhci -> dwc3 core -> >> dwc3 glue. >> xhci device's runtime/pm suspend should happen before dwc3 gets suspended. > Since the [2] patch will get/put xhci usage counter to avoid affecting > other controller's runtime PM, then we need ignore child. But now > xhci-plat driver has done this (by issuing pm_runtime_forbid() > default), we can remove the get/put counter in dwc3, then we do not > need ignore child flag any more. > runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. suspending dwc3 once xhci gets suspended and pm_stay_awake/relax can be used to block pm_suspend until runtime suspend of glue driver happens. > But [2] has not applied yet now, I will try to upstream it again. Then > we can suspend xhci device--> suspend dwc3 host---> glue layer can > power off, and it is similar when resuming in host mode. Do you see any issues with this patch? I am able to get runtime suspend/resume happening fine with XHCI on my platform. It involves runtime suspend/resume of USB HUB and dwc3 glue driver without any other change. >>> Great, I will try this patch again. Baolin, just checking if you were able to test this? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi, On 13 July 2017 at 15:26, Manu Gautam wrote: > > > On 7/13/2017 11:33 AM, Baolin Wang wrote: >> On 12 July 2017 at 16:58, Manu Gautam wrote: >>> >>> On 7/12/2017 2:06 PM, Baolin Wang wrote: Hi, On 12 July 2017 at 15:25, Manu Gautam wrote: > > On 7/12/2017 12:19 PM, Baolin Wang wrote: >> Hi, >> >> On 3 July 2017 at 19:25, Manu Gautam wrote: >>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >>> resume. While this works fine for gadget mode but in host >>> mode there is not re-initialization of host stack. Also, resetting >>> bus as part of bus_suspend/resume is not correct which could affect >>> (or disconnect) connected devices. >>> Fix this by not reinitializing core on suspend/resume in host mode >>> for HOST only and OTG/drd configurations. >> But for some mobile devices, they also need suspend/resume in host >> mode which will power off dwc3 controller in glue layer. If we remove >> dwc3_core_init() for host mode, I am afraid it can not work well in >> host mode after resuming dwc3. > Can you point me to a glue driver doing that? Yes, now there are no glue driver doing that, but for many vendor trees they will do that. (Our platform will power off dwc3 when suspending dwc3, but have not upstreamed yet) >>> >>> Fine, but glue driver still need to take care of re-initialization on resume >>> with current design. >> Yes. >> > If dwc3 is powered off on suspend then Xhci level initialization also > needed > after > performing dwc3_core_init on resume which is currently not present. So > this > seems > to me broken anyway. Since we've add runtime PM for xhci-plat driver [1], which means we can runtime suspend/resume xhci device from dwc3 [2]. [1] https://www.spinics.net/lists/linux-usb/msg156077.html [2] https://patchwork.kernel.org/patch/9471869/ >>> >>> Sure. We can discuss this patch once you re-submit. >>> One concern I have with the patch is marking ignore_children for dwc3 and as >>> part of >>> dwc3 suspend/resume invoking >> Suppose we will suspend xhci device as dwc3's child, but now dwc3 >> device is not suspend yet, which will block to suspend xhci device. >> Thus we should set ignore children flag to remove the parent >> dependency. > > I may not have understood the issue. In any case children must be suspended > first. > Example sequence is: > external hub/device (if any) suspend -> root hub -> xhci -> dwc3 core -> > dwc3 glue. > xhci device's runtime/pm suspend should happen before dwc3 gets suspended. Since the [2] patch will get/put xhci usage counter to avoid affecting other controller's runtime PM, then we need ignore child. But now xhci-plat driver has done this (by issuing pm_runtime_forbid() default), we can remove the get/put counter in dwc3, then we do not need ignore child flag any more. >>> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. >>> suspending dwc3 >>> once xhci gets suspended and pm_stay_awake/relax can be used to block >>> pm_suspend >>> until runtime suspend of glue driver happens. >>> But [2] has not applied yet now, I will try to upstream it again. Then we can suspend xhci device--> suspend dwc3 host---> glue layer can power off, and it is similar when resuming in host mode. >>> >>> Do you see any issues with this patch? >>> I am able to get runtime suspend/resume happening fine with XHCI on my >>> platform. >>> It involves runtime suspend/resume of USB HUB and dwc3 glue driver without >>> any other >>> change. >> Great, I will try this patch again. >> > -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
On 7/13/2017 11:33 AM, Baolin Wang wrote: > On 12 July 2017 at 16:58, Manu Gautam wrote: >> >> On 7/12/2017 2:06 PM, Baolin Wang wrote: >>> Hi, >>> >>> On 12 July 2017 at 15:25, Manu Gautam wrote: On 7/12/2017 12:19 PM, Baolin Wang wrote: > Hi, > > On 3 July 2017 at 19:25, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >> bus as part of bus_suspend/resume is not correct which could affect >> (or disconnect) connected devices. >> Fix this by not reinitializing core on suspend/resume in host mode >> for HOST only and OTG/drd configurations. > But for some mobile devices, they also need suspend/resume in host > mode which will power off dwc3 controller in glue layer. If we remove > dwc3_core_init() for host mode, I am afraid it can not work well in > host mode after resuming dwc3. Can you point me to a glue driver doing that? >>> Yes, now there are no glue driver doing that, but for many vendor >>> trees they will do that. (Our platform will power off dwc3 when >>> suspending dwc3, but have not upstreamed yet) >> >> Fine, but glue driver still need to take care of re-initialization on resume >> with current design. > Yes. > If dwc3 is powered off on suspend then Xhci level initialization also needed after performing dwc3_core_init on resume which is currently not present. So this seems to me broken anyway. >>> Since we've add runtime PM for xhci-plat driver [1], which means we >>> can runtime suspend/resume xhci device from dwc3 [2]. >>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html >>> [2] https://patchwork.kernel.org/patch/9471869/ >> >> Sure. We can discuss this patch once you re-submit. >> One concern I have with the patch is marking ignore_children for dwc3 and as >> part of >> dwc3 suspend/resume invoking > Suppose we will suspend xhci device as dwc3's child, but now dwc3 > device is not suspend yet, which will block to suspend xhci device. > Thus we should set ignore children flag to remove the parent > dependency. I may not have understood the issue. In any case children must be suspended first. Example sequence is: external hub/device (if any) suspend -> root hub -> xhci -> dwc3 core -> dwc3 glue. xhci device's runtime/pm suspend should happen before dwc3 gets suspended. >> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. >> suspending dwc3 >> once xhci gets suspended and pm_stay_awake/relax can be used to block >> pm_suspend >> until runtime suspend of glue driver happens. >> >>> But [2] has not applied yet now, I will try to upstream it again. Then >>> we can suspend xhci device--> suspend dwc3 host---> glue layer can >>> power off, and it is similar when resuming in host mode. >> >> Do you see any issues with this patch? >> I am able to get runtime suspend/resume happening fine with XHCI on my >> platform. >> It involves runtime suspend/resume of USB HUB and dwc3 glue driver without >> any other >> change. > Great, I will try this patch again. > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
On 12 July 2017 at 16:58, Manu Gautam wrote: > > > On 7/12/2017 2:06 PM, Baolin Wang wrote: >> >> Hi, >> >> On 12 July 2017 at 15:25, Manu Gautam wrote: >>> >>> >>> On 7/12/2017 12:19 PM, Baolin Wang wrote: Hi, On 3 July 2017 at 19:25, Manu Gautam wrote: > > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also, resetting > bus as part of bus_suspend/resume is not correct which could affect > (or disconnect) connected devices. > Fix this by not reinitializing core on suspend/resume in host mode > for HOST only and OTG/drd configurations. But for some mobile devices, they also need suspend/resume in host mode which will power off dwc3 controller in glue layer. If we remove dwc3_core_init() for host mode, I am afraid it can not work well in host mode after resuming dwc3. >>> >>> Can you point me to a glue driver doing that? >> >> Yes, now there are no glue driver doing that, but for many vendor >> trees they will do that. (Our platform will power off dwc3 when >> suspending dwc3, but have not upstreamed yet) > > > Fine, but glue driver still need to take care of re-initialization on resume > with current design. Yes. > >>> If dwc3 is powered off on suspend then Xhci level initialization also >>> needed >>> after >>> performing dwc3_core_init on resume which is currently not present. So >>> this >>> seems >>> to me broken anyway. >> >> Since we've add runtime PM for xhci-plat driver [1], which means we >> can runtime suspend/resume xhci device from dwc3 [2]. >> [1] https://www.spinics.net/lists/linux-usb/msg156077.html >> [2] https://patchwork.kernel.org/patch/9471869/ > > > Sure. We can discuss this patch once you re-submit. > One concern I have with the patch is marking ignore_children for dwc3 and as > part of > dwc3 suspend/resume invoking Suppose we will suspend xhci device as dwc3's child, but now dwc3 device is not suspend yet, which will block to suspend xhci device. Thus we should set ignore children flag to remove the parent dependency. > runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. > suspending dwc3 > once xhci gets suspended and pm_stay_awake/relax can be used to block > pm_suspend > until runtime suspend of glue driver happens. > >> >> But [2] has not applied yet now, I will try to upstream it again. Then >> we can suspend xhci device--> suspend dwc3 host---> glue layer can >> power off, and it is similar when resuming in host mode. > > > Do you see any issues with this patch? > I am able to get runtime suspend/resume happening fine with XHCI on my > platform. > It involves runtime suspend/resume of USB HUB and dwc3 glue driver without > any other > change. Great, I will try this patch again. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
On 7/12/2017 2:06 PM, Baolin Wang wrote: Hi, On 12 July 2017 at 15:25, Manu Gautam wrote: On 7/12/2017 12:19 PM, Baolin Wang wrote: Hi, On 3 July 2017 at 19:25, Manu Gautam wrote: Driver powers-off PHYs and reinitializes DWC3 core and gadget on resume. While this works fine for gadget mode but in host mode there is not re-initialization of host stack. Also, resetting bus as part of bus_suspend/resume is not correct which could affect (or disconnect) connected devices. Fix this by not reinitializing core on suspend/resume in host mode for HOST only and OTG/drd configurations. But for some mobile devices, they also need suspend/resume in host mode which will power off dwc3 controller in glue layer. If we remove dwc3_core_init() for host mode, I am afraid it can not work well in host mode after resuming dwc3. Can you point me to a glue driver doing that? Yes, now there are no glue driver doing that, but for many vendor trees they will do that. (Our platform will power off dwc3 when suspending dwc3, but have not upstreamed yet) Fine, but glue driver still need to take care of re-initialization on resume with current design. If dwc3 is powered off on suspend then Xhci level initialization also needed after performing dwc3_core_init on resume which is currently not present. So this seems to me broken anyway. Since we've add runtime PM for xhci-plat driver [1], which means we can runtime suspend/resume xhci device from dwc3 [2]. [1] https://www.spinics.net/lists/linux-usb/msg156077.html [2] https://patchwork.kernel.org/patch/9471869/ Sure. We can discuss this patch once you re-submit. One concern I have with the patch is marking ignore_children for dwc3 and as part of dwc3 suspend/resume invoking runtime pm on xhci. Ideally pm core should handle it seamlessly i.e. suspending dwc3 once xhci gets suspended and pm_stay_awake/relax can be used to block pm_suspend until runtime suspend of glue driver happens. But [2] has not applied yet now, I will try to upstream it again. Then we can suspend xhci device--> suspend dwc3 host---> glue layer can power off, and it is similar when resuming in host mode. Do you see any issues with this patch? I am able to get runtime suspend/resume happening fine with XHCI on my platform. It involves runtime suspend/resume of USB HUB and dwc3 glue driver without any other change. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi,
On 12 July 2017 at 15:25, Manu Gautam wrote:
>
>
> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 3 July 2017 at 19:25, Manu Gautam wrote:
>>>
>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>> resume. While this works fine for gadget mode but in host
>>> mode there is not re-initialization of host stack. Also, resetting
>>> bus as part of bus_suspend/resume is not correct which could affect
>>> (or disconnect) connected devices.
>>> Fix this by not reinitializing core on suspend/resume in host mode
>>> for HOST only and OTG/drd configurations.
>>
>> But for some mobile devices, they also need suspend/resume in host
>> mode which will power off dwc3 controller in glue layer. If we remove
>> dwc3_core_init() for host mode, I am afraid it can not work well in
>> host mode after resuming dwc3.
>
> Can you point me to a glue driver doing that?
Yes, now there are no glue driver doing that, but for many vendor
trees they will do that. (Our platform will power off dwc3 when
suspending dwc3, but have not upstreamed yet)
> If dwc3 is powered off on suspend then Xhci level initialization also needed
> after
> performing dwc3_core_init on resume which is currently not present. So this
> seems
> to me broken anyway.
Since we've add runtime PM for xhci-plat driver [1], which means we
can runtime suspend/resume xhci device from dwc3 [2].
[1] https://www.spinics.net/lists/linux-usb/msg156077.html
[2] https://patchwork.kernel.org/patch/9471869/
But [2] has not applied yet now, I will try to upstream it again. Then
we can suspend xhci device--> suspend dwc3 host---> glue layer can
power off, and it is similar when resuming in host mode.
> Also, powering off dwc3 on suspend by default from dwc3 core may not be
> correct
> and better left to glue drivers as some platforms might not want to
> reinitialize host
> after suspend/resume. This can be achieved by exposing dwc3_core_init and
> dwc3_core_init_mode to glue drivers.
>
>>> Signed-off-by: Manu Gautam
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index c22c37d..fc556a4 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>>>
>>> switch (dwc->dr_mode) {
>>> case USB_DR_MODE_PERIPHERAL:
>>> + dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
>>> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>>> ret = dwc3_gadget_init(dwc);
>>> if (ret) {
>>> @@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>>> }
>>> break;
>>> case USB_DR_MODE_HOST:
>>> + dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
>>> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
>>> ret = dwc3_host_init(dwc);
>>> if (ret) {
>>> @@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
>>> {
>>> unsigned long flags;
>>>
>>> - switch (dwc->dr_mode) {
>>> - case USB_DR_MODE_PERIPHERAL:
>>> - case USB_DR_MODE_OTG:
>>> + switch (dwc->current_dr_role) {
>>> + case DWC3_GCTL_PRTCAP_DEVICE:
>>> spin_lock_irqsave(&dwc->lock, flags);
>>> dwc3_gadget_suspend(dwc);
>>> spin_unlock_irqrestore(&dwc->lock, flags);
>>> + dwc3_core_exit(dwc);
>>> break;
>>> - case USB_DR_MODE_HOST:
>>> + case DWC3_GCTL_PRTCAP_HOST:
>>> default:
>>> /* do nothing */
>>> break;
>>> }
>>>
>>> - dwc3_core_exit(dwc);
>>> -
>>> return 0;
>>> }
>>>
>>> @@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>>> unsigned long flags;
>>> int ret;
>>>
>>> - ret = dwc3_core_init(dwc);
>>> - if (ret)
>>> - return ret;
>>> + switch (dwc->current_dr_role) {
>>> + case DWC3_GCTL_PRTCAP_DEVICE:
>>> + ret = dwc3_core_init(dwc);
>>> + if (ret)
>>> + return ret;
>>>
>>> - switch (dwc->dr_mode) {
>>> - case USB_DR_MODE_PERIPHERAL:
>>> - case USB_DR_MODE_OTG:
>>> spin_lock_irqsave(&dwc->lock, flags);
>>> dwc3_gadget_resume(dwc);
>>> spin_unlock_irqrestore(&dwc->lock, flags);
>>> - /* FALLTHROUGH */
>>> - case USB_DR_MODE_HOST:
>>> + break;
>>> + case DWC3_GCTL_PRTCAP_HOST:
>>> default:
>>> /* do nothing */
>>> break;
>>> @@ -1325,7 +1324,7 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>>>
>>> static int dwc3_runtime_checks(struct dwc3 *dwc)
>>> {
>>> - switch (dwc->dr_mode) {
>>> + switch (dwc->current_dr_role) {
>>> case USB_DR_MODE_PERIPHERAL:
>>> case USB_DR_
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
On 7/12/2017 12:19 PM, Baolin Wang wrote:
Hi,
On 3 July 2017 at 19:25, Manu Gautam wrote:
Driver powers-off PHYs and reinitializes DWC3 core and gadget on
resume. While this works fine for gadget mode but in host
mode there is not re-initialization of host stack. Also, resetting
bus as part of bus_suspend/resume is not correct which could affect
(or disconnect) connected devices.
Fix this by not reinitializing core on suspend/resume in host mode
for HOST only and OTG/drd configurations.
But for some mobile devices, they also need suspend/resume in host
mode which will power off dwc3 controller in glue layer. If we remove
dwc3_core_init() for host mode, I am afraid it can not work well in
host mode after resuming dwc3.
Can you point me to a glue driver doing that?
If dwc3 is powered off on suspend then Xhci level initialization also
needed after
performing dwc3_core_init on resume which is currently not present. So
this seems
to me broken anyway.
Also, powering off dwc3 on suspend by default from dwc3 core may not be
correct
and better left to glue drivers as some platforms might not want to
reinitialize host
after suspend/resume. This can be achieved by exposing dwc3_core_init and
dwc3_core_init_mode to glue drivers.
Signed-off-by: Manu Gautam
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c22c37d..fc556a4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+ dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret) {
@@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
}
break;
case USB_DR_MODE_HOST:
+ dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
{
unsigned long flags;
- switch (dwc->dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
+ switch (dwc->current_dr_role) {
+ case DWC3_GCTL_PRTCAP_DEVICE:
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
+ dwc3_core_exit(dwc);
break;
- case USB_DR_MODE_HOST:
+ case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
}
- dwc3_core_exit(dwc);
-
return 0;
}
@@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
unsigned long flags;
int ret;
- ret = dwc3_core_init(dwc);
- if (ret)
- return ret;
+ switch (dwc->current_dr_role) {
+ case DWC3_GCTL_PRTCAP_DEVICE:
+ ret = dwc3_core_init(dwc);
+ if (ret)
+ return ret;
- switch (dwc->dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
- /* FALLTHROUGH */
- case USB_DR_MODE_HOST:
+ break;
+ case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
@@ -1325,7 +1324,7 @@ static int dwc3_resume_common(struct dwc3 *dwc)
static int dwc3_runtime_checks(struct dwc3 *dwc)
{
- switch (dwc->dr_mode) {
+ switch (dwc->current_dr_role) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
if (dwc->connected)
@@ -1368,12 +1367,11 @@ static int dwc3_runtime_resume(struct device *dev)
if (ret)
return ret;
- switch (dwc->dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
+ switch (dwc->current_dr_role) {
+ case DWC3_GCTL_PRTCAP_DEVICE:
dwc3_gadget_process_pending_events(dwc);
break;
- case USB_DR_MODE_HOST:
+ case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
@@ -1389,13 +1387,12 @@ static int dwc3_runtime_idle(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
- switch (dwc->dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
+ switch (dwc->current_dr_role) {
+ case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc3_runtime_checks(dwc))
return -EBUSY;
break;
- case USB_DR_MODE_HOST:
+ case DWC3_GCTL_PRTCAP_H
Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume
Hi,
On 3 July 2017 at 19:25, Manu Gautam wrote:
> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
> resume. While this works fine for gadget mode but in host
> mode there is not re-initialization of host stack. Also, resetting
> bus as part of bus_suspend/resume is not correct which could affect
> (or disconnect) connected devices.
> Fix this by not reinitializing core on suspend/resume in host mode
> for HOST only and OTG/drd configurations.
But for some mobile devices, they also need suspend/resume in host
mode which will power off dwc3 controller in glue layer. If we remove
dwc3_core_init() for host mode, I am afraid it can not work well in
host mode after resuming dwc3.
>
> Signed-off-by: Manu Gautam
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index c22c37d..fc556a4 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> + dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> ret = dwc3_gadget_init(dwc);
> if (ret) {
> @@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> }
> break;
> case USB_DR_MODE_HOST:
> + dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
> ret = dwc3_host_init(dwc);
> if (ret) {
> @@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
> {
> unsigned long flags;
>
> - switch (dwc->dr_mode) {
> - case USB_DR_MODE_PERIPHERAL:
> - case USB_DR_MODE_OTG:
> + switch (dwc->current_dr_role) {
> + case DWC3_GCTL_PRTCAP_DEVICE:
> spin_lock_irqsave(&dwc->lock, flags);
> dwc3_gadget_suspend(dwc);
> spin_unlock_irqrestore(&dwc->lock, flags);
> + dwc3_core_exit(dwc);
> break;
> - case USB_DR_MODE_HOST:
> + case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> }
>
> - dwc3_core_exit(dwc);
> -
> return 0;
> }
>
> @@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
> unsigned long flags;
> int ret;
>
> - ret = dwc3_core_init(dwc);
> - if (ret)
> - return ret;
> + switch (dwc->current_dr_role) {
> + case DWC3_GCTL_PRTCAP_DEVICE:
> + ret = dwc3_core_init(dwc);
> + if (ret)
> + return ret;
>
> - switch (dwc->dr_mode) {
> - case USB_DR_MODE_PERIPHERAL:
> - case USB_DR_MODE_OTG:
> spin_lock_irqsave(&dwc->lock, flags);
> dwc3_gadget_resume(dwc);
> spin_unlock_irqrestore(&dwc->lock, flags);
> - /* FALLTHROUGH */
> - case USB_DR_MODE_HOST:
> + break;
> + case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> @@ -1325,7 +1324,7 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>
> static int dwc3_runtime_checks(struct dwc3 *dwc)
> {
> - switch (dwc->dr_mode) {
> + switch (dwc->current_dr_role) {
> case USB_DR_MODE_PERIPHERAL:
> case USB_DR_MODE_OTG:
> if (dwc->connected)
> @@ -1368,12 +1367,11 @@ static int dwc3_runtime_resume(struct device *dev)
> if (ret)
> return ret;
>
> - switch (dwc->dr_mode) {
> - case USB_DR_MODE_PERIPHERAL:
> - case USB_DR_MODE_OTG:
> + switch (dwc->current_dr_role) {
> + case DWC3_GCTL_PRTCAP_DEVICE:
> dwc3_gadget_process_pending_events(dwc);
> break;
> - case USB_DR_MODE_HOST:
> + case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> @@ -1389,13 +1387,12 @@ static int dwc3_runtime_idle(struct device *dev)
> {
> struct dwc3 *dwc = dev_get_drvdata(dev);
>
> - switch (dwc->dr_mode) {
> - case USB_DR_MODE_PERIPHERAL:
> - case USB_DR_MODE_OTG:
> + switch (dwc->current_dr_role) {
> + case DWC3_GCTL_PRTCAP_DEVICE:
> if (dwc3_runtime_checks(dwc))
> return -EBUSY;
> break;
> - case USB_DR_MODE_HOST:
> + case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
> Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://v
