Re: [PATCH v5 1/9] dt-bindings: usb: Add Type-C switch binding

[Prashant Malani]

On Thu, Jun 23, 2022 at 5:35 PM Prashant Malani <pmalani@xxxxxxxxxxxx> wrote:
>
> On Thu, Jun 23, 2022 at 4:14 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
> >
> > Quoting Prashant Malani (2022-06-23 12:08:21)
> > > On Thu, Jun 23, 2022 at 11:30 AM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
> > > >
> > > > Quoting Prashant Malani (2022-06-22 10:34:30)
> > > > > diff --git a/Documentation/devicetree/bindings/usb/typec-switch.yaml b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..78b0190c8543
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/usb/typec-switch.yaml
> > > > > @@ -0,0 +1,74 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > [...]
> > > > > +  ports:
> > > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > > +    description: OF graph binding modelling data lines to the Type-C switch.
> > > > > +
> > > > > +    properties:
> > > > > +      port@0:
> > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > +        description: Link between the switch and a Type-C connector.
> > > >
> > > > Is there an update to the usb-c-connector binding to accept this port
> > > > connection?
> > >
> > > Not at this time. I don't think we should enforce that either.
> > > (Type-C data-lines could theoretically be routed through intermediate
> > > hardware like retimers/repeaters)
> >
> > I'm mostly wondering if having such a connection to the usb-c-connector,
> > or even through some retimer/repeater, would be sufficient to detect how
> > many type-c ports are connected to the device. If the type-c pin
> > assignments only support two or four lanes for DP then it seems like we
> > should describe the two lanes or four lanes as one graph endpoint
> > "output" and then have some 'data-lanes' property in case the DP lanes
> > are flipped while being sent to the retimer or usb-c-connector. This
> > would of course depend on the capability of the device, i.e. if it can
> > remap DP lanes or only has 2 lanes of DP, etc.
> >
> > > > > +  - |
> > > > > +    drm-bridge {
> > > > > +        usb-switch {
> > > > > +            compatible = "typec-switch";
> > > >
> > > > I still don't understand the subnode design here. usb-switch as a
> > > > container node indicates to me that this is a bus, but in earlier rounds
> > > > of this series it was stated this isn't a bus.
> > >
> > > I am not aware of this as a requirement. Can you please point me to the
> > > documentation that states this needs to be the case?
> >
> > I'm not aware of any documentation for the dos and don'ts here. Are
> > there any examples in the bindings directory that split up a device into
> > subnodes that isn't in bindings/mfd?
>
> usb-c-connector [3] and its users is an example.
>
> >  I just know from experience that
> > any time I try to make a child node of an existing node that I'm
> > supposed to be describing a bus, unless I'm adding some sort of
> > exception node like a graph binding or an opp table. Typically a node
> > corresponds 1:1 with a device in the kernel. I'll defer to Rob for any
> > citations.
> >
> > >
> > > > Why doesn't it work to
> > > > merge everything inside usb-switch directly into the drm-bridge node?
> > >
> > > I attempted to explain the rationale in the previous version [1], but
> > > using a dedicated sub-node means the driver doesn't haven't to
> > > inspect individual ports to determine which of them need switches
> > > registered for them. If it sees a `typec-switch`, it registers a
> > > mode-switch and/or orientation-switch. IMO it simplifies the hardware
> > > device binding too.
> >
> > How is that any harder than hard-coding that detail into the driver
> > about which port and endpoint is possibly connected to the
> > usb-c-connector (or retimer)? All of that logic could be behind some API
> > that registers a typec-switch based on a graph port number that's passed
> > in, ala drm_of_find_panel_or_bridge()'s design.
>
> If each driver has to do it (and the port specifics vary for each driver),
> it becomes an avoidable overhead for each of them.
> I prefer hard-coding such details if avoidable. I suppose both approaches
Sorry, I meant "I prefer not hard-coding such details..."

> require modifications to the binding and the driver code.
>
> >
> > Coming from a DT writer's perspective, I just want to go through the
> > list of output pins in the datasheet and match them up to the ports
> > binding for this device. If it's a pure DP bridge, where USB hardware
> > isn't an input or an output like the ITE chip, then I don't want to have
> > to describe a port graph binding for the case when it's connected to a
> > dp-connector (see dp-connector.yaml) in the top-level node and then have
> > to make an entirely different subnode for the usb-c-connector case with
> > a whole other set of graph ports.
>
> This approach still allows for that, if the driver has any use for it
> (AFAICT these drivers don't).
> Iff that driver uses it, one can (optionally) route their output
> (top-level) ports through the
> "typec-switch" sub-node (and onwards as required).
> If it's being used in a "pure-DP" configuration, the "typec-switch" just
> goes away (the top level ports can be routed as desired by the driver).
> (Again, I must reiterate that neither this driver or the anx driver
> utilizes this)
>
> >
> > How would I even know which two differential pairs correspond to port0
> > or port1 in this binding in the ITE case?
>
> Why do we need to know that? It doesn't affect this or the other
> driver or hardware's
> functioning in a perceivable way.
>
> > Ideally we make the graph
> > binding more strict for devices by enforcing that their graph ports
> > exist. Otherwise we're not fully describing the connections between
> > devices and our dtb checkers are going to let things through where the
> > driver most likely will fail because it can't figure out what to do,
> > e.g. display DP on 4 lanes or play some DP lane rerouting games to act
> > as a mux.
>
> How is the current binding enforcing this? The typec-switch binding
> as a first step ensures that the DT is connecting the hardware(anx,ite
> etc) to something
> that at least "claims" to be a Type-C switch.
>
> >
> > >
> > > It also maps with the internal block diagram for these hardware
> > > components (for ex. the anx7625 crosspoint switch is a separate
> > > sub-block within anx7625).
> >
> > We don't make DT bindings for sub-components like this very often. It
> > would make more sense to me to have a subnode if a typec switch was some
> > sort of off the shelf hard macro that the hardware engineer placed down
> > inside the IC that they delivered. Then we could have a completely
> > generic driver that binds to the generic binding that knows how to drive
> > the hardware, because it's an unchangeable hard macro with a well
> > defined programming interface.
> >
> > >
> > > [1] https://lore.kernel.org/linux-usb/CACeCKaeH6qTTdG_huC4yw0xxG8TYEOtfPW3tiVNwYs=P4QVPXg@xxxxxxxxxxxxxx/
> >
> > I looked at the fsa4480 driver and the device has a publicly available
> > datasheet[2]. That device is designed for "audio accessory mode" but I
> > guess it's being used to simply mux SBU lines? There isn't an upstream
> > user of the binding so far, but it also doesn't look like a complete
> > binding. I'd expect to see DN_L/R as a graph output connected to the
> > usb-c-connector and probably have a usb2.0 input port and a 'sound-dai'
> > property to represent the input audio path.
> >
> > Finally, simply connecting to the typec controller node isn't sufficient
> > because a typec controller can be controlling many usb-c-connectors so I
> > don't see how the graph binding would be able to figure out how many
> > usb-c-connectors are connected to a mux like device, unless we took the
> > approach of this patch.
>
> It can follow the endpoint of the typec-switch port (the port parent
> of the remote
> end-point would be a 'usb-c-connector'). That is if the graph binding
> (I'm assuming you mean the switch device here) wants to figure this
> out in the first place.
>
> > Is that why you're proposing this binding? To
> > avoid describing a graph binding in the usb-c-connector and effectively
> > "pushing" the port count up to the mux?
>
> No, that is not the intention behind this series. The
> 'usb-c-connector' still needs the
> graph binding to the `typec-switch`. SBU, HS and SS lanes might have different
> muxes altogether (usb-c-connect has separate ports for SBU, HS and SS lanes)
>
> >
> > [2] https://www.onsemi.com/pdf/datasheet/fsa4480-d.pdf
>
> [3] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/connector/usb-connector.yaml#L23