From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755182AbcHSIAe (ORCPT ); Fri, 19 Aug 2016 04:00:34 -0400 Received: from mail-yw0-f170.google.com ([209.85.161.170]:34600 "EHLO mail-yw0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750721AbcHSIAd (ORCPT ); Fri, 19 Aug 2016 04:00:33 -0400 MIME-Version: 1.0 In-Reply-To: <87d1l642j3.fsf@linux.intel.com> References: <87inuy5yvr.fsf@linux.intel.com> <87inuy463c.fsf@linux.intel.com> <87d1l642j3.fsf@linux.intel.com> From: Baolin Wang Date: Fri, 19 Aug 2016 15:52:53 +0800 Message-ID: Subject: Re: [PATCH 2/4] usb: host: xhci: Introduce one new 'usb3_slow_suspend' member for xhci private data To: Felipe Balbi Cc: Greg KH , mathias.nyman@intel.com, USB , LKML , Mark Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Felipe, On 18 August 2016 at 21:42, Felipe Balbi wrote: > > Hi Baolin, > > Baolin Wang writes: >>>>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c >>>>>> index e2e2487..162f17c 100644 >>>>>> --- a/drivers/usb/host/xhci-plat.c >>>>>> +++ b/drivers/usb/host/xhci-plat.c >>>>>> @@ -250,6 +250,9 @@ static int xhci_plat_probe(struct platform_device *pdev) >>>>>> (pdata && pdata->usb3_lpm_capable)) >>>>>> xhci->quirks |= XHCI_LPM_SUPPORT; >>>>>> >>>>>> + if (pdata && pdata->usb3_slow_suspend) >>>>>> + xhci->quirks |= XHCI_SLOW_SUSPEND; >>>>> >>>>> I remember having a discussion about this with Paul Z and it turned out >>>>> that we really didn't need SLOW_SUSPEND. Can you describe further in >>>>> what situation you need this quirk? >>>> >>>> On my dwc3 platform, xhci suspend will be failed if we have not >>>> enabled XHCI_SLOW_SUSPEND quirk. >>> >>> fail how? What error do you see? Do you have some traces of what's >>> happening? Did you try figuring out if this is, perhaps, caused by some >>> call ordering which is wrong? Perhaps disabling PHYs too early or >>> something like that? >> >> It shows the warning "WARN: xHC CMD_RUN timeout" when running >> xhci_suspend(). If I enbale XHCI_SLOW_SUSPEND quirk, then it can work >> well. I did not try to figure out other things, due to I think the >> dwc3 need XHCI_SLOW_SUSPEND quirk. But I can re-try to figure out if >> there are other issues if you still believe that dwc3 does not need >> XHCI_SLOW_SUSPEND quirk. Thanks. > > When I discussed this with Paul Z, he told me there was no known > DWC3 SoC that really needed SLOW_SUSPEND, so it's likely to be a bug in > either xhci or dwc3. > > Please try to track this down. I would start looking at ordering with > PHY poweroff or something like that. OK. Thanks. -- Baolin.wang Best Regards