| Message ID | 1351808077-11932-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Warren |
| Headers | show |
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 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(-)
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.
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