QCLINUX: arm64: configs: qcom: enable core crypto hash and SHA-256 op… - #901
Open
Sasi Kumar Maddineni (sasikuma-qti) wants to merge 365 commits into
Open
QCLINUX: arm64: configs: qcom: enable core crypto hash and SHA-256 op…#901Sasi Kumar Maddineni (sasikuma-qti) wants to merge 365 commits into
Sasi Kumar Maddineni (sasikuma-qti) wants to merge 365 commits into
Conversation
The Shikra EVK boards have an RGMII TI PHY connected to the dual EMACs of the SoC. Remove its config from prune.config to enable its driver. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Enable the extensible scheduling class (SCX) which allows BPF-based scheduling policies. Also enable its cgroup dependencies: - CONFIG_SCHED_CLASS_EXT=y -- core sched_ext class BTF support (DEBUG_INFO_BTF, DEBUG_INFO_BTF_MODULES) is enabled which is required by SCHED_CLASS_EXT and also needed for BPF CO-RE and kernel module BTF. Signed-off-by: Ashay Jaiswal <ashay.jaiswal@oss.qualcomm.com>
…a SoC Enable the video, camera and gpu clock controllers for their respective functionalities on the Qualcomm Eliza boards. Link: https://lore.kernel.org/r/20260317-eliza_mm_clock_controllers_v1-v1-7-4696eeda8cfb@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Enable CONFIG_DMA_CMA as a dependency to allow the DMA-BUF heap configs (DMABUF_HEAPS, DMABUF_HEAPS_CMA, DMABUF_HEAPS_SYSTEM) to be selected in qcom.config. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add support for SYSTEM_RESET2 vendor-specific resets as reboot-modes in the psci node. Describe the resets: "bootloader" will cause device to reboot and stop in the bootloader's fastboot mode. "edl" will cause device to reboot into "emergency download mode", which permits loading images via the Firehose protocol. Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-11-46e085bca4cc@oss.qualcomm.com Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies. Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module. The module provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Link: https://lore.kernel.org/all/20251113130519.2647081-1-wei.deng@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…upport Add binding for the Lontium LT9211C bridge chip. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-1-9c63bb035c17@oss.qualcomm.com/
Currently edid_read has value from previous connect session and resulting in drm using older edid before new edid is available in lt9611uxc. Reset edid_read so that correct status is updated and correct edid is available for drm. Link: https://lore.kernel.org/lkml/20260202-lt9611uxc-reset-edid-v2-1-b1e1d72edc90@oss.qualcomm.com/ Signed-off-by: Ravi Agola <raviagol@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
If HPD IRQ is enabled in the display_connector's probe, it can be triggered too early, before the DRM connector is completely setup. Use the enable_hpd / disable_hpd callbacks to control enablement of the HPD IRQ. Fixes: 0c275c3 ("drm/bridge: Add bridge driver for display connectors") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-1-786044cedc17@oss.qualcomm.com/
…r DP If the DisplayPort drivers use display-connector for the HPD detection, the internal HPD state machine might be not active and thus the hardware might be not able to handle cable detection correctly. Instead it will depend on the externall HPD notifications to set the cable state, bypassing the internal HPD state machine (for example this is the case for the msm DP driver). However if the cable has been plugged before the HPD IRQ has been enabled, there will be no HPD event coming. The drivers might fail detection in such a case. Trigger the HPD notification after enabling the HPD IRQ, propagating the cable insertion state. Fixes: 2e2bf3a ("drm/bridge: display-connector: add DP support") Reported-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-2-786044cedc17@oss.qualcomm.com/
…Glymur The existing DP PHY PLL and AUX configuration for the Glymur platform does not fully follow the Hardware Programming Guide requirements for DP over Type-C, which results in DP link bring-up failures. Update the DP PHY programming sequence and PLL-related register settings to align with the latest HPG recommendations. With this change, DP link training completes successfully on Glymur-based platforms. Fixes: d10736d ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms") Link: https://lore.kernel.org/r/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
LT9211c is a Single/Dual-Link DSI/LVDS or Single DPI input to Single-link/Dual-Link DSI/LVDS or Single DPI output bridge chip. Extend the existing lontium-lt9211 driver to support DSI-to-LVDS bridge configuration. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link:https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-2-9c63bb035c17@oss.qualcomm.com/
QCC2072's rx_mpdu_start TLV has a different field layout from QCN9274. Reusing struct rx_mpdu_start_qcn9274 in hal_rx_desc_qcc2072 causes the RX datapath to read the wrong offsets for info2, info4, pn[] and phy_ppdu_id, producing corrupted sequence number, PN, ppdu_id and mpdu-info flags (encrypted, fragment, addr2/addr4 valid). Add a dedicated struct rx_mpdu_start_qcc2072 that matches the actual hardware descriptor layout, and use it in hal_rx_desc_qcc2072. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00188-QCACOLSWPL_V1_TO_SILICONZ-1 Fixes: 28badc7 ("wifi: ath12k: add HAL descriptor and ops for QCC2072") Link: https://lore.kernel.org/linux-wireless/20260629061529.1993932-1-wei.zhang@oss.qualcomm.com/ Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
…ntation Add QCOM System Control Management Interface (SCMI) Generic Vendor Extensions Protocol documentation. It exposes Qualcomm SoC-specific features through (algorithm string, param_id) pairs carried over a small set of generic SET/GET/START/STOP commands, alongside the standard PROTOCOL_VERSION / _ATTRIBUTES / _MESSAGE_ATTRIBUTES handshake required by the Arm SCMI specification. Document the protocol so that drivers targeting it have a stable reference for command ids, payload layouts and status code semantics. The first algorithm covered is MEMLAT (memory latency governor), including its memory-group model (DDR, LLCC, DDR_QOS), event-map programming and per- monitor frequency voting tables. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Co-developed-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-1-f3f68c608f25@oss.qualcomm.com/
…sion Protocol Add the binding schema for the Qualcomm SCMI Generic Extension Protocol which helps support Bus DVFS on Glymur/Mahua/Hamoa/Purwa SoCs. Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-2-f3f68c608f25@oss.qualcomm.com/
The QCOM SCMI Generic Extensions Protocol provides a generic way of exposing a number of Qualcomm SoC specific features (like memory bus scaling) through a mixture of pre-determined algorithm strings and param_id pairs hosted on the SCMI controller. Co-developed-by: Amir Vajid <amir.vajid@oss.qualcomm.com> Signed-off-by: Amir Vajid <amir.vajid@oss.qualcomm.com> Co-developed-by: Ramakrishna Gottimukkula <ramakrishna.gottimukkula@oss.qualcomm.com> Signed-off-by: Ramakrishna Gottimukkula <ramakrishna.gottimukkula@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-3-f3f68c608f25@oss.qualcomm.com/
The target_freq sysfs attribute exposes a governor's predicted next target frequency. Not every devfreq governor has a meaningful value to report there; some merely observe an externally-driven device. Add a DEVFREQ_GOV_ATTR_TARGET_FREQ attribute flag that governors with a meaningful target frequency must opt in to. Gate the existing target_freq sysfs read on the flag and return -EINVAL when the active governor does not advertise it. Tag all in-tree governors that already populate previous_freq via get_target_freq() so visible behaviour stays unchanged for in-tree users. Out-of-tree governors that drive frequency updates and want to keep target_freq readable need to set the new flag. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-4-f3f68c608f25@oss.qualcomm.com/
Some devfreq governors need to track frequency changes performed on remote devices rather than driving the frequency updates themselves. In such cases, the device's frequency is already updated by an external entity and devfreq only needs to keep its transition statistics and notifier subscribers in sync. Add a new DEVFREQ_GOV_FLAG_TRACK_REMOTE governor flag. When set, devfreq_set_target() skips the profile->target() update sequence but still emits the DEVFREQ_PRECHANGE/DEVFREQ_POSTCHANGE notification pair and the devfreq_frequency trace event, so transition-notifier subscribers (passive governor, devfreq cooling, etc.) and tracing observe the remote frequency change exactly as they would on the normal path, and the transition statistics are refreshed. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-5-f3f68c608f25@oss.qualcomm.com/
…quencies On SoCs where the governor and the mechanism to control the frequency for devices like caches is hosted on the System Control Processor (SCP), there exists a need to track the frequency changes in a reliable way and provide ways to tweak parameters on the remote governor. Add a new "remote" devfreq governor that uses the track_remote flag to expose the remote device's frequency to userspace via trans_stat. The governor deliberately does not advertise the DEVFREQ_GOV_ATTR_TARGET_FREQ attribute since the kernel cannot set the frequency on a remote-managed device; reads of the target_freq sysfs node therefore return -EINVAL. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-6-f3f68c608f25@oss.qualcomm.com/
On Qualcomm Glymur, Mahua and X1E/X1P (Hamoa) SoCs, the memlat governor and the mechanism to control the various caches and RAM is hosted on the CPU Control Processor (CPUCP), and configuration and control of this governor is exposed through the QCOM SCMI Generic Extension Protocol, addressed via the "MEMLAT" algorithm string. Introduce a devfreq SCMI client driver that uses the MEMLAT algorithm string to detect memory-latency-bound workloads and control the frequency/level of the memory buses (DDR, LLCC and DDR_QOS). Model each bus as a devfreq device using the remote devfreq governor. This provides basic insight into device operation via trans_stat and allows further tuning of the remote governor's parameters from userspace. Co-developed-by: Amir Vajid <amir.vajid@oss.qualcomm.com> Signed-off-by: Amir Vajid <amir.vajid@oss.qualcomm.com> Co-developed-by: Ramakrishna Gottimukkula <ramakrishna.gottimukkula@oss.qualcomm.com> Signed-off-by: Ramakrishna Gottimukkula <ramakrishna.gottimukkula@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Co-developed-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260610-rfc_v7_scmi_memlat-v7-7-f3f68c608f25@oss.qualcomm.com/
The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs in a bifurcated configuration. Each PHY has its own power domain (phy_gdsc) that must be powered on before initialization per hardware requirements. Current PHY power management assumes a single power domain per PHY, preventing proper setup for this dual-PHY scenario. Add support for multiple power domains by using devm_pm_domain_attach_list() to attach power domains manually, while maintaining compatibility with single power domain PHYs. Enable runtime PM to allow power domain control when the PCIe driver calls phy_power_on/phy_power_off: - Single power domain: QMP PHY platform device directly attaches to power domain and controls it during runtime resume/suspend - Multiple power domains: devm_pm_domain_attach_list() creates virtual devices as power domain suppliers, linked to the QMP PHY platform device as consumer This ensures power domains are properly attached and turned on/off for both single and multiple power domain configurations. Link: https://lore.kernel.org/all/20260304-glymur_gen5x8_phy-v1-2-849e9a72e125@oss.qualcomm.com/ Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Refactor nocsr reset handling to support multiple nocsr resets required for PHY configurations with bifurcated operation modes. The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs in bifurcation, where each PHY requires its own nocsr reset to be controlled simultaneously. The current implementation only supports a single nocsr reset per PHY configuration. Add num_nocsr and nocsr_list fields to struct qmp_phy_cfg to represent the number and names of a group of nocsr reset names. Initialize these fields for all PHYs that have nocsr resets, allowing the driver to correctly acquire multiple nocsr resets during probe and control them as an array by using reset_control_bulk APIs. The refactoring maintains backward compatibility for existing single nocsr reset configurations while enabling support for multi-PHY scenarios like Glymur's 8-lane bifurcation mode. Additionally, introduces x1e80100_qmp_gen3x2_pciephy_cfg as a separate configuration from sm8550_qmp_gen3x2_pciephy_cfg since the x1e80100 Gen3x2 PHY requires nocsr reset support while the sm8550 Gen3x2 PHY does not. Link: https://lore.kernel.org/all/20260304-glymur_gen5x8_phy-v1-3-849e9a72e125@oss.qualcomm.com/ Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
The third PCIe controller on Glymur SoC supports 8-lane operation via
bifurcation of two PHYs (each requires separate power domian, resets and
aux clk).
Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
clock ("phy_b_aux") required for 8-lane operation. Introduce new
glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
Link: https://lore.kernel.org/all/20260304-glymur_gen5x8_phy-v1-4-849e9a72e125@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
…es for Glymur The PCIe QMP PHYs on Glymur require stable reference voltage provided by refgen and reference clk provided by qref. The refgen and qref requires power supplies. Add support for vdda-refgen0p9, vdda-refgen1p2 and vdda-qref2 supplies in sm8550_qmp_phy_vreg_l list. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
A race condition is occasionally observed on the RB8 platform where the APPS processor removes its turbo vote from the LCX and LMX rails immediately after receiving the handover interrupt from firmware. At that moment, the ADSP firmware vote has not yet been applied to these rails, causing the PMIC shut down and leading the device to hang. Keep the vote of lcx and lmx rails to SVS_L1 from APPS side instead of completely removing it as a WA until actual fix is available. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…oth USB and UART On Hamoa boards, a single M.2 slot may host either a UART-based or a USB-based Bluetooth device. As a result, the UART controller node is always present in DT, while the USB path is hot-pluggable. When Bluetooth operates over USB, the presence of the UART DT node still causes the hci_qca UART driver to probe. During probe or power sequencing, the driver may deassert BT_EN, cutting power to the shared Bluetooth device and disconnecting the USB interface. Model BT_EN as an always-on fixed regulator so it cannot be toggled by the UART probe. This prevents the UART driver from interfering with Bluetooth operation when the device is connected over USB. Workaround will be reverted once the M.2 solutionis available upstream. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
…nable GPIO If a Bluetooth consumer device does not have a bt-enable GPIO configured in the power sequencer (for example, when BT_EN is tied high via a hardware pull-up and therefore absent from the DT), the power sequencer should not match the device. In this case, the Bluetooth consumer driver will fall back to its legacy power control path and correctly set power_ctrl_enabled to false. Bluetooth device nodes are conventionally named "bluetooth" in the device tree, so use of_node_name_eq() as a generic check instead of enumerating specific compatible strings. Workaround will be reverted once the M.2 solution is available upstream. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
Bootup crash seen on kaanapali-mtp board. [ 8.114249][ C0] [drm:dpu_encoder_frame_done_timeout:2731] [dpu error]enc33 frame done timeout [ 8.116480][ T284] Unable to handle kernel paging request at virtual address ffff800080e5e000 [ 8.116488][ T284] Mem abort info: [ 8.116492][ T284] ESR = 0x0000000096000007 [ 8.116497][ T284] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.116502][ T284] SET = 0, FnV = 0 [ 8.116507][ T284] EA = 0, S1PTW = 0 [ 8.116511][ T284] FSC = 0x07: level 3 translation fault [ 8.116516][ T284] Data abort info: [ 8.116519][ T284] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 8.116524][ T284] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.116529][ T284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.116535][ T284] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000009bf36c000 [ 8.116541][ T284] [ffff800080e5e000] pgd=0000000000000000, p4d=1000000880346403, pud=1000000880347403, pmd=1000000881e2d403, pte=0000000000000000 [ 8.116567][ T284] Internal error: Oops: 0000000096000007 [qualcomm-linux#1] SMP Revert the change for now to unblock. This reverts commit b0907ee. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
…oth USB and UART On Purwa boards, a single M.2 slot may host either a UART-based or a USB-based Bluetooth device. As a result, the UART controller node is always present in DT, while the USB path is hot-pluggable. When Bluetooth operates over USB, the presence of the UART DT node still causes the hci_qca UART driver to probe. During probe or power sequencing, the driver may deassert BT_EN, cutting power to the shared Bluetooth device and disconnecting the USB interface. Model BT_EN as an always-on fixed regulator so it cannot be toggled by the UART probe. This prevents the UART driver from interfering with Bluetooth operation when the device is connected over USB. Workaround will be reverted once the M.2 solutionis available upstream. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…es for Monaco The PCIe QMP PHYs on Monaco (QCS8300) require stable reference voltage provided by refgen and reference clock provided by qref. The refgen and qref require power supplies. Add a new sa8775p_qmp_phy_vreg_l list with vdda-qref and vdda-refgen supplies, and use it for qcs8300_qmp_gen4x2, sa8775p_qmp_gen4x2 and sa8775p_qmp_gen4x4 PCIe PHY configurations. Workaround will be reverted once the vote qref regulator for PCIe available in upstream. Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Enable CONFIG_ZRAM_BACKEND_LZ4 to allow use of LZ4 compression for zram. LZ4 offers low latency and reduced CPU overhead, making it well-suited for embedded systems. Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
Set the deferred probe timeout to 60 seconds in the Qualcomm config fragment.With the kernel default of 10s ,we are observing probe deferrals on Qualcomm platforms where supplier drivers (e.g. regulators, clocks) are probing late; 60s gives sufficient margin without waiting indefinitely. Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com>
Add configs for ATH11K/ATH12K debug/coredump/tracing, CMA debug, pstore/EFI vars, ftrace extensions (dynamic ftrace with args/call-ops/ direct-calls, hwlat/timerlat/sched tracers, snapshot), lockup detectors, lock debugging (spinlock, rwsems, list), DMABUF sysfs stats, WQ watchdog, PM debug, and various other debug instrumentation. These configs are already part of QLI.1.0. Adding them to QLI.2.0 and QLI mainline. Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com>
Enable the IXGBE and IXGBEVF drivers to support the Intel X550 T2 NIC on QLI boards with SR-IOV support. Signed-off-by: Hariprasad kelam <kelam@qti.qualcomm.com>
The Shikra EVK boards have an RGMII TI PHY connected to the dual EMACs of the SoC. Remove its config from prune.config to enable its driver. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Enable the extensible scheduling class (SCX) which allows BPF-based scheduling policies. Also enable its cgroup dependencies: - CONFIG_SCHED_CLASS_EXT=y -- core sched_ext class BTF support (DEBUG_INFO_BTF, DEBUG_INFO_BTF_MODULES) is enabled which is required by SCHED_CLASS_EXT and also needed for BPF CO-RE and kernel module BTF. Signed-off-by: Ashay Jaiswal <ashay.jaiswal@oss.qualcomm.com>
…a SoC Enable the video, camera and gpu clock controllers for their respective functionalities on the Qualcomm Eliza boards. Link: https://lore.kernel.org/r/20260317-eliza_mm_clock_controllers_v1-v1-7-4696eeda8cfb@oss.qualcomm.com Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Enable CONFIG_DMA_CMA as a dependency to allow the DMA-BUF heap configs (DMABUF_HEAPS, DMABUF_HEAPS_CMA, DMABUF_HEAPS_SYSTEM) to be selected in qcom.config. Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
This reverts commit 2549688. These changes are superseded by the BCL v2 patch series. Signed-off-by: Dipa Ramesh Mantre <dipa.mantre@oss.qualcomm.com>
Enable Qualcomm pmic BCL driver config. Signed-off-by: Dipa Ramesh Mantre <dipa.mantre@oss.qualcomm.com>
Enable CONFIG_XDP_SOCKETS to support AF_XDP zero-copy networking on Qualcomm platforms. AF_XDP provides a high-performance path for packet processing by allowing XDP programs to redirect frames directly to userspace via shared memory rings, bypassing the normal kernel network stack. Signed-off-by: Rajkumar Patel <patel.rajkumar@oss.qualcomm.com>
…emory and SMMU mappings" This change have introduced an issue on multimedia builds where AudioRecord is broken on monaco-evk board. [ 153.325884] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 19 [ 153.335982] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on SEC_MI2S_TX [ 153.348489] MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture [ 153.357875] MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed Revert the change for now, to fix the issue. This reverts commit cd0f5c6. Signed-off-by: Salendarsingh Gaud <sgaud@qti.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 d8a14b9 30 tech/bsp/devfreq 5a26797 7 tech/bsp/soc-infra ff6ff7b 22 tech/bsp/pinctrl 79149ef 1 tech/bsp/remoteproc cbd11fb 10 tech/bus/peripherals fedd8c6 6 tech/bus/pci/all ebd808f 4 tech/bus/pci/phy 1f1f4b6 7 tech/bus/usb/dwc 9dd47ad 3 tech/bus/usb/phy c3aa7d5 35 tech/debug/hwtracing d9accac 22 tech/pmic/misc 6fb618c 8 tech/mem/iommu 44df12a 8 tech/mm/audio/all 88b8f29 8 tech/mm/camss c394dfb 32 tech/mm/drm 1d1d827 64 tech/mm/fastrpc e014e35 11 tech/mm/video 590953d 36 tech/mm/gpu 0b8d9f4 7 tech/net/ath 638841e 16 tech/pm/power bb88701 13 tech/pm/thermal d36b3ee 7 tech/security/crypto c36112e 14 tech/security/ice beabac0 9 tech/storage/all d86d915 4 tech/all/dt/qcs6490 db0d97d 20 tech/all/dt/qcs9100 166356c 88 tech/all/dt/qcs8300 cd0f5c6 22 tech/all/dt/qcs615 9a58c35 9 tech/all/dt/agatti c828f10 1 tech/all/dt/hamoa fa16fdb 36 tech/all/dt/glymur aba48bf 39 tech/all/dt/kaanapali c637991 19 tech/all/dt/pakala 960924d 13 tech/all/config 044539b 69 tech/overlay/dt 6a1064f 77 tech/all/workaround 2a67b15 26 tech/mproc/all 104969c 2 tech/noup/debug/all cbdd4bb 26 tech/hwe/unoq a2d85fe 4 early/hwe/shikra/drivers 46a583d 161 early/hwe/shikra/dt e6da759 122
On Glymur, there is an issue while working with the FP sensor connected to USB Hs only controller. The issue is as follows: 1) During boot, the usb controller initialises fine, but an error stating that the descriptor read from FP sensor failed and hence the controller is in an unknown state with failed enumeration of FP sensor. 2) At this point, the problem may be resource voting, but if unbind and rebind is done on the controller, enumeration is fine. All resources were thorughly checked and also schematic was checked to ensure that no GPIOs (if any) are left un-initialised. But resources seem to be fine. 3) When in this state, if we try to enter system suspend, GDSC too gets off, and also on resume we see that usb controller goes dead. And further attempts to enter suspend are gated by this dead controller. 4) If we re-bind controller on boot and then let enumration be successful, and then enter suspend, we see a SMMU crash on resume. On upstream code however, enumeration is fine on every reboot. This suspend-resume behavior is gating XO SD and hence disable it on CRD. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Signed-off-by: Pratham Pratap <pratham.pratap@oss.qualcomm.com>
…ng system resume On Glymur, display NoC errors are observed during system resume when MDSS register accesses occur before the MMCX/Display NoC path has scaled back to a voltage level sufficient for the required bandwidth. Keep the display clock controller's power-domain requirement at the turbo operating point as a temporary workaround to ensure the interconnect remains at a stable performance level during the resume sequence and avoid NoC errors triggered by early MDSS register access. Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
Enabling QSEECOM on Glymur CRD as below parameter is added in cmdline After the QSEECOM driver is enabled, the LoaderTpm2ActivePcrBanks UEFI variable is visible to userspace on Glymur platforms. This makes systemd wait for /dev/tpm0 during boot, but the secure TPM device is not yet enabled on Glymur. The missing TPM device adds a 90-second boot delay. Set `systemd.tpm2_wait=false` on the command line so systemd does not wait for a TPM device that is not currently available. This is a temporary change and is expected to be reverted by the end of September 2026, once the secure TPM is fully enabled on Glymur. This reverts commit e1374ed. Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Add support for the contiguous hint (CONT) bit in ARM LPAE page tables.
When a set of consecutive PTEs map a naturally-aligned contiguous block
of memory, the CONT bit can be set on all entries in the group to allow
the hardware to combine them into a single TLB entry, improving TLB
utilization.
The contiguous hint sizes per granule are:
Page Size | CONT PTE | Block | CONT Block | L1 Block | CONT L1
----------+----------+---------+------------+----------+---------
4K | 64K | 2M | 32M | 1G | 16G
16K | 2M | 32M | 1G | |
64K | 2M | 512M | 16G | |
Contiguous hint sizes are advertised in pgsize_bitmap so that IOMMU API
users can align allocations to these sizes and benefit from the TLB
optimization automatically.
Partial unmaps of a contiguous group are rejected, ensuring the full
group is always invalidated as a unit. The
IO_PGTABLE_QUIRK_ARM_NO_CONT_HINT quirk allows SMMU drivers to disable
contiguous hint support at runtime for hardware with
implementation-specific errata.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Co-developed-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260722-iommu_contig_hint-v3-1-10923a683441@oss.qualcomm.com/
…nule issue Qualcomm SMMU-500 has an issue with TLBIVA/TLBIVAL where only the base-page-size entry at the base IOVA is invalidated, leaving stale TLB entries for the rest of the range. This causes use-after-free: after dma_free_coherent() unmaps a large buffer, the device can still access freed physical memory through stale TLB entries. On FastRPC workloads this manifests as ADSP crashes when the ELF loader writes to a freed PA that has been reallocated. Force the TLB invalidation step granule to the minimum page size for all Qualcomm SMMU-500 domains, ensuring each page in the range is individually invalidated. The minimum page size from pgsize_bitmap is used rather than hardcoded 4K to correctly handle 16K and 64K granule configurations. This increases the number of TLB invalidation operations for large ranges, but correctness takes precedence. Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
…omain When the remoteproc has an IOMMU (kernel running at EL2 without a separate hypervisor), memory carveouts must be explicitly mapped into the remoteproc's IOMMU domain so the DSP can access them. Without this mapping the DSP triggers an SMMU translation fault when accessing the remote heap carveout used for audio PD static process creation. Add has_iommu to fastrpc_channel_ctx, set from the "iommus" property of the remoteproc DT node. When set, map the ADSP remote heap carveout into the remoteproc's IOMMU domain using an identity mapping (IOVA == PA) via iommu_map(), and skip qcom_scm_assign_mem() which is only needed when a separate hypervisor manages inter-VM memory access control. Introduce fastrpc_remote_heap_map() and fastrpc_remote_heap_unmap() helpers to encapsulate the IOMMU domain lookup and map/unmap. Link: https://lore.kernel.org/all/20260618-audio_fix_clean_v3-v1-1-ec1ee66fe455@oss.qualcomm.com/ Signed-off-by: Anandu Krishnan E <anandu.e@oss.qualcomm.com>
…ling support The Qualcomm Crypto Engine (QCE) driver currently lacks support for runtime power management (PM) and interconnect bandwidth control. As a result, the hardware remains fully powered and clocks stay enabled even when the device is idle. Additionally, static interconnect bandwidth votes are held indefinitely, preventing the system from reclaiming unused bandwidth. Address this by enabling runtime PM and dynamic interconnect bandwidth scaling to allow the system to suspend the device when idle and scale interconnect usage based on actual demand. Improve overall system efficiency by reducing power usage and optimizing interconnect resource allocation. Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com> Tested-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260517105233.807935-1-udit.tiwari@oss.qualcomm.com
Enable CONFIG_HOTPLUG_PCI_PCIE to support native PCIe hotplug controllers on arm64 platforms. Link: https://lore.kernel.org/r/20260728-hotplug_pci-v1-1-d1f38cfb9122@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…latforms Commit eb3b5bf ("PCI: Whitelist native hotplug ports for runtime D3"), prevented native Hotplug capable Root Ports from entering D3 citing issues on old Intel SkyLake Xeon-SP platform. But there is no reason to restrict D3 for native Hotplug capable Root Ports on DT platforms. We recently enabled D3 on non-Hotplug capable Root Ports on non-x86 platforms (specifically for DT platforms) in commit a5fb3ff ("PCI: Allow PCI bridges to go to D3Hot on all non-x86"). So do the same for native Hotplug capable Root Ports as well. To honor the above platform_pci_bridge_d3() check, allow passing this check only for DT platforms, unlike a5fb3ff, which used !CONFIG_X86 check. Link: https://lore.kernel.org/all/20260729071514.859778-1-manivannan.sadhasivam@oss.qualcomm.com/ Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…tions Enable the required crypto core options so dependent features like dmverity can select and use them. Signed-off-by: Sasi Kumar Maddineni <sasikuma@qti.qualcomm.com>
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
2 similar comments
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next
branch
from
August 12, 2026 05:18
8d5dbc1 to
49dbe0d
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.
Enable the required crypto core options so dependent features like dmverity can select and use them.
Fixes: https://github.com/qualcomm-linux/meta-qcom-distro/issues/377