linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 209555] dwc2 driver stops working after sudden disconnect
Date: Sun, 25 Jul 2021 14:25:43 +0000	[thread overview]
Message-ID: <bug-209555-208809-Sqgt75Got2@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-209555-208809@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=209555

--- Comment #18 from Minas Harutyunyan (Minas.Harutyunyan@synopsys.com) ---
Hi Yunhao,

Thank you for provided info.

Driver by default set to DDMA mode. In DDMA mode very important when requests
producer (function driver) produce more requests that consumer (HW) can
process, otherwise BNA (buffer not available) interrupt will be asserted.
In your case function driver queued only 2 requests for EP2OUT. Driver create
descriptor list with 2 descriptors. On completion of 2nd descriptor core
returning to first one, which already completed and not renewed yet. Because of
this BNA asserted. For OUT EP's on BNA interrupt RxFIFO should be flushed, but
due to AHB not idle - core permanently try to get new descriptor, but no new
descriptor created yet. This create infinite loop.
So, I suggest you, to allow your function driver produce more requests before
first ISOC OUT packets will received in RxFIFO to have enough big pool of
descriptors.
If you can't control initial requests count from function driver then you can
try set core to BDMA mode:
g_dma_desc                    : 1 --> 0

In BDMA mode BNA will not asserted.

Thanks,
Minas

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2021-07-25 14:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 21:59 [Bug 209555] New: dwc2 driver stops working after sudden disconnect bugzilla-daemon
2020-10-07 20:00 ` [Bug 209555] " bugzilla-daemon
2020-10-08  7:46 ` bugzilla-daemon
2020-10-08 19:47 ` bugzilla-daemon
2020-10-09  6:47 ` bugzilla-daemon
2021-02-26  1:43 ` bugzilla-daemon
2021-07-24 16:42 ` bugzilla-daemon
2021-07-25  5:45   ` Minas Harutyunyan
2021-07-25  5:45 ` bugzilla-daemon
2021-07-25  6:55 ` bugzilla-daemon
2021-07-25  7:16   ` Minas Harutyunyan
2021-07-25  7:23     ` Minas Harutyunyan
2021-07-25  7:17 ` bugzilla-daemon
2021-07-25  7:23 ` bugzilla-daemon
2021-07-25  8:52 ` bugzilla-daemon
2021-07-25 14:25 ` bugzilla-daemon [this message]
2021-07-25 15:14 ` bugzilla-daemon
2021-07-26  5:08 ` bugzilla-daemon
2021-12-02 23:42 ` bugzilla-daemon
2021-12-03  0:20 ` bugzilla-daemon
2021-12-03  0:40 ` bugzilla-daemon
2021-12-03  0:43 ` bugzilla-daemon
2021-12-03  0:44 ` bugzilla-daemon
2021-12-03  1:08 ` bugzilla-daemon
2021-12-03  1:47 ` bugzilla-daemon
2021-12-07  2:13 ` bugzilla-daemon
2022-02-19 11:11 ` bugzilla-daemon
2022-02-19 11:11 ` bugzilla-daemon
2022-05-18 10:20 ` bugzilla-daemon
2023-05-03  1:56 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-209555-208809-Sqgt75Got2@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).