On Fri, Nov 25, 2022 at 01:53:25PM +0100, Luca Weiss wrote: > On Fri Nov 25, 2022 at 11:19 AM CET, Johan Hovold wrote: > > On Fri, Nov 25, 2022 at 10:55:31AM +0100, Luca Weiss wrote: > > > On Fri Nov 25, 2022 at 10:50 AM CET, Johan Hovold wrote: > > > > Yeah, you may need to add a platform specific section of the clocks, > > > > which appear to be different, even if I'm not sure they are currently > > > > described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are > > > > they named in the vendor's dts? > > > > > > This is the msm-4.19 dts: > > > https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-usb.dtsi#354 > > > > clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>, > > <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>, > > <&rpmhcc RPMH_QLINK_CLK>, > > <&gcc GCC_USB3_PRIM_CLKREF_CLK>, > > <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>; > > clock-names = "aux_clk", "pipe_clk", "ref_clk_src", > > "ref_clk", "com_aux_clk"; > > > > So it looks like you don't need update the binding for the clocks as the > > above matches sc8280xp: > > > > aux > > ref > > com_aux > > usb3_pipe > > Thanks for checking! > > > > > Parent clocks (ref_clk_src) should not be included in the binding, but > > rather be handled by the clock driver. For example, see: > > > > https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@xxxxxxxxxx/ > > https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@xxxxxxxxxxx/ > > So I assume you mean that I shouldn't do this: > > clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>, > <&rpmhcc RPMH_QLINK_CLK>, > <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>, > <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>; > clock-names = "aux", "ref", "com_aux", "usb3_pipe"; > > But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work > fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in > debugfs). Exactly. Since the vendor dts describes RPMH_QLINK_CLK as parent of ref, I'd suggest modelling that in the clock driver. Perhaps it has just been left on by the boot firmware. Someone with access to docs may be able explain how it is supposed to be used. > And for the driver patch, I've discovered that this phy doesn't have > separate txa/tbx region, so dts was also wrong there. Do you know if > there's a way to test DP phy initialization without having all the USB-C > plumbing in place? Might be good to validate at least phy init works if > we're already touching all of this. Do you mean that it appears to work as sc8280xp with txa/txb shared by both the USB and DP parts? I guess you need a proper setup to test it properly. Not sure what you'll be able to learn otherwise, apart from whether it passes basic smoke testing. Johan
