diff mbox

[2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

Message ID 1446657109-15568-3-git-send-email-thierry.reding@gmail.com
State Superseded
Headers show

Commit Message

Thierry Reding Nov. 4, 2015, 5:11 p.m. UTC
From: Thierry Reding <treding@nvidia.com>

Extend the binding to cover the set of feature found in Tegra210.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 .../bindings/phy/nvidia,tegra-xusb-padctl.txt      | 330 +++++++++++++++++++++
 1 file changed, 330 insertions(+)

Comments

Stephen Warren Nov. 4, 2015, 8:59 p.m. UTC | #1
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
Thierry Reding Nov. 13, 2015, 4:32 p.m. UTC | #2
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
Andrew Bresticker Nov. 13, 2015, 5:58 p.m. UTC | #3
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
Stephen Warren Nov. 16, 2015, 8:26 p.m. UTC | #4
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
Stephen Warren Nov. 16, 2015, 8:30 p.m. UTC | #5
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
Stephen Warren Nov. 16, 2015, 11:35 p.m. UTC | #6
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 mbox

Patch

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>;
+			};
+		};
+	};