Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp236048ybk; Sat, 9 May 2020 01:12:13 -0700 (PDT) X-Google-Smtp-Source: APiQypJn/vkmlnGTk1Ujm9dffYfwzYp+jty+TnKXTK0GKQVhKk8e4+eUAfS/LbWb1llh7OhKktfJ X-Received: by 2002:a17:906:3048:: with SMTP id d8mr5262935ejd.97.1589011932833; Sat, 09 May 2020 01:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589011932; cv=none; d=google.com; s=arc-20160816; b=AzShfyK25U0nBGcicZiQRPDkWl7TMxHgfn/uiGx5gFG74Q9pOahOg6GTG5Nm0vKCWO /eZ0JOx5TbxfNqW3OdXHQH5RfHiaiVjrvZOdCLhQj3O1uKTL/X3D8Fh+cZm0yIydVRc6 /dvWWTfaxxX789EVeZmoiy19eSrTET/KhUylgyeZwFvfblT11zxrMqUCPRWXMHljhUSj 2KhT40uQ0lAEgG1N1Ww+Xil6L+F5xa8geJtLBR2l4jW13UPmgoyLtj4M0glh7dixfhrc ipgrcT7o2erkvT34a22JHdRtAT2rYLCK5rpRhhkSvlAsGOG+qsDBG+huWcgpZPEtu2vs ttvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=hg2j4yDUwU/HdTy91WVT+D8cDbi67SkruoSAu6walPg=; b=SPb2BdLEV8q3Koco4ocK924VhM0mZlQfAwz79gRaCcs8SxMQoBFXtkDJvupI5JHyTt IVcbxqHSJhcAKYUsP+0EHAm9Dtrn3KQvI2yPq12bV/cKBEy/t1OHJVcHklmgv0LPpBOn eyvSTlzZ53CeVLzG/Z2h88jp5/XaIBO2eexvTtJoKJYu2WmR1NTXj2pMFsYEvt8OhurI CiHuF9q0iwqoR+oRAC4qxpQLRi8Q3hLSDkTdmNFZn1JPkgk4wol8QiL3tAzEWp89nTef JKi5UQk8TAtGh+tua9ffmCG4glCAUXw3iw1Bw2pp2RDEoRWkLRDnyMQ9D8dg49k8i9eE INKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cmAwXjqz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp5si1804067ejc.344.2020.05.09.01.11.48; Sat, 09 May 2020 01:12:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cmAwXjqz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726948AbgEIIKc (ORCPT + 99 others); Sat, 9 May 2020 04:10:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725850AbgEIIKc (ORCPT ); Sat, 9 May 2020 04:10:32 -0400 Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 248F4C061A0C; Sat, 9 May 2020 01:10:32 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id a5so2550786vsm.7; Sat, 09 May 2020 01:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hg2j4yDUwU/HdTy91WVT+D8cDbi67SkruoSAu6walPg=; b=cmAwXjqzTs4mGPYVsr1LRa/7NH7QWL+ied3aAdEqVx+8AhccAWLtdFRjQJVW4AujgG NzhEAj/FI/1az32WuUjuIlt/beelqF3cUYZyJkt3uDV0ppjLKRH65s9Oa5Uj2OQnodmN IeETq/CyU5jych/jLblezYeAVvA9S8a6harjeNvjsIXHQdyDTJ/8WgHPsxDn/t+KnqX2 isAzn++2aPYs/Bf61eR05iUUmdQ7ND69oNlHPXG3+FA4u3QwlcjtS53Va4OwRzk0Dv30 N10GxSA/KX+L5BsSt8RVO4bWTc6khulHWVB5wR1YUhS8Q8KwJFVsod1mVWF8hWAMBDLz 6r+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hg2j4yDUwU/HdTy91WVT+D8cDbi67SkruoSAu6walPg=; b=uZS2JNhuL0SJT+JnXoslxNf/1NRYMDxav6Ab4QV5BSYiln2mVLRKPReo71YGCFvltL DsD31BySuZ5FmKmwvr5fOOBeB7asxV9kJ3LReeNC1RHsboU03vjzRVHOD1tInyE4bIXp Jy24ycolFwnt9O4Lkq9j7arDQcHvgh140tVEXnO8Wx2Rw9mGcOrldwwZfXWashM8imF0 DeTnLHcr4bOejdEM8fPMDTnMim/qaeWLyT8XyTQmzzZP2hubZIvsFvOn9N5PZNdDvvsf fIOcL8jKutQSeKxdJBD9mPYAML/k+jeF+PnD0Ucup3frYcVH591pPlzFTR9RUnERksmK RrcQ== X-Gm-Message-State: AGi0Puag3+oG7poBX5U7XlDePXvFWb47ggnl7mBaOK9z8pnTAdyv1B3s cUnA2ClZX1hAObRUvFVAaE1GFHVr2ADaEqLmUds= X-Received: by 2002:a67:fe8c:: with SMTP id b12mr4980915vsr.186.1589011831107; Sat, 09 May 2020 01:10:31 -0700 (PDT) MIME-Version: 1.0 References: <20191028215919.83697-1-john.stultz@linaro.org> <20191028215919.83697-4-john.stultz@linaro.org> <87mudjj4rc.fsf@gmail.com> <87h7wqmwrv.fsf@kernel.org> In-Reply-To: <87h7wqmwrv.fsf@kernel.org> From: Jun Li Date: Sat, 9 May 2020 16:10:19 +0800 Message-ID: Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller To: Felipe Balbi Cc: John Stultz , lkml , Yu Chen , Greg Kroah-Hartman , Rob Herring , Mark Rutland , ShuFan Lee , Heikki Krogerus , Suzuki K Poulose , Chunfeng Yun , Hans de Goede , Andy Shevchenko , Valentin Schneider , Jack Pham , Linux USB List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , peter.chen@nxp.com, Li Jun , Thinh Nguyen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Felipe Balbi =E4=BA=8E2020=E5=B9=B45=E6=9C=888=E6=97=A5= =E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=888:33=E5=86=99=E9=81=93=EF=BC=9A > > > Hi, > > Jun Li writes: > > John Stultz =E4=BA=8E2019=E5=B9=B410=E6=9C=883= 0=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D=885:18=E5=86=99=E9=81=93=EF=BC= =9A > >> > >> On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi wrote: > >> > John Stultz writes: > >> > > From: Yu Chen > >> > > > >> > > It needs more time for the device controller to clear the CmdAct o= f > >> > > DEPCMD on Hisilicon Kirin Soc. > >> > > >> > Why does it need more time? Why is it so that no other platform need= s > >> > more time, only this one? And which command, specifically, causes > >> > problem? > > > > Sorry for my back to this so late. > > > > This change is required on my dwc3 based HW too, I gave a check > > and the reason is suspend_clk is used in case the PIPE phy is at P3, > > this slow clock makes my EP command below timeout. > > The phy needs to woken up before the command is triggered. Currently we > only wake up the HS PHY. Does it help you if we wake up the SS phy as > well? > > Something like below ought to do it: > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index a0555252dee0..ee46c2dacaeb 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -274,7 +274,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsi= gned cmd, > const struct usb_endpoint_descriptor *desc =3D dep->endpoint.desc= ; > struct dwc3 *dwc =3D dep->dwc; > u32 timeout =3D 1000; > - u32 saved_config =3D 0; > + u32 saved_hs_config =3D 0; > + u32 saved_ss_config =3D 0; > u32 reg; > > int cmd_status =3D 0; > @@ -293,19 +294,28 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, un= signed cmd, > if (dwc->gadget.speed <=3D USB_SPEED_HIGH) { > reg =3D dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); > if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) { > - saved_config |=3D DWC3_GUSB2PHYCFG_SUSPHY; > + saved_hs_config |=3D DWC3_GUSB2PHYCFG_SUSPHY; > reg &=3D ~DWC3_GUSB2PHYCFG_SUSPHY; > } > > if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { > - saved_config |=3D DWC3_GUSB2PHYCFG_ENBLSLPM; > + saved_hs_config |=3D DWC3_GUSB2PHYCFG_ENBLSLPM; > reg &=3D ~DWC3_GUSB2PHYCFG_ENBLSLPM; > } > > - if (saved_config) > + if (saved_hs_config) > dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); > } > > + reg =3D dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); > + if (unlikely(reg & DWC3_GUSB3PIPECTL_SUSPHY)) { > + saved_ss_config |=3D DWC3_GUSB3PIPECTL_SUSPHY; > + reg &=3D ~DWC3_GUSB3PIPECTL_SUSPHY; > + } > + > + if (saved_ss_config) > + dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); > + > if (DWC3_DEPCMD_CMD(cmd) =3D=3D DWC3_DEPCMD_STARTTRANSFER) { > int needs_wakeup; > > @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, un= signed cmd, > dwc3_gadget_ep_get_transfer_index(dep); > } > > - if (saved_config) { > + if (saved_hs_config) { > reg =3D dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); > - reg |=3D saved_config; > + reg |=3D saved_hs_config; > dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); > } > > + if (saved_ss_config) { > + reg =3D dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); > + reg |=3D saved_ss_config; > + dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg); > + } > + > return ret; > } Unfortunately this way can't work, once the SS PHY enters P3, disable suspend_en can't force SS PHY exit P3, unless do this at the very beginning to prevent SS PHY entering P3(e.g. add "snps,dis_u3_susphy_quirk" for test)= . thanks Li Jun > > -- > balbi