Re: [PATCH v3 0/9] Tegra xHCI support
On 09/17/2014 01:40 AM, Stephen Warren wrote: That's a huge time-sink, unless I work out NFS root, which probably isn't properly or easily supported by any distro. FWIW, this is how I've been working, and it hasn't been /that/ difficult to get working. The Tegra side is trivial, just append something like ip=dhcp root=/dev/nfs nfsroot=host_ip:/your/nfsroot,v3,rsize=8192,wsize=8192,timeo=15 (Granted, I had to do a bit of mucking around before finding this working incantation..) to the kernel boot arguments. I've used Ubuntu 12.04, 13.10 and Arch Linux on my Jetson in this way. The more annoying part is the nfs host machine, but there are guides for that. Anyway, I've had both Ubuntu 12.04 and Arch working as hosts without problems. Mikko -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/16/2014 05:51 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 4:15 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. Interesting - just doing usb start made the difference for me. 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
Re: [PATCH v3 0/9] Tegra xHCI support
On Wed, Sep 17, 2014 at 8:41 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 05:51 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 4:15 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. Interesting - just doing usb start made the difference for me. The easiest way to fix this is to just
Re: [PATCH v3 0/9] Tegra xHCI support
On 15 September 2014 19:06, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. Ok, since Blaze has been announced, hopefully we can post a device-tree for it soon. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 Yup, I'm using the same firmware. If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). That, or perhaps bootloader differences? I'm using mainline U-Boot. Also mainline here: U-Boot 2014.10-rc1-00136-g7bee1c9 (Aug 28 2014 - 15:22:05) Don't know how to check what revision of the hw I have, though. Regards, Tomeu Stephen, Thierry, have either of you had a chance to test this series? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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. I tried three USB3 mass storage devices, and they all appeared to work without issue. 0781:5581 SanDisk Corp. 154b:fa0a PNY 0781:5580 SanDisk Corp. I tried the following USB2 devices without issue: 0781:5575 SanDisk Corp. 0b95:7720 ASIX Electronics Corp. AX88772 045e:0095 Microsoft Corp. IntelliMouse Explorer 4.0 (IntelliPoint) 046d:c313 Logitech, Inc. Internet 350 Keyboard The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/16/2014 10:57 AM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). Hmm. I didn't have to do that for the Atmel touchpad driver to work, but perhaps it's just ignoring a firmware loading error, and continuing with whatever is in the device's flash already. It seems odd that such a fundamental feature would require a deprecated Kconfig option. Is there some replacement that does the same thing that isn't deprecated? The Kconfig help for the option doesn't say anything useful... Oh, this option doesn't actually seem to work. I see the following in dmesg: [root@swarren-dt ~]# dmesg|grep -i -e xhci -e firmware [1.461773] xhci-tegra 7009.usb: Failed to get supply 'avddio-pex': -517 [1.468930] platform 7009.usb: Driver xhci-tegra requests probe deferral [2.567966] xhci-tegra 7009.usb: Direct firmware load for nvidia/tegra124/xusb.bin failed with error -2 [2.577786] xhci-tegra 7009.usb: Falling back to user helper ... but: [root@swarren-dt ~]# lsusb unable to initialize libusb: -99 Perhaps systemd-udevd doesn't implement firmware loading; is it user-space udev that's deprecated implementing user-space firmware loading, rather than the kernel deprecating support for calling out to user space? This sucks, because now I can't just TFTP boot kernels but somehow have to get updated kernel modules onto my device every time before testing a new kernel build. That's a huge time-sink, unless I work out NFS root, which probably isn't properly or easily supported by any distro. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. 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.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts index a473750..dacb0d0 100644 ---
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 3:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 10:57 AM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). Hmm. I didn't have to do that for the Atmel touchpad driver to work, but perhaps it's just ignoring a firmware loading error, and continuing with whatever is in the device's flash already. It seems odd that such a fundamental feature would require a deprecated Kconfig option. Is there some replacement that does the same thing that isn't deprecated? The Kconfig help for the option doesn't say anything useful... Oh, this option doesn't actually seem to work. I see the following in dmesg: [root@swarren-dt ~]# dmesg|grep -i -e xhci -e firmware [1.461773] xhci-tegra 7009.usb: Failed to get supply 'avddio-pex': -517 [1.468930] platform 7009.usb: Driver xhci-tegra requests probe deferral [2.567966] xhci-tegra 7009.usb: Direct firmware load for nvidia/tegra124/xusb.bin failed with error -2 [2.577786] xhci-tegra 7009.usb: Falling back to user helper ... but: [root@swarren-dt ~]# lsusb unable to initialize libusb: -99 Perhaps systemd-udevd doesn't implement firmware loading; is it user-space udev that's deprecated implementing user-space firmware loading, rather than the kernel deprecating support for calling out to user space? I believe it is userspace udev that has deprecated user firmware loading. The kernel still does call out to userspace. Alternatively, you could use the firmware_class loading interface described in Documentation/firmware_class/README, but that kind of sucks too. This sucks, because now I can't just TFTP boot kernels but somehow have to get updated kernel modules onto my device every time before testing a new kernel build. Yeah... it does. I get around this by building the firmware into the kernel image (i.e. CONFIG_EXTRA_FIRMWARE), which is also your only option if the root device happens to be on USB. Unfortunately, I'm not aware of any other alternatives. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. 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
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 4:15 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. ... 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-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. 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). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 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 7009.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 7009.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. Interesting - just doing usb start made the difference for me. 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
Re: [PATCH v3 0/9] Tegra xHCI support
On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). Regards, Tomeu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. Ok, since Blaze has been announced, hopefully we can post a device-tree for it soon. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 Yup, I'm using the same firmware. If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). That, or perhaps bootloader differences? I'm using mainline U-Boot. Stephen, Thierry, have either of you had a chance to test this series? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. Ok, since Blaze has been announced, hopefully we can post a device-tree for it soon. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 Yup, I'm using the same firmware. If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). That, or perhaps bootloader differences? I'm using mainline U-Boot. 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? Thierry is on vacation right now. I think he was expecting to return sometime this week, but the start of his vacation was delayed, so perhaps he'll be back a bit later too. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. Ok, since Blaze has been announced, hopefully we can post a device-tree for it soon. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 Yup, I'm using the same firmware. If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). That, or perhaps bootloader differences? I'm using mainline U-Boot. 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-xhci You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/09/2014 07:09 PM, Andrew Bresticker wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 Alcor flash drive: 058f:6387 JMicron SATA bridge: 152d:2329 I have the same SATA bridge and it is enumerating fine for me, but I've ordered the hub as well and will check that out. Did you have any other patches applied when testing these? Here is the branch, including the .config I used: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Were you using either SATA or PCIe at the same time? Nope, haven't even tried those yet. Just trying to figure out if there's anything else different between our setups. Yeah, I'm afraid I don't have any good suggestion to make. But maybe you will find some error on my part in how I have applied the patches or in the config. Regards, Tomeu -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 Alcor flash drive: 058f:6387 JMicron SATA bridge: 152d:2329 HTH, Tomeu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 Alcor flash drive: 058f:6387 JMicron SATA bridge: 152d:2329 I have the same SATA bridge and it is enumerating fine for me, but I've ordered the hub as well and will check that out. Did you have any other patches applied when testing these? Were you using either SATA or PCIe at the same time? Just trying to figure out if there's anything else different between our setups. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Regards, Tomeu Notes: - HSIC support is mostly untested and I think there are still some issues to work out there. I do have a Tegra124 board with a HSIC hub so I'll try to sort those out later. - The XUSB padctl driver doesn't play nice with the existing Tegra USB2.0 PHY driver, so all ports should be assigned to the XHCI controller. Based on work by: a lot of people, but from what I can tell from the L4T tree [3], the original authors of the Tegra xHCI driver are: Ajay Gupta aj...@nvidia.com Bharath Yadav bya...@nvidia.com Chagnes from v2: - Dropped mailbox channel specifier. The mailbox driver allocates virtual channels backed by the single physical channel. - Added support for HS_CURR_LEVEL adjustment pinconfig property, which will be required for the Blaze board. - Addressed Stephen's review comments. Changes from v1: - Converted mailbox driver to use the common mailbox framework. - Fixed up host driver so that it can now be built and used as a module. - Addressed Stephen's review comments. - Misc. cleanups. Changes from RFC: - Dropped Tegra114 support. - Split out mailbox into separate driver. - Stopped using child xhci-plat device in xHCI host-controller driver. - Added PHY support to Thierry's XUSB padctl driver instead of in a separate USB PHY driver. - Added Jetson TK1 support. - Misc. cleanups. [0] https://lkml.org/lkml/2014/8/1/200 [1] https://lkml.org/lkml/2014/8/18/504 [2] https://patchwork.ozlabs.org/patch/384013/ [3] git://nv-tegra.nvidia.com/linux-3.10.git Andrew Bresticker (9): of: Add NVIDIA Tegra XUSB mailbox binding mailbox: Add NVIDIA Tegra XUSB mailbox driver of: Update Tegra XUSB pad controller binding for USB pinctrl: tegra-xusb: Add USB PHY support of: Add NVIDIA Tegra xHCI controller binding usb: xhci: Add NVIDIA Tegra xHCI host-controller driver ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller ARM: tegra: jetson-tk1: Add xHCI support ARM: tegra: venice2: Add xHCI support .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 + .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 56 +- .../bindings/usb/nvidia,tegra124-xhci.txt | 104 ++ arch/arm/boot/dts/tegra124-jetson-tk1.dts | 48 +- arch/arm/boot/dts/tegra124-venice2.dts | 79 +- arch/arm/boot/dts/tegra124.dtsi| 41 + drivers/mailbox/Kconfig|3 + drivers/mailbox/Makefile |2 + drivers/mailbox/tegra-xusb-mailbox.c | 290 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1233 +++- drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |1 + drivers/usb/host/xhci-tegra.c | 905 ++ include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h | 20 + include/soc/tegra/xusb.h | 53 + 16 files changed, 2796 insertions(+), 81 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c create mode 100644 drivers/usb/host/xhci-tegra.c create mode 100644 include/soc/tegra/xusb.h -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Tegra xHCI support
On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: 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]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/9] Tegra xHCI support
This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: - patches 1 and 2: adding a driver for the mailbox used to communicate with the xHCI controller's firmware, - patches 3 and 4: extending the XUSB pad controller driver to support the USB PHY types (UTMI, HSIC, and USB3), - patches 5 and 6: adding a xHCI host-controller driver, and - patches 7, 8, and 9: updating the relevant DT files. The PHY and host drivers have compile-time dependencies on the mailbox driver, and the host driver has compile-time dependencies on the PHY driver. It is probably best if these all get merged through the Tegra tree. Based on 3.17-rc3, Jassi Brar's common mailbox framework [0], and my xHCI modules series [1]. 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]. Notes: - HSIC support is mostly untested and I think there are still some issues to work out there. I do have a Tegra124 board with a HSIC hub so I'll try to sort those out later. - The XUSB padctl driver doesn't play nice with the existing Tegra USB2.0 PHY driver, so all ports should be assigned to the XHCI controller. Based on work by: a lot of people, but from what I can tell from the L4T tree [3], the original authors of the Tegra xHCI driver are: Ajay Gupta aj...@nvidia.com Bharath Yadav bya...@nvidia.com Chagnes from v2: - Dropped mailbox channel specifier. The mailbox driver allocates virtual channels backed by the single physical channel. - Added support for HS_CURR_LEVEL adjustment pinconfig property, which will be required for the Blaze board. - Addressed Stephen's review comments. Changes from v1: - Converted mailbox driver to use the common mailbox framework. - Fixed up host driver so that it can now be built and used as a module. - Addressed Stephen's review comments. - Misc. cleanups. Changes from RFC: - Dropped Tegra114 support. - Split out mailbox into separate driver. - Stopped using child xhci-plat device in xHCI host-controller driver. - Added PHY support to Thierry's XUSB padctl driver instead of in a separate USB PHY driver. - Added Jetson TK1 support. - Misc. cleanups. [0] https://lkml.org/lkml/2014/8/1/200 [1] https://lkml.org/lkml/2014/8/18/504 [2] https://patchwork.ozlabs.org/patch/384013/ [3] git://nv-tegra.nvidia.com/linux-3.10.git Andrew Bresticker (9): of: Add NVIDIA Tegra XUSB mailbox binding mailbox: Add NVIDIA Tegra XUSB mailbox driver of: Update Tegra XUSB pad controller binding for USB pinctrl: tegra-xusb: Add USB PHY support of: Add NVIDIA Tegra xHCI controller binding usb: xhci: Add NVIDIA Tegra xHCI host-controller driver ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller ARM: tegra: jetson-tk1: Add xHCI support ARM: tegra: venice2: Add xHCI support .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 + .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 56 +- .../bindings/usb/nvidia,tegra124-xhci.txt | 104 ++ arch/arm/boot/dts/tegra124-jetson-tk1.dts | 48 +- arch/arm/boot/dts/tegra124-venice2.dts | 79 +- arch/arm/boot/dts/tegra124.dtsi| 41 + drivers/mailbox/Kconfig|3 + drivers/mailbox/Makefile |2 + drivers/mailbox/tegra-xusb-mailbox.c | 290 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1233 +++- drivers/usb/host/Kconfig |9 + drivers/usb/host/Makefile |1 + drivers/usb/host/xhci-tegra.c | 905 ++ include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h | 20 + include/soc/tegra/xusb.h | 53 + 16 files changed, 2796 insertions(+), 81 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c create mode 100644 drivers/usb/host/xhci-tegra.c create mode 100644 include/soc/tegra/xusb.h -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
