From: Felipe Balbi <balbi@kernel.org>
To: "Yang\, Fei" <fei.yang@intel.com>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
John Stultz <john.stultz@linaro.org>,
lkml <linux-kernel@vger.kernel.org>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>,
Thinh Nguyen <thinhn@synopsys.com>,
Tejas Joglekar <tejas.joglekar@synopsys.com>,
Jack Pham <jackp@codeaurora.org>, Todd Kjos <tkjos@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
Linux USB List <linux-usb@vger.kernel.org>,
stable <stable@vger.kernel.org>
Subject: RE: [RFC][PATCH 0/2] Avoiding DWC3 transfer stalls/hangs when using adb over f_fs
Date: Thu, 23 Jan 2020 19:46:51 +0200 [thread overview]
Message-ID: <87lfpy3w1g.fsf@kernel.org> (raw)
In-Reply-To: <02E7334B1630744CBDC55DA8586225837F9EE335@ORSMSX102.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]
Hi,
"Yang, Fei" <fei.yang@intel.com> writes:
>>>>> Hey all,
>>>>> I wanted to send these out for comment and thoughts.
>>>>>
>>>>> Since ~4.20, when the functionfs gadget enabled scatter-gather
>>>>> support, we have seen problems with adb connections stalling and
>>>>> stopping to function on hardware with dwc3 usb controllers.
>>>>> Specifically, HiKey960, Dragonboard 845c, and Pixel3 devices.
>>>>
>>>> Any chance this:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/commit/
>>>> ?h=testing/next&id=f63333e8e4fd63d8d8ae83b89d2c38cf21d64801
>>> This is a different issue. I have tried initializing num_sgs when debugging this adb stall problem, but it didn't help.
>>
>> So multiple folks have run through this problem, but not *one* has tracepoints collected from the issue? C'mon guys. Can someone, please, collect tracepoints so we can figure out what's actually going on?
>>
>> I'm pretty sure this should be solved at the DMA API level, just want to confirm.
>
> I have sent you the tracepoints long time ago. Also my analysis of the
> problem (BTW, I don't think the tracepoints helped much). It's
> basically a logic problem in function dwc3_gadget_ep_reclaim_trb_sg().
AFAICT, this is caused by DMA API merging pages together when map an
sglist for DMA. While doing that, it does *not* move the SG_END flag
which sg_is_last() checks.
I consider that an overlook on the DMA API, wouldn't you? Why should DMA
API users care if pages were merged or not while mapping the sglist? We
have for_each_sg() and sg_is_last() for a reason.
> I can try dig into my old emails and resend, but that is a bit hard to find.
Don't bother, I'm still not convinced we should fix at the driver level
when sg_is_last() should be working here, unless we should iterate over
num_sgs instead of num_mapped_sgs, though I don't think that's the case
since in that case we would have to chain buffers of size zero.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-01-23 17:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 22:26 [RFC][PATCH 0/2] Avoiding DWC3 transfer stalls/hangs when using adb over f_fs John Stultz
2020-01-22 22:26 ` [RFC][PATCH 1/2] usb: dwc3: gadget: Check for IOC/LST bit in both event->status and TRB->ctrl fields John Stultz
2020-01-23 7:24 ` Felipe Balbi
2020-01-23 18:54 ` Yang, Fei
[not found] ` <CALAqxLUeBf2Jx2tLW1yzJk6JHM0RP9cJbTt7m19Qdz-rWMw2mQ@mail.gmail.com>
2020-01-24 7:45 ` Felipe Balbi
2020-01-24 22:10 ` John Stultz
2020-01-25 11:02 ` Felipe Balbi
2020-01-27 18:48 ` John Stultz
2020-01-22 22:26 ` [RFC][PATCH 2/2] usb: dwc3: gadget: Correct the logic for finding last SG entry John Stultz
2020-01-23 7:25 ` Felipe Balbi
2020-01-23 15:50 ` Anurag Kumar Vulisha
2020-01-23 7:18 ` [RFC][PATCH 0/2] Avoiding DWC3 transfer stalls/hangs when using adb over f_fs Felipe Balbi
2020-01-23 8:43 ` Andrzej Pietrasiewicz
2020-01-23 16:29 ` Yang, Fei
2020-01-23 17:31 ` Felipe Balbi
2020-01-23 17:37 ` Yang, Fei
2020-01-23 17:46 ` Felipe Balbi [this message]
2020-01-23 18:28 ` Yang, Fei
2020-02-05 21:03 ` John Stultz
2020-02-06 6:23 ` Felipe Balbi
2020-02-06 7:40 ` Christoph Hellwig
2020-02-06 18:29 ` Felipe Balbi
2020-02-06 18:41 ` Christoph Hellwig
2020-02-07 6:00 ` Felipe Balbi
2020-01-23 19:58 ` John Stultz
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=87lfpy3w1g.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=andrzej.p@collabora.com \
--cc=fei.yang@intel.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jackp@codeaurora.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tejas.joglekar@synopsys.com \
--cc=thinhn@synopsys.com \
--cc=tkjos@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.