[PATCH V5 1/6] dt-bindings: usb: Add NVIDIA Tegra234 XUSB host controller binding

[Thierry Reding]

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 at 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 at nvidia.com>
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > Signed-off-by: Jon Hunter <jonathanh at 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 at gmail.com>
> > +  - Jon Hunter <jonathanh at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20230109/9920908b/attachment.sig>