Hi John, ? 2016?02?02? 07:31, John Youn ??: > On 2/1/2016 3:13 AM, Caesar Wang wrote: >> >> ? 2016?02?01? 19:12, Caesar Wang ??: >>> Doug >>> >>> ? 2016?01?30? 03:11, Doug Anderson ??: >>>> Caesar, >>>> >>>> On Tue, Jan 26, 2016 at 6:12 PM, Caesar Wang >>>> <caesar.upstream at gmail.com> wrote: >>>>> Thanks Doug's reply. >>>>> >>>>> Cc: Wulf >>>>> ? 2016?01?27? 00:05, Doug Anderson ??: >>>>>> Hi, >>>>>> >>>>>> On Tue, Jan 26, 2016 at 4:02 AM, Caesar Wang <wxt at rock-chips.com> >>>>>> wrote: >>>>>>> Hi John, Felipe >>>>>>> >>>>>>> >>>>>>> I'm no familiar with usb stuff. >>>>>>> then I found this patch will break usb working for rk3036 SoCs, maybe >>>>>>> more >>>>>>> SoCs. >>>>>>> Says, U disk can't work on usb host. >>>>>>> >>>>>>> The failure log: >>>>>>> >>>>>>> 32.645481] usb usb2-port1: connect-debounce failed >>>>>>> >>>>>>> >>>>>>> Tested by following branch: >>>>>>> https://github.com/Caesar-github/rockchip/tree/kylin/next (kernel: >>>>>>> 4.5-rc1) >>>>>>> >>>>>>> Revert "usb: dwc2: Add functions to set and clear force mode" will >>>>>>> work >>>>>>> for >>>>>>> it. >>>>>>> >>>>>>> >>>>>>> Maybe, someone have some suggestions or ideas? >>>>>> Can you check if this series helps you? >>>>>> >>>>>> http://marc.info/?l=linux-usb&m=145255851516121&w=2 >>>>> Unluckily, this series patches can't fix it on rk3036 SoCs. >>>>> I revert this CL ("usb: dwc2: Add functions to set and clear force >>>>> mode") to >>>>> work firstly. >>>> You're 100% positive? In particular you made sure you had this patch >>>> (one of the two in John's series I pointed at), which explicitly >>>> mentions fixing a problem with the patch you mention? >>> I'm 100% positive the John's patches can fix this issue >> Sorry, John's patches can't fix this issue. >> >> >>> As the following verified on >>> https://github.com/Caesar-github/rockchip/commits/for-usb-tests >>> >>> Anyway, Meanwhile if we add the folllowing patch can work for me. I >>> will track it on tomorrow if you have other suggestions. >>> >>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c >>> >>> index e991d55..90f4abf 100644 >>> >>> --- a/drivers/usb/dwc2/core.c >>> >>> +++ b/drivers/usb/dwc2/core.c >>> >>> @@ -637,6 +637,13 @@ int dwc2_core_reset_and_force_dr_mode(struct >>> dwc2_hsotg *hsotg) >>> >>> return retval; >>> >>> >>> >>> dwc2_force_dr_mode(hsotg); >>> >>> + >>> >>> + /* >>> >>> + * NOTE: This long sleep is_very_ important, otherwise the core >>> will >>> >>> + * not stay in host mode after a connector ID change! >>> >>> + */ >>> >>> + usleep_range(150000, 160000); >>> >>> + >>> >>> return 0; >>> >>> } >>> > Hi Cesar, > > On your platform, is the dwc2 controller OTG? If so, what mode is the > driver running in (dr_mode=HOST, PERIPHERAL, or OTG)? It's the Host mode. ( USB_DR_MODE_HOST) > > The force mode only requires 25ms delay but maybe the sleep needs to > be longer on your system for some other reason. Which is unfortunate > because 150ms is very long. > > Under what condition do you see the problem. Is it on connector ID > change? If so we might put the long delay in a more appropriate > location so as not to affect delay in probe. > > Also, could you try *only* reverting the following: > > commit 97e463886b873f62bea2293e7edf81fdb884b84f ("usb: dwc2: Reduce > delay when forcing mode in reset") I'm sure can't work if we revert it. log ...: "[ 5.705971] usb usb2-port1: connect-debounce failed" d4b3ff1 Revert "usb: dwc2: Reduce delay when forcing mode in reset" c69654f usb: dwc2: Fix probe problem on bcm283 b9da0ff Revert "usb: dwc2: Move reset into dwc2_get_hwparams() -- Then, add the following patch can work. diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index e991d55..90f4abf 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -637,6 +637,13 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg) return retval; dwc2_force_dr_mode(hsotg); + + /* + * NOTE: This long sleep is _very_ important, otherwise the core will + * not stay in host mode after a connector ID change! + */ + usleep_range(150000, 160000); + return 0; } > The original patch you referred to preserves the long delay at the > point it is used for OTG but then this later patch (97e46388) > decreased the value. So maybe we can just revert this later patch. > > Regards, > John > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
