Re: [PATCH v2 1/3] arm64: dts: qcom: x1e80100-hp-x14: add usb-1-ss1-sbu-mux

[Johan Hovold]

On Fri, Apr 11, 2025 at 01:52:38PM +0200, Stephan Gerhold wrote:
> On Fri, Apr 11, 2025 at 01:25:39PM +0200, Johan Hovold wrote:
 
> > > +	usb_1_ss1_sbu_default: usb-1-ss1-sbu-state {
> > > +		mode-pins {
> > > +			pins = "gpio177";
> > > +			function = "gpio";
> > > +			bias-disable;
> > > +			drive-strength = <2>;
> > > +			output-high;
> > > +		};
> > 
> > This is more of a question for Stephan who added this to QCP [1], but
> > why is this mode pin here and what does it do?
> > 
> > It's not part of the binding for the mux (which indeed only has two
> > control signals according to the datasheet) so it looks like something
> > is not modelled correctly.
> 
> I'm afraid you have opened a "can of worms" here. :')

Heh.

> On the QCP, there are actually two of these muxes chained for each port.
> One of them does the orientation switching that we are describing here,
> the other selects between routing SBU to DP AUX or USB SBTX/SBRX. I'm
> guessing this is meant for USB4. Given that:
> 
>  - We don't have any support for USB4 on QC platforms at the moment.
>  - We're not modelling the USB4 stuff for the retimer either(?).
>  - We have no clear overview of what/how to model for USB4.
>  - The ports without retimer aren't advertised with USB4 support (I'm
>    guessing the signal quality is not reliable enough without retimer).
>  - The gpio-sbu-mux driver doesn't support shared enable-gpios.
> 
> ... we just went with the tradeoff of forcing DP AUX mode here by
> setting a fixed state for the second mux. I'm not sure if the other
> configuration is even a valid use case for the ports without retimer.
> 
> A comment about this would have been nice, but I didn't think of that
> anymore when cleaning up the patches. :-)

Thanks for the explanation. Makes sense.

Johan