Hi Felipe, > -----Original Message----- > From: Felipe Balbi <bal...@gmail.com> On Behalf Of Felipe Balbi > Sent: 2020年5月21日 14:23 > To: Thinh Nguyen <thinh.ngu...@synopsys.com>; Jun Li <jun...@nxp.com>; Jun Li > <lijun.ker...@gmail.com> > Cc: John Stultz <john.stu...@linaro.org>; lkml > <linux-kernel@vger.kernel.org>; Yu > Chen <cheny...@huawei.com>; Greg Kroah-Hartman <gre...@linuxfoundation.org>; > Rob > Herring <robh...@kernel.org>; Mark Rutland <mark.rutl...@arm.com>; ShuFan Lee > <shufan_...@richtek.com>; Heikki Krogerus <heikki.kroge...@linux.intel.com>; > Suzuki K Poulose <suzuki.poul...@arm.com>; Chunfeng Yun > <chunfeng....@mediatek.com>; Hans de Goede <hdego...@redhat.com>; Andy > Shevchenko > <andy.shevche...@gmail.com>; Valentin Schneider <valentin.schnei...@arm.com>; > Jack Pham <ja...@codeaurora.org>; Linux USB List <linux-...@vger.kernel.org>; > open > list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > <devicet...@vger.kernel.org>; > Peter Chen <peter.c...@nxp.com> > Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by > device > controller > > > Hi Jun, > > Felipe Balbi <ba...@kernel.org> writes: > >> In any case, increasing the timeout should be fine with me. It maybe > >> difficult to determine the max timeout base on the slowest clock rate > >> and number of cycles. Different controller and controller versions > >> behave differently and may have different number of clock cycles to > >> complete a command. > >> > >> The RTL engineer recommended timeout to be at least 1ms (which maybe > >> more than the polling rate of this patch). I'm fine with either the > >> rate provided by this tested patch or higher. > > > > A whole ms waiting for a command to complete? Wow, that's a lot of > > time blocking the CPU. It looks like, perhaps, we should move to > > command completion interrupts. The difficulty here is that we issue > > commands from within the interrupt handler and, as such, can't > > wait_for_completion(). > > > > Meanwhile, we will take the timeout increase I guess, otherwise NXP > > won't have a working setup. > > patch 1 in this series doesn't apply to testing/next. Care to rebase and > resend?
Sure, I will rebase and resend this patch with timeout loop 5000. Thanks Li Jun > > Thank you > > -- > balbi