Message ID | 20230106152858.49574-2-jonathanh@nvidia.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Enable USB host on Jetson AGX Orin | expand |
On 06/01/2023 16:28, Jon Hunter wrote: > From: Wayne Chang <waynec@nvidia.com> > > Add device-tree binding documentation for the XUSB host controller present > on Tegra234 SoC. This controller supports the USB 3.1 specification. > > Signed-off-by: Wayne Chang <waynec@nvidia.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > --- > V4 -> V5: No changes > V3 -> V4: minor update to the power-domain description > V2 -> V3: nothing has changed > V1 -> V2: address the issue on phy-names property > > .../bindings/usb/nvidia,tegra234-xusb.yaml | 158 ++++++++++++++++++ > 1 file changed, 158 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > > diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > new file mode 100644 > index 000000000000..190a23c72963 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > @@ -0,0 +1,158 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/nvidia,tegra234-xusb.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NVIDIA Tegra234 xHCI controller > + > +maintainers: > + - Thierry Reding <thierry.reding@gmail.com> > + - Jon Hunter <jonathanh@nvidia.com> > + > +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces Line ends after "description:" > + exposed by the Tegra XUSB pad controller. > + > +properties: > + compatible: > + const: nvidia,tegra234-xusb > + > + reg: > + items: > + - description: base and length of the xHCI host registers Just "xHCI host registers". Same in other places. > + - description: base and length of the XUSB FPCI registers > + - description: base and length of the XUSB bar2 registers > + > + reg-names: > + items: > + - const: hcd > + - const: fpci > + - const: bar2 > + > + interrupts: > + items: > + - description: xHCI host interrupt > + - description: mailbox interrupt > + > + clocks: > + items: > + - description: XUSB host clock > + - description: XUSB Falcon source clock > + - description: XUSB SuperSpeed clock > + - description: XUSB SuperSpeed source clock > + - description: XUSB HighSpeed clock source > + - description: XUSB FullSpeed clock source > + - description: USB PLL > + - description: reference clock > + - description: I/O PLL > + > + clock-names: > + items: > + - const: xusb_host > + - const: xusb_falcon_src > + - const: xusb_ss > + - const: xusb_ss_src > + - const: xusb_hs_src > + - const: xusb_fs_src > + - const: pll_u_480m > + - const: clk_m > + - const: pll_e > + > + interconnects: > + items: > + - description: read client > + - description: write client > + > + interconnect-names: > + items: > + - const: dma-mem # read > + - const: write > + > + iommus: > + maxItems: 1 > + > + nvidia,xusb-padctl: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: phandle to the XUSB pad controller that is used to configure > + the USB pads used by the XHCI controller > + > + phys: > + minItems: 1 > + maxItems: 8 > + > + phy-names: > + minItems: 1 > + maxItems: 8 > + items: > + enum: > + - usb2-0 > + - usb2-1 > + - usb2-2 > + - usb2-3 > + - usb3-0 > + - usb3-1 > + - usb3-2 > + - usb3-3 Why do you have so many optional phys? In what case you would put there usb2-0 and usb3-3 together? Or even 8 phys at the same time? IOW, what are the differences between them and why one controller would be connected once to usb3-2 and once to usb3-3 phy? And once to both? > + > + power-domains: > + items: > + - description: XUSBC power domain (for Host and USB 2.0) > + - description: XUSBA power domain (for SuperSpeed) > + > + power-domain-names: > + items: > + - const: xusb_host > + - const: xusb_ss > + > + dma-coherent: Just: true > + type: boolean Drop > + > +allOf: > + - $ref: usb-xhci.yaml > + > +unevaluatedProperties: false > + Best regards, Krzysztof
On Sun, Jan 08, 2023 at 04:21:24PM +0100, Krzysztof Kozlowski wrote: > On 06/01/2023 16:28, Jon Hunter wrote: > > From: Wayne Chang <waynec@nvidia.com> > > > > Add device-tree binding documentation for the XUSB host controller present > > on Tegra234 SoC. This controller supports the USB 3.1 specification. > > > > Signed-off-by: Wayne Chang <waynec@nvidia.com> > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > > --- > > V4 -> V5: No changes > > V3 -> V4: minor update to the power-domain description > > V2 -> V3: nothing has changed > > V1 -> V2: address the issue on phy-names property > > > > .../bindings/usb/nvidia,tegra234-xusb.yaml | 158 ++++++++++++++++++ > > 1 file changed, 158 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > > > > diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > > new file mode 100644 > > index 000000000000..190a23c72963 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml > > @@ -0,0 +1,158 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/usb/nvidia,tegra234-xusb.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: NVIDIA Tegra234 xHCI controller > > + > > +maintainers: > > + - Thierry Reding <thierry.reding@gmail.com> > > + - Jon Hunter <jonathanh@nvidia.com> > > + > > +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces > > Line ends after "description:" > > > + exposed by the Tegra XUSB pad controller. > > + > > +properties: > > + compatible: > > + const: nvidia,tegra234-xusb > > + > > + reg: > > + items: > > + - description: base and length of the xHCI host registers > > Just "xHCI host registers". Same in other places. > > > + - description: base and length of the XUSB FPCI registers > > + - description: base and length of the XUSB bar2 registers > > + > > + reg-names: > > + items: > > + - const: hcd > > + - const: fpci > > + - const: bar2 > > + > > + interrupts: > > + items: > > + - description: xHCI host interrupt > > + - description: mailbox interrupt > > + > > + clocks: > > + items: > > + - description: XUSB host clock > > + - description: XUSB Falcon source clock > > + - description: XUSB SuperSpeed clock > > + - description: XUSB SuperSpeed source clock > > + - description: XUSB HighSpeed clock source > > + - description: XUSB FullSpeed clock source > > + - description: USB PLL > > + - description: reference clock > > + - description: I/O PLL > > + > > + clock-names: > > + items: > > + - const: xusb_host > > + - const: xusb_falcon_src > > + - const: xusb_ss > > + - const: xusb_ss_src > > + - const: xusb_hs_src > > + - const: xusb_fs_src > > + - const: pll_u_480m > > + - const: clk_m > > + - const: pll_e > > + > > + interconnects: > > + items: > > + - description: read client > > + - description: write client > > + > > + interconnect-names: > > + items: > > + - const: dma-mem # read > > + - const: write > > + > > + iommus: > > + maxItems: 1 > > + > > + nvidia,xusb-padctl: > > + $ref: /schemas/types.yaml#/definitions/phandle > > + description: phandle to the XUSB pad controller that is used to configure > > + the USB pads used by the XHCI controller > > + > > + phys: > > + minItems: 1 > > + maxItems: 8 > > + > > + phy-names: > > + minItems: 1 > > + maxItems: 8 > > + items: > > + enum: > > + - usb2-0 > > + - usb2-1 > > + - usb2-2 > > + - usb2-3 > > + - usb3-0 > > + - usb3-1 > > + - usb3-2 > > + - usb3-3 > > Why do you have so many optional phys? In what case you would put there > usb2-0 and usb3-3 together? Or even 8 phys at the same time? IOW, what > are the differences between them and why one controller would be > connected once to usb3-2 and once to usb3-3 phy? And once to both? This controller has up to four ports, each of which can be wired to a USB connector. Furthermore, each port is composed of a USB3 port and a USB2 companion port. You can technically have USB3-only ports, though I'm not sure if that's actually supported, USB3/2 combo ports (the typical case) and USB2-only ports. So that's why we have four USB3 PHYs, each controlling the physical layer of one USB3 port and four USB2 PHYs, each of which can be bound to one of the USB3 PHYs to make a composite USB3/2 port. Thierry
On 08/01/2023 15:21, Krzysztof Kozlowski wrote: ... > On 06/01/2023 16:28, Jon Hunter wrote: >> + phys: >> + minItems: 1 >> + maxItems: 8 >> + >> + phy-names: >> + minItems: 1 >> + maxItems: 8 >> + items: >> + enum: >> + - usb2-0 >> + - usb2-1 >> + - usb2-2 >> + - usb2-3 >> + - usb3-0 >> + - usb3-1 >> + - usb3-2 >> + - usb3-3 > > Why do you have so many optional phys? In what case you would put there > usb2-0 and usb3-3 together? Or even 8 phys at the same time? IOW, what > are the differences between them and why one controller would be > connected once to usb3-2 and once to usb3-3 phy? And once to both? Here is the description from the device documentation ... "The NVIDIA Orin series System-on-Chip (SoC) has one xHCI host controller and one USB 3.2 Gen1 x1 device controller. The two controllers control a total of up to eight exposed ports. There are up to four USB 2.0 ports and up to four USB 3.2 Gen1 x1 ports." So there are eight phys and we could have 4 USB2 and 4 USB3. Depending on which pins you want to use, you could have various combinations. I can add these details to the binding doc if that helps. Thanks Jon
On 09/01/2023 18:00, Jon Hunter wrote: > > On 08/01/2023 15:21, Krzysztof Kozlowski wrote: > > ... > >> On 06/01/2023 16:28, Jon Hunter wrote: >>> + phys: >>> + minItems: 1 >>> + maxItems: 8 >>> + >>> + phy-names: >>> + minItems: 1 >>> + maxItems: 8 >>> + items: >>> + enum: >>> + - usb2-0 >>> + - usb2-1 >>> + - usb2-2 >>> + - usb2-3 >>> + - usb3-0 >>> + - usb3-1 >>> + - usb3-2 >>> + - usb3-3 >> >> Why do you have so many optional phys? In what case you would put there >> usb2-0 and usb3-3 together? Or even 8 phys at the same time? IOW, what >> are the differences between them and why one controller would be >> connected once to usb3-2 and once to usb3-3 phy? And once to both? > > > Here is the description from the device documentation ... > > "The NVIDIA Orin series System-on-Chip (SoC) has one xHCI host > controller and one USB 3.2 Gen1 x1 device controller. The two > controllers control a total of up to eight exposed ports. There are up > to four USB 2.0 ports and up to four USB 3.2 Gen1 x1 ports." > > So there are eight phys and we could have 4 USB2 and 4 USB3. Depending > on which pins you want to use, you could have various combinations. I > can add these details to the binding doc if that helps. Yeah, could solve some questions. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml new file mode 100644 index 000000000000..190a23c72963 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nvidia,tegra234-xusb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra234 xHCI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The Tegra xHCI controller supports both USB2 and USB3 interfaces + exposed by the Tegra XUSB pad controller. + +properties: + compatible: + const: nvidia,tegra234-xusb + + reg: + items: + - description: base and length of the xHCI host registers + - description: base and length of the XUSB FPCI registers + - description: base and length of the XUSB bar2 registers + + reg-names: + items: + - const: hcd + - const: fpci + - const: bar2 + + interrupts: + items: + - description: xHCI host interrupt + - description: mailbox interrupt + + clocks: + items: + - description: XUSB host clock + - description: XUSB Falcon source clock + - description: XUSB SuperSpeed clock + - description: XUSB SuperSpeed source clock + - description: XUSB HighSpeed clock source + - description: XUSB FullSpeed clock source + - description: USB PLL + - description: reference clock + - description: I/O PLL + + clock-names: + items: + - const: xusb_host + - const: xusb_falcon_src + - const: xusb_ss + - const: xusb_ss_src + - const: xusb_hs_src + - const: xusb_fs_src + - const: pll_u_480m + - const: clk_m + - const: pll_e + + interconnects: + items: + - description: read client + - description: write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + iommus: + maxItems: 1 + + nvidia,xusb-padctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the XUSB pad controller that is used to configure + the USB pads used by the XHCI controller + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + maxItems: 8 + items: + enum: + - usb2-0 + - usb2-1 + - usb2-2 + - usb2-3 + - usb3-0 + - usb3-1 + - usb3-2 + - usb3-3 + + power-domains: + items: + - description: XUSBC power domain (for Host and USB 2.0) + - description: XUSBA power domain (for SuperSpeed) + + power-domain-names: + items: + - const: xusb_host + - const: xusb_ss + + dma-coherent: + type: boolean + +allOf: + - $ref: usb-xhci.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra234-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra234-mc.h> + #include <dt-bindings/power/tegra234-powergate.h> + + usb@3610000 { + compatible = "nvidia,tegra234-xusb"; + reg = <0x03610000 0x40000>, + <0x03600000 0x10000>, + <0x03650000 0x10000>; + reg-names = "hcd", "fpci", "bar2"; + + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&bpmp TEGRA234_CLK_XUSB_CORE_HOST>, + <&bpmp TEGRA234_CLK_XUSB_FALCON>, + <&bpmp TEGRA234_CLK_XUSB_CORE_SS>, + <&bpmp TEGRA234_CLK_XUSB_SS>, + <&bpmp TEGRA234_CLK_CLK_M>, + <&bpmp TEGRA234_CLK_XUSB_FS>, + <&bpmp TEGRA234_CLK_UTMIP_PLL>, + <&bpmp TEGRA234_CLK_CLK_M>, + <&bpmp TEGRA234_CLK_PLLE>; + clock-names = "xusb_host", "xusb_falcon_src", + "xusb_ss", "xusb_ss_src", "xusb_hs_src", + "xusb_fs_src", "pll_u_480m", "clk_m", + "pll_e"; + interconnects = <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTR &emc>, + <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTW &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu_niso1 TEGRA234_SID_XUSB_HOST>; + + power-domains = <&bpmp TEGRA234_POWER_DOMAIN_XUSBC>, + <&bpmp TEGRA234_POWER_DOMAIN_XUSBA>; + power-domain-names = "xusb_host", "xusb_ss"; + + nvidia,xusb-padctl = <&xusb_padctl>; + + phys = <&pad_lanes_usb2_0>; + phy-names = "usb2-0"; + };