[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[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.

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 at c5008000";
+		usb1 = "/usb at c5000000";
 	};
 
 	memory {
@@ -48,7 +49,7 @@
 	};
 
 	usb at c5000000 {
-		status = "disabled";
+		nvidia,vbus-gpio = <&gpio 170 0>; /* PV2 */
 	};
 
 	usb at 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
-- 
1.7.0.4

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[Lucas Stach]

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 at c5008000";
> +		usb1 = "/usb at c5000000";
>  	};
>  
>  	memory {
> @@ -48,7 +49,7 @@
>  	};
>  
>  	usb at c5000000 {
> -		status = "disabled";
> +		nvidia,vbus-gpio = <&gpio 170 0>; /* PV2 */
>  	};
>  
>  	usb at 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

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[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.

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[Lucas Stach]

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.

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[Simon Glass]

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(-)

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[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?

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[Lucas Stach]

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.

[U-Boot] [PATCH] ARM: tegra: TrimSlice: add support for USB1 port

[Stephen Warren]

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.