[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Yuri Frolov]

Hi,

I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip.
Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. g_snpsid register reports 0x5533290a revision.

It's verified, that linux kernel support is ok, usb is fully functional.

	axi {
		<...>

		usb at 1F04D050 {
			compatible = "be,baikal-dwc3";
			reg = <0x1f04d050 0x4>;
			interrupts = <0x0 0x45 0x4>;
			#address-cells = <0x1>;
			#size-cells = <0x1>;
			clocks = <0xf 0x0>;
			clock-names = "usb";
			ranges;
			status = "okay";

			dwc3 at 1F100000 {
				compatible = "snps,dwc3", "synopsys,dwc3", "generic-xhci";
				reg = <0x1f100000 0x10000>;
				interrupts = <0x0 0x44 0x4>;
				dr_mode = "host";
				tx-fifo-resize;
				maximum-speed = "high-speed";
			};
		};
	};

whereas in u-boot 'usb start' fails on hub initialization (as I can see):

Any ideas why this could happen?.. Any direction where to look at?
Any suggestions will be greatly appreciated.

# usb start
(Re)start USB...
USB0:   dwc3_reg->g_snpsid: 0x5533290a
Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... New Device 0
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F
get_conf_no 0 Result 25, wLength 31
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF
Manufacturer U-Boot
Product      XHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC
1 ports detected
ganged power switching
standalone hub
individual port over-current protection
TT requires at most 8 FS bit times (666 ns)
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
get_hub_status returned status 1, change 801
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
port 1 returns 0
devnum=1 poweron: query_delay=100 connect_timeout=1100
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
Port 1 Status 101 Change 1
devnum=1 port=1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0
usb_hub_port_reset: resetting port 1...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 111, change 0, 12 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0
New Device 1
XHCI timeout on event type 33... cannot recover.
BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
BUG!
Reset CPU by CPC

Here is the drivers/usb/host/xhci-baikal.c:

#include <common.h>
#include <usb.h>
#include <linux/errno.h>

#include <linux/compat.h>
#include <linux/usb/dwc3.h>
#include <linux/usb/xhci-omap.h>

#include "xhci.h"

/* Declare global data pointer */
DECLARE_GLOBAL_DATA_PTR;

struct baikal_xhci {
	struct xhci_hccr *hcd;
	struct dwc3 *dwc3_reg;
};

static struct baikal_xhci baikal;

int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init);

static int baikal_xhci_core_init(struct baikal_xhci *baikal)
{
	int ret = 0;

	ret = dwc3_core_init(baikal->dwc3_reg);
	if (ret) {
		debug("%s:failed to initialize core\n", __func__);
		return ret;
	}

	/* We are hard-coding DWC3 core to Host Mode */
	dwc3_set_mode(baikal->dwc3_reg, DWC3_GCTL_PRTCAP_HOST);

	return ret;
}

static void baikal_xhci_core_exit(struct baikal_xhci *baikal)
{
}

int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
{
	struct baikal_xhci *ctx = &baikal;
	int ret = 0;

	ctx->hcd = (struct xhci_hccr *)CONFIG_USB_XHCI_BAIKAL_BASE;
	ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET);

	ret = board_usb_init(index, USB_INIT_HOST);
	if (ret != 0) {
		puts("Failed to initialize board for USB\n");
		return ret;
	}

	ret = baikal_xhci_core_init(ctx);
	if (ret < 0) {
		puts("Failed to initialize xhci\n");
		return ret;
	}

	*hccr = (struct xhci_hccr *)(CONFIG_USB_XHCI_BAIKAL_BASE);
	*hcor = (struct xhci_hcor *)((uint32_t) *hccr
				+ HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));

	debug("baikal-xhci: init hccr %x and hcor %x hc_length %d\n",
	      (uint32_t)*hccr, (uint32_t)*hcor,
	      (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));

	return ret;
}

void xhci_hcd_stop(int index)
{
}

TIA,
Yuri

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Neil Armstrong]

Hi Bin,

I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
connected to 2 HS-only PHYs and no SS PHY.

When a device is connected on the second PHY, I have the same BUG(),
but no more when a device is also connected on the first PHY, and no issues
at all on the first PHY.

XHCI timeout on event type 33... cannot recover.

What kind of debug output would you need to debug this ?

=> When Port 1 is disconnected, but Port 2 is populated:
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
clear port connect change, actual port 2 status  = 0x6e1
...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
...
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
SPEED = FULLSPEED
...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
...
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
SPEED = FULLSPEED
...
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
clear port reset change, actual port 2 status  = 0x603


=> When Port 1 is populated:
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
clear port connect change, actual port 2 status  = 0x6e1
...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
...
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
SPEED = FULLSPEED
...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
...
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
SPEED = HIGHSPEED
...
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
clear port reset change, actual port 2 status  = 0xe03

When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
but why ?


Neil

On 09/04/2018 15:11, Yuri Frolov wrote:
> Hi,
> 
> I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip.
> Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. g_snpsid register reports 0x5533290a revision.
> 
> It's verified, that linux kernel support is ok, usb is fully functional.
> 
>     axi {
>         <...>
> 
>         usb at 1F04D050 {
>             compatible = "be,baikal-dwc3";
>             reg = <0x1f04d050 0x4>;
>             interrupts = <0x0 0x45 0x4>;
>             #address-cells = <0x1>;
>             #size-cells = <0x1>;
>             clocks = <0xf 0x0>;
>             clock-names = "usb";
>             ranges;
>             status = "okay";
> 
>             dwc3 at 1F100000 {
>                 compatible = "snps,dwc3", "synopsys,dwc3", "generic-xhci";
>                 reg = <0x1f100000 0x10000>;
>                 interrupts = <0x0 0x44 0x4>;
>                 dr_mode = "host";
>                 tx-fifo-resize;
>                 maximum-speed = "high-speed";
>             };
>         };
>     };
> 
> whereas in u-boot 'usb start' fails on hub initialization (as I can see):
> 
> Any ideas why this could happen?.. Any direction where to look at?
> Any suggestions will be greatly appreciated.
> 
> # usb start
> (Re)start USB...
> USB0:   dwc3_reg->g_snpsid: 0x5533290a
> Register 1000140 NbrPorts 1
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... New Device 0
> set address 1
> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F
> get_conf_no 0 Result 25, wLength 31
> if 0, ep 0
> ##EP epmaxpacketin[1] = 8
> set configuration 1
> usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
> new device strings: Mfr=1, Product=2, SerialNumber=0
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF
> USB device number 1 default language ID 0x409
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF
> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF
> Manufacturer U-Boot
> Product      XHCI Host Controller
> SerialNumber
> USB hub found
> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4
> usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC
> 1 ports detected
> ganged power switching
> standalone hub
> individual port over-current protection
> TT requires at most 8 FS bit times (666 ns)
> power on to power good time: 20ms
> hub controller current requirement: 0mA
> port 1 is removable
> usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
> get_hub_status returned status 1, change 801
> local power source is lost (inactive)
> no over-current condition exists
> enabling power on all ports
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
> port 1 returns 0
> devnum=1 poweron: query_delay=100 connect_timeout=1100
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> Port 1 Status 101 Change 1
> devnum=1 port=1: USB dev found
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> portstatus 101, change 1, 12 Mb/s
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0
> usb_hub_port_reset: resetting port 1...
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> portstatus 111, change 0, 12 Mb/s
> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
> portstatus 503, change 10, 480 Mb/s
> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0
> New Device 1
> XHCI timeout on event type 33... cannot recover.
> BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
> BUG!
> Reset CPU by CPC
> 
> Here is the drivers/usb/host/xhci-baikal.c:
> 
> #include <common.h>
> #include <usb.h>
> #include <linux/errno.h>
> 
> #include <linux/compat.h>
> #include <linux/usb/dwc3.h>
> #include <linux/usb/xhci-omap.h>
> 
> #include "xhci.h"
> 
> /* Declare global data pointer */
> DECLARE_GLOBAL_DATA_PTR;
> 
> struct baikal_xhci {
>     struct xhci_hccr *hcd;
>     struct dwc3 *dwc3_reg;
> };
> 
> static struct baikal_xhci baikal;
> 
> int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init);
> 
> static int baikal_xhci_core_init(struct baikal_xhci *baikal)
> {
>     int ret = 0;
> 
>     ret = dwc3_core_init(baikal->dwc3_reg);
>     if (ret) {
>         debug("%s:failed to initialize core\n", __func__);
>         return ret;
>     }
> 
>     /* We are hard-coding DWC3 core to Host Mode */
>     dwc3_set_mode(baikal->dwc3_reg, DWC3_GCTL_PRTCAP_HOST);
> 
>     return ret;
> }
> 
> static void baikal_xhci_core_exit(struct baikal_xhci *baikal)
> {
> }
> 
> int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
> {
>     struct baikal_xhci *ctx = &baikal;
>     int ret = 0;
> 
>     ctx->hcd = (struct xhci_hccr *)CONFIG_USB_XHCI_BAIKAL_BASE;
>     ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET);
> 
>     ret = board_usb_init(index, USB_INIT_HOST);
>     if (ret != 0) {
>         puts("Failed to initialize board for USB\n");
>         return ret;
>     }
> 
>     ret = baikal_xhci_core_init(ctx);
>     if (ret < 0) {
>         puts("Failed to initialize xhci\n");
>         return ret;
>     }
> 
>     *hccr = (struct xhci_hccr *)(CONFIG_USB_XHCI_BAIKAL_BASE);
>     *hcor = (struct xhci_hcor *)((uint32_t) *hccr
>                 + HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));
> 
>     debug("baikal-xhci: init hccr %x and hcor %x hc_length %d\n",
>           (uint32_t)*hccr, (uint32_t)*hcor,
>           (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));
> 
>     return ret;
> }
> 
> void xhci_hcd_stop(int index)
> {
> }
> 
> TIA,
> Yuri
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Bin Meng]

Hi Neil,

On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Hi Bin,
>
> I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
> connected to 2 HS-only PHYs and no SS PHY.
>
> When a device is connected on the second PHY, I have the same BUG(),
> but no more when a device is also connected on the first PHY, and no issues
> at all on the first PHY.
>
> XHCI timeout on event type 33... cannot recover.
>
> What kind of debug output would you need to debug this ?
>
> => When Port 1 is disconnected, but Port 2 is populated:
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
> clear port connect change, actual port 2 status  = 0x6e1
> ...
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> ...
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> SPEED = FULLSPEED
> ...
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> ...
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> SPEED = FULLSPEED
> ...
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
> clear port reset change, actual port 2 status  = 0x603
>
>
> => When Port 1 is populated:
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
> clear port connect change, actual port 2 status  = 0x6e1
> ...
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> ...
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> SPEED = FULLSPEED
> ...
> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> ...
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> SPEED = HIGHSPEED
> ...
> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
> clear port reset change, actual port 2 status  = 0xe03
>
> When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
> but why ?
>

This looks really strange. Sounds like a hardware internal state
depends on the first USB port. Do you know if Linux works?

Regards,
Bin

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Neil Armstrong]

Hi Bin,

Le 07/09/2019 à 05:44, Bin Meng a écrit :
> Hi Neil,
> 
> On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Hi Bin,
>>
>> I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
>> connected to 2 HS-only PHYs and no SS PHY.
>>
>> When a device is connected on the second PHY, I have the same BUG(),
>> but no more when a device is also connected on the first PHY, and no issues
>> at all on the first PHY.
>>
>> XHCI timeout on event type 33... cannot recover.
>>
>> What kind of debug output would you need to debug this ?
>>
>> => When Port 1 is disconnected, but Port 2 is populated:
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>> clear port connect change, actual port 2 status  = 0x6e1
>> ...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>> ...
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>> SPEED = FULLSPEED
>> ...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>> ...
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>> SPEED = FULLSPEED
>> ...
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>> clear port reset change, actual port 2 status  = 0x603
>>
>>
>> => When Port 1 is populated:
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>> clear port connect change, actual port 2 status  = 0x6e1
>> ...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>> ...
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>> SPEED = FULLSPEED
>> ...
>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>> ...
>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>> SPEED = HIGHSPEED
>> ...
>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>> clear port reset change, actual port 2 status  = 0xe03
>>
>> When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
>> but why ?
>>
> 
> This looks really strange. Sounds like a hardware internal state
> depends on the first USB port. Do you know if Linux works?

Yes, Linux works fine, is it worth tracing the Linux XHCI driver aswell ?

Neil


> 
> Regards,
> Bin
> 

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Bin Meng]

Hi Neil,

On Sun, Sep 8, 2019 at 8:33 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Hi Bin,
>
> Le 07/09/2019 à 05:44, Bin Meng a écrit :
> > Hi Neil,
> >
> > On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >> Hi Bin,
> >>
> >> I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
> >> connected to 2 HS-only PHYs and no SS PHY.
> >>
> >> When a device is connected on the second PHY, I have the same BUG(),
> >> but no more when a device is also connected on the first PHY, and no issues
> >> at all on the first PHY.
> >>
> >> XHCI timeout on event type 33... cannot recover.
> >>
> >> What kind of debug output would you need to debug this ?
> >>
> >> => When Port 1 is disconnected, but Port 2 is populated:
> >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
> >> clear port connect change, actual port 2 status  = 0x6e1
> >> ...
> >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> >> ...
> >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> >> SPEED = FULLSPEED
> >> ...
> >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> >> ...
> >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> >> SPEED = FULLSPEED
> >> ...
> >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
> >> clear port reset change, actual port 2 status  = 0x603
> >>
> >>
> >> => When Port 1 is populated:
> >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
> >> clear port connect change, actual port 2 status  = 0x6e1
> >> ...
> >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> >> ...
> >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> >> SPEED = FULLSPEED
> >> ...
> >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
> >> ...
> >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
> >> SPEED = HIGHSPEED
> >> ...
> >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
> >> clear port reset change, actual port 2 status  = 0xe03
> >>
> >> When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
> >> but why ?
> >>
> >
> > This looks really strange. Sounds like a hardware internal state
> > depends on the first USB port. Do you know if Linux works?
>
> Yes, Linux works fine, is it worth tracing the Linux XHCI driver aswell ?

Yes, that will definitely help.

Regards,
Bin

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Neil Armstrong]

Hi Bin,


On 08/09/2019 14:35, Bin Meng wrote:
> Hi Neil,
> 
> On Sun, Sep 8, 2019 at 8:33 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Hi Bin,
>>
>> Le 07/09/2019 à 05:44, Bin Meng a écrit :
>>> Hi Neil,
>>>
>>> On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>
>>>> Hi Bin,
>>>>
>>>> I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
>>>> connected to 2 HS-only PHYs and no SS PHY.
>>>>
>>>> When a device is connected on the second PHY, I have the same BUG(),
>>>> but no more when a device is also connected on the first PHY, and no issues
>>>> at all on the first PHY.
>>>>
>>>> XHCI timeout on event type 33... cannot recover.
>>>>
>>>> What kind of debug output would you need to debug this ?
>>>>
>>>> => When Port 1 is disconnected, but Port 2 is populated:
>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>>>> clear port connect change, actual port 2 status  = 0x6e1
>>>> ...
>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>> ...
>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>> SPEED = FULLSPEED
>>>> ...
>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>> ...
>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>> SPEED = FULLSPEED
>>>> ...
>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>>>> clear port reset change, actual port 2 status  = 0x603
>>>>
>>>>
>>>> => When Port 1 is populated:
>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>>>> clear port connect change, actual port 2 status  = 0x6e1
>>>> ...
>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>> ...
>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>> SPEED = FULLSPEED
>>>> ...
>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>> ...
>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>> SPEED = HIGHSPEED
>>>> ...
>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>>>> clear port reset change, actual port 2 status  = 0xe03
>>>>
>>>> When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
>>>> but why ?
>>>>
>>>
>>> This looks really strange. Sounds like a hardware internal state
>>> depends on the first USB port. Do you know if Linux works?
>>
>> Yes, Linux works fine, is it worth tracing the Linux XHCI driver aswell ?
> 
> Yes, that will definitely help.

I did a extensive debug and print session today agains the amlogic u-boot release and Linux,

and only :
clrbits_le32(&dwc3_reg->g_usb2phycfg, DWC3_GUSB2PHYCFG_SUSPHY);

was missing in drivers/usb/host/xhci-dwc3.c

because xhci-dwc3 is not using the dwc3 core init.

it should use the dwc3 core init instead of a copy, that correctly handles
the quirks.

Neil

> 
> Regards,
> Bin
> 

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Jean-Jacques Hiblot]

On 09/09/2019 18:03, Neil Armstrong wrote:
> Hi Bin,
>
>
> On 08/09/2019 14:35, Bin Meng wrote:
>> Hi Neil,
>>
>> On Sun, Sep 8, 2019 at 8:33 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> Hi Bin,
>>>
>>> Le 07/09/2019 à 05:44, Bin Meng a écrit :
>>>> Hi Neil,
>>>>
>>>> On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI controller
>>>>> connected to 2 HS-only PHYs and no SS PHY.
>>>>>
>>>>> When a device is connected on the second PHY, I have the same BUG(),
>>>>> but no more when a device is also connected on the first PHY, and no issues
>>>>> at all on the first PHY.
>>>>>
>>>>> XHCI timeout on event type 33... cannot recover.
>>>>>
>>>>> What kind of debug output would you need to debug this ?
>>>>>
>>>>> => When Port 1 is disconnected, but Port 2 is populated:
>>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>>>>> clear port connect change, actual port 2 status  = 0x6e1
>>>>> ...
>>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>>> ...
>>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>>> SPEED = FULLSPEED
>>>>> ...
>>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>>> ...
>>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>>> SPEED = FULLSPEED
>>>>> ...
>>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>>>>> clear port reset change, actual port 2 status  = 0x603
>>>>>
>>>>>
>>>>> => When Port 1 is populated:
>>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length 0x0
>>>>> clear port connect change, actual port 2 status  = 0x6e1
>>>>> ...
>>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>>> ...
>>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>>> SPEED = FULLSPEED
>>>>> ...
>>>>> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length 0x0
>>>>> ...
>>>>> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4
>>>>> SPEED = HIGHSPEED
>>>>> ...
>>>>> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length 0x0
>>>>> clear port reset change, actual port 2 status  = 0xe03
>>>>>
>>>>> When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
>>>>> but why ?
>>>>>
>>>> This looks really strange. Sounds like a hardware internal state
>>>> depends on the first USB port. Do you know if Linux works?
>>> Yes, Linux works fine, is it worth tracing the Linux XHCI driver aswell ?
>> Yes, that will definitely help.
> I did a extensive debug and print session today agains the amlogic u-boot release and Linux,
>
> and only :
> clrbits_le32(&dwc3_reg->g_usb2phycfg, DWC3_GUSB2PHYCFG_SUSPHY);
>
> was missing in drivers/usb/host/xhci-dwc3.c
>
> because xhci-dwc3 is not using the dwc3 core init.
>
> it should use the dwc3 core init instead of a copy, that correctly handles
> the quirks.

I posted today the v4 of a series that uses the DWC3 core for host 
operations.

Can you give it try? The goal is ultimately to be able to replace 
platform-specific dwc3 host implementation.

JJ

>
> Neil
>
>> Regards,
>> Bin
>>
>