Re: [PATCH v3 0/9] Tegra xHCI support
From: Stephen Warren <hidden>
Date: 2014-09-16 23:15:26
Also in:
linux-arm-kernel, linux-tegra, lkml
On 09/16/2014 04:46 PM, Andrew Bresticker wrote:
On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker [off-list ref] wrote:quoted
On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren [off-list ref] wrote:quoted
On 09/15/2014 01:30 PM, Andrew Bresticker wrote:quoted
On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren [off-list ref] wrote:quoted
On 09/15/2014 11:06 AM, Andrew Bresticker wrote:quoted
On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso [off-list ref] wrote:quoted
On 12 September 2014 18:37, Andrew Bresticker [off-list ref] wrote:quoted
On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso [off-list ref] wrote:quoted
On 8 September 2014 18:22, Andrew Bresticker [off-list ref] wrote:quoted
On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso [off-list ref] wrote:quoted
On 2 September 2014 23:34, Andrew Bresticker [off-list ref] wrote:quoted
Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]....quoted
quoted
quoted
Stephen, Thierry, have either of you had a chance to test this series?I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies?Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhciHmm. That git server was quite reluctant to cough up its bits, but it did eventually.quoted
You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during "Direct firmware loading". The driver needs to work with either immediate or deferred firmware loading.If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated).quoted
The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772quoted
[ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 70090000.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 70090000.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22(repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device.Thanks, I'll try to figure out what's going on here.Grr... this is due to the unfortunate UTMI pad controller design on Tegra. Here's the issue: When UTMI pad 0 is assigned to the EHCI controller (as is currently the case on Jetson-TK1), the UTMI parameters from UTMIP_BIAS_CFG0 in the global UTMI pad register space are used regardless of the owner of the UTMI pads. If pad 0 is assigned to the XUSB controller, then parameters in USB2_BIAS_PAD_CTL0 in the XUSB register space are used for all UTMI pads (again, regardless of ownership). I wasn't able to reproduce before because I always TFTP booted and U-Boot programs the UTMI parameters correctly when starting the EHCI controllers. I suspect you and Tomeu were booting without starting the EHCI controllers and thus were stuck with the POR values.
I am loading the kernel over the PCIe Ethernet on Jetson TK1. However, the U-Boot boot scripts do "usb start" first, so I would assume all the USB set is already done either way, before U-Boot attempts to probe USB devices.
quoted hunk ↗ jump to hunk
The easiest way to fix this is to just assign UTMI port 0 (i.e. the OTG port) to the XUSB controller. AFAIK, device mode on Tegra isn't supported yet in the kernel, so this shouldn't break any existing use cases. If we wanted to support device mode in the future, it would just have to be done with the XUSB controller instead. The alternative is some ugly driver that programs the correct register set depending on which controller UTMI port 0 is assigned to. BTW, here's a patch to assign UTMI port 0 to XUSB:diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dtsb/arch/arm/boot/dts/tegra124-jetson-tk1.dts index a473750..dacb0d0 100644--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts@@ -1644,7 +1644,7 @@ padctl_default: pinmux { otg { - nvidia,lanes = "otg-1", "otg-2"; + nvidia,lanes = "otg-0", "otg-1", "otg-2"; nvidia,function = "xusb"; };
That's a bit better; I now see dmesg entries when I plug in my hub where before I got none. However, I still get some descriptor read errors etc., and the USB HDD I have behind the hub isn't fully detected. It seemed like "lsusb" hung for quite a while when I first ran it too. Perhaps it makes a difference whether the USB device is plugged in on boot or plugged later, or whether it was plugged in when U-Boot detected USB or not.