Hi Manu, On 20 July 2017 at 19:12, Manu Gautam <mgautam@xxxxxxxxxxxxxx> wrote: > 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? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
