Re: [PATCH V6 00/12] Tegra xHCI support
On Wed, Feb 25, 2015 at 1:15 PM, Thierry Reding wrote: > On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote: >> Hi Thierry, >> >> > Sorry for taking so awfully long to look at this. I've spent some time >> > looking at various pieces of documentation and I concluded that >> > representing the port assignment as muxing options doesn't seem right >> > after all. Instead I've come up with an alternate proposal (attached). >> > Could you take a look and see if that sounds reasonable to you? >> >> Thanks for taking a look at this. I've been meaning to pick this >> series back up, but haven't had quite enough bandwidth lately. >> >> This all looks good to me, just one comment below: >> >> > +PHY nodes: >> > +-- >> > + >> > +An optional child node named "phys" can contain nodes describing >> > additional >> > +properties of each PHY. Only USB3 and UTMI PHYs can be complemented in >> > this >> > +way, in which case the name of each node must match one of the following: >> > + >> > + usb3-0, usb3-1, utmi-0, utmi-1, utmi-2 >> > + >> > +Required properties for USB3 PHYs: >> > +- nvidia,lanes: specifies the name of the lane that this USB3 PHY uses >> > +- nvidia,port: specifies the number of the USB2 port that is used for this >> > + USB3 PHY >> > + >> > +Optional properties for UTMI PHYs: >> > +- vbus-supply: regulator providing the VBUS voltage for the UTMI pad >> >> What about the HSIC PHYs? Shouldn't they be represented as PHY nodes as >> well? > > Yes, they could. The PCIe and SATA PHYs could as well. I haven't > included them because they currently don't take any properties. In > addition to that, perhaps some of the nvidia,hsic-* properties could be > moved into the PHY nodes, too. But they're also properties of the pin, > so keeping them in the pinmux nodes seems fine as well. > > On a slightly different topic, I've been trying to wrap my head around > the use of the nvidia,port property and my conclusion was that in fact > one of the physical ports is shared between USB2 and USB3. That is the > utmi-2 PHY and usb3-0 PHY go to the very same port. The vbus-supply > specified in the Jetson TK1 DTS would support that (it's associated with > utmi-2 but named vdd_usb3_reg, and the USB3 port doesn't work without > it). Can you confirm that? Yes, that is my understanding as well. -- 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 V6 00/12] Tegra xHCI support
On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote: > Hi Thierry, > > > Sorry for taking so awfully long to look at this. I've spent some time > > looking at various pieces of documentation and I concluded that > > representing the port assignment as muxing options doesn't seem right > > after all. Instead I've come up with an alternate proposal (attached). > > Could you take a look and see if that sounds reasonable to you? > > Thanks for taking a look at this. I've been meaning to pick this > series back up, but haven't had quite enough bandwidth lately. > > This all looks good to me, just one comment below: > > > +PHY nodes: > > +-- > > + > > +An optional child node named "phys" can contain nodes describing additional > > +properties of each PHY. Only USB3 and UTMI PHYs can be complemented in this > > +way, in which case the name of each node must match one of the following: > > + > > + usb3-0, usb3-1, utmi-0, utmi-1, utmi-2 > > + > > +Required properties for USB3 PHYs: > > +- nvidia,lanes: specifies the name of the lane that this USB3 PHY uses > > +- nvidia,port: specifies the number of the USB2 port that is used for this > > + USB3 PHY > > + > > +Optional properties for UTMI PHYs: > > +- vbus-supply: regulator providing the VBUS voltage for the UTMI pad > > What about the HSIC PHYs? Shouldn't they be represented as PHY nodes as well? Yes, they could. The PCIe and SATA PHYs could as well. I haven't included them because they currently don't take any properties. In addition to that, perhaps some of the nvidia,hsic-* properties could be moved into the PHY nodes, too. But they're also properties of the pin, so keeping them in the pinmux nodes seems fine as well. On a slightly different topic, I've been trying to wrap my head around the use of the nvidia,port property and my conclusion was that in fact one of the physical ports is shared between USB2 and USB3. That is the utmi-2 PHY and usb3-0 PHY go to the very same port. The vbus-supply specified in the Jetson TK1 DTS would support that (it's associated with utmi-2 but named vdd_usb3_reg, and the USB3 port doesn't work without it). Can you confirm that? Thierry pgpTJsQjGZyDp.pgp Description: PGP signature
Re: [PATCH V6 00/12] Tegra xHCI support
Hi Thierry, > Sorry for taking so awfully long to look at this. I've spent some time > looking at various pieces of documentation and I concluded that > representing the port assignment as muxing options doesn't seem right > after all. Instead I've come up with an alternate proposal (attached). > Could you take a look and see if that sounds reasonable to you? Thanks for taking a look at this. I've been meaning to pick this series back up, but haven't had quite enough bandwidth lately. This all looks good to me, just one comment below: > +PHY nodes: > +-- > + > +An optional child node named "phys" can contain nodes describing additional > +properties of each PHY. Only USB3 and UTMI PHYs can be complemented in this > +way, in which case the name of each node must match one of the following: > + > + usb3-0, usb3-1, utmi-0, utmi-1, utmi-2 > + > +Required properties for USB3 PHYs: > +- nvidia,lanes: specifies the name of the lane that this USB3 PHY uses > +- nvidia,port: specifies the number of the USB2 port that is used for this > + USB3 PHY > + > +Optional properties for UTMI PHYs: > +- vbus-supply: regulator providing the VBUS voltage for the UTMI pad What about the HSIC PHYs? Shouldn't they be represented as PHY nodes as well? -- 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 V6 00/12] Tegra xHCI support
On Mon, Nov 24, 2014 at 04:17:12PM -0800, Andrew Bresticker wrote: > This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: > - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, > - patches 4 and 5: adding a driver for the mailbox used to communicate >with the xHCI controller's firmware, > - patches 6 and 7: extending the XUSB pad controller driver to support >the USB PHY types (UTMI, HSIC, and USB3), > - patches 8 and 9: adding a xHCI host-controller driver, and > - patches 10, 11, and 12: updating the relevant DT files. > > The mailbox driver (patch 5) has a compile-time dependency on patch 2 and > a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) > drivers have compile-time dependencies on the mailbox driver. The host > driver also has a run-time dependency on patch 1. Because of this, this > entire series should probably go through the Tegra tree. Patches 11 and 12 > should probably not be merged until the controller firmware [0] lands in > linux-firmware since they disable the EHCI controllers. > > Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and > USB3.0 memory sticks and ethernet dongles. This has also been tested, > with additional out-of-tree patches, on a Tegra132-based board. > > Based on v3.18-rc6. A branch with the entire series is available at: > https://github.com/abrestic/linux/tree/tegra-xhci-v6 > > 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 [1], the > original authors of the Tegra xHCI driver are: > Ajay Gupta > Bharath Yadav > > [0] https://patchwork.ozlabs.org/patch/400110/ > [1] git://nv-tegra.nvidia.com/linux-3.10.git > > Changes from v5: > - Addressed review comments from Jassi and Felipe. > > Changes from v4: > - Made USB support optional in padctl driver. > - Made usb3-port a pinconfig property again. > - Cleaned up mbox_request_channel() error handling and allowed it to defer >probing (patch 3). > - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested >by Thierry. > - Addressed Thierry's review comments. > > Changes from v3: > - Fixed USB2.0 flakiness on Jetson-TK1. > - Switched to 32-bit DMA mask for host. > - Addressed Stephen's review comments. > > 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. > > Andrew Bresticker (11): > xhci: Set shared HCD's hcd_priv in xhci_gen_setup > mailbox: Make struct mbox_controller's ops field const > 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: jetson-tk1: Add xHCI support > ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller > ARM: tegra: venice2: Add xHCI support > > Benson Leung (1): > mailbox: Fix up error handling in mbox_request_channel() > > .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 + > .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 63 +- > .../bindings/usb/nvidia,tegra124-xhci.txt | 104 ++ > arch/arm/boot/dts/tegra124-jetson-tk1.dts | 46 +- > 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/mailbox.c | 11 +- > drivers/mailbox/tegra-xusb-mailbox.c | 278 + > drivers/pinctrl/Kconfig|1 + > drivers/pinctrl/pinctrl-tegra-xusb.c | 1262 > +++- > drivers/usb/host/Kconfig | 10 + > drivers/usb/host/Makefile |1 + > drivers/usb/host/xhci-pci.c|5 - > drivers/usb/host/xhci-plat.c |5 - > drivers/usb/host/xhci-tegra.c | 931 +++ >
Re: [PATCH V6 00/12] Tegra xHCI support
On Tue, Nov 25, 2014 at 5:32 AM, Jassi Brar wrote: > On 25 November 2014 at 05:47, Andrew Bresticker wrote: >> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: >> - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, >> - patches 4 and 5: adding a driver for the mailbox used to communicate >>with the xHCI controller's firmware, >> - patches 6 and 7: extending the XUSB pad controller driver to support >>the USB PHY types (UTMI, HSIC, and USB3), >> - patches 8 and 9: adding a xHCI host-controller driver, and >> - patches 10, 11, and 12: updating the relevant DT files. >> >> The mailbox driver (patch 5) has a compile-time dependency on patch 2 and >> a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) >> drivers have compile-time dependencies on the mailbox driver. The host >> driver also has a run-time dependency on patch 1. Because of this, this >> entire series should probably go through the Tegra tree. >> > Why shouldn't I pick 2 & 3 at least? I don't see why not. Because of the PHY API change I'm going to have to re-spin the series and at this point 3.19 is looking pretty unlikely. Maybe we could get a Tegra maintainer's ACK for patches 4 and 5 so that you could take them through your tree as well for 3.19? (Stephen, Thierry, Alex?) -- 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 V6 00/12] Tegra xHCI support
On 25 November 2014 at 05:47, Andrew Bresticker wrote: > This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: > - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, > - patches 4 and 5: adding a driver for the mailbox used to communicate >with the xHCI controller's firmware, > - patches 6 and 7: extending the XUSB pad controller driver to support >the USB PHY types (UTMI, HSIC, and USB3), > - patches 8 and 9: adding a xHCI host-controller driver, and > - patches 10, 11, and 12: updating the relevant DT files. > > The mailbox driver (patch 5) has a compile-time dependency on patch 2 and > a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) > drivers have compile-time dependencies on the mailbox driver. The host > driver also has a run-time dependency on patch 1. Because of this, this > entire series should probably go through the Tegra tree. > Why shouldn't I pick 2 & 3 at least? -Jassi -- 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 V6 00/12] Tegra xHCI support
This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, - patches 4 and 5: adding a driver for the mailbox used to communicate with the xHCI controller's firmware, - patches 6 and 7: extending the XUSB pad controller driver to support the USB PHY types (UTMI, HSIC, and USB3), - patches 8 and 9: adding a xHCI host-controller driver, and - patches 10, 11, and 12: updating the relevant DT files. The mailbox driver (patch 5) has a compile-time dependency on patch 2 and a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) drivers have compile-time dependencies on the mailbox driver. The host driver also has a run-time dependency on patch 1. Because of this, this entire series should probably go through the Tegra tree. Patches 11 and 12 should probably not be merged until the controller firmware [0] lands in linux-firmware since they disable the EHCI controllers. Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles. This has also been tested, with additional out-of-tree patches, on a Tegra132-based board. Based on v3.18-rc6. A branch with the entire series is available at: https://github.com/abrestic/linux/tree/tegra-xhci-v6 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 [1], the original authors of the Tegra xHCI driver are: Ajay Gupta Bharath Yadav [0] https://patchwork.ozlabs.org/patch/400110/ [1] git://nv-tegra.nvidia.com/linux-3.10.git Changes from v5: - Addressed review comments from Jassi and Felipe. Changes from v4: - Made USB support optional in padctl driver. - Made usb3-port a pinconfig property again. - Cleaned up mbox_request_channel() error handling and allowed it to defer probing (patch 3). - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested by Thierry. - Addressed Thierry's review comments. Changes from v3: - Fixed USB2.0 flakiness on Jetson-TK1. - Switched to 32-bit DMA mask for host. - Addressed Stephen's review comments. 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. Andrew Bresticker (11): xhci: Set shared HCD's hcd_priv in xhci_gen_setup mailbox: Make struct mbox_controller's ops field const 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: jetson-tk1: Add xHCI support ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller ARM: tegra: venice2: Add xHCI support Benson Leung (1): mailbox: Fix up error handling in mbox_request_channel() .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 + .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 63 +- .../bindings/usb/nvidia,tegra124-xhci.txt | 104 ++ arch/arm/boot/dts/tegra124-jetson-tk1.dts | 46 +- 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/mailbox.c | 11 +- drivers/mailbox/tegra-xusb-mailbox.c | 278 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1262 +++- drivers/usb/host/Kconfig | 10 + drivers/usb/host/Makefile |1 + drivers/usb/host/xhci-pci.c|5 - drivers/usb/host/xhci-plat.c |5 - drivers/usb/host/xhci-tegra.c | 931 +++ drivers/usb/host/xhci.c|6 +- include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h |7 + include/linux/mailbox_controller.h |2 +- include/soc/tegra/xusb.h | 50 + 21 files changed, 2852 insertion
