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

[Stephan Gerhold]

On Fri, Apr 11, 2025 at 01:25:39PM +0200, Johan Hovold wrote:
> [ +CC: Stephan ]
> 
> On Thu, Apr 10, 2025 at 12:07:28PM +0200, Jens Glathe via B4 Relay wrote:
> > From: Jens Glathe <jens.glathe@xxxxxxxxxxxxxxxxxxxxxx>
> > 
> > The usb_1_1 port doesn't have the PS8830 repeater, but apparently some
> > MUX for DP altmode control. After a suggestion from sgerhold on
> > '#aarch64-laptops' I added gpio-sbu-mux nodes from the x1e80100-QCP
> > tree, and this appears to work well. It is still guesswork, but
> > working guesswork.
> [...]
> > @@ -1424,6 +1451,30 @@ reset-n-pins {
> >  		};
> >  	};
> >  
> > +	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. :')

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,
Stephan