Hi, On 13 July 2017 at 15:26, Manu Gautam <mgau...@codeaurora.org> wrote: > > > On 7/13/2017 11:33 AM, Baolin Wang wrote: >> On 12 July 2017 at 16:58, Manu Gautam <mgau...@codeaurora.org> wrote: >>> >>> On 7/12/2017 2:06 PM, Baolin Wang wrote: >>>> Hi, >>>> >>>> On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote: >>>>> >>>>> On 7/12/2017 12:19 PM, Baolin Wang wrote: >>>>>> Hi, >>>>>> >>>>>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> 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
