在 2022/3/18 22:53, Guenter Roeck 写道:
On 3/17/22 23:05, qianfan wrote:
[ ... ]
So I think it's a bug of MUSB, not caused by dev_WARN_ONCE. But I
can't check which stop hrtimer.
Correct. Look at the code:
static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
{
...
int retries = 1000;
...
while (csr & MUSB_TXCSR_FIFONOTEMPTY) {
...
if (dev_WARN_ONCE(musb->controller, retries-- < 1,
"Could not flush host TX%d fifo: csr:
%04x\n",
ep->epnum, csr))
return;
mdelay(1);
}
This is where the one second comes from. The function is called from
musb_urb_dequeue() which disables interrupts. This forces a hard stall
of the kernel for a full second.
Hi, thanks for your's guide. the one second delay plus the times for
dev_WARN_ON is about 1.5s, it's not friendly for most of all gpio-watchdog.
@Bin Liu
"mdelay(1)" in musb_h_tx_fifo is removed in commit
68fe05e2a45181ce02ab2698930b37f20487bd24 and adding back in commit
45d73860530a14c608f410b91c6c341777bfa85d
could we remove mdelay(1) again and and find another way to resolv the
problem mention in:
commit 45d73860530a14c608f410b91c6c341777bfa85d
Author: Bin Liu <b-liu@xxxxxx>
Date: Tue Jul 25 09:31:34 2017 -0500
usb: musb: fix tx fifo flush handling again
commit 68fe05e2a451 ("usb: musb: fix tx fifo flush handling") drops the
1ms delay trying to solve the long disconnect time issue when
application queued many tx urbs. However, the 1ms delay is needed for
some use cases, for example, without the delay, reconnecting AR9271
WIFI
dongle no longer works if the connection is dropped from the AP.
So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and
solve the
long disconnect time problem with a separate patch for
usb_hcd_flush_endpoint().
Cc: stable@xxxxxxxxxxxxxxx # v4.4+
Signed-off-by: Bin Liu <b-liu@xxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
There is nothing we can do about that in the watchdog driver.
Guenter
