Repository navigation
wifi: ath11k: fix QRTR readiness related WLAN initialization failures - #154
Open
miaoqing-quic wants to merge 1428 commits into
Open
miaoqing-quic wants to merge 1428 commits into
miaoqing-quic wants to merge 1428 commits into
Conversation
…s_ops" This reverts commit f4ae97728b76f007b5deac796c2cf815bb5420c1. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 0a5cf3619a0f1ed239e93c720d1c7b702536016d) (cherry picked from commit 2b9d7c7)
…ommand_ops" This reverts commit a6625a0660fae1a835dc699ed507f6bed091a2aa. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 985cc2f2c167fcf115ef768b5a0865db71d3676f) (cherry picked from commit cdbaa60)
…ops" This reverts commit c118090e106fa681265eac9889a34fde760d7aa9. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit f9f88d8793d6f982e3d9a5ec1302f359aa6dc162) (cherry picked from commit fadfeff)
…n gen2-specific code" This reverts commit 3ba6edcae18fae7533b657e975fc26d09f3b4f8d. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 5d1340a71382656ed3499d10d8fdcc9e7383eaaa) (cherry picked from commit 75581f0)
…function" This reverts commit f7c099d95df11961e696cf97f4f2b3eb3f785d24. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit ec7aac0eff74e8797d22f68661fc2454f6f82a7d) (cherry picked from commit 265ec19)
…rm_data struct" This reverts commit 61333e4328bb6332909aa8afb328965b48885f43. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 41458ecbabf5372b9e4688db94ab8e74ab785944) (cherry picked from commit 5987968)
This reverts commit f4c1c6e5a6df14e31fbc82722f83ae47917726b5. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 0c0f1b1738f336a6cb3bf5f1ee261372e9ab1346) (cherry picked from commit 5539ea5)
This reverts commit bf97a5be01bc4419f0a95a296f1eddd12bdf4428. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit ab7d407f06b414620d17e3ef01bb3fb660ad0506) (cherry picked from commit 54de858)
…_devs" This reverts commit 9bfd102524eb4481e62b60c81d1fa36091f09507. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit deb4c98fc8f78da8020e392b1d201ac744b9b55a) (cherry picked from commit 168bddc)
…d in frequency formula" This reverts commit 573b0f8af6ef1ba0c060945950e8a6ebaef8a8f5. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 3f12bb5c64616a500502e3b68b3fd900e0ffdfc6) (cherry picked from commit b746299)
This reverts commit fe0cd11ec5ac3ac3c2595cc5f71c9a0e0daa010e. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit c76add22a18ad8866dfc38d61bb8fbcffc57059d) (cherry picked from commit 498273e)
…anaged by Linux" This reverts commit fb6622cf93fd939918247f3c785df56f9e14ff4d. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit 627c6e193bef230548bd212e0f27f869c002ab36) (cherry picked from commit 6e0b286)
This reverts commit 1a7aeec169892b24bcce1d93e4f1c72e4516c9ed. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com> (cherry picked from commit b525af135fe540899c6373929b4c163ac9cf9ff4) (cherry picked from commit 3891a7e)
Specifying UBWC data in each driver doesn't scale and is prone to errors. Request UBWC data from the central database in preparation to using it through the rest of the driver. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-1-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit d22d52faca4d25705413d1761ca9b0fa8c9a6507) (cherry picked from commit bde4536)
The min_acc length can be calculated from the platform UBWC configuration. Use the freshly introduced helper and calculate min_acc length based on the platform UBWC configuration instead of specifying it directly in the source. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-2-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 82ededb5f93a617ad0773560f39526dc8f2c46dd) (cherry picked from commit 85806d8)
The highest_bank_bit param is specified both in the Iris driver and in the platform UBWC config. Use the platform UBWC configuration instead of specifying it directly in the source. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-3-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 42c7164efbfcf00a630fe4e61de73f5952ab0dc8) (cherry picked from commit 57c10f2)
The UBWC swizzle is specified both in the Iris driver and in the platform UBWC config. Use the platform UBWC configuration instead of specifying it directly in the source. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-4-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit c14b4f92b31a769404e4245941b313d0a6de4f1f) (cherry picked from commit 672b69c)
The UBWC bank spreading is specified both in the Iris driver and in the platform UBWC config. Use the platform UBWC configuration instead of specifying it directly in the source. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-5-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 7b540a07f1d0cbfc62c359cceb597f1fe122514c) (cherry picked from commit 518c864)
The UBWC max_channels spreading is specified in the Iris driver, but it also can be calculated from the platform UBWC config. Use the platform UBWC configuration instead of specifying it directly in the source. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-6-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 29b8299ab08312ac080082610c4d7a6c2808ef18) (cherry picked from commit aa9198a)
Now as all UBWC configuration bits were migrated to be used or derived from the global UBWC platform-specific data, drop the unused struct and field definitions. Link: https://lore.kernel.org/linux-media/20260507-iris-ubwc-v5-7-e9a3aee53c49@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Tested-by: Wangao Wang <wangao.wang@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit e2f0779da85f445426adacd2e57d08be38ff4e4a) (cherry picked from commit edb265c)
…truct The PAS ID, the authentication service ID, used by the Iris is a constant and it is not expected to change anytime. Drop it from the platform data and use the constant instead. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-1-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 97698845dd532ab6c14dd435144959545d4cfef7) (cherry picked from commit c9770fd)
The set_preset_registers is (currently) common to all supported devices. Extract it to a iris_vpu_common.c and call it directly from iris_vpu_power_on(). Later, if any of the devices requires special handling, it can be sorted out separately. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-2-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 4869025571b9200f0583bacb161ad6696970b073) (cherry picked from commit 2164172)
…ecific code To note that iris_set_num_comv() is gen2-internal, rename it to iris_hfi_gen2_set_num_comv() and then stop using hfi_ops indirection to set session property (like other functions in this file do). Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-3-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit c0a100ae13e15d615fbedb0308e71ea267b5517e) (cherry picked from commit 0d2e886)
Calling HFI instance-specific ops should not require double indirection through the core ops. Split instance-specific ops to a separate struct, keep a pointer to it in struct iris_inst and set it directly in the get_instance function. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-4-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 82e4f934dadf3b413fc0fdf2d245f04f77093f96) (cherry picked from commit 86d4231)
There is little point in having two different structures for HFI-related core ops. Merge both of them into the new iris_hfi_ops structure. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-5-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit cd4e5d9712ac067c62eab264dee2876fd6db807d) (cherry picked from commit b055bd8)
The get_instance() is a callback tightly connected to the HFI implementation. Move it into the new iris_hfi_sys_ops structure, merging all core callbacks into a single vtable. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-6-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit c095fcdeb695cf639e4d9d8b625b815e8a43b267) (cherry picked from commit a38c882)
…m data The HW response time is a constant between platforms. Remove it from the iris_platform_data structure and use it directly. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-7-eea672b03a95@oss.qualcomm.com/ Suggested-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit ee904ba27b3888a93366a898e88518e82ae3451f) (cherry picked from commit 58a686d)
Having firmware-related fields in platform data results in the tying platform data to the HFI firmware data rather than the actual hardware. For example, SM8450 uses Gen2 firmware, so currently its platform data should be placed next to the other gen2 platforms, although it has the VPU2.0 core, similar to the one found on SM8250 and SC7280 and so the hardware-specific platform data is also close to those devices. Split firmware data to a separate struct, separating hardware-related data from the firmware interfaces. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-8-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 5b44ad08fc61d89d50a8b15c0f65f77970d7bd81) (cherry picked from commit d85773c)
Finalize the logical separation of the software and hardware interface descriptions by moving hardware properties to the files specific to the particular VPU version. Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-9-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 5f21ce799f4c3e98109b85dc024bb69f938d077a) (cherry picked from commit 7b32dbd)
The linux-firmware is providing the vpuNN_pM.mbn firmware for SM8250 since August of 2024. Stop using the legacy firmware name (vpu-1.0/venus.mbn) and switch to the standard firmware name schema (vpu/vpu20_p4.mbn). Link: https://lore.kernel.org/linux-media/20260329-iris-platform-data-v11-10-eea672b03a95@oss.qualcomm.com/ Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Bryan O'Donoghue <bod@kernel.org> (cherry picked from commit 8425f4c9924073717b48adc7f93cc5b57c224088) (cherry picked from commit bc755d8)
…non-secure world Add assign_dump_table_region() to notify TZ that the memory dump table region should be made accessible to AOP, via a self-contained SCM SMC call (QCOM_SCM_SVC_UTIL / QCOM_SCM_UTIL_DUMP_TABLE_ASSIGN). The SMC convention probe (__get_convention()) and dispatch helper are kept local to this driver rather than exported from qcom_scm, since only the register-argument SMC path is needed here. Wire it into mem_dump_alloc(), falling back to the IMEM-based dump table registration path if the SCM call fails. signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Start the graph at trigger callback. Staring the graph at prepare does not make sense as there is no data transfer at this point. Moving this to trigger will also help cope situation where pipewire is not happy if display port is not connected during start. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260402081118.348071-12-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
Initial support for Advantech SOM-DB5830 board
…om-devel FROMGIT: power: sequencing: pwrseq-pcie-m2: Support PCIe switch topologies
QCLINUX: firmware: qcom: memory_dump_v2: assign dump table region to non-secure world
UPSTREAM: ASoC: qcom: q6apm-lpass-dai: move graph start to trigger
FROMLIST: misc: fastrpc: map ADSP remote heap into remoteproc IOMMU d…
The Qualcomm QCS8300 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
UPSTREAM: cpufreq: Add QCS8300 to cpufreq-dt-platdev blocklist
…0 and SA8775p PCIe PHYs Add vdda-refgen and refgen supply properties to dt-bindings, add the sa8775p_qmp_phy_vreg_l regulator list in the PHY driver, and wire up vdda-qref-supply, vdda-refgen-supply and refgen-supply in board DTS files for QCS8300 (qcs8300-ride, monaco-evk, monaco-monza-som, monaco dtsi) and SA8775p (lemans-evk, lemans-ride-common). Without these supplies the PCIe PHY lacks stable reference clock and voltage, causing initialization timeouts and occasional system crashes. Link: https://lore.kernel.org/all/20260916102023.2054761-1-ziyue.zhang@oss.qualcomm.com/ Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Signed-off-by: Abhishek Reddy Sudugu <abhishek.sudugu@oss.qualcomm.com>
…n-regulator-support phy: qcom: Add qref and refgen regulator support for QCS8300 and SA8775p PCIe PHYs
…tem suspend Qcom PCIe RCs can successfully exit from L1ss during OS runtime. However, during system suspend, the Qcom PCIe RC driver may remove all resource votes and turns off the PHY to maximize power savings. Consequently, when the host is in system suspend with the link in L1ss and the endpoint asserts CLKREQ#, the OS must first wake up and the RC driver must restore the PHY and enable the refclk. This recovery process causes the strict L1ss exit latency time to be exceeded (roughly L10_REFCLK_ON + T_COMMONMODE). If the RC driver were to retain all votes during suspend, L1ss exit would succeed without issue, but at the expense of higher power consumption. So when the host fails to move the link from L1ss to L0 within the L10_REFCLK_ON + T_COMMONMODE time, the endpoint may treat it as a fatal condition and trigger Link Down (LDn) during resume. This LDn can crash the OS if the endpoint hosts the RootFS, and for other types of devices, it may result in a full device reset/recovery. So to ensure that the client drivers can properly handle this scenario, let them know about this platform limitation by setting the 'pci_host_bridge::broken_l1ss_resume' flag. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-pci/ahC8Pyuatu_AvnZp@google.com/ Tested-by: Brian Norris <briannorris@chromium.org>
The layer mixer count is picked purely from the mode width, via the MAX_HDISPLAY_SPLIT threshold. Width is only half of what constrains a mixer: it also processes one pixel per core clock cycle, so a mode narrow enough to stay under the width threshold can still demand a higher pixel rate than one mixer sustains. A 1080 wide panel at a few hundred Hz is enough to get there. Such a mode is currently given a single mixer and then has to be clocked past the maximum core clock rate, which that mixer cannot do. Factor the decision out into dpu_crtc_num_lm_for_mode() and have it ask for a second mixer when the adjusted mode clock does not fit the maximum core clock rate, in addition to the existing width test. Modes that already fit within one mixer are unaffected, so the only decisions that change are the ones that could not be driven as they were. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-1-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…g mode clock dpu_crtc_mode_valid() halves the adjusted mode clock whenever the hardware has a 3d_mux block, assuming the mode will be driven by two layer mixers. Modes no wider than MAX_HDISPLAY_SPLIT are driven by a single mixer, so for those the check permits twice the pixel rate the datapath can sustain. Divide by the mixer count the mode will really be driven by, as reported by dpu_crtc_num_lm_for_mode(). Split modes still get the halved rate, single mixer modes are held to what one mixer sustains, and parts without a 3d_mux divide by one. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-2-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
LM block doesn't have a hardware buffer (unlike PINGPONG and DSC encoders). As such, don't use ephemeral max_mixer_width and MAX_HDISPLAY_SPLIT to validate requested modes. Instead use PP and DSC buffer widths. While on the DPU 8.x+ supports a max linewidth of 8960 for PINGPONG_0, there is some additional logic that needs to be added to the resource manager to specifically try and reserve PINGPONG_0 for modes that are greater than 5k. The layer-mixer count for a merge-capable, non-DSC mode is chosen by dpu_crtc_num_lm_for_mode(); feed the PINGPONG/DSC derived width to it as the split threshold in place of the removed MAX_HDISPLAY_SPLIT, so the pixel-rate floor added earlier keeps high-refresh modes that now fit within a single PINGPONG buffer split across two mixers. [MP: rebased on msm-next; fed PINGPONG/DSC width into dpu_crtc_num_lm_for_mode() instead of open-coding the width test] Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-3-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Tested-by: Xilin Wu <sophon@radxa.com> [DB: reworked to drop catalog changes, updated commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…width Maximum width of the writeback mode is limited by the hardware buffer in the WB block rather than by the LM properties (LM doesn't have an actual buffer). Use the actual hardware limit (the writeback maxlinewidth) to filter modes. Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-4-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> [DB: fixed commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Remove the now-unused max_mixer_width field from the HW catalog. It doesn't represent an actual hardware constraint. [MP: rebased on msm-next; also drop the field from the milos, eliza and kaanapali catalogs added since v3] Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-5-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [Mahadevan: dropped dpu_10_2_milos.h and dpu_12_4_eliza.h hunks, not present in resolute-qcom-devel] Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…o source split Layer mixers without DPU_MIXER_SOURCESPLIT stage one pipe per blend level, so a plane is fetched by a single pipe of at most max_linewidth pixels. max_mixer_width used to reject wider modes. Now that the mode is checked against the PINGPONG width (4096/5120), keep max_linewidth as an extra bound when source split isn't available. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-6-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
All the existing variants Kodiak boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, the remote processor firmware IOMMU streams are controlled by Gunyah. However, without Gunyah, the IOMMU is managed by the consumer of this DeviceTree. Therefore, describe the firmware streams for each remote processor. Add a EL2-specific DT overlay and apply it to Kodiak IOT variant devices to create -el2.dtb for each of them alongside "normal" dtb. Note that modem and media subsystems haven't been supported yet due to missing dependencies. For GPU to work, zap shader is disabled and in EL2 mode the kernel owns hardware watchdog which is enabled here. And for wifi to work wpss copy engine memory need to be mapped for WPSS firmware to work which is aligning with sc7280 chrome. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Link: https://lore.kernel.org/all/20260624063952.2242702-1-mukesh.ojha@oss.qualcomm.com/ Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…en-l1ss-resume PCI: qcom: Indicate broken L1ss exit during resume from system suspend
FROMLIST: arm64: dts: qcom: kodiak: Add EL2 overlay
…PU < 5.0 Before DPU 5.0, the layer mixer places the higher priority SSPP on the left of a source-split pair. Priority follows the SSPP index (VIG, RGB, DMA), while allocation prefers DMA, RGB, then VIG. Swap the two SSPPs when the right one has the lower index. Both are reserved with the same requirements. Same-SSPP parallel multirect already puts RECT_0, the higher priority rectangle, on the left. Fixes: 8c62a31 ("drm/msm/dpu: allow using two SSPP blocks for a single plane") Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-1-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
DPU 5.0 introduced SRC_SPLIT_ORDER in bit 4 of SSPP_SRC_OP_MODE and SSPP_SRC_OP_MODE_REC1. For source-split pairs using legacy CTL routing, this field identifies the left source with 0 and the right source with 1. Add a setup_src_split_order() operation for the SSPP register layout used on DPU 5.0 through 12.x. Select SSPP_SRC_OP_MODE for SOLO or RECT0 and SSPP_SRC_OP_MODE_REC1 for RECT1, and update only the ordering bit. Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-2-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Virtual planes can use two SSPPs when a plane exceeds the single-pipe width or clock limit and parallel multirect cannot be used. Program SRC_SPLIT_ORDER during mixer setup from the pipes' destination X positions. Set the bit for the right source and clear it for the left source or a source without a sibling. Fixes: 8c62a31 ("drm/msm/dpu: allow using two SSPP blocks for a single plane") Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-3-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
DPU 13.x places the SSPP op-mode register in separate REC0 and REC1 banks. Add the source split order operation for this layout, using the shared helper to update SRC_SPLIT_ORDER in the selected bank. Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-4-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…ubuntu drm/msm/dpu: add pipe ordering fix on top of LM fixes
On WCN6750 platforms, reboot stress testing occasionally results in WLAN initialization failures after boot. The WPSS firmware reaches the running state successfully, but no WLAN interface is created. Analysis shows that ath11k_ahb depends on the QRTR SMD transport for QMI communication with WPSS firmware. However, this dependency is not currently expressed in Kconfig, allowing qrtr_smd and ath11k_ahb to load in either order when built as modules. If ath11k_ahb is loaded before qrtr_smd becomes available, WLAN initialization may not complete successfully. Make the QRTR and QRTR_SMD dependencies explicit and add a soft dependency to ensure qrtr_smd is loaded before ath11k_ahb. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 00402f4 ("ath11k: Add support for WCN6750 device") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260806101331.484063-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
…nit incomplete On WCN6750, if QMI messages never arrive (for example when qrtr_smd is not ready), WLAN initialization stops before the device is fully registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no QMI event handler is executed. When the driver is removed, ath11k_ahb_remove() still calls ath11k_core_deinit(), which eventually triggers ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a NULL pointer dereference in ath11k_hal_srng_access_begin(): ath11k_hal_srng_access_begin+0x14/0x68 [ath11k] ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k] ath11k_pcic_stop+0x24/0x38 [ath11k] ath11k_core_deinit+0xfc/0x1c0 [ath11k] ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb] Fix this by invoking ath11k_ahb_remove_prepare() before the state check and skipping ath11k_core_deinit() if ATH11K_FLAG_REGISTERED is not set, core initialization did not complete and CE pipes may remain uninitialized, making ath11k_core_deinit() unsafe. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 00402f4 ("ath11k: Add support for WCN6750 device") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260806101331.484063-3-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath11k_core_init() registers a PM notifier before the QMI server becomes available. If the QMI server never arrives, the device remove() path can take the early-exit path introduced for QMI initialization failures, skipping ath11k_core_deinit(). As a result, the PM notifier remains registered after the ath11k base object has been freed. A subsequent suspend or resume event may invoke the stale notifier and trigger a use-after-free. Fix this by explicitly unregistering the PM notifier in the QMI failure cleanup path before releasing ath11k resources. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 32d93b5 ("wifi: ath11k: choose default PM policy for hibernation") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260806101331.484063-4-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ximiali
force-pushed
the
resolute-qcom-devel
branch
from
October 15, 2026 06:38
b3cfa57 to
2b10559
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On WCN6750 platforms, reboot stress testing occasionally results in WLAN
initialization failures after boot. The WPSS firmware reaches the running
state successfully, but no WLAN interface is created.
Analysis shows that ath11k_ahb depends on the QRTR SMD transport for QMI
communication with WPSS firmware. However, this dependency is not
currently expressed in Kconfig, allowing qrtr_smd and ath11k_ahb to load
in either order when built as modules.
If ath11k_ahb is loaded before qrtr_smd becomes available, WLAN
initialization may not complete successfully.
Make the QRTR and QRTR_SMD dependencies explicit and add a soft
dependency to ensure qrtr_smd is loaded before ath11k_ahb.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1