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

Johan Hovold
2025-04-11T12:16:22Z

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