[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd534ff9-e500-c7ea-426a-347ac2b0830b@linux.intel.com>
Date: Fri, 14 Jan 2022 21:31:17 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Dave Hansen <dave.hansen@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
Chunfeng Yun <chunfeng.yun@...iatek.com>
Subject: Re: earlyprintk=xdbc seems broken
On 14.1.2022 10.47, Peter Zijlstra wrote:
> On Tue, Dec 21, 2021 at 10:40:50AM +0100, Peter Zijlstra wrote:
>> On Fri, Dec 17, 2021 at 02:55:07PM +0100, Peter Zijlstra wrote:
>>> On Fri, Dec 17, 2021 at 01:01:43PM +0200, Mathias Nyman wrote:
>>>> I can reproduce this.
>>>> Looks like problems started when driver converted to readl_poll_timeout_atomic() in:
>>>>
>>>> 796eed4b2342 usb: early: convert to readl_poll_timeout_atomic()
>>>
>>> I can confirm, reverting that solves the boot hang, things aren't quite
>>> working for me though.
>>
>> I've been poking at this a little, find debug patch and full dmesg
>> below. The TL;DR version of the dmesg seems to be:
>>
>> [ 4.984148] xhci_dbc:xdbc_start: waiting for connection timed out
>> [ 4.984149] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host
>>
>> Initially I thought this was due to delay not being set up properly, but
>> I 'fixed' that, and I've ran out of ideas. I really don't know anything
>> about USB :/
>
> Any thoughts on this? I'd really like to be able to use this machine but
> can't due to lack of console.
>
Tried to reproduce this with another cable that should have all pins connected,
but it still workes for me.
It looks like the connection is not even detected in your case.
What does the host say? If the cable is connected before CTRL_DBC_ENABLED bit is
written on the target side, then the link should go to a inactive "error" state.
Host should try to recover the inactive link with a warm reset.
On host side dynamic debug for usb core and xhci can be added with:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
xHCI documentation also states that Debug capability enable bit (CTRL_DBC_ENABLE)
could be toggled to retry failed enumeration.
The non-early dbc that works for you does clear the control register before enabling
the debug capability, and it also skips port reset.
Something like the below could be worth trying out:
8<---
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 4502108069cd..8969c88e8c24 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -419,7 +419,9 @@ static int xdbc_start(void)
{
u32 ctrl, status;
int ret;
+ bool first_try = true;
+retry:
ctrl = readl(&xdbc.xdbc_reg->control);
writel(ctrl | CTRL_DBC_ENABLE | CTRL_PORT_ENABLE, &xdbc.xdbc_reg->control);
ret = handshake(&xdbc.xdbc_reg->control, CTRL_DBC_ENABLE, CTRL_DBC_ENABLE, 100000, 100);
@@ -429,13 +431,21 @@ static int xdbc_start(void)
}
/* Reset port to avoid bus hang: */
- if (xdbc.vendor == PCI_VENDOR_ID_INTEL)
+ if (xdbc.vendor == PCI_VENDOR_ID_INTEL && first_try)
xdbc_reset_debug_port();
/* Wait for port connection: */
ret = handshake(&xdbc.xdbc_reg->portsc, PORTSC_CONN_STATUS, PORTSC_CONN_STATUS, 5000000, 100);
if (ret) {
- xdbc_trace("waiting for connection timed out\n");
+ xdbc_trace("waiting for connection timed out, DCPORTSC:0x%x\n",
+ readl(&xdbc.xdbc_reg->portsc));
+ if (first_try) {
+ first_try = false;
+ /* Toggle DCE and retry without port reset */
+ writel(0, &xdbc.xdbc_reg->control);
+ handshake(&xdbc.xdbc_reg->control, CTRL_DBC_ENABLE, 0, 100000, 10);
+ goto retry;
+ }
return ret;
}
Powered by blists - more mailing lists