Documentation/devicetree/bindings/arm/qcom.yaml | 5 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/glymur-crd.dts | 601 +++ arch/arm64/boot/dts/qcom/glymur.dtsi | 5913 +++++++++++++++++++++++ arch/arm64/boot/dts/qcom/pmcx0102.dtsi | 187 + arch/arm64/boot/dts/qcom/pmh0101.dtsi | 68 + arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 144 + arch/arm64/boot/dts/qcom/pmh0110-glymur.dtsi | 144 + arch/arm64/boot/dts/qcom/pmk8850.dtsi | 70 + arch/arm64/boot/dts/qcom/smb2370.dtsi | 45 + arch/arm64/configs/defconfig | 5 + 11 files changed, 7183 insertions(+)
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@oss.qualcomm.com/
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@oss.qualcomm.com/
2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/
3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/
4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/
Linux-next based tree with Glymur patches is available at:
https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
---
Changes in v6:
- Moved pmic thermal zones to their respective pmic dtsi files
- Link to v5: https://lore.kernel.org/r/20260122-upstream_v3_glymur_introduction-v5-0-8ba76c354e9a@oss.qualcomm.com
Changes in v5:
- Added opp entries for pcie nodes
- Dropped qup-memory interconnect from uart nodes
- Update trip1 type to critical for pmic thermal zones
- Alignment and newline fixes according to comments
- Link to v4: https://lore.kernel.org/r/20260112-upstream_v3_glymur_introduction-v4-0-8a0366210e02@oss.qualcomm.com
Changes in v4:
- Enabled PCIe SMMU for all 4 PCIe instances
- Updated dispcc required opps level to "rpmhpd_opp_low_svs"
- Updated watchdog compatible
- Renamed gic-its to msi-controller
- Updated GCC clocks property to 43 from 44
- Moved cpu-idle-states to domain-idle-states
- Fixed alignment and zero padding issues according to review comments
- Dropped glymur-pmics.dtsi
- Moved pmic thermal zones from board dts to soc dtsi
- Link to v3: https://lore.kernel.org/r/20251219-upstream_v3_glymur_introduction-v3-0-32271f1f685d@oss.qualcomm.com
Changes in v3:
- Enabled system-cache-controller
- Squashed all initial features to boot to shell with nvme as storage
- Updated tsens nodes according to comments
- Merged tcsr and tcsrcc node
- Addressed review comments
- Link to v1: https://lore.kernel.org/all/20250925-v3_glymur_introduction-v1-0-24b601bbecc0@oss.qualcomm.com
Changes in v2:
- Series was sent erroneously
- Link to v1: https://lore.kernel.org/r/20250925-v3_glymur_introduction-v1-0-5413a85117c6@oss.qualcomm.com
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
---
Pankaj Patil (4):
dt-bindings: arm: qcom: Document Glymur SoC and board
arm64: defconfig: Enable Glymur configs for boot to shell
arm64: dts: qcom: Introduce Glymur base dtsi
arm64: dts: qcom: glymur: Enable Glymur CRD board support
Documentation/devicetree/bindings/arm/qcom.yaml | 5 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/glymur-crd.dts | 601 +++
arch/arm64/boot/dts/qcom/glymur.dtsi | 5913 +++++++++++++++++++++++
arch/arm64/boot/dts/qcom/pmcx0102.dtsi | 187 +
arch/arm64/boot/dts/qcom/pmh0101.dtsi | 68 +
arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 144 +
arch/arm64/boot/dts/qcom/pmh0110-glymur.dtsi | 144 +
arch/arm64/boot/dts/qcom/pmk8850.dtsi | 70 +
arch/arm64/boot/dts/qcom/smb2370.dtsi | 45 +
arch/arm64/configs/defconfig | 5 +
11 files changed, 7183 insertions(+)
---
base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b
change-id: 20251007-upstream_v3_glymur_introduction-5a105b54493d
prerequisite-message-id: <20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@oss.qualcomm.com>
prerequisite-patch-id: bd5a4703a5a7fc530418337680cf1e2ea1518f35
prerequisite-message-id: <20251215-knp-pmic-leds-v3-0-5e583f68b0e5@oss.qualcomm.com>
prerequisite-patch-id: 6bbaff642cfd1f1386ff0ccd746739b68cdbeb45
prerequisite-patch-id: e30603778b23b7f7586b1c01a362e45af7bd0aa3
prerequisite-message-id: <20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com>
prerequisite-patch-id: 14469fd166b31b251b98bf25e783ab6f57ddd13a
Best regards,
--
Pankaj Patil <pankaj.patil@oss.qualcomm.com>
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@oss.qualcomm.com/
> 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@oss.qualcomm.com/
> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/
> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/
> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/
>
> 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@0-1c00000.pci'
# 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.
Regards,
Bjorn
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@oss.qualcomm.com/ > > 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@oss.qualcomm.com/ > > 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > > 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > > 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > > > > 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@0-1c00000.pci' > > # dmesg | grep -E 'debugfs: .+ already exists' |wc -l > 508 > That's worse. Looks like these are coming from the OPP core. We are debugging it internally. > The system does eventually boot, and I was happy to see that we do end > up finding the PCIe devices after all. > That's good. These errors shouldn't be a blocker for merging this series. But we will resolve it asap. - Mani -- மணிவண்ணன் சதாசிவம்
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@oss.qualcomm.com/ > > 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@oss.qualcomm.com/ > > 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > > 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > > 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > > > > 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@0-1c00000.pci' > > # 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. - Qiang Yu > Regards, > Bjorn
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@oss.qualcomm.com/ >>> 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@oss.qualcomm.com/ >>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ >>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ >>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ >>> >>> 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@0-1c00000.pci' >> >> # 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 Konrad
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@oss.qualcomm.com/ > >>> 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@oss.qualcomm.com/ > >>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > >>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > >>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > >>> > >>> 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@0-1c00000.pci' > >> > >> # 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. - Qiang Yu > Konrad
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@oss.qualcomm.com/
>>>>> 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@oss.qualcomm.com/
>>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/
>>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/
>>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/
>>>>>
>>>>> 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@0-1c00000.pci'
>>>>
>>>> # 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?
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
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@oss.qualcomm.com/
> >>>>> 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@oss.qualcomm.com/
> >>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/
> >>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/
> >>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/
> >>>>>
> >>>>> 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@0-1c00000.pci'
> >>>>
> >>>> # 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@oss.qualcomm.com/
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
On 2/2/26 11:21 AM, Qiang Yu wrote: > 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@oss.qualcomm.com/ >>>>>>> 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@oss.qualcomm.com/ >>>>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ >>>>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ >>>>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ >>>>>>> >>>>>>> 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@0-1c00000.pci' >>>>>> >>>>>> # 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@oss.qualcomm.com/ > > Our goal is to prevent probe deferrals from occurring in our driver. Right, I would assume that was previously aided by devlink taking into account 'phys', but since they're no longer part of the PCIe device node directly, that logic fails. Still, modifying the DT to fit Linux behavior generally indicated that Linux is not super good at doing that particular thing.. In this instance I think we should extend drivers/of/property.c to maybe check for supplier dependencies under subnodes of nodes that have device_type="pci"? Konrad
On Tue, Feb 03, 2026 at 10:50:26AM +0100, Konrad Dybcio wrote: > On 2/2/26 11:21 AM, Qiang Yu wrote: > > 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@oss.qualcomm.com/ > >>>>>>> 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@oss.qualcomm.com/ > >>>>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > >>>>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > >>>>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > >>>>>>> > >>>>>>> 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@0-1c00000.pci' > >>>>>> > >>>>>> # 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@oss.qualcomm.com/ > > > > Our goal is to prevent probe deferrals from occurring in our driver. > > Right, I would assume that was previously aided by devlink taking > into account 'phys', but since they're no longer part of the PCIe > device node directly, that logic fails. > > Still, modifying the DT to fit Linux behavior generally indicated that > Linux is not super good at doing that particular thing.. In this > instance I think we should extend drivers/of/property.c to maybe check > for supplier dependencies under subnodes of nodes that have > device_type="pci"? > Yes, that's exactly how I think it should be fixed. I'm wiring a patch now. - Mani -- மணிவண்ணன் சதாசிவம்
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@oss.qualcomm.com/ > >>> 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@oss.qualcomm.com/ > >>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > >>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > >>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > >>> > >>> 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@0-1c00000.pci' > >> > >> # 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 > We did try to avoid that by guarding it with dev_pm_opp_get_opp_count(). But that doesn't seem to be helping. The error might be due to duplicate non-shared opp entries, but I'm yet to confirm. - Mani -- மணிவண்ணன் சதாசிவம்
On 1/29/26 5:32 PM, Manivannan Sadhasivam 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@oss.qualcomm.com/ >>>>> 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@oss.qualcomm.com/ >>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ >>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ >>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ >>>>> >>>>> 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@0-1c00000.pci' >>>> >>>> # 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 >> > > We did try to avoid that by guarding it with dev_pm_opp_get_opp_count(). But > that doesn't seem to be helping. The error might be due to duplicate non-shared > opp entries, but I'm yet to confirm. What if you just move the devm_pm_opp_of_add_table() to after the calls that can return -EPROBE_DEFER? Konrad
On 1/29/2026 6:51 AM, 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@oss.qualcomm.com/ >> 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@oss.qualcomm.com/ >> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ >> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ >> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ >> >> 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. qcom,pmh0101-flash-led and qcom,pmh0101-pwm are part of lee's for-leds-next tree but don't see them in next https://git.kernel.org/pub/scm/linux/kernel/git/lee/leds.git/log/?h=for-leds-next The interrupt maxItems has been acked by rob but not picked up by vinod yet https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > > > Booting the system I get a ton of errors from PCIe in the kernel log: > > debugfs: 'opp:5000000' already exists in 'soc@0-1c00000.pci' > > # 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. > > Regards, > Bjorn
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@oss.qualcomm.com/ > > 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@oss.qualcomm.com/ > > 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > > 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > > 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > > > > 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@0-1c00000.pci' > > # dmesg | grep -E 'debugfs: .+ already exists' |wc -l > 508 Hi Bjorn, I tested this patch series on my Glymur setup and I also see this opp debugfs warning. I checked other platforms and found this warning has been there on sm8450 and sm8550. I checked git history and identified the warning is intrduced by this patch series: https://lore.kernel.org/linux-arm-msm/20251013-opp_pcie-v5-0-eb64db2b4bd3@oss.qualcomm.com/ But I don't see so many warnings on my setup. As per talked offline, these many warnings are because the probe gets deferred many times on your setup. I will work with PCIe maintainers to see how to fix the warnings. At same time, let's figure out why there are so many probe defers on your setup. Could you please share me your bootup logs? - Qiang Yu > > The system does eventually boot, and I was happy to see that we do end > up finding the PCIe devices after all. > > Regards, > Bjorn
On Thu, 22 Jan 2026 20:53:57 +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@oss.qualcomm.com/ > 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@oss.qualcomm.com/ > 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > > Linux-next based tree with Glymur patches is available at: > https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction > > Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> > --- > Changes in v6: > - Moved pmic thermal zones to their respective pmic dtsi files > - Link to v5: https://lore.kernel.org/r/20260122-upstream_v3_glymur_introduction-v5-0-8ba76c354e9a@oss.qualcomm.com > > Changes in v5: > - Added opp entries for pcie nodes > - Dropped qup-memory interconnect from uart nodes > - Update trip1 type to critical for pmic thermal zones > - Alignment and newline fixes according to comments > - Link to v4: https://lore.kernel.org/r/20260112-upstream_v3_glymur_introduction-v4-0-8a0366210e02@oss.qualcomm.com > > Changes in v4: > - Enabled PCIe SMMU for all 4 PCIe instances > - Updated dispcc required opps level to "rpmhpd_opp_low_svs" > - Updated watchdog compatible > - Renamed gic-its to msi-controller > - Updated GCC clocks property to 43 from 44 > - Moved cpu-idle-states to domain-idle-states > - Fixed alignment and zero padding issues according to review comments > - Dropped glymur-pmics.dtsi > - Moved pmic thermal zones from board dts to soc dtsi > - Link to v3: https://lore.kernel.org/r/20251219-upstream_v3_glymur_introduction-v3-0-32271f1f685d@oss.qualcomm.com > > Changes in v3: > - Enabled system-cache-controller > - Squashed all initial features to boot to shell with nvme as storage > - Updated tsens nodes according to comments > - Merged tcsr and tcsrcc node > - Addressed review comments > - Link to v1: https://lore.kernel.org/all/20250925-v3_glymur_introduction-v1-0-24b601bbecc0@oss.qualcomm.com > > Changes in v2: > - Series was sent erroneously > - Link to v1: https://lore.kernel.org/r/20250925-v3_glymur_introduction-v1-0-5413a85117c6@oss.qualcomm.com > > Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> > > --- > Pankaj Patil (4): > dt-bindings: arm: qcom: Document Glymur SoC and board > arm64: defconfig: Enable Glymur configs for boot to shell > arm64: dts: qcom: Introduce Glymur base dtsi > arm64: dts: qcom: glymur: Enable Glymur CRD board support > > Documentation/devicetree/bindings/arm/qcom.yaml | 5 + > arch/arm64/boot/dts/qcom/Makefile | 1 + > arch/arm64/boot/dts/qcom/glymur-crd.dts | 601 +++ > arch/arm64/boot/dts/qcom/glymur.dtsi | 5913 +++++++++++++++++++++++ > arch/arm64/boot/dts/qcom/pmcx0102.dtsi | 187 + > arch/arm64/boot/dts/qcom/pmh0101.dtsi | 68 + > arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 144 + > arch/arm64/boot/dts/qcom/pmh0110-glymur.dtsi | 144 + > arch/arm64/boot/dts/qcom/pmk8850.dtsi | 70 + > arch/arm64/boot/dts/qcom/smb2370.dtsi | 45 + > arch/arm64/configs/defconfig | 5 + > 11 files changed, 7183 insertions(+) > --- > base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b > change-id: 20251007-upstream_v3_glymur_introduction-5a105b54493d > prerequisite-message-id: <20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@oss.qualcomm.com> > prerequisite-patch-id: bd5a4703a5a7fc530418337680cf1e2ea1518f35 > prerequisite-message-id: <20251215-knp-pmic-leds-v3-0-5e583f68b0e5@oss.qualcomm.com> > prerequisite-patch-id: 6bbaff642cfd1f1386ff0ccd746739b68cdbeb45 > prerequisite-patch-id: e30603778b23b7f7586b1c01a362e45af7bd0aa3 > prerequisite-message-id: <20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com> > prerequisite-patch-id: 14469fd166b31b251b98bf25e783ab6f57ddd13a > > Best regards, > -- > Pankaj Patil <pankaj.patil@oss.qualcomm.com> > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade This patch series was applied (using b4) to base: Deps: looking for dependencies matching 4 patch-ids Deps: Applying prerequisite patch: [PATCH] dt-bindings: mfd: qcom,spmi-pmic: Document PMICs present on Glymur Deps: Applying prerequisite patch: [PATCH v3 1/2] dt-bindings: leds: leds-qcom-lpg: Add support for PMH0101 PWM Deps: Applying prerequisite patch: [PATCH v3 2/2] dt-bindings: leds: qcom,spmi-flash-led: Add PMH0101 compatible Deps: Applying prerequisite patch: [PATCH v2] dt-bindings: dma: qcom,gpi: Update max interrupt lines to 16 Base: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b (use --merge-base to override) If this is not the correct base, please add 'base-commit' tag (or use b4 which does this automatically) New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20260122-upstream_v3_glymur_introduction-v6-0-245f408ed82a@oss.qualcomm.com: arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1bf0000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1bf0000 (qcom,glymur-pcie): compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] is too long from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/pci@1bf0000: failed to match any schema with compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1b40000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1b40000 (qcom,glymur-pcie): compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] is too long from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/pci@1b40000: failed to match any schema with compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1c00000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1c00000 (qcom,glymur-pcie): compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] is too long from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/pci@1c00000: failed to match any schema with compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1b80000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1b80000 (qcom,glymur-pcie): compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] is too long from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/pci@1b80000: failed to match any schema with compatible: ['qcom,glymur-pcie', 'qcom,pcie-x1e80100'] arch/arm64/boot/dts/qcom/glymur-crd.dtb: mailbox@3e04000 (qcom,glymur-ipcc): compatible:0: 'qcom,glymur-ipcc' is not one of ['qcom,milos-ipcc', 'qcom,qcs8300-ipcc', 'qcom,qdu1000-ipcc', 'qcom,sa8255p-ipcc', 'qcom,sa8775p-ipcc', 'qcom,sar2130p-ipcc', 'qcom,sc7280-ipcc', 'qcom,sc8280xp-ipcc', 'qcom,sdx75-ipcc', 'qcom,sm6350-ipcc', 'qcom,sm6375-ipcc', 'qcom,sm8250-ipcc', 'qcom,sm8350-ipcc', 'qcom,sm8450-ipcc', 'qcom,sm8550-ipcc', 'qcom,sm8650-ipcc', 'qcom,sm8750-ipcc', 'qcom,x1e80100-ipcc'] from schema $id: http://devicetree.org/schemas/mailbox/qcom-ipcc.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/mailbox@3e04000: failed to match any schema with compatible: ['qcom,glymur-ipcc', 'qcom,ipcc'] arch/arm64/boot/dts/qcom/glymur-crd.dtb: watchdog@17600000 (qcom,apss-wdt-glymur): compatible: 'oneOf' conditional failed, one must be fixed: ['qcom,apss-wdt-glymur', 'qcom,kpss-wdt'] is too long ['qcom,apss-wdt-glymur', 'qcom,kpss-wdt'] is too short 'qcom,apss-wdt-glymur' is not one of ['qcom,kpss-wdt-ipq4019', 'qcom,apss-wdt-ipq5018', 'qcom,apss-wdt-ipq5332', 'qcom,apss-wdt-ipq5424', 'qcom,apss-wdt-ipq9574', 'qcom,apss-wdt-kaanapali', 'qcom,apss-wdt-msm8226', 'qcom,apss-wdt-msm8974', 'qcom,apss-wdt-msm8994', 'qcom,apss-wdt-qcm2290', 'qcom,apss-wdt-qcs404', 'qcom,apss-wdt-qcs615', 'qcom,apss-wdt-qcs8300', 'qcom,apss-wdt-sa8255p', 'qcom,apss-wdt-sa8775p', 'qcom,apss-wdt-sc7180', 'qcom,apss-wdt-sc7280', 'qcom,apss-wdt-sc8180x', 'qcom,apss-wdt-sc8280xp', 'qcom,apss-wdt-sdm845', 'qcom,apss-wdt-sdx55', 'qcom,apss-wdt-sdx65', 'qcom,apss-wdt-sm6115', 'qcom,apss-wdt-sm6350', 'qcom,apss-wdt-sm8150', 'qcom,apss-wdt-sm8250'] 'qcom,kpss-wdt' was expected 'qcom,scss-timer' was expected 'qcom,apss-wdt-glymur' is not one of ['qcom,kpss-wdt-apq8064', 'qcom,kpss-wdt-ipq8064', 'qcom,kpss-wdt-mdm9615', 'qcom,kpss-wdt-msm8960'] 'qcom,msm-timer' was expected 'qcom,kpss-timer' was expected from schema $id: http://devicetree.org/schemas/watchdog/qcom-wdt.yaml arch/arm64/boot/dts/qcom/glymur-crd.dtb: /soc@0/watchdog@17600000: failed to match any schema with compatible: ['qcom,apss-wdt-glymur', 'qcom,kpss-wdt']
On 1/22/26 7:07 PM, Rob Herring wrote: > > On Thu, 22 Jan 2026 20:53:57 +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@oss.qualcomm.com/ >> 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@oss.qualcomm.com/ >> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ >> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ >> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ >> >> Linux-next based tree with Glymur patches is available at: >> https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction >> >> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> >> --- >> Changes in v6: >> - Moved pmic thermal zones to their respective pmic dtsi files >> - Link to v5: https://lore.kernel.org/r/20260122-upstream_v3_glymur_introduction-v5-0-8ba76c354e9a@oss.qualcomm.com >> >> Changes in v5: >> - Added opp entries for pcie nodes >> - Dropped qup-memory interconnect from uart nodes >> - Update trip1 type to critical for pmic thermal zones >> - Alignment and newline fixes according to comments >> - Link to v4: https://lore.kernel.org/r/20260112-upstream_v3_glymur_introduction-v4-0-8a0366210e02@oss.qualcomm.com >> >> Changes in v4: >> - Enabled PCIe SMMU for all 4 PCIe instances >> - Updated dispcc required opps level to "rpmhpd_opp_low_svs" >> - Updated watchdog compatible >> - Renamed gic-its to msi-controller >> - Updated GCC clocks property to 43 from 44 >> - Moved cpu-idle-states to domain-idle-states >> - Fixed alignment and zero padding issues according to review comments >> - Dropped glymur-pmics.dtsi >> - Moved pmic thermal zones from board dts to soc dtsi >> - Link to v3: https://lore.kernel.org/r/20251219-upstream_v3_glymur_introduction-v3-0-32271f1f685d@oss.qualcomm.com >> >> Changes in v3: >> - Enabled system-cache-controller >> - Squashed all initial features to boot to shell with nvme as storage >> - Updated tsens nodes according to comments >> - Merged tcsr and tcsrcc node >> - Addressed review comments >> - Link to v1: https://lore.kernel.org/all/20250925-v3_glymur_introduction-v1-0-24b601bbecc0@oss.qualcomm.com >> >> Changes in v2: >> - Series was sent erroneously >> - Link to v1: https://lore.kernel.org/r/20250925-v3_glymur_introduction-v1-0-5413a85117c6@oss.qualcomm.com >> >> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> >> >> --- >> Pankaj Patil (4): >> dt-bindings: arm: qcom: Document Glymur SoC and board >> arm64: defconfig: Enable Glymur configs for boot to shell >> arm64: dts: qcom: Introduce Glymur base dtsi >> arm64: dts: qcom: glymur: Enable Glymur CRD board support >> >> Documentation/devicetree/bindings/arm/qcom.yaml | 5 + >> arch/arm64/boot/dts/qcom/Makefile | 1 + >> arch/arm64/boot/dts/qcom/glymur-crd.dts | 601 +++ >> arch/arm64/boot/dts/qcom/glymur.dtsi | 5913 +++++++++++++++++++++++ >> arch/arm64/boot/dts/qcom/pmcx0102.dtsi | 187 + >> arch/arm64/boot/dts/qcom/pmh0101.dtsi | 68 + >> arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 144 + >> arch/arm64/boot/dts/qcom/pmh0110-glymur.dtsi | 144 + >> arch/arm64/boot/dts/qcom/pmk8850.dtsi | 70 + >> arch/arm64/boot/dts/qcom/smb2370.dtsi | 45 + >> arch/arm64/configs/defconfig | 5 + >> 11 files changed, 7183 insertions(+) >> --- >> base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b >> change-id: 20251007-upstream_v3_glymur_introduction-5a105b54493d >> prerequisite-message-id: <20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@oss.qualcomm.com> >> prerequisite-patch-id: bd5a4703a5a7fc530418337680cf1e2ea1518f35 >> prerequisite-message-id: <20251215-knp-pmic-leds-v3-0-5e583f68b0e5@oss.qualcomm.com> >> prerequisite-patch-id: 6bbaff642cfd1f1386ff0ccd746739b68cdbeb45 >> prerequisite-patch-id: e30603778b23b7f7586b1c01a362e45af7bd0aa3 >> prerequisite-message-id: <20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com> >> prerequisite-patch-id: 14469fd166b31b251b98bf25e783ab6f57ddd13a >> >> Best regards, >> -- >> Pankaj Patil <pankaj.patil@oss.qualcomm.com> >> >> >> > > > My bot found new DTB warnings on the .dts files added or changed in this > series. > > Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings > are fixed by another series. Ultimately, it is up to the platform > maintainer whether these warnings are acceptable or not. No need to reply > unless the platform maintainer has comments. > > If you already ran DT checks and didn't see these error(s), then > make sure dt-schema is up to date: > > pip3 install dtschema --upgrade > > > This patch series was applied (using b4) to base: > Deps: looking for dependencies matching 4 patch-ids > Deps: Applying prerequisite patch: [PATCH] dt-bindings: mfd: qcom,spmi-pmic: Document PMICs present on Glymur > Deps: Applying prerequisite patch: [PATCH v3 1/2] dt-bindings: leds: leds-qcom-lpg: Add support for PMH0101 PWM > Deps: Applying prerequisite patch: [PATCH v3 2/2] dt-bindings: leds: qcom,spmi-flash-led: Add PMH0101 compatible > Deps: Applying prerequisite patch: [PATCH v2] dt-bindings: dma: qcom,gpi: Update max interrupt lines to 16 > Base: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b (use --merge-base to override) > > If this is not the correct base, please add 'base-commit' tag > (or use b4 which does this automatically) > > > New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20260122-upstream_v3_glymur_introduction-v6-0-245f408ed82a@oss.qualcomm.com: > > arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1bf0000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected > from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml +Mani you sent a 'b4 ty' for this months ago, what happened? https://lore.kernel.org/linux-arm-msm/176189884156.5303.14323602106505981794.b4-ty@kernel.org/ The ipcc one should be handled by Rob now: https://lore.kernel.org/linux-arm-msm/20260116162057.GA1681736-robh@kernel.org/ And watchdog is perhaps in Guenter's queue https://lore.kernel.org/linux-arm-msm/de7f0b8a-a355-42c1-ac3c-d0b5de754711@roeck-us.net/ Konrad
On Thu, Jan 22, 2026 at 2:41 PM Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote: > > On 1/22/26 7:07 PM, Rob Herring wrote: > > > > On Thu, 22 Jan 2026 20:53:57 +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@oss.qualcomm.com/ > >> 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@oss.qualcomm.com/ > >> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > >> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > >> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > >> > >> Linux-next based tree with Glymur patches is available at: > >> https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction > >> > >> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> > >> --- > >> Changes in v6: > >> - Moved pmic thermal zones to their respective pmic dtsi files > >> - Link to v5: https://lore.kernel.org/r/20260122-upstream_v3_glymur_introduction-v5-0-8ba76c354e9a@oss.qualcomm.com > >> > >> Changes in v5: > >> - Added opp entries for pcie nodes > >> - Dropped qup-memory interconnect from uart nodes > >> - Update trip1 type to critical for pmic thermal zones > >> - Alignment and newline fixes according to comments > >> - Link to v4: https://lore.kernel.org/r/20260112-upstream_v3_glymur_introduction-v4-0-8a0366210e02@oss.qualcomm.com > >> > >> Changes in v4: > >> - Enabled PCIe SMMU for all 4 PCIe instances > >> - Updated dispcc required opps level to "rpmhpd_opp_low_svs" > >> - Updated watchdog compatible > >> - Renamed gic-its to msi-controller > >> - Updated GCC clocks property to 43 from 44 > >> - Moved cpu-idle-states to domain-idle-states > >> - Fixed alignment and zero padding issues according to review comments > >> - Dropped glymur-pmics.dtsi > >> - Moved pmic thermal zones from board dts to soc dtsi > >> - Link to v3: https://lore.kernel.org/r/20251219-upstream_v3_glymur_introduction-v3-0-32271f1f685d@oss.qualcomm.com > >> > >> Changes in v3: > >> - Enabled system-cache-controller > >> - Squashed all initial features to boot to shell with nvme as storage > >> - Updated tsens nodes according to comments > >> - Merged tcsr and tcsrcc node > >> - Addressed review comments > >> - Link to v1: https://lore.kernel.org/all/20250925-v3_glymur_introduction-v1-0-24b601bbecc0@oss.qualcomm.com > >> > >> Changes in v2: > >> - Series was sent erroneously > >> - Link to v1: https://lore.kernel.org/r/20250925-v3_glymur_introduction-v1-0-5413a85117c6@oss.qualcomm.com > >> > >> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> > >> > >> --- > >> Pankaj Patil (4): > >> dt-bindings: arm: qcom: Document Glymur SoC and board > >> arm64: defconfig: Enable Glymur configs for boot to shell > >> arm64: dts: qcom: Introduce Glymur base dtsi > >> arm64: dts: qcom: glymur: Enable Glymur CRD board support > >> > >> Documentation/devicetree/bindings/arm/qcom.yaml | 5 + > >> arch/arm64/boot/dts/qcom/Makefile | 1 + > >> arch/arm64/boot/dts/qcom/glymur-crd.dts | 601 +++ > >> arch/arm64/boot/dts/qcom/glymur.dtsi | 5913 +++++++++++++++++++++++ > >> arch/arm64/boot/dts/qcom/pmcx0102.dtsi | 187 + > >> arch/arm64/boot/dts/qcom/pmh0101.dtsi | 68 + > >> arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 144 + > >> arch/arm64/boot/dts/qcom/pmh0110-glymur.dtsi | 144 + > >> arch/arm64/boot/dts/qcom/pmk8850.dtsi | 70 + > >> arch/arm64/boot/dts/qcom/smb2370.dtsi | 45 + > >> arch/arm64/configs/defconfig | 5 + > >> 11 files changed, 7183 insertions(+) > >> --- > >> base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b > >> change-id: 20251007-upstream_v3_glymur_introduction-5a105b54493d > >> prerequisite-message-id: <20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@oss.qualcomm.com> > >> prerequisite-patch-id: bd5a4703a5a7fc530418337680cf1e2ea1518f35 > >> prerequisite-message-id: <20251215-knp-pmic-leds-v3-0-5e583f68b0e5@oss.qualcomm.com> > >> prerequisite-patch-id: 6bbaff642cfd1f1386ff0ccd746739b68cdbeb45 > >> prerequisite-patch-id: e30603778b23b7f7586b1c01a362e45af7bd0aa3 > >> prerequisite-message-id: <20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com> > >> prerequisite-patch-id: 14469fd166b31b251b98bf25e783ab6f57ddd13a > >> > >> Best regards, > >> -- > >> Pankaj Patil <pankaj.patil@oss.qualcomm.com> > >> > >> > >> > > > > > > My bot found new DTB warnings on the .dts files added or changed in this > > series. > > > > Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings > > are fixed by another series. Ultimately, it is up to the platform > > maintainer whether these warnings are acceptable or not. No need to reply > > unless the platform maintainer has comments. > > > > If you already ran DT checks and didn't see these error(s), then > > make sure dt-schema is up to date: > > > > pip3 install dtschema --upgrade > > > > > > This patch series was applied (using b4) to base: > > Deps: looking for dependencies matching 4 patch-ids > > Deps: Applying prerequisite patch: [PATCH] dt-bindings: mfd: qcom,spmi-pmic: Document PMICs present on Glymur > > Deps: Applying prerequisite patch: [PATCH v3 1/2] dt-bindings: leds: leds-qcom-lpg: Add support for PMH0101 PWM > > Deps: Applying prerequisite patch: [PATCH v3 2/2] dt-bindings: leds: qcom,spmi-flash-led: Add PMH0101 compatible > > Deps: Applying prerequisite patch: [PATCH v2] dt-bindings: dma: qcom,gpi: Update max interrupt lines to 16 > > Base: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b (use --merge-base to override) > > > > If this is not the correct base, please add 'base-commit' tag > > (or use b4 which does this automatically) > > > > > > New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20260122-upstream_v3_glymur_introduction-v6-0-245f408ed82a@oss.qualcomm.com: > > > > arch/arm64/boot/dts/qcom/glymur-crd.dtb: pci@1bf0000 (qcom,glymur-pcie): compatible:0: 'qcom,pcie-x1e80100' was expected > > from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml > > +Mani you sent a 'b4 ty' for this months ago, what happened? > > https://lore.kernel.org/linux-arm-msm/176189884156.5303.14323602106505981794.b4-ty@kernel.org/ It wasn't in 1/16 linux-next, but it is there now. > The ipcc one should be handled by Rob now: > > https://lore.kernel.org/linux-arm-msm/20260116162057.GA1681736-robh@kernel.org/ Actually, Bjorn picked that up instead since there are other mailbox patches that didn't get picked up. > And watchdog is perhaps in Guenter's queue > > https://lore.kernel.org/linux-arm-msm/de7f0b8a-a355-42c1-ac3c-d0b5de754711@roeck-us.net/ Seems to be hit or miss if wdog bindings are picked up, but again, this one is in today's next. Perhaps slow down the pace on this given the 4 listed dependencies and 3 unlisted dependencies. Rob
© 2016 - 2026 Red Hat, Inc.