Thread (6 messages) 6 messages, 2 authors, 2021-09-22

Re: dwc3-qcom: tx-fifo-resize regression on Poco F1 (sdm845) with v5.15-rc1

From: Wesley Cheng <hidden>
Date: 2021-09-22 08:53:44
Also in: linux-arm-msm, linux-devicetree, lkml

Hi Amit,

On 9/21/2021 3:18 AM, Amit Pundir wrote:
On Tue, 21 Sept 2021 at 13:00, Wesley Cheng [off-list ref] wrote:
quoted
Hi Amit,

On 9/21/2021 12:04 AM, Amit Pundir wrote:
quoted
Hi Wesley,

On Tue, 21 Sept 2021 at 02:44, Wesley Cheng [off-list ref] wrote:
quoted
Hi Amit,

On 9/20/2021 1:45 PM, Amit Pundir wrote:
quoted
Hi Wesley, All,

I see a reboot loop on Xiaomi Pocophone F1 (sdm845) with TX FIFO
resize patches which landed in v5.15-rc1. Upstream commit cefdd52fa045
"usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default" to
be specific, which switched on this feature by default.

At times the phone crashes into the fastboot mode after the reboot
loop, but mostly end up booting to UI after a while. This is what it
looks like https://people.linaro.org/~amit.pundir/beryllium-userdebug/PXL_20210920_162749483.mp4.
I believe Android will attempt a number of bootup sequences and if it
fails, it falls back to fastboot mode.  Are there any available logs you
might be able to collect to see where the issue is?
It is a stock phone with no UART access, so I can't get early crash
logs unless I'm booted up to adb shell. I can try getting some info
using pstore-ramoops but warm reset support for sdm845 was not
upstreamed when I tried using that the last time.
I see, can we maybe avoid the actual resizing by commenting out the
following writel() calls, but let the fifo resize logic calculate the EPs?

void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
{
...
                /* Don't change TXFRAMNUM on usb31 version */
                size = DWC3_IP_IS(DWC3) ? 0 :
                        dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(num >> 1)) &
                                   DWC31_GTXFIFOSIZ_TXFRAMNUM;
                /* Comment the dwc3_writel() */
                //dwc3_writel(dwc->regs, DWC3_GTXFIFOSIZ(num >> 1), size);

and

static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep)
{
...
        /* Comment the dwc3_writel() */
        //dwc3_writel(dwc->regs, DWC3_GTXFIFOSIZ(dep->number >> 1), fifo_size);
        dwc->num_ep_resized++;

Those 2 writel() would be the one that actually programs the TXFIFO
register.  I hope when commented out, no resize should actually happen
anymore.

With this, hopefully we can get some logs from the device at least :)
I can boot fine with above 2 writel() removed but I don't see EP
counts being printed in the log anywhere and the only relevant
message in dmesg I see is this:

    Duplicate name in dwc3@a600000, renamed to "tx-fifo-resize#1"

which is interesting because I don't see tx-fifo-resize property being
set by any of the upstream sdm845 or relevant dtsi files.
Thanks for testing.  What is the current composition the device is
exposing to the host?

Can we get a ftrace log w/ the DWC3 events enabled, as well as the
kernel log? (if not at boot up then maybe a plug in/out)  This will at
least help us identify when the DWC3 ep enable is being called (which
triggers the resize routine)

Thanks
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help