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. 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. 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. 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. Regards, Bjorn