RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi Felipe,

> -----Original Message-----
> From: Felipe Balbi <balbif@xxxxxxxxx> On Behalf Of Felipe Balbi
> Sent: 2020年5月21日 14:23
> To: Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx>; Jun Li <jun.li@xxxxxxx>; Jun Li
> <lijun.kernel@xxxxxxxxx>
> Cc: John Stultz <john.stultz@xxxxxxxxxx>; lkml <linux-kernel@xxxxxxxxxxxxxxx>; Yu
> Chen <chenyu56@xxxxxxxxxx>; Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Rob
> Herring <robh+dt@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; ShuFan Lee
> <shufan_lee@xxxxxxxxxxx>; Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>;
> Suzuki K Poulose <suzuki.poulose@xxxxxxx>; Chunfeng Yun
> <chunfeng.yun@xxxxxxxxxxxx>; Hans de Goede <hdegoede@xxxxxxxxxx>; Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx>; Valentin Schneider <valentin.schneider@xxxxxxx>;
> Jack Pham <jackp@xxxxxxxxxxxxxx>; Linux USB List <linux-usb@xxxxxxxxxxxxxxx>; open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@xxxxxxxxxxxxxxx>;
> Peter Chen <peter.chen@xxxxxxx>
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device
> controller
> 
> 
> Hi Jun,
> 
> Felipe Balbi <balbi@xxxxxxxxxx> 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