Message ID | 1446657109-15568-3-git-send-email-thierry.reding@gmail.com |
---|---|
State | Superseded |
Headers | show |
On 11/04/2015 10:11 AM, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > Extend the binding to cover the set of feature found in Tegra210. > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > +PCIe pad: > +--------- > + > +Required properties: > +- clocks: Must contain an entry for each entry in clock-names. > +- clock-names: Must contain the following entries: > + - "pll": phandle and specifier referring to the PLLE > +- resets: Must contain an entry for each entry in reset-names. > +- reset-names: Must contain the following entries: > + - "phy": reset for the PCIe UPHY block I don't recall any clocks or resets properties in the pads for Tegra124. Do we really not need any? > +SATA pad: > +--------- > + > +Required properties: > +- resets: Must contain an entry for each entry in reset-names. > +- reset-names: Must contain the following entries: > + - "phy": reset for the SATA UPHY block > + > > PHY nodes: Nit: 2 blank lines there. > +For Tegra210, the list of valid PHY nodes is given below: > +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 > + - functions: "snps", "xusb", "uart" > +- hsic: hsic-0, hsic-1 > + - functions: "snps", "xusb" > +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 > + - functions: "pcie-x1", "usb3-ss", "pcie-x4" > +- sata: sata-0 > + - functions: "usb3-ss", "sata" usb2-bias also needs to be present. > + > + > Port nodes: > =========== Nit: 2 blank lines there. > +For Tegra210, the XUSB pad controller exposes the following ports: > +- 4x UTMI: utmi-0, utmi-1, utmi-2, utmi-3 > +- 2x HSIC: hsic-0, hsic-1 > +- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 > + > > Examples: > ========= Nit: 2 blank lines there. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: > On 11/04/2015 10:11 AM, Thierry Reding wrote: > >From: Thierry Reding <treding@nvidia.com> > > > >Extend the binding to cover the set of feature found in Tegra210. > > >diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > > >+PCIe pad: > >+--------- > >+ > >+Required properties: > >+- clocks: Must contain an entry for each entry in clock-names. > >+- clock-names: Must contain the following entries: > >+ - "pll": phandle and specifier referring to the PLLE > >+- resets: Must contain an entry for each entry in reset-names. > >+- reset-names: Must contain the following entries: > >+ - "phy": reset for the PCIe UPHY block > > I don't recall any clocks or resets properties in the pads for Tegra124. Do > we really not need any? Tegra124 had two instances of what used to be called IOPHY, one for PCIe and one for SATA. On Tegra210 these have been replaced by two instances of what's called UPHY. The resets listed in the PCIe and SATA pad nodes are wired to those UPHY instances, hence why they are new on Tegra210. For Tegra124 no resets exist for the IOPHY instances. > >+SATA pad: > >+--------- > >+ > >+Required properties: > >+- resets: Must contain an entry for each entry in reset-names. > >+- reset-names: Must contain the following entries: > >+ - "phy": reset for the SATA UPHY block > >+ > > > > PHY nodes: > > Nit: 2 blank lines there. Those were intentional for additional spacing between sections. > >+For Tegra210, the list of valid PHY nodes is given below: > >+- utmi: utmi-0, utmi-1, utmi-2, utmi-3 > >+ - functions: "snps", "xusb", "uart" > >+- hsic: hsic-0, hsic-1 > >+ - functions: "snps", "xusb" > >+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 > >+ - functions: "pcie-x1", "usb3-ss", "pcie-x4" > >+- sata: sata-0 > >+ - functions: "usb3-ss", "sata" > > usb2-bias also needs to be present. I'm not sure about this. All of the driver code that I've looked deals with the usb2-bias pad internally. As far as I can tell, this pad needs to be configured to whatever any of the other pads is configured for. I think that means if any of the UTMI pads is configured for XUSB then the usb2-bias pad must also be configured for XUSB. Which would also imply that if one of the UTMI pads is configured for XUSB, all of them must be configured for XUSB. It's also not a pad in the sense that the others are pads. It doesn't directly connect anywhere. It's also shared by all the UTMI pads. That said, there are two registers that allow some of the parameters of the pad to be set, so perhaps adding the node exclusively for configurability might make sense. It wouldn't really be a PHY node, though, so wouldn't fit into the above group. Perhaps something like the following could be added: There is an additional pad that is used to support the bias voltages to the USB2/UTMI pads. This is not a PHY that can be consumed by any I/O controller, but the device tree node can be used to specify parameters needed for the programming of the pad. I think the function shouldn't necessarily be exposed as a parameter, because all that would do is add the possibility for a conflicting set of mux options with the USB2/UTMI pads. > >+ > >+ > > Port nodes: > > =========== > > Nit: 2 blank lines there. > > >+For Tegra210, the XUSB pad controller exposes the following ports: > >+- 4x UTMI: utmi-0, utmi-1, utmi-2, utmi-3 > >+- 2x HSIC: hsic-0, hsic-1 > >+- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 > >+ > > > > Examples: > > ========= > > Nit: 2 blank lines there. Again, those were intentional for readability. I can remove them if you don't think they fulfil that purpose. Thierry
On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: >> On 11/04/2015 10:11 AM, Thierry Reding wrote: >> >From: Thierry Reding <treding@nvidia.com> >> > >> >Extend the binding to cover the set of feature found in Tegra210. >> >> >diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt >> >> >+For Tegra210, the list of valid PHY nodes is given below: >> >+- utmi: utmi-0, utmi-1, utmi-2, utmi-3 >> >+ - functions: "snps", "xusb", "uart" >> >+- hsic: hsic-0, hsic-1 >> >+ - functions: "snps", "xusb" >> >+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 >> >+ - functions: "pcie-x1", "usb3-ss", "pcie-x4" >> >+- sata: sata-0 >> >+ - functions: "usb3-ss", "sata" >> >> usb2-bias also needs to be present. > > I'm not sure about this. All of the driver code that I've looked deals > with the usb2-bias pad internally. As far as I can tell, this pad needs > to be configured to whatever any of the other pads is configured for. I > think that means if any of the UTMI pads is configured for XUSB then the > usb2-bias pad must also be configured for XUSB. Which would also imply > that if one of the UTMI pads is configured for XUSB, all of them must be > configured for XUSB. I was told by hardware engineers at NVIDIA that (at least on Tegra124/Tegra132) the usb2-bias pad must be configured in the XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB. If UTMI pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the USB register space (base 0x7d000000). You may want to follow up internally to confirm this. If it's true, that could make things here a bit nastier, especially if we want to support configurations where some pads are muxed to XUSB while others are muxed to SNPS. -Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/13/2015 09:32 AM, Thierry Reding wrote: > On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: >> On 11/04/2015 10:11 AM, Thierry Reding wrote: >>> From: Thierry Reding <treding@nvidia.com> >>> >>> Extend the binding to cover the set of feature found in Tegra210. >> >>> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt >> >>> +PCIe pad: >>> +--------- >>> + >>> +Required properties: >>> +- clocks: Must contain an entry for each entry in clock-names. >>> +- clock-names: Must contain the following entries: >>> + - "pll": phandle and specifier referring to the PLLE >>> +- resets: Must contain an entry for each entry in reset-names. >>> +- reset-names: Must contain the following entries: >>> + - "phy": reset for the PCIe UPHY block >> >> I don't recall any clocks or resets properties in the pads for Tegra124. Do >> we really not need any? > > Tegra124 had two instances of what used to be called IOPHY, one for PCIe > and one for SATA. On Tegra210 these have been replaced by two instances > of what's called UPHY. The resets listed in the PCIe and SATA pad nodes > are wired to those UPHY instances, hence why they are new on Tegra210. > > For Tegra124 no resets exist for the IOPHY instances. OK. I wonder if renaming the section title from "PCIe pad" to "Tegra210 PCIe pad" would be helpful; it'd certainly allow the reader to more quickly work out what part of the document they were looking at if jumping around in it. >>> +SATA pad: >>> +--------- >>> + >>> +Required properties: >>> +- resets: Must contain an entry for each entry in reset-names. >>> +- reset-names: Must contain the following entries: >>> + - "phy": reset for the SATA UPHY block >>> + >>> >>> PHY nodes: >> >> Nit: 2 blank lines there. > > Those were intentional for additional spacing between sections. That seems inconsistent, and not something I recall seeing before, so I'm not sure anyone would realize that. Better to do it with more explicit section names I think. >>> +For Tegra210, the list of valid PHY nodes is given below: >>> +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 >>> + - functions: "snps", "xusb", "uart" >>> +- hsic: hsic-0, hsic-1 >>> + - functions: "snps", "xusb" >>> +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 >>> + - functions: "pcie-x1", "usb3-ss", "pcie-x4" >>> +- sata: sata-0 >>> + - functions: "usb3-ss", "sata" >> >> usb2-bias also needs to be present. > > I'm not sure about this. All of the driver code that I've looked deals > with the usb2-bias pad internally. As far as I can tell, this pad needs > to be configured to whatever any of the other pads is configured for. I > think that means if any of the UTMI pads is configured for XUSB then the > usb2-bias pad must also be configured for XUSB. Which would also imply > that if one of the UTMI pads is configured for XUSB, all of them must be > configured for XUSB. I don't believe that's true; on Tegra210 I have successfully configured the (legacy) "USB2 controller" to drive the recovery/micro-USB board-level port, and the "XUSB controller" (USB2 and USB3 ports thereof) to drive a couple of other board-level ports. > It's also not a pad in the sense that the others are pads. It doesn't > directly connect anywhere. It's also shared by all the UTMI pads. That > said, there are two registers that allow some of the parameters of the > pad to be set, so perhaps adding the node exclusively for > configurability might make sense. > > It wouldn't really be a PHY node, though, so wouldn't fit into the above > group. Perhaps something like the following could be added: > > There is an additional pad that is used to support the bias voltages > to the USB2/UTMI pads. This is not a PHY that can be consumed by any > I/O controller, but the device tree node can be used to specify > parameters needed for the programming of the pad. > > I think the function shouldn't necessarily be exposed as a parameter, > because all that would do is add the possibility for a conflicting set > of mux options with the USB2/UTMI pads. OK, if we can come up with a well-described algorithm re: how/when to program/enable this pad, then we can probably represent this differently than the other pads. I might expect DT to contain values for HS_DISCON_LEVEL HS_SQUELCH_LEVEL, although I can't recall if those values are SoC- or board-specific off the top of my head. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/13/2015 10:58 AM, Andrew Bresticker wrote: > On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding > <thierry.reding@gmail.com> wrote: >> On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: >>> On 11/04/2015 10:11 AM, Thierry Reding wrote: >>>> From: Thierry Reding <treding@nvidia.com> >>>> >>>> Extend the binding to cover the set of feature found in Tegra210. >>> >>>> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt >>> >>>> +For Tegra210, the list of valid PHY nodes is given below: >>>> +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 >>>> + - functions: "snps", "xusb", "uart" >>>> +- hsic: hsic-0, hsic-1 >>>> + - functions: "snps", "xusb" >>>> +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 >>>> + - functions: "pcie-x1", "usb3-ss", "pcie-x4" >>>> +- sata: sata-0 >>>> + - functions: "usb3-ss", "sata" >>> >>> usb2-bias also needs to be present. >> >> I'm not sure about this. All of the driver code that I've looked deals >> with the usb2-bias pad internally. As far as I can tell, this pad needs >> to be configured to whatever any of the other pads is configured for. I >> think that means if any of the UTMI pads is configured for XUSB then the >> usb2-bias pad must also be configured for XUSB. Which would also imply >> that if one of the UTMI pads is configured for XUSB, all of them must be >> configured for XUSB. > > I was told by hardware engineers at NVIDIA that (at least on > Tegra124/Tegra132) the usb2-bias pad must be configured in the > XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB. If UTMI > pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the > USB register space (base 0x7d000000). You may want to follow up > internally to confirm this. If it's true, that could make things here > a bit nastier, especially if we want to support configurations where > some pads are muxed to XUSB while others are muxed to SNPS. Hmm. I've certainly successfully tested a configuration where UTMI pad 0 was handled by the SNPS controller and other pads by the XUSB controller *and* where I set the usb2-bias "pad"'s muxing and configuration via the XUSB PADCTL module. In that case, I /had/ to configure usb2-bias via XUSB PADCTL or the other XUSB pads didn't work. However, perhaps that was because the XUSB controller driver probed before the SNPS driver; perhaps if they'd probed the other way around and the SNPS driver configured the bias pad, then everything would have worked without configuring the bias pad via XUSB PADCTL. I suppose I'll have to start another internal thread to get the full details, and differentiate between "recommended" and "supported" and "must" vs. "can"/"should". -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/16/2015 01:30 PM, Stephen Warren wrote: > On 11/13/2015 10:58 AM, Andrew Bresticker wrote: >> On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding >> <thierry.reding@gmail.com> wrote: >>> On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: >>>> On 11/04/2015 10:11 AM, Thierry Reding wrote: >>>>> From: Thierry Reding <treding@nvidia.com> >>>>> >>>>> Extend the binding to cover the set of feature found in Tegra210. >>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt >>>>> >>>> >>>>> +For Tegra210, the list of valid PHY nodes is given below: >>>>> +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 >>>>> + - functions: "snps", "xusb", "uart" >>>>> +- hsic: hsic-0, hsic-1 >>>>> + - functions: "snps", "xusb" >>>>> +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 >>>>> + - functions: "pcie-x1", "usb3-ss", "pcie-x4" >>>>> +- sata: sata-0 >>>>> + - functions: "usb3-ss", "sata" >>>> >>>> usb2-bias also needs to be present. >>> >>> I'm not sure about this. All of the driver code that I've looked deals >>> with the usb2-bias pad internally. As far as I can tell, this pad needs >>> to be configured to whatever any of the other pads is configured for. I >>> think that means if any of the UTMI pads is configured for XUSB then the >>> usb2-bias pad must also be configured for XUSB. Which would also imply >>> that if one of the UTMI pads is configured for XUSB, all of them must be >>> configured for XUSB. >> >> I was told by hardware engineers at NVIDIA that (at least on >> Tegra124/Tegra132) the usb2-bias pad must be configured in the >> XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB. If UTMI >> pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the >> USB register space (base 0x7d000000). You may want to follow up >> internally to confirm this. If it's true, that could make things here >> a bit nastier, especially if we want to support configurations where >> some pads are muxed to XUSB while others are muxed to SNPS. > > Hmm. I've certainly successfully tested a configuration where UTMI pad 0 > was handled by the SNPS controller and other pads by the XUSB controller > *and* where I set the usb2-bias "pad"'s muxing and configuration via the > XUSB PADCTL module. In that case, I /had/ to configure usb2-bias via > XUSB PADCTL or the other XUSB pads didn't work. However, perhaps that > was because the XUSB controller driver probed before the SNPS driver; > perhaps if they'd probed the other way around and the SNPS driver > configured the bias pad, then everything would have worked without > configuring the bias pad via XUSB PADCTL. > > I suppose I'll have to start another internal thread to get the full > details, and differentiate between "recommended" and "supported" and > "must" vs. "can"/"should". I've discussed this with a HW engineer, and apparently this rule is simply a recommendation, with the acknowledgement that everything will work perfectly fine if we ignore it. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt index 026e924ae54a..e7d7400bc981 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt @@ -22,6 +22,7 @@ Required properties: -------------------- - compatible: Must be: - "nvidia,tegra124-xusb-padctl": for Tegra124 and Tegra132 + - "nvidia,tegra210-xusb-padctl": for Tegra210 - reg: Physical base address and length of the controller's registers. - resets: Must contain an entry for each entry in reset-names. - reset-names: Must include the following entries: @@ -45,6 +46,44 @@ the pad and any of its lanes, this property must be set to "okay". For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie and sata. No extra resources are required for operation of these pads. +For Tegra210, the following pads exist: utmi, hsic, pcie and sata. Below is +a description of the properties of each pad. + +UTMI pad: +--------- + +Required properties: +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Must contain the following entries: + - "trk": phandle and specifier referring to the USB2 tracking clock + +HSIC pad: +--------- + +Required properties: +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Must contain the following entries: + - "trk": phandle and specifier referring to the HSIC tracking clock + +PCIe pad: +--------- + +Required properties: +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Must contain the following entries: + - "pll": phandle and specifier referring to the PLLE +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the PCIe UPHY block + +SATA pad: +--------- + +Required properties: +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the SATA UPHY block + PHY nodes: ========== @@ -74,6 +113,17 @@ For Tegra124 and Tegra132, the list of valid PHY nodes is given below: - sata: sata-0 - functions: "usb3-ss", "sata" +For Tegra210, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 + - functions: "snps", "xusb", "uart" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 + - functions: "pcie-x1", "usb3-ss", "pcie-x4" +- sata: sata-0 + - functions: "usb3-ss", "sata" + + Port nodes: =========== @@ -129,6 +179,7 @@ Required properties: this super-speed USB port to. The range of valid port numbers varies with the SoC generation: - 0-2: for Tegra124 and Tegra132 + - 0-3: for Tegra210 Optional properties: - nvidia,internal: A boolean property whose presence determines that a port @@ -142,6 +193,11 @@ ports: - 2x HSIC: hsic-0, hsic-1 - 2x super-speed USB: usb3-0, usb3-1 +For Tegra210, the XUSB pad controller exposes the following ports: +- 4x UTMI: utmi-0, utmi-1, utmi-2, utmi-3 +- 2x HSIC: hsic-0, hsic-1 +- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 + Examples: ========= @@ -357,3 +413,277 @@ Board file: }; }; }; + +Tegra210: +--------- + +SoC include: + + padctl@0,7009f000 { + compatible = "nvidia,tegra210-xusb-padctl"; + reg = <0x0 0x7009f000 0x0 0x1000>; + resets = <&tegra_car 142>; + reset-names = "padctl"; + mboxes = <&xusb_mbox>; + mbox-names = "xusb"; + + status = "disabled"; + + pads { + utmi { + clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>; + clock-names = "trk"; + status = "disabled"; + + utmi-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + utmi-1 { + status = "disabled"; + #phy-cells = <0>; + }; + + utmi-2 { + status = "disabled"; + #phy-cells = <0>; + }; + + utmi-3 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + hsic { + clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>; + clock-names = "trk"; + status = "disabled"; + + hsic-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + hsic-1 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + pcie { + clocks = <&tegra_car TEGRA210_CLK_PLL_E>; + clock-names = "pll"; + resets = <&tegra_car 205>; + reset-names = "phy"; + status = "disabled"; + + pcie-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-1 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-2 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-3 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-4 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-5 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-6 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + sata { + clocks = <&tegra_car TEGRA210_CLK_PLL_E>; + clock-names = "pll"; + resets = <&tegra_car 204>; + reset-names = "phy"; + status = "disabled"; + + sata-0 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + }; + + ports { + utmi-0 { + status = "disabled"; + }; + + utmi-1 { + status = "disabled"; + }; + + utmi-2 { + status = "disabled"; + }; + + utmi-3 { + status = "disabled"; + }; + + hsic-0 { + status = "disabled"; + }; + + hsic-1 { + status = "disabled"; + }; + + usb3-0 { + status = "disabled"; + }; + + usb3-1 { + status = "disabled"; + }; + + usb3-2 { + status = "disabled"; + }; + + usb3-3 { + status = "disabled"; + }; + }; + }; + +Board file: + + padctl@0,7009f000 { + status = "okay"; + + pads { + utmi { + status = "okay"; + + utmi-0 { + nvidia,function = "xusb"; + status = "okay"; + }; + + utmi-1 { + nvidia,function = "xusb"; + status = "okay"; + }; + + utmi-2 { + nvidia,function = "xusb"; + status = "okay"; + }; + + utmi-3 { + nvidia,function = "xusb"; + status = "okay"; + }; + }; + + pcie { + status = "okay"; + + pcie-0 { + nvidia,function = "pcie-x1"; + status = "okay"; + }; + + pcie-1 { + nvidia,function = "pcie-x4"; + status = "okay"; + }; + + pcie-2 { + nvidia,function = "pcie-x4"; + status = "okay"; + }; + + pcie-3 { + nvidia,function = "pcie-x4"; + status = "okay"; + }; + + pcie-4 { + nvidia,function = "pcie-x4"; + status = "okay"; + }; + + pcie-5 { + nvidia,function = "usb3-ss"; + status = "okay"; + }; + + pcie-6 { + nvidia,function = "usb3-ss"; + status = "okay"; + }; + }; + + sata { + status = "okay"; + + sata-0 { + nvidia,function = "sata"; + status = "okay"; + }; + }; + }; + + ports { + utmi-0 { + status = "okay"; + mode = "otg"; + }; + + utmi-1 { + status = "okay"; + vbus-supply = <&vdd_5v0_rtl>; + mode = "host"; + }; + + utmi-2 { + status = "okay"; + vbus-supply = <&vdd_usb_vbus>; + mode = "host"; + }; + + utmi-3 { + status = "okay"; + mode = "host"; + }; + + usb3-0 { + status = "okay"; + nvidia,lanes = "pcie-6"; + nvidia,port = <1>; + }; + + usb3-1 { + status = "okay"; + nvidia,lanes = "pcie-5"; + nvidia,port = <2>; + }; + }; + };