[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Signed-off-by: Stephen Warren swarren@nvidia.com --- board/compulab/dts/tegra20-trimslice.dts | 3 ++- board/compulab/trimslice/trimslice.c | 8 ++++++++ include/configs/trimslice.h | 1 + 3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/board/compulab/dts/tegra20-trimslice.dts b/board/compulab/dts/tegra20-trimslice.dts index db79e77..4450674 100644 --- a/board/compulab/dts/tegra20-trimslice.dts +++ b/board/compulab/dts/tegra20-trimslice.dts @@ -8,6 +8,7 @@
aliases { usb0 = "/usb@c5008000"; + usb1 = "/usb@c5000000"; };
memory { @@ -48,7 +49,7 @@ };
usb@c5000000 { - status = "disabled"; + nvidia,vbus-gpio = <&gpio 170 0>; /* PV2 */ };
usb@c5004000 { diff --git a/board/compulab/trimslice/trimslice.c b/board/compulab/trimslice/trimslice.c index 9ef66fd..8f4dd09 100644 --- a/board/compulab/trimslice/trimslice.c +++ b/board/compulab/trimslice/trimslice.c @@ -34,6 +34,14 @@ #include <mmc.h> #endif
+void pin_mux_usb(void) +{ + /* + * USB1 internal/external mux GPIO, which masquerades as a VBUS GPIO + * in the current device tree. + */ + pinmux_tristate_disable(PINGRP_UAC); +}
void pin_mux_spi(void) { diff --git a/include/configs/trimslice.h b/include/configs/trimslice.h index eeb0dbe..165bc73 100644 --- a/include/configs/trimslice.h +++ b/include/configs/trimslice.h @@ -80,6 +80,7 @@ #define CONFIG_ENV_OFFSET (512 * 1024)
/* USB Host support */ +#define CONFIG_USB_MAX_CONTROLLER_COUNT 3 #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_TEGRA #define CONFIG_USB_STORAGE
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
Signed-off-by: Stephen Warren swarren@nvidia.com
board/compulab/dts/tegra20-trimslice.dts | 3 ++- board/compulab/trimslice/trimslice.c | 8 ++++++++ include/configs/trimslice.h | 1 + 3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/board/compulab/dts/tegra20-trimslice.dts b/board/compulab/dts/tegra20-trimslice.dts index db79e77..4450674 100644 --- a/board/compulab/dts/tegra20-trimslice.dts +++ b/board/compulab/dts/tegra20-trimslice.dts @@ -8,6 +8,7 @@
aliases { usb0 = "/usb@c5008000";
usb1 = "/usb@c5000000";};
memory {
@@ -48,7 +49,7 @@ };
usb@c5000000 {
status = "disabled";
nvidia,vbus-gpio = <&gpio 170 0>; /* PV2 */};
usb@c5004000 {
diff --git a/board/compulab/trimslice/trimslice.c b/board/compulab/trimslice/trimslice.c index 9ef66fd..8f4dd09 100644 --- a/board/compulab/trimslice/trimslice.c +++ b/board/compulab/trimslice/trimslice.c @@ -34,6 +34,14 @@ #include <mmc.h> #endif
+void pin_mux_usb(void) +{
- /*
* USB1 internal/external mux GPIO, which masquerades as a VBUS GPIO* in the current device tree.*/- pinmux_tristate_disable(PINGRP_UAC);
+}
void pin_mux_spi(void) { diff --git a/include/configs/trimslice.h b/include/configs/trimslice.h index eeb0dbe..165bc73 100644 --- a/include/configs/trimslice.h +++ b/include/configs/trimslice.h @@ -80,6 +80,7 @@ #define CONFIG_ENV_OFFSET (512 * 1024)
/* USB Host support */ +#define CONFIG_USB_MAX_CONTROLLER_COUNT 3 #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_TEGRA #define CONFIG_USB_STORAGE
On 11/01/2012 05:17 PM, Lucas Stach wrote:
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
I don't know, I think it's fine. It's certainly this way in the kernel. And for all I know, this GPIO does actually affect VBUS as well as flipping any mux (and the more I think about that, the more likely it is) although I can't actually know for sure since I don't have the schematics.
Am Donnerstag, den 01.11.2012, 17:30 -0600 schrieb Stephen Warren:
On 11/01/2012 05:17 PM, Lucas Stach wrote:
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
I don't know, I think it's fine. It's certainly this way in the kernel. And for all I know, this GPIO does actually affect VBUS as well as flipping any mux (and the more I think about that, the more likely it is) although I can't actually know for sure since I don't have the schematics.
If it's really triggering VBUS I'm fine with this, but then the comment in pin_mux_usb() is a bit off.
On 11/01/2012 05:34 PM, Lucas Stach wrote:
Am Donnerstag, den 01.11.2012, 17:30 -0600 schrieb Stephen Warren:
On 11/01/2012 05:17 PM, Lucas Stach wrote:
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
I don't know, I think it's fine. It's certainly this way in the kernel. And for all I know, this GPIO does actually affect VBUS as well as flipping any mux (and the more I think about that, the more likely it is) although I can't actually know for sure since I don't have the schematics.
If it's really triggering VBUS I'm fine with this, but then the comment in pin_mux_usb() is a bit off.
Sorry, I don't see anything inaccurate about it. What's wrong?
Am Freitag, den 02.11.2012, 08:45 -0600 schrieb Stephen Warren:
On 11/01/2012 05:34 PM, Lucas Stach wrote:
Am Donnerstag, den 01.11.2012, 17:30 -0600 schrieb Stephen Warren:
On 11/01/2012 05:17 PM, Lucas Stach wrote:
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
I don't know, I think it's fine. It's certainly this way in the kernel. And for all I know, this GPIO does actually affect VBUS as well as flipping any mux (and the more I think about that, the more likely it is) although I can't actually know for sure since I don't have the schematics.
If it's really triggering VBUS I'm fine with this, but then the comment in pin_mux_usb() is a bit off.
Sorry, I don't see anything inaccurate about it. What's wrong?
In which way is it "masquerades as a VBUS GPIO"? If it triggers VBUS it _is_ a VBUS GPIO. So the comment should rather state that switching on VBUS also muxes the port to the internal bridge.
On 11/02/2012 09:30 AM, Lucas Stach wrote:
Am Freitag, den 02.11.2012, 08:45 -0600 schrieb Stephen Warren:
On 11/01/2012 05:34 PM, Lucas Stach wrote:
Am Donnerstag, den 01.11.2012, 17:30 -0600 schrieb Stephen Warren:
On 11/01/2012 05:17 PM, Lucas Stach wrote:
Hi Stephen,
Am Donnerstag, den 01.11.2012, 16:14 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Hm, I don't really like to abuse the VBUS GPIO for this function. As the GPIO controlled routing is more a sort of pinmux can't you just add the GPIO enable to pin_mux_usb()?
I don't know, I think it's fine. It's certainly this way in the kernel. And for all I know, this GPIO does actually affect VBUS as well as flipping any mux (and the more I think about that, the more likely it is) although I can't actually know for sure since I don't have the schematics.
If it's really triggering VBUS I'm fine with this, but then the comment in pin_mux_usb() is a bit off.
Sorry, I don't see anything inaccurate about it. What's wrong?
In which way is it "masquerades as a VBUS GPIO"? If it triggers VBUS it _is_ a VBUS GPIO. So the comment should rather state that switching on VBUS also muxes the port to the internal bridge.
The GPIO definitely flips some form of bus mux. It's unclear whether it is a also VBUS GPIO for the internal device or not. My suspicion is that it must be, but without schematics I can't confirm. Either way, the comment seems quite accurate and descriptive, and this seems a perfectly reasonable solution.
On Thu, Nov 1, 2012 at 3:14 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
TrimSlice's USB1 port has two purposes; it either acts as a device port hosting Tegra's USB recovery protocol, or acts as a host port connected to the internal USB->SATA bridge chip, which may in turn be connected to an SSD or HDD. Add the appropriate device tree and board configuration options to enable this port as a host port, and route the port to the SATA bridge using the VBUS GPIO.
Signed-off-by: Stephen Warren swarren@nvidia.com
Looks right to me.
Acked-by: Simon Glass sjg@chromium.org
board/compulab/dts/tegra20-trimslice.dts | 3 ++- board/compulab/trimslice/trimslice.c | 8 ++++++++ include/configs/trimslice.h | 1 + 3 files changed, 11 insertions(+), 1 deletions(-)
participants (3)
-
Lucas Stach -
Simon Glass -
Stephen Warren