FROMLIST: Add qref and refgen regulator support for QCS8300 and SA8775p PCIe PHYs - #1684
Conversation
Shikra uses the same CAMSS IP as QCM2290. Extend the existing qcom,qcm2290-camss binding to add the qcom,shikra-camss compatible string. Co-developed-by: Vikram Sharma <vikramsa@qti.qualcomm.com> Signed-off-by: Vikram Sharma <vikramsa@qti.qualcomm.com> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
Add Shikra compatible consistent with CAMSS CCI interfaces. It requires only two clocks. Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
Add CAMSS driver support for Shikra SoC. Add high level resource definitions for 2 CSIPHY, 2 CSID and 2 VFE instances along with the interconnect bandwidth votes for AHB, HF and SF MNOC paths. Co-developed-by: Vikram Sharma <vikramsa@qti.qualcomm.com> Signed-off-by: Vikram Sharma <vikramsa@qti.qualcomm.com> Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com>
SMEM_SMSM_SIZE_INFO (id 419) is not populated by the boot firmware on Shikra. The SMSM driver falls back to SMSM_DEFAULT_NUM_HOSTS when this segment is absent, which causes SMEM_SMSM_CPU_INTR_MASK (id 333) to be allocated with the wrong size. The upstream default of 3 allocates 8*3*4 = 96 bytes. Shikra modem firmware expects 8*5*4 = 160 bytes, matching the num_hosts=5 used by the downstream kernel. The size mismatch causes the modem to crash on boot with "smsm.c: Bad pointer from smem_alloc". Increasing the host count only results in a larger allocation, so this change is safe for existing platforms. Increase the default to 5 to match the modem firmware expectation. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM interrupt, which overrides the trigger type specified in the device tree. This is incorrect for platforms like Shikra where the A2 BAM requires edge-triggered interrupts. Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the trigger type already configured by platform_get_irq() when it parsed the device tree interrupts property. This makes the driver platform-agnostic. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
This driver provides access to modem data channels on platforms using the A2 BAM hardware, including Shikra. Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Add support for the Adreno A704 GPU (chip ID 0x07000400). It belongs to the A610 family and shares its configuration with the A702, including HWCG, UBWC settings, and CP memory pool size. Introduce adreno_is_a704() and include A704 in adreno_is_a610_family(). Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
The Shikra SoC uses an Adreno A704 GPU identified by chip ID 0x07000400. Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
Drop generic compatible approach, and add Shikra specific bindings. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Update the compatible string to "qcom,shikra-epss" as per the latest bindings. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add ftrace tracepoints to SMSM for observability of state bit updates, IPC kicks, interrupt handling, and IRQ mask/unmask operations. Introduce a trace header and wire CFLAGS_smsm.o so the trace header is found via -I$(src). Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Add ftrace tracepoints to the BAM-DMUX driver for observability of channel open/close (local and remote), RX callbacks, power on/off transitions, power control IRQs, and each step of the runtime resume sequence. Introduce a trace header and wire CFLAGS_qcom_bam_dmux.o so the trace header is found via -I$(src). Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
This patch introduces the creation of AEST platform devices, where each device represents a logical "error node device" grouping one or more AEST nodes from the ACPI table. Instead of relying on the optional 'error_node_device' field in the AEST table[1], this commit uses the interrupt number as the sole identifier for the parent device. This design simplifies the driver logic by providing a single, consistent mechanism for grouping nodes. The 'error_node_device' field can be unspecified, but an AEST node is always physically associated with a parent component. The interrupt number serves as a reliable proxy for this association. This approach is based on the safe assumption that distinct hardware components (e.g., SMMU, CMN, GIC) are assigned unique error interrupts and do not share them. [1]: https://developer.arm.com/documentation/den0085/latest Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-2-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Parse register information from the AEST table in the probe function, create corresponding structures, and mappings AEST record. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-3-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Support for various AEST group formats allows for flexible configuration of AEST node address space sizes and maximum record counts per group. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-4-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…IO register Use record_read/write to simultaneously read and write system registers and MMIO registers while maintaining code conciseness. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-5-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The RAS version of a component can be probed via its ERRDEVARCH register. In cases where a component (e.g., SMMU) does not implement an ERRDEVARCH register, the driver falls back to using the RAS version of the Processing Element (PE). Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-6-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Add inject register descripted in Common Fault Injection Model Extension. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-7-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The CE threshold defines the number of Correctable Errors (CE) that must occur in a record before triggering an interrupt. Error records support multiple threshold configurations, including 8B, 16B, and 32B. This patch detects the supported threshold settings for error records and sets the default threshold to 1, ensuring an interrupt is generated for every CE occurrence. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-8-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The interrupt numbers for certain error records may be explicitly programmed into their configuration register. And for PPIs, each core will maintains its own copy of the aest_device structure. Given that handling RAS errors entails complex processes such as EDAC and memory_failure, all handling is deferred to and handled within a bottom-half context. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-9-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Move the configuration of interrupts and CE thresholds into the CPU hotplug callbacks for the per-CPU AEST node. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-10-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Exposes certain AEST driver information to userspace.
Only ROOT can access these interface because it includes
hardware-sensitive information:
ls /sys/kernel/debug/aest/
memory<id> smmu<id> ...
ls /sys/kernel/debug/aest/memory<id>/
record0 record1 ...
All details at:
Documentation/ABI/testing/debugfs-aest
Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
Link: https://patch.msgid.link/20260122094656.73399-11-tianruidong@linux.alibaba.com
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
This commit introduces error counting functionality for AEST records. Previously, error statistics were not directly available for individual error records or AEST nodes. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-12-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
This commit introduces the ability to configure the Corrected Error (CE) threshold for AEST records through debugfs. This allows administrators to dynamically adjust the CE threshold for error reporting. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-13-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
AEST offers both soft and hard injection. Soft injection simulates errors in software, providing flexibility to define the error register content. Hard injection, on the other hand, utilizes error injection registers to introduce hardware faults, strictly requiring values that adhere to their specifications. Read Documentation/ABI/testing/debugfs-aest to learn how to use them. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-14-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
AEST table include vendor error node to support the component that do not implement standard Arm RAS architecture[1]. Each vendor node may have their own initialize and interrupt handle function. This patch supply a framework to process vendor error nodes, the vendor process function is binded with vendor HID. [1]: https://developer.arm.com/documentation/ddi0587/latest/ Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-15-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The CMN (Coherent Mesh Network) architecture incorporates five distinct device types. Each device type is associated with an error group register set. The struct aest_cmn_700 models a single CMN instance, while struct aest_cmn_700_child represents an individual CMN device. CMN's error records utilize a memory-mapped single error record view [1]. Critically, one error record corresponds to one AEST node, implying that a single CMN instance can generate hundreds of AEST nodes. To manage this scale, this driver introduces a virtual AEST node, which represents an entire CMN device, such as an HNI or HNF. This allows an HNF AEST node, for instance, to leverage its errgsr register to pinpoint which specific error record has reported an error. During the AEST probe phase, the CMN AEST driver identifies the CMN node type using the cmn_node_info register. It then reorganizes all AEST nodes belonging to the same CMN node type into a cohesive CMN AEST node structure. To locate the relevant CMN register addresses, the CMN's presence in the DSDT is required, along with the CMN node offset specified in the AEST vendor specification data [1]. [1]: https://developer.arm.com/documentation/102308/latest/ Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-16-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Add a trace event for hardware errors reported by the ARMv8 RAS extension registers. userspace app can monitor this trace event and decode error information. Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Link: https://patch.msgid.link/20260122094656.73399-17-tianruidong@linux.alibaba.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
… messages Two related fixes for processor nodes with ACPI_AEST_PROC_FLAG_SHARED or ACPI_AEST_PROC_FLAG_GLOBAL set (e.g. cluster L3 cache, DSU): 1. aest_dev_is_oncore() returns true for any PROCESSOR_ERROR_NODE, causing shared processor nodes (which use an SPI) to take the cpuhp/PPI path. cpuhp_setup_state() is called instead of aest_online_dev(), so aest_config_irq() is never called and the hardware IRQ-config register is never programmed. Fix aest_dev_is_oncore() to check irq_is_percpu() on the registered IRQ. Only nodes whose FHI or ERI is a per-CPU PPI take the oncore path, nodes with an SPI take aest_online_dev(). 2. alloc_aest_node_name() uses processor_id for the node name of all processor nodes. Shared/global nodes have processor_id=0 (the field is unused when SHARED/GLOBAL is set), so every shared node and the per-PE node for CPU 0 both got the name "processor.0", making error logs ambiguous. For shared/global nodes, build the name as "processor.<resource_type>.<device_id>" (e.g. "processor.cache.1") so each node has a unique, meaningful identifier. Per-PE nodes keep the original "processor.<mpidr>" form. Also add proc_flags to struct aest_event so aest_print() can distinguish shared from per-PE nodes and print an appropriate message. Link: https://lore.kernel.org/lkml/20260505-aest-devicetree-support-v1-1-d5d6ffacf0a5@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
The error counts visible under: /sys/kernel/debug/aest/<dev>/processor<cpu>/<node>/err_count always reported zero, even though corrected errors (CEs) were being serviced by the interrupt handler. aest_oncore_dev_init_debugfs() sets up per CPU debugfs entries but wired them up incorrectly in two places: - this_cpu_ptr(adev->adev_oncore) was used inside for_each_possible_cpu(). This always selects the slot for the CPU executing the init code, so all debugfs files ended up referencing the same per CPU aest_device instance instead of the CPU indicated by the loop variable. - The code referenced adev->nodes[i], i.e. the template nodes allocated before __setup_ppi, rather than the per-CPU copies at percpu_dev->nodes[i]. The IRQ handler updates CE counters in the per-CPU records created by __setup_ppi, the template records are never touched at runtime, so err_count always read as zero. Fix this by: - Using per_cpu_ptr(adev->adev_oncore, cpu) when iterating over CPUs. Wiring debugfs files to percpu_dev->nodes[i] so counters reflect the data updated by the IRQ handler. - Using adev->nodes[i].name for debugfs directory names. The per-CPU node receives name via a shallow memcpy and is not the authoritative source. Link: https://lore.kernel.org/lkml/20260505-aest-devicetree-support-v1-2-d5d6ffacf0a5@oss.qualcomm.com/ Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…no SMMU On Monaco platforms, the Adreno SMMU requires a bandwidth vote on the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers are accessible. Without this vote, the SMMU may become unreachable, leading to intermittent probe failures and runtime issues. Add the required interconnect to ensure reliable register access. Link: https://lore.kernel.org/all/20260526-smmu_interconnect_addition-v2-5-2a6d8ca30d63@oss.qualcomm.com/ Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…org/pub/scm/linux/kernel/git/torvalds/linux.git tech/bsp/clk a832eb6 16 tech/bsp/devfreq a0c2f21 6 tech/bsp/ec 643c24b 2 tech/bsp/soc-infra 6aff3e6 25 tech/bsp/pinctrl 3f1acf8 1 tech/bsp/remoteproc a7b9b6d 10 tech/bus/peripherals 342d00a 10 tech/bus/pci/all 2557ced 17 tech/bus/pci/phy aaf8ef1 4 tech/bus/usb/dwc e929e6d 3 tech/bus/usb/phy 984aa89 36 tech/debug/hwtracing 25c6a74 30 tech/pmic/misc ee32a8c 5 tech/mem/iommu 1fa98cb 5 tech/mm/audio/all cab3357 10 tech/mm/camss 147ae87 28 tech/mm/drm 2fbdd74 60 tech/mm/fastrpc f5f3138 10 tech/mm/video 859dbe7 100 tech/mm/gpu cee7794 5 tech/net/ath f542adb 18 tech/net/phy a3602e9 1 tech/pm/power 2d42c35 9 tech/pm/thermal 3f033cb 7 tech/security/crypto f030676 14 tech/security/ice 1564b82 25 tech/storage/all 6a34168 4 tech/all/dt/qcs6490 da803bf 21 tech/all/dt/qcs9100 46bbcdd 21 tech/all/dt/qcs8300 965645d 20 tech/all/dt/qcs615 195c20d 10 tech/all/dt/agatti c828f10 1 tech/all/dt/hamoa fd53d0e 30 tech/all/dt/glymur 165f40a 28 tech/all/dt/kaanapali 0fa62a7 15 tech/all/dt/pakala d7f29fa 9 tech/all/config c8f71c6 65 tech/overlay/dt a82b9ac 57 tech/all/workaround 060e2bd 20 tech/mproc/all 0aa90b7 3 tech/noup/debug/all cbdd4bb 26 tech/hwe/unoq b2ea57b 5 early/hwe/shikra/drivers f8edc71 109 early/hwe/shikra/dt 33c6905 94
🔨 Build Failure Analysis — PR #1684PR: #1684
VerdictAll 4 failures are merge conflicts during integration, not compilation errors. None are introduced by this PR's code changes. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1684PR: #1684
VerdictAll 4 failures are merge conflicts, not compilation errors. These are pre-existing conflicts between the PR and the integration branch baseline (topic/tech/bus/pci/all merged into commit 49dbe0dae5cf). The PR code itself is valid. 📎 Detailed analysis: Full report |
843c4ef to
c02816d
Compare
PR #1684 — validate-patchPR: #1684
Final Summary
|
PR #1684 — checker-log-analyzerPR: #1684
Detailed report: Full report
|
🔨 Build Failure Analysis — PR #1684PR: #1684
VerdictNo compilation errors found. The build failed during the merge phase due to 4 merge conflicts between this PR and the integration branch. These conflicts are not caused by errors in the PR code itself, but by overlapping changes in the same files between the PR and the target branch. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1684PR: #1684
VerdictAll 4 merge conflicts are introduced by this PR when merging into the integration branch. The build never reached compilation - it failed during the merge phase. 📎 Detailed analysis: Full report |
PR #1684 — validate-patchPR: #1684
Final Summary
|
PR #1684 — checker-log-analyzerPR: #1684
Detailed report: Full report
|
…en and refgen supply properties QCS8300 and SA8775p PCIe PHYs require dedicated vdda-refgen and refgen LDO supplies for QREF to provide a stable reference clock. Without these supplies, the PCIe PHYs cannot work properly. Mark them as required for the affected compatibles even though it breaks ABI. vdda-refgen-supply is required for all three QCS8300 and SA8775p PHY compatibles. refgen-supply is required for QCS8300 only, as a workaround for a hardware issue where QREF actually depends on refgen3 rather than refgen2 as documented, so the PHY driver votes for refgen3 directly via this supply. Link: https://lore.kernel.org/r/20260810112735.1326807-2-ziyue.zhang@oss.qualcomm.com Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
… QCS8300 and SA8775p PHY Add a new sa8775p_qmp_phy_vreg_l that includes vdda-phy, vdda-pll, vdda-qref, vdda-refgen and refgen supplies, and use it for QCS8300 and SA8775p PCIe PHY configurations. This avoids modifying sm8550_qmp_phy_vreg_l and breaking SM8550 and SM8650. Note that due to a hardware issue, QREF actually depends on refgen3 rather than refgen2 as documented; refgen3 is therefore voted manually via the refgen supply as a workaround. Fixes: a05b6d5 ("phy: qcom-qmp-pcie: add support for sa8775p") Fixes: ebf198f ("phy: qcom-qmp-pcie: add dual lane PHY support for QCS8300") Link: https://lore.kernel.org/r/20260810112735.1326807-3-ziyue.zhang@oss.qualcomm.com Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…CIe PHYs The QMP PCIe PHYs on QCS8300 require dedicated qref and refgen voltage supplies for stable operation. Without these supplies, the system may occasionally crash. Add vdda-qref-supply and vdda-refgen-supply in the board files (QCS8300-RIDE, Monaco-EVK and Monaco-Monza-SoM), and add refgen-supply in the SoC DTSI (monaco.dtsi) since refgen is an on-chip regulator shared across boards. The PHY driver votes for refgen3 directly as a workaround for a hardware issue where QREF actually depends on refgen3 rather than refgen2 as documented. Fixes: 33967ea ("arm64: dts: qcom: qcs8300-ride: enable pcie0 interface") Fixes: cdb613a ("arm64: dts: qcom: qcs8300-ride: enable pcie1 interface") Fixes: 41e2424 ("arm64: dts: qcom: monaco-evk: Enable PCIe0 and PCIe1.") Fixes: 5238f4e ("arm64: dts: qcom: Add Monaco Monza SoM") Link: https://lore.kernel.org/r/20260810112735.1326807-4-ziyue.zhang@oss.qualcomm.com Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…CIe PHYs The QMP PCIe PHYs on SA8775p require dedicated qref and refgen voltage supplies for stable operation. Without these supplies, the system may occasionally crash. Add vdda-qref-supply and vdda-refgen-supply in the board files (Lemans-EVK, Lemans-RIDE, QCS9100-RIDE and QCS9100-RIDE-R3). Fixes: 94d7d37 ("arm64: dts: qcom: lemans-evk: Enable PCIe support") Fixes: 76326da ("arm64: dts: qcom: lemans: Refactor ride/ride-r3 boards based on daughter cards") Link: https://lore.kernel.org/r/20260810112735.1326807-5-ziyue.zhang@oss.qualcomm.com Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
c02816d to
3f24454
Compare
This series adds qref and refgen regulator support for the PCIe QMP PHYs on QCS8300 and SA8775p platforms.
The PCIe PHYs on these SoCs require dedicated qref and refgen voltage supplies for stable operation. Without enabling these supplies, PCIe may be unstable and the system can occasionally crash under certain scenarios.
The refgen supply in particular works around a hardware issue where both QREF and the PCIe PHY are expected to depend on refgen2, but QREF actually depends on refgen3. This series therefore votes for refgen3 manually via the refgen supply.
Change 1: dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen and refgen supply properties
Change 2: phy: qcom: qmp-pcie: Add qref and refgen regulator vote for QCS8300 and SA8775p PHY
Change 3: arm64: dts: qcom: qcs8300: Add qref and refgen supply for PCIe PHYs
Change 4: arm64: dts: qcom: sa8775p: Add qref and refgen supply for PCIe PHYs
Link: https://lore.kernel.org/r/20260810112735.1326807-1-ziyue.zhang@oss.qualcomm.com