On Wed, Jan 25, 2023 at 03:40:13PM -0800, Bjorn Andersson wrote:
> On Tue, Jan 24, 2023 at 08:31:13PM -0600, Rob Herring wrote:
> > On Tue, Jan 24, 2023 at 11:04 AM Bjorn Andersson
> > <quic_bjorande@xxxxxxxxxxx> wrote:
> > >
> > > On Tue, Jan 24, 2023 at 10:00:12AM -0600, Rob Herring wrote:
> > > > On Thu, Jan 19, 2023 at 11:40 AM Bjorn Andersson
> > > > <quic_bjorande@xxxxxxxxxxx> wrote:
> > > > >
> > > > > On Thu, Jan 19, 2023 at 10:11:32AM -0600, Rob Herring wrote:
> > > > > > On Wed, Jan 18, 2023 at 10:08:11AM -0800, Bjorn Andersson wrote:
> > > > > > > On Tue, Jan 17, 2023 at 11:56:57AM -0600, Rob Herring wrote:
> > > > > > > > On Thu, Jan 12, 2023 at 08:11:14PM -0800, Bjorn Andersson wrote:
> > > > > > > > > From: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > > > > > > > >
> > > > > > > > > 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>
> > > > > > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx>
> > > > > > > > > ---
> > > > > >
> > > > > >
> > > > > > > > > + tcpm {
> > > > > > > > > + connector {
> > > > > > > > > + compatible = "usb-c-connector";
> > > > > > > > > +
> > > > > > > > > + ports {
> > > > > > > > > + #address-cells = <1>;
> > > > > > > > > + #size-cells = <0>;
> > > > > > > > > +
> > > > > > > > > + port@0 {
> > > > > > > > > + reg = <0>;
> > > > > > > > > + tcpm_hs_out: endpoint {
> > > > > > > > > + remote-endpoint = <&usb_hs_phy_in>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + port@1 {
> > > > > > > > > + reg = <1>;
> > > > > > > > > + tcpm_ss_out: endpoint {
> > > > > > > > > + remote-endpoint = <&usb_ss_phy_in>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + port@2 {
> > > > > > > > > + reg = <2>;
> > > > > > > > > + tcpm_sbu_out: endpoint {
> > > > > > > > > + remote-endpoint = <&sbu_mux_in>;
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > + sbu-mux {
> > > > > > > > > + compatible = "pericom,pi3usb102", "gpio-sbu-mux";
> > > > > > > > > +
> > > > > > > > > + enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
> > > > > > > > > + select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
> > > > > > > > > +
> > > > > > > > > + mode-switch;
> > > > > > > > > + orientation-switch;
> > > > > > > > > +
> > > > > > > > > + port {
> > > > > > > > > + sbu_mux_in: endpoint {
> > > > > > > > > + remote-endpoint = <&tcpm_sbu_out>;
> > > > > > > > > + };
> > > > > > > >
> > > > > > > > Don't you need a connection to whatever drives SBU? Maybe your case is
> > > > > > > > fixed because the phy does the DP/USB muxing? But the binding needs to
> > > > > > > > support the worst case which I guess would be all the muxing/switching
> > > > > > > > is done by separate board level components.
> > > > > > > >
> > > > > > >
> > > > > > > Perhaps I'm misunderstanding your request, but I think this is the worst
> > > > > > > case you're talking about.
> > > > > > >
> > > > > > > &usb_ss_phy_in is a reference to the PHY, which does switching/muxing of
> > > > > > > the SuperSpeed lanes in the connector, but the PHY provides no control
> > > > > > > over the SBU signals.
> > > > > > >
> > > > > > > So this sbu-mux is a separate component between the SBU-pads on the SoC
> > > > > > > and the usb-c-connector, referenced through he &sbu_mux_in reference.
> > > > > > >
> > > > > > >
> > > > > > > So upon e.g. a orientation switch, the typec_switch_set() call the tcpm
> > > > > > > implementation will request orientation switching from port@1 and port@2
> > > > > > > (no orientation-switch on port@0/HS pins).
> > > > > >
> > > > > > 'port@2' is supposed to define the connection to what controls SBU. The
> > > > > > mux here switches the signals, but it doesn't control them.
> > > > >
> > > > > The SBU signals are driven by the SS PHY, on behalf of the DisplayPort
> > > > > controller. These signals are turned on/off as a result of the TCPM
> > > > > indicating the HPD state to the DisplayPort controller.
> > > > >
> > > > > There's a such not really a direct representation today of the entity
> > > > > that drives the SBU lines. It happens to be a sub-block in
> > > > > &usb_ss_phy_in, but I don't envision that we need/want any signaling
> > > > > between the TCPM and the SBU-"driver".
> > > > >
> > > > >
> > > > > I see that I missed that in the example above, your suggestion on how to
> > > > > model that relationship (TCPM - DP controller) was to add an additional
> > > > > endpoint in port@1. So that's the current design (but neither ports nor
> > > > > endpoints are significant from an implementation point of view).
> > > > >
> > > > > > The mux should sit in the middle, but the graph terminates at the mux.
> > > > > > You don't have a connection presumably because you know what the
> > > > > > connection.
> > > > >
> > > > > But do you suggest that the graph should reference the entity that
> > > > > drives the SBU signals?
> > > >
> > > > Yes, that was the original intent.
> > > >
> > >
> > > Directly from the connector, or just indirectly?
> > >
> > > > > What about the discrete mux?
> > > >
> > > > You mean the mux in this binding, right? That should be in the middle:
> > > >
> > > > DPaux --> SBUmux --> connector
> > > >
> > > > Maybe the SS phy is in there too.
> > > >
> > >
> > > The signal originally comes from the DP controller, the analog
> > > electronics lives in the SS phy, then the signal goes to the SBU mux and
> > > finally to the connector.
> > >
> > > > >
> > > > > > Perhaps because there is only 1 connector and controller.
> > > > > >
> > > > >
> > > > > There is one SBU mux, one DP controller and one SS PHY per
> > > > > usb-c-connector.
> > > > >
> > > > > > Suppose you have 2 connectors and 2 controllers which drive SBU
> > > > > > signals. Also assume that the SBU signals are completely independent
> > > > > > from what's driving the altmode SS signals. How would you describe that?
> > > > > >
> > > > >
> > > > > This is the setup we have on e.g. SC8280XP CRD; where the TCPM has two
> > > > > usb-c-connectors defined, each with their graph referencing the SS PHY,
> > > > > DP controller and respective sbu-mux.
> > > > >
> > > > > There's an incomplete example of this published at [1] (where the SS phy
> > > > > isn't represented yet - and hence there's no control over the SS lanes,
> > > > > nor is the HS lanes connected to the dwc3 for role switching).
> > > > >
> > > > > Perhaps I'm misunderstanding your concerns though?
> > > >
> > > > That looks like you can assume who drives SBU based on the DP
> > > > controller. Probably a safe assumption for DP (that DP-aux is part of
> > > > the DP controller), but I was more worried about if you can't assume
> > > > that relationship. Take HDMI for example where the DDC signals can
> > > > come from anywhere. They could be part of the HDMI bridge, a general
> > > > purpose I2C bus off the SoC, or bitbanged GPIOs. Though from what I've
> > > > read, HDMI Altmode is dead. I don't know if the need to describe the
> > > > SBU connection would apply to anything else.
> > > >
> > > > I guess this all boils down to whether the SBU mux should have a 2nd
> > > > optional port as the input for what drives it.
> > > >
> > >
> > > Are you saying that the connector should link with the mux and then the
> > > source of the signal should be daisy chained? Or that we should just
> > > link both of them as two separate endpoints from the connector?
> >
> > The former. The data path of the signal in h/w should match in the DT
> > graph. The caveat being we don't normally show PHYs in that mix
> > because they are somewhat transparent. That's maybe becoming less true
> > with routing or muxing included in PHYs.
> >
>
> We have discussed and prototyped this a few times now in the Qualcomm
> community, and I am not a fan of having to add forwarding-logic to each
> implementation of a Type-C mux/switch, which in some configuration might
> have an entity behind it that needs the notifications.
I don't know if we can really escape that.
> But I don't think there's a concern for this binding (in my
> implementation), there's currently no mode/orientation switching
> happening beyond this entity.
>
>
>
> That said, if we're to represent each signal path to the connector,
> I would like to bring up this problem again:
> https://lore.kernel.org/all/20220520164810.141400-1-bjorn.andersson@xxxxxxxxxx/
>
> port@0 represent the HS signals going to the connector, port@1 the SS
> signals going to the connector, port@2 the SBU signals going to the
> connector.
>
> But I need some representation of the HPD (hot plug detection) "signal"
> (there is no actual signal path in hardware, this is a virtual
> notification) going _from_ the connector to the DisplayPort controller.
I would assume whatever entity is deciding to enable the DP signals on
the connector would be what generates the HPD notification. I think you
want to describe the DP signal connections and muxing, but HPD itself
wouldn't be in the DT.
> We discussed this (perhaps in person, as there's no trace on lkml?) and
> you suggested that I use a second endpoint under port@1, instead of
> introducing a fourth port.
Multiple endpoints on a port are typically a mux or fanout depending on
the data direction. But the muxing is not really in the connector, so
that should probably be represented somewhere else. I think a new port
suffers from the same issue. Maybe that's close enough? Depends if there
are cases of more alt modes or more complicated muxing/switching.
> I'm fine either way, but I don't think it would be convenient nor
> representable to daisy chain this behind any of the existing endpoints;
> none of the other endpoints should deal with the HPD signal and the
> direct of_graph-link between the usb-c-connector and the DP controller
> mimics that of e.g. dp-connector very nicely, both in description and
> implementation.
That would be nice, but the reality is there's a lot more between DP and
the connector with USB-C and the graph should reflect that. I guess the
problem there is being able to walk the graph. Suppose we have:
DP out port -> altmode mux in port -> altmode mux out port -> type-c
port 1
The issue walking the graph here would be generic code doesn't know
altmode mux port numbering as that's not a generic thing (could be
perhaps?). Maybe you can walk from each end and see if you end up in
the same device.
Of course, I haven't even considered the split cases where it's not
just either USB3 OR DP, but combinations.
What I'd really like to see for all this USB-C stuff is block diagrams
of the h/w components and then what the corresponding DT looks like.
Trying to extend things one piece at a time is hard to review and not
likely going to end with a flexible design.
Rob
