On Sat, Jul 18, 2026 at 04:52:34PM -0500, Bjorn Andersson wrote: > On Mon, Jul 13, 2026 at 09:59:35PM -0700, Qiang Yu wrote: > > This series adds a common clkref_en implementation and converts glymur > > and mahua to use it, along with the related binding and DTS updates. > > > > The PCIe clkref clocks on Glymur and Mahua gate the QREF block which > > provides reference clocks to the PCIe PHYs. QREF requires LDO supplies > > and a reference voltage from the refgen block to operate. The refgen > > block itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to > > function. > > > > Previously, these QREF votes were done in PHY drivers. In earlier > > discussion [1], the feedback was that this is the wrong ownership point: > > those supplies are for the QREF controlled by clkref registers, not for > > the PHY directly. Based on that feedback, this series keeps the > > regulator handling with the clkref control path. > > > > Another reason for this series is reuse. clkref_en registers may live in > > different blocks across platforms (for example TCSR on Glymur, TLMM on > > SM8750 [2]), while the behavior is the same. The common helper lets each > > driver provide simple descriptors (name, offset, optional supplies) and > > reuse shared registration and runtime logic. > > > > Glymur and Mahua share the same QREF TX/RPT/RX component naming but > > have different PCIe QREF topologies. Both are handled in tcsrcc-glymur.c > > via match_data to select the correct descriptor table per compatible. > > > > [1] https://lore.kernel.org/lkml/[email protected]/ > > [2] > > https://lore.kernel.org/linux-arm-msm/[email protected]/ > > > > Changes in v9: > > - Add reviewed-by tags, no code change. > > - Link to v8: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v8: > > - Define refs with __counted_by(num_refs) and make provider a single > > allocation > > - Use mahua_tcsr_tx1_rpt012_rx2_regulators for PCIe6. > > - Link to v7: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v7: > > - Define compatible as an enum and add the per-compatible allOf/if/then > > block upfront for glymur. Reword commit msg for patch1 > > - Drop Krzysztof's Reviewed-by since the patch changed substantially from > > what he reviewed. > > - Added a comment noting that on Mahua the REFGEN4 block is supplied by > > the vdda-refgen3-* regulators, and mentioned this in the commit message for > > patch2. > > - Change the descriptor array to an array of pointers (const struct > > qcom_clk_ref_desc * const *). Skip unpopulated indices with if (!desc) > > - Convert tcsr_cc_glymur_clk_descs[] and tcsr_cc_mahua_clk_descs[] to a > > pointer array. > > - Add regulator lists for clkref_en on Mahua. > > - Null-check device_get_match_data() result in probe. > > - Add rx0 regulator in mahua tcsr node > > - Squashed the former patch 8 (switch pcie5_phy ref clock to > > RPMH_CXO_CLK) into patch7, so Mahua PCIe probes at every commit. > > - Link to v6: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v6: > > - Split dt-bindings patch into two: one to move glymur-tcsr to its own > > binding file, and one to add mahua support > > - Use regmap_set_bits()/regmap_clear_bits() instead of regmap_update_bits() > > in clk-ref.c > > - Move clk_init_data from struct qcom_clk_ref to a stack variable in > > qcom_clk_ref_register() > > - Add Co-developed-by/Reviewed-by tags from Konrad Dybcio > > - Add missing regulator supplies for EDP and USB clkref_en on glymur > > - Link to v5: > > https://patch.msgid.link/[email protected] > > > > Changes in v5: > > - Return 0 if regmap_read fail > > - Add a separate file for glymur-tcsr and mahua-tcsr > > - Link to v4: > > https://patch.msgid.link/[email protected] > > > > Changes in v4: > > - Add mahua QREF support (binding, driver, DTS) to avoid dtb check error > > - Override pcie5_phy ref clock to RPMH_CXO_CLK on mahua since > > TCSR_PCIE_1_CLKREF_EN is not available > > - Rename regulator arrays to topology-based names and merge duplicates > > - Remove else: false blocks from binding > > - Sort supply properties alphabetically in binding and DTS > > - Link to v3: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v3: > > - Fix dtb check error: allOf:0: 'then' is a dependency of 'if'. > > - Link to v2: > > https://lore.kernel.org/all/[email protected]/ > > > > Changes in v2: > > - RFC tag dropped > > - Changed back to additionalProperties: false > > - Moved all Glymur supply properties into top-level properties so they are > > explicitly defined. > > - Link to v1: > > https://lore.kernel.org/all/[email protected]/ > > > > Signed-off-by: Qiang Yu <[email protected]> > > --- > > Qiang Yu (7): > > dt-bindings: clock: qcom: Move glymur TCSR to own binding > > dt-bindings: clock: qcom,glymur-tcsr: Add mahua support > > clk: qcom: Add generic clkref_en support > > clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to > > clk_ref helper > > clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support > > arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR > > arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR > > > > .../bindings/clock/qcom,glymur-tcsr.yaml | 146 +++++++ > > .../bindings/clock/qcom,sm8550-tcsr.yaml | 2 - > > arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 + > > arch/arm64/boot/dts/qcom/mahua-crd.dts | 16 + > > arch/arm64/boot/dts/qcom/mahua.dtsi | 13 + > > drivers/clk/qcom/Makefile | 1 + > > drivers/clk/qcom/clk-ref.c | 205 +++++++++ > > drivers/clk/qcom/tcsrcc-glymur.c | 471 > > +++++++++++---------- > > include/linux/clk/qcom.h | 67 +++ > > 9 files changed, 704 insertions(+), 237 deletions(-) > > --- > > base-commit: 3da905eb243cad56200f09bb7eaa060537aed0cc > > I was hoping to apply this series, but I don't have this commit and > patch 4 ("migrate to clk_ref helper") doesn't apply to my tree. > > What did you base this on? Why don't you test your changes on latest > mainline or linux-next? > > Please rebase and test on a relevant branch.
Sorry for the trouble, I based v9 on next-20260713, but I forgot to drop this patch https://lore.kernel.org/all/[email protected]/, which is a dependency for another series I'm working on, before running b4 prep -n. I can git am v9 cleanly onto latest linux-next (next-20260717), but I'm not sure if that's the branch you apply against. Could you confirm which branch I should rebase onto, so I don't run into the same issue again? - Qiang Yu
