Re: [PATCH 1/2] dt-bindings: usb: Introduce GPIO-based SBU mux

[Bjorn Andersson]

On Sun 14 Aug 16:01 CDT 2022, Rob Herring wrote:

> On Thu, Aug 11, 2022 at 12:14:48PM +0300, Krzysztof Kozlowski wrote:
> > On 10/08/2022 23:47, Bjorn Andersson wrote:
> > > Introduce a binding for GPIO-based mux hardware used for connecting,
> > > disconnecting and switching orientation of the SBU lines in USB Type-C
> > > applications.
> > > 
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > > ---
> > >  .../devicetree/bindings/usb/gpio-sbu-mux.yaml | 77 +++++++++++++++++++
> > >  1 file changed, 77 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> > > new file mode 100644
> > > index 000000000000..7d8aca40c7ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> > > @@ -0,0 +1,77 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: "http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#";
> > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > > +
> > > +title: GPIO-based SBU mux
> > > +
> > > +maintainers:
> > > +  - Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > > +
> > > +description:
> > > +  In USB Type-C applications the SBU lines needs to be connected, disconnected
> > > +  and swapped depending on the altmode and orientation. This binding describes
> > > +  a family of hardware which perform this based on GPIO controls.
> > 
> > +Cc few folks.
> > 
> > This looks familiar to:
> > 
> > https://lore.kernel.org/linux-devicetree/eaf2fda8-0cd6-b518-10cb-4e21b5f8c909@xxxxxxxxxx/T/#m39254b7f8970b3e1264f9d1a979557bb46ab162c
> > 
> > Rob and Stephen had several concerns about that approach.
> 
> My overall concern is a bunch of one-off bindings with no one thinking 
> about a variety of USB-C h/w. I need h/w diagrams and corresponding 
> bindings. The key part being more than 1. I'm not all that familiar with 
> the former to help on the bindings.
> 

This is the setup that we're dealing with:

                     +------------- - -
 USB connector       | SoC
 +-+                 |
 | |                 |   +-----+
 |*|<------- HS -----|-->| HS  |
 |*|<------- HS -----|-->| phy |<-+   +--------+
 | |                 |   +-----+   \->|        |
 | |                 |                |  dwc3  |
 | |                 |   +-----+   /->|        |
 |*|<------- SS -----|-->|     |<-+   +--------+
 |*|<------- SS -----|-->| QMP |
 |*|<------- SS -----|-->| phy |
 |*|<------- SS -----|-->|     |<-\   +------------+
 | |                 |   +-----+   \->|            |
 | |                 |                |     DP     |
 | |    +-----+      |                | controller |
 |*|<-->| SBU |<-----|--------------->|            |
 |*|<-->| mux |<-----|--------------->|            |
 | |    +----+       |                +------------+
 +-+                 |
                     +------------- - -

The dwc3 controller is connected to the HS phy for HighSpeed signals and
QMP phy to be muxed out on 0, 2 or 4 of the SuperSpeed pins (for
DP-only, USB/DP combo or USB-only mode).

The DisplayPort controller is connected to the same QMP phy, for and is
muxed onto the same 0, 2 or 4 of the SuperSpeed pins (for USB-only,
USB/DP combo or DP-only mode).

The SuperSpeed pins can be switched around within the QMP phy, to handle
the case where the USB Type-C cable is flipped around.


The AUX pins of the DP controller are connected to the SBU pins in the
connector. These signals needs to be disconnected while DP mode is not
negotiated with the remote. The DP controller does not support swapping
the two lines.
The disconnecting and swapping thereby needs to be performed by an
external entity. For which we have a few examples already, such as
fcs,fsa4480.

Lastly, in USB Power Delivery, the hot-plug signal found in a physical
DisplayPort or HDMI cable is communicated as a message. So the USB
Type-C controller must be able to pass this onto the DP controller.


I model the usb-c-connector as a child of the USB Type-C controller,
with the following representation of the connections:

connector {
  compatible = "usb-c-connector";

  ports {
    port@0 {
      reg = <0>;
      endpoint {
        remote-endpoint = <&dwc3>;
      };
    };

    port@1 {
      reg = <1>;
      endpoint@0 {
        reg = <0>;
        remote-endpoint = <&qmp_phy>;
      };
      endpoint@1 {
        reg = <1>;
        remote-endpoint = <&dp_controller>;
    };

    port@2 {
      reg = <2>;
      endpoint {
        remote-endpoint = <&sbu_mux>;
      };
    };
  };
};

This allows the USB Type-C controller to:
1) Perform USB role switching in the dwc3 on port@0
2) Orientation and muxing of the SuperSpeed lines in the QMP phy on
   port@1:0, implement a drm_bridge for signalling HPD back to the DP
   controller on port@1:1
3) Orientation and muxing (connecting/disconnecting) the SBU/AUX lines
   in the SBU mux on port@2.

The SBU mux in several of these designs is a component that takes a
power supply and two GPIOs, for enabling/disabling the connection and
flip the switch (which is used to swap the lines).

I hope this helps with the bigger picture.

Regards,
Bjorn