Re: [PATCH v6 0/4] arm64: dts: qcom: Introduce Glymur SoC dtsi and Glymur CRD dts

[Qiang Yu]

On Mon, Feb 02, 2026 at 10:49:10AM +0100, Konrad Dybcio wrote:
> On 2/2/26 6:21 AM, Qiang Yu wrote:
> > On Thu, Jan 29, 2026 at 01:07:08PM +0100, Konrad Dybcio wrote:
> >> On 1/29/26 1:05 PM, Qiang Yu wrote:
> >>> On Wed, Jan 28, 2026 at 07:21:04PM -0600, Bjorn Andersson wrote:
> >>>> On Thu, Jan 22, 2026 at 08:53:57PM +0530, Pankaj Patil wrote:
> >>>>> Introduce dt-bindings and initial device tree support for Glymur,
> >>>>> Qualcomm's next-generation compute SoC and it's associated
> >>>>> Compute Reference Device (CRD) platform.
> >>>>>
> >>>>> https://www.qualcomm.com/products/mobile/snapdragon/laptops-and-tablets/snapdragon-x2-elite
> >>>>> https://www.qualcomm.com/news/releases/2025/09/new-snapdragon-x2-elite-extreme-and-snapdragon-x2-elite-are-the-
> >>>>>
> >>>>> The base support enables booting to shell with rootfs on NVMe,
> >>>>> demonstrating functionality for PCIe and NVMe subsystems.
> >>>>> DCVS is also enabled, allowing dynamic frequency scaling for the CPUs.
> >>>>> TSENS (Thermal Sensors) enabled for monitoring SoC temperature and
> >>>>> thermal management. The platform is capable of booting kernel at EL2
> >>>>> with kvm-unit tests performed on it for sanity.
> >>>>>
> >>>>> Added dtsi files for the PMIC's enabled PMH0101, PMK8850, PMCX0102,
> >>>>> SMB2370, PMH0104, PMH0110 along with temp-alarm and GPIO nodeS.
> >>>>>
> >>>>> For CPU compatible naming, there is one discussion which is not specific
> >>>>> to Glymur, Kaanapali and Glymur use the same Oryon cores.
> >>>>> https://lore.kernel.org/all/20251119-oryon-binding-v1-1-f79a101b0391@xxxxxxxxxxxxxxxx/
> >>>>> We've kept the "qcom,oryon" compatible
> >>>>>
> >>>>> Features enabled in this patchset:
> >>>>> 1. NVMe storage support
> >>>>> 2. PCIe controller and PCIe PHY
> >>>>> 3. RPMH Regulators
> >>>>> 4. Clocks and reset controllers - GCC, TCSRCC, DISPCC, RPMHCC
> >>>>> 5. Interrupt controller
> >>>>> 6. TLMM (Top-Level Mode Multiplexer)
> >>>>> 7. QUP Block
> >>>>> 8. Reserved memory regions
> >>>>> 9. PMIC support with regulators
> >>>>> 10. CPU Power Domains
> >>>>> 11. TSENS (Thermal Sensors)
> >>>>> 12. DCVS: CPU DCVS with scmi perf protocol
> >>>>>
> >>>>> Dependencies:
> >>>>>
> >>>>> dt-bindings:
> >>>>> 1. https://lore.kernel.org/all/20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@xxxxxxxxxxxxxxxx/
> >>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@xxxxxxxxxxxxxxxx/
> >>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@xxxxxxxxxxxxxxxx/
> >>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@xxxxxxxxxxxxxxxx/
> >>>>>
> >>>>> Linux-next based tree with Glymur patches is available at:
> >>>>> https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction
> >>>>>
> >>>>
> >>>> FWIW, I applied these patches onto next-20260128 to see if things has
> >>>> improved since Rob's report and I get:
> >>>>
> >>>> $ make qcom/glymur-crd.dtb CHECK_DTBS=1
> >>>>   DTC [C] arch/arm64/boot/dts/qcom/glymur-crd.dtb
> >>>> qcom/glymur-crd.dtb: dma-controller@800000 (qcom,glymur-gpi-dma): interrupts: [[0, 588, 4], [0, 589, 4], [0, 590, 4], [0, 591, 4], [0, 592, 4], [0, 593, 4], [0, 594, 4], [0, 595, 4], [0, 596, 4], [0, 597, 4], [0, 598, 4], [0, 599, 4], [2, 129, 4], [2, 130, 4], [2, 131, 4], [2, 132, 4]] is too long
> >>>>         from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
> >>>> qcom/glymur-crd.dtb: dma-controller@a00000 (qcom,glymur-gpi-dma): interrupts: [[0, 279, 4], [0, 280, 4], [0, 281, 4], [0, 282, 4], [0, 283, 4], [0, 284, 4], [0, 293, 4], [0, 294, 4], [0, 295, 4], [0, 296, 4], [0, 297, 4], [0, 298, 4], [2, 124, 4], [2, 125, 4], [2, 126, 4], [2, 127, 4]] is too long
> >>>>         from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
> >>>> qcom/glymur-crd.dtb: dma-controller@b00000 (qcom,glymur-gpi-dma): interrupts: [[2, 76, 4], [2, 77, 4], [2, 78, 4], [2, 79, 4], [2, 80, 4], [2, 81, 4], [2, 82, 4], [2, 83, 4], [2, 84, 4], [2, 85, 4], [2, 86, 4], [2, 87, 4], [2, 88, 4], [2, 89, 4], [2, 90, 4], [2, 91, 4]] is too long
> >>>>         from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
> >>>> qcom/glymur-crd.dtb: pmic@1 (qcom,pmh0101): led-controller@ee00:compatible:0: 'qcom,pmh0101-flash-led' is not one of ['qcom,pm6150l-flash-led', 'qcom,pm660l-flash-led', 'qcom,pm7550-flash-led', 'qcom,pm8150c-flash-led', 'qcom,pm8150l-flash-led', 'qcom,pm8350c-flash-led', 'qcom,pm8550-flash-led', 'qcom,pmi8998-flash-led']
> >>>>         from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
> >>>> qcom/glymur-crd.dtb: pmic@1 (qcom,pmh0101): pwm:compatible: 'oneOf' conditional failed, one must be fixed:
> >>>>         ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm'] is too long
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm660l-lpg', 'qcom,pm8150b-lpg', 'qcom,pm8150l-lpg', 'qcom,pm8350c-pwm', 'qcom,pm8916-pwm', 'qcom,pm8941-lpg', 'qcom,pm8994-lpg', 'qcom,pmc8180c-lpg', 'qcom,pmi632-lpg', 'qcom,pmi8950-pwm', 'qcom,pmi8994-lpg', 'qcom,pmi8998-lpg', 'qcom,pmk8550-pwm']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm6150l-lpg']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm8550-pwm']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm8937-pwm']
> >>>>         'qcom,pm8150l-lpg' was expected
> >>>>         'qcom,pm8916-pwm' was expected
> >>>>         from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml#
> >>>> qcom/glymur-crd.dtb: led-controller@ee00 (qcom,pmh0101-flash-led): compatible:0: 'qcom,pmh0101-flash-led' is not one of ['qcom,pm6150l-flash-led', 'qcom,pm660l-flash-led', 'qcom,pm7550-flash-led', 'qcom,pm8150c-flash-led', 'qcom,pm8150l-flash-led', 'qcom,pm8350c-flash-led', 'qcom,pm8550-flash-led', 'qcom,pmi8998-flash-led']
> >>>>         from schema $id: http://devicetree.org/schemas/leds/qcom,spmi-flash-led.yaml#
> >>>> qcom/glymur-crd.dtb: /soc@0/arbiter@c400000/spmi@c426000/pmic@1/led-controller@ee00: failed to match any schema with compatible: ['qcom,pmh0101-flash-led', 'qcom,spmi-flash-led']
> >>>> qcom/glymur-crd.dtb: pwm (qcom,pmh0101-pwm): compatible: 'oneOf' conditional failed, one must be fixed:
> >>>>         ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm'] is too long
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm660l-lpg', 'qcom,pm8150b-lpg', 'qcom,pm8150l-lpg', 'qcom,pm8350c-pwm', 'qcom,pm8916-pwm', 'qcom,pm8941-lpg', 'qcom,pm8994-lpg', 'qcom,pmc8180c-lpg', 'qcom,pmi632-lpg', 'qcom,pmi8950-pwm', 'qcom,pmi8994-lpg', 'qcom,pmi8998-lpg', 'qcom,pmk8550-pwm']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm6150l-lpg']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm8550-pwm']
> >>>>         'qcom,pmh0101-pwm' is not one of ['qcom,pm8937-pwm']
> >>>>         'qcom,pm8150l-lpg' was expected
> >>>>         'qcom,pm8916-pwm' was expected
> >>>>         from schema $id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml#
> >>>> qcom/glymur-crd.dtb: /soc@0/arbiter@c400000/spmi@c426000/pmic@1/pwm: failed to match any schema with compatible: ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm']
> >>>>
> >>>> So, we're still missing a few dependencies.
> >>>>
> >>>>
> >>>> Booting the system I get a ton of errors from PCIe in the kernel log:
> >>>>
> >>>> debugfs: 'opp:5000000' already exists in 'soc@xxxxxxxxxxxxx'
> >>>>
> >>>> # dmesg | grep -E 'debugfs: .+ already exists' |wc -l
> >>>> 508
> >>>>
> >>>> The system does eventually boot, and I was happy to see that we do end
> >>>> up finding the PCIe devices after all.
> >>>>
> >>> I enabled dynamic debug logs and observed that each PCIe platform device
> >>> probe was deferred approximately 10 times. The probe deferrals resulted in
> >>> additional OPP debugfs warnings being printed.
> >>>
> >>> The PCIe platform device probe was deferred because the PHY driver was not
> >>> ready - either because the PHY driver was not yet loaded, or because the
> >>> PHY driver's own probe was also deferred due to its dependency (e.g.,
> >>> 1fd5000.clock-controller) not being ready. This is normal behavior,
> >>> correct? I also observed that other driver probes were deferred.
> >>>
> >>> But I'm not sure why there are more than 300 times probe deferrals on
> >>> your setup.
> >>
> >> I think Bjorn is trying to say that the driver is wrong, because it
> >> effectively seems to call devm_pm_opp_of_add_table repeatedly
> >>
> > Okay, to avoid PCIe driver probe deferrals and the resulting increased OPP
> > debugfs warnings caused by these deferrals, we plan to move the PHY
> > properties back from the root port node to the controller device tree
> > node.
> 
> Would (roughly) this solve your problems without messing with the DT?

This change cannot fix the OPP warning. The warning occurs because the OPP
subsystem creates debugfs nodes using "op-hz" as the name, which is not
unique for PCIe OPP tables. Mani posted a patch to fix this issue:
https://lore.kernel.org/all/20260130071940.6949-1-manivannan.sadhasivam@xxxxxxxxxxxxxxxx/

Our goal is to prevent probe deferrals from occurring in our driver.

- Qiang Yu
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index fb6bd545f89f..745cca225bcf 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1917,6 +1917,24 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->cfg = pcie_cfg;
>  
> +	ret = qcom_pcie_parse_ports(pcie);
> +	if (ret) {
> +		if (ret != -ENODEV) {
> +			dev_err_probe(pci->dev, ret,
> +				      "Failed to parse Root Port: %d\n", ret);
> +			goto err_pm_runtime_put;
> +		}
> +
> +		/*
> +		 * In the case of properties not populated in Root Port node,
> +		 * fallback to the legacy method of parsing the Host Bridge
> +		 * node. This is to maintain DT backwards compatibility.
> +		 */
> +		ret = qcom_pcie_parse_legacy_binding(pcie);
> +		if (ret)
> +			goto err_pm_runtime_put;
> +	}
> +
>  	pcie->parf = devm_platform_ioremap_resource_byname(pdev, "parf");
>  	if (IS_ERR(pcie->parf)) {
>  		ret = PTR_ERR(pcie->parf);
> @@ -1979,24 +1997,6 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>  
>  	pp->ops = &qcom_pcie_dw_ops;
>  
> -	ret = qcom_pcie_parse_ports(pcie);
> -	if (ret) {
> -		if (ret != -ENODEV) {
> -			dev_err_probe(pci->dev, ret,
> -				      "Failed to parse Root Port: %d\n", ret);
> -			goto err_pm_runtime_put;
> -		}
> -
> -		/*
> -		 * In the case of properties not populated in Root Port node,
> -		 * fallback to the legacy method of parsing the Host Bridge
> -		 * node. This is to maintain DT backwards compatibility.
> -		 */
> -		ret = qcom_pcie_parse_legacy_binding(pcie);
> -		if (ret)
> -			goto err_pm_runtime_put;
> -	}
> -
>  	platform_set_drvdata(pdev, pcie);
>  
>  	ret = dw_pcie_host_init(pp);
> 
> Konrad