Hi, On 7/13/2017 1:13 PM, Baolin Wang wrote: > Hi, > > On 13 July 2017 at 15:26, Manu Gautam <mgautam@xxxxxxxxxxxxxx> wrote: >> >> On 7/13/2017 11:33 AM, Baolin Wang wrote: >>> On 12 July 2017 at 16:58, Manu Gautam <mgautam@xxxxxxxxxxxxxx> wrote: >>>> On 7/12/2017 2:06 PM, Baolin Wang wrote: >>>>> Hi, >>>>> >>>>> On 12 July 2017 at 15:25, Manu Gautam <mgautam@xxxxxxxxxxxxxx> wrote: >>>>>> On 7/12/2017 12:19 PM, Baolin Wang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 3 July 2017 at 19:25, Manu Gautam <mgautam@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
