Prepare qcom-next based on tag 'Linux 7.1-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#593
Open
sgaud-quic wants to merge 834 commits into
Conversation
Enable video codec on Talos in the EL2 configuration and describe the firmware IOMMU mapping using the iommu-map property. Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Previously, the driver skipped putting the link into L2/device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the host bridge may enter D3cold. So, replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_can_enter_d3cold() helper to decide whether the DesignWare host bridge can safely transition to D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-2-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…host bridges Add a common helper, pci_host_common_can_enter_d3cold(), to determine whether a PCI host bridge can safely transition to D3cold. The helper walks all devices on the bridge's bus and only allows the host bridge to enter D3cold if all PCIe endpoints are already in PCI_D3hot. For devices that may wake the system, it additionally requires that the device supports PME wakeup from D3cold(with WAKE#). Devices without wakeup enabled are not restricted by this check and can be allowed to keep device in D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-1-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Add pme_turn_off() support and use DWC common suspend resume methods for device D3cold entry & exit. If the device is not kept in D3cold use existing methods like keeping icc votes, opp votes etc.. intact. In qcom_pcie_deinit_2_7_0(), explicitly disable PCIe clocks and resets in the controller. Remove suspended flag from qcom_pcie structure as it is no longer needed. Link: https://lore.kernel.org/r/20260128-d3cold-v1-3-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Currently, the driver expects the devices to remain in D0 across system suspend, but the genpd framework may still power down the associated GDSC during suspend. When that happens, the PCIe link goes down and cannot be recovered on resume. Prevent genpd from turning off the PCIe GDSC by using dev_pm_genpd_rpm_always_on() so that the power domain stays on while the controller is suspended. This preserves the link state across suspend/resume and avoids unrecoverable link failures. Fixes: 82a8238 ("PCI: qcom: Add Qualcomm PCIe controller driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260128-genpd_fix-v1-1-cd45a249d12f@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm(), which retrieves the LTSSM state from the PARF_LTSSM register instead. Link: https://lore.kernel.org/r/20260217-d3cold-v2-3-89b322864043@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…vice context during suspend Currently, the PCI endpoint drivers like NVMe checks whether the device context will be retained or not during system suspend, with the help of pm_suspend_via_firmware() API. But it is possible that the device context might be lost due to some platform limitation as well. Having those checks in the endpoint drivers will not scale and will cause a lot of code duplication. So introduce an API that acts as a sole point of truth that the endpoint drivers can rely on to check whether they can expect the device context to be retained or not. If the API returns 'false', then the client drivers need to prepare for context loss by performing actions such as resetting the device, saving the context, shutting it down etc... If it returns 'true', then the drivers do not need to perform any special action and can leave the device in active state. Right now, this API only incorporates the pm_suspend_via_firmware() check. But will be extended in the future commits. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-1-adbb4555b5ab@oss.qualcomm.com
…sume from system suspend The PCIe spec v7.0, sec 5.5.3.3.1, states that for exiting L1.2 due to an endpoint asserting CLKREQ# signal, the refclk must be turned on no earlier than TL10_REFCLK_ON, and within the latency advertised in the LTR message. This same behavior applies to L1.1 as well. On some platforms like Qcom, these requirements are satisfied during OS runtime, but not while resuming from the system suspend. This happens because the PCIe RC driver may remove all resource votes and turns off the PHY during suspend to maximize power savings while keeping the link in L1ss. Consequently, when the endpoint asserts CLKREQ# to wake up, the OS must first resume and the RC driver must restore the PHY and enable the refclk. This recovery process exceeds the L1ss exit latency time. And this latency violation results in an L1ss exit timeout, followed by Link Down (LDn). If the endpoint device is used to host the RootFS, it will result in an OS crash. For other endpoints, it may result in a complete device reset/recovery. So to indicate this platform limitation to the client drivers, introduce a new flag 'pci_host_bridge::broken_l1ss_resume' and check it in the pci_dev_suspend_retention_supported() API. If the flag is set by the RC driver, the API will return 'false' indicating the client drivers that the device context may not be retained and the drivers must be prepared for context loss. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-2-adbb4555b5ab@oss.qualcomm.com
…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. (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). This latency violation leads to an L1ss exit timeout, followed by a Link Down (LDn) condition 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> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-3-adbb4555b5ab@oss.qualcomm.com
…ing suspend The pci_dev_suspend_retention_supported() API lets PCI client drivers know if the platform can retain the device context during suspend. This is decided based on several factors like: 1. Firmware involvement at the end of suspend 2. Any platform limitation in waking from low power state (L1ss) And this API might also get extended in the future to cover other platform specific issues impacting the device low power mode during system suspend. So use this API instead of checks like pm_suspend_via_firmware(). When this API returns false, then assume that the platform cannot retain the context and shutdown the controller. If it returns true, then assume that the context will be retained and keep the device in low power mode. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-4-adbb4555b5ab@oss.qualcomm.com
…d eligibility Add a common helper, pci_host_common_d3cold_possible(), to determine whether PCIe devices under host bridge can safely transition to D3cold. This helper is intended to be used by PCI host controller drivers to decide whether they may safely put the host bridge into D3cold based on the power state and wakeup capabilities of downstream endpoints. The helper walks all devices on the all bridge buses and only allows the devices to enter D3cold if all PCIe endpoints are already in PCI_D3hot. This ensures that we do not power off the host bridge while any active endpoint still requires the link to remain powered. For devices that may wake the system, the helper additionally requires that the device supports PME wake from D3cold (via WAKE#). Devices that do not have wakeup enabled are not restricted by this check and do not block the devices under host bridge from entering D3cold. Devices without a bound driver and with PCI not enabled via sysfs are treated as inactive and therefore do not prevent the devices under host bridge from entering D3cold. This allows controllers to power down more aggressively when there are no actively managed endpoints. Some devices (e.g. M.2 without auxiliary power) lose PME detection when main power is removed. Even if such devices advertise PME-from-D3cold capability, entering D3cold may break wakeup. So, return PME-from-D3cold capability via an output parameter so PCIe controller drivers can apply platform-specific handling to preserve wakeup functionality. Link: https://lore.kernel.org/r/20260429-d3cold-v5-1-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm() to retrieve the LTSSM state. For newer platforms, the LTSSM state is read from the PARF_LTSSM register, while older platforms continue to retrieve it from ELBI_SYS_STTS. This helper is used in place of direct DBI-based link state checks in the D3cold path after sending PME turn-off message, ensuring the LTSSM state can be queried safely even after DBI access is no longer valid. Link: https://lore.kernel.org/r/20260429-d3cold-v5-2-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…g rails/clocks Some Qcom PCIe controller variants bring the PHY out of test power-down (PHY_TEST_PWR_DOWN) during init. When the link is later transitioned towards D3cold and the driver disables PCIe clocks and/or regulators without explicitly re-asserting PHY_TEST_PWR_DOWN, the PHY can remain partially powered, leading to avoidable power leakage. Update the init-path comments to reflect that PARF_PHY_CTRL is used to power the PHY on. Also, for controller revisions that enable PHY power in init (2.3.2, 2.3.3, 2.4.0, 2.7.0 and 2.9.0), explicitly power the PHY down via PARF_PHY_CTRL in the deinit path before disabling clocks or regulators. This ensures the PHY is put into a defined low-power state prior to removing its supplies, preventing leakage when entering D3cold. Link: https://lore.kernel.org/r/20260429-d3cold-v5-3-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Previously, the driver skipped putting the link into L2/device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the devices under host bridge may enter D3cold. So, replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_d3cold_possible() helper to decide whether the devices under host bridge can safely transition to D3cold. In addition, propagate PME-from-D3cold capability information from the helper and record it in skip_pwrctrl_off. Some devices (e.g. M.2 cards without auxiliary power) may lose PME detection when main power is removed, even if they advertise PME-from-D3cold support. This allows controller power-off to be skipped when required to preserve wakeup functionality. Update the suspended flag in dw_pcie_resume_noirq() only after the PCIe link resumes successfully, to avoid marking the controller active when link resume fails. Link: https://lore.kernel.org/r/20260429-d3cold-v5-4-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Add support for transitioning PCIe endpoints under host bridge into D3cold by integrating with the DWC core suspend/resume helpers. Implement PME_TurnOff message generation via ELBI_SYS_CTRL and hook it into the DWC host operations so the controller follows the standard PME_TurnOff-based power-down sequence before entering D3cold. When the device is suspended into D3cold, fully tear down interconnect bandwidth, OPP votes. If D3cold is not entered, retain existing behavior by keeping the required interconnect and OPP votes. Use dw_pcie::skip_pwrctrl_off to avoid powering off devices during suspend to preserve wakeup capability of the devices and also not to power on the devices in the init path. Drop the qcom_pcie::suspended flag and rely on the existing dw_pcie::suspended state, which now drives both the power-management flow and the interconnect/OPP handling. Link: https://lore.kernel.org/r/20260429-d3cold-v5-5-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Add the DCC register capture list for the Shikra platform (SoC IDs 756, 758, 759) across two linked lists and move the configuration into a dedicated header qcom-dcc-shikra-config.h. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
In A8xx, the RSCC block is part of GPU's register space. Update the virtual base address of rscc to point to the correct address. Link: https://lore.kernel.org/all/20260512-glymur-gpu-dt-v3-1-84232dc21c03@oss.qualcomm.com/ Fixes: 50e8a55 ("drm/msm/a8xx: Add support for A8x GMU") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Adreno X2-185 GPU found in Glymur chipsets belongs to the A8x family. It features a new slice architecture with 4 slices, significantly higher bandwidth throughput compared to mobile counterparts, raytracing support, and the highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other improvements. Update the dt bindings documentation to describe this GPU. Link: https://lore.kernel.org/all/20260513-glymur-gpu-dt-v4-2-f83832c3bc9a@oss.qualcomm.com/ Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
…U SMMU Add interconnects property to the common SMMU properties and extend the sm8750 clock description section to also cover Glymur since it uses the same single "hlos" vote clock. Link: https://lore.kernel.org/all/20260513-glymur-gpu-dt-v4-3-f83832c3bc9a@oss.qualcomm.com/ Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
…ap_attach() Commit c7d8100 introduced a brace-less if that skips the dma_buf_map_attachment_unlocked() call when sess->coherent is true, leaving 'table' uninitialized. The unconditional IS_ERR(table) check that follows does not catch NULL, so execution continues with a NULL sg_table, causing a level-0 translation fault when the sgl pointer is dereferenced. Remove the guard; the mapping is always needed to obtain DMA addresses consumed by the rest of the function. Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
…-reg The pm4125 PMIC uses a different USB VBUS register layout than pm8150b. It uses a 2-bit VBOOST voltage selector supporting output voltages of 4.25 V, 4.5 V, 4.75 V and 5.0 V, instead of a current-limit selector. Move qcom,pm4125-vbus-reg from the pm8150b fallback items list into the standalone enum since the driver handles it with its own match-data and register layout. Make regulator-min/max-microamp conditional so they are only required for current-limit variants (pm8150b, pm6150, pm7250b, pmi632). Add an if/then condition for qcom,pm4125-vbus-reg requiring regulator-min/ max-microvolt instead, and update the pm4125 example accordingly. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
The PM4125 PMIC uses a different register layout for USB VBUS control compared to PM8150B. On PM4125, CMD_OTG is at offset 0x50, OTG_CFG is at 0x56, and offset 0x52 is a 2-bit VBOOST voltage selector rather than a current-limit selector. Introduce per-compatible regulator descriptor data to accommodate these differences. This keeps the existing PM8150B current-limit logic intact while adding a dedicated voltage-selector path for PM4125. Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Document shikra compatible for the True Random Number Generator. Link: https://lore.kernel.org/lkml/20260514-shikra_rng-v1-1-4ea721a1429a@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
…ngine Document the crypto engine on the Shikra platform. Link:https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-1-80f07b345c29@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Shikra bam dma engine support seven iommu entries. Increase maxItems property for iommus to pass dtbs_check errors. Link: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-2-80f07b345c29@oss.qualcomm.com/ Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Document the Inline Crypto Engine (ICE) on the Shikra platform. Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
…sent Some clock controller descriptors do not provide any reset lines. Avoid registering a reset controller when desc->num_resets is zero by making the registration conditional. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Some Qualcomm clock controller descriptors may contain NULL entries in the clk_hws array. Skip such entries when registering clock hardware to avoid passing NULL pointers to the clock framework. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Add GCC LPASS clocks support for Qualcomm Shikra SoC. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
The GCC LPASS clocks must be enabled to access audio core clock controller registers. Hence, mark them as critical on Qualcomm Shikra SoCs. Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/kaanapali.dtsi
# Conflicts: # drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
# Conflicts: # Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml # drivers/remoteproc/qcom_q6v5_pas.c # drivers/soc/qcom/smem.c
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
sgaud-quic
force-pushed
the
qcom-next-staging-7.1-rc4-20260519
branch
from
d1beae3 to
62f1b08
Compare
Test Matrix
|
1 similar comment
Test Matrix
|
Test Matrix
|
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.
Name SHA Commits
tech/bsp/clk eea3e98 11
tech/bsp/devfreq a0c2f21 6
tech/bsp/ec 643c24b 2
tech/bsp/soc-infra 20c09ce 3
tech/bsp/pinctrl 3f1acf8 1
tech/bsp/remoteproc a7b9b6d 10
tech/bus/peripherals 287f0f5 8
tech/bus/pci/all c266573 14
tech/bus/pci/phy aaf8ef1 4
tech/bus/usb/dwc 49ac8e0 2
tech/bus/usb/phy 8c7f91d 35
tech/debug/hwtracing 25c6a74 30
tech/pmic/misc eee20da 1
tech/mem/iommu 1fa98cb 5
tech/mm/audio/all cab3357 10
tech/mm/camss 147ae87 28
tech/mm/drm 2fbdd74 60
tech/mm/fastrpc e0ba718 9
tech/mm/phy 56ccbf4 1
tech/mm/video 8bbe314 36
tech/mm/gpu 8a269bc 3
tech/net/ath 3623de0 13
tech/net/phy a3602e9 1
tech/net/bluetooth 9cca493 2
tech/pm/power 2d42c35 9
tech/pm/thermal 90f2db5 5
tech/security/crypto f030676 14
tech/security/ice 1564b82 25
tech/security/optee cee615a 21
tech/storage/phy cf1667f 1
tech/storage/all e254dae 1
tech/all/dt/qcs6490 5828ac7 17
tech/all/dt/qcs9100 8a00fd7 17
tech/all/dt/qcs8300 ffd35fe 16
tech/all/dt/qcs615 9e2f111 9
tech/all/dt/agatti c828f10 1
tech/all/dt/hamoa 670d002 29
tech/all/dt/glymur bd03470 27
tech/all/dt/kaanapali 7436a08 9
tech/all/dt/pakala 705ac54 6
tech/all/config ff67f6a 61
tech/overlay/dt c6232b6 46
tech/all/workaround d15f5a1 15
tech/mproc/all 0aa90b7 3
tech/noup/debug/all d2b684d 25
tech/hwe/unoq b2ea57b 5
early/hwe/shikra/drivers 3aa65ff 84
early/hwe/shikra/dt 919fd6c 61