Qcom 6.18.y#63
Open
hasiburr-qti wants to merge 46 commits into
Open
Conversation
Add dailinks for DISPLAY-PORT to enable audio functionality on edp0. Link: https://lore.kernel.org/all/ce8ca265-24df-41e5-a763-f9475de2fa9b@oss.qualcomm.com/ Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
…al board The Rb3Gen2 Industrial board has the Realtek RTL8221 PHY which fails to function correctly without the Realtek PHY driver. Remove CONFIG_REALTEK_PHY from prune.config to properly enable it. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@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. Link: https://lore.kernel.org/all/20260402081118.348071-12-srinivas.kandagatla@oss.qualcomm.com/ Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Karthik S <karthik.s@oss.qualcomm.com>
Enable secondary mi2s to support HDMI audio. Link: https://lore.kernel.org/all/20260413091937.134469-2-kumar.singh@oss.qualcomm.com/ Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com> Signed-off-by: Karthik S <karthik.s@oss.qualcomm.com>
Add new dai link to enable DP audio. Link: https://lore.kernel.org/all/20260413091937.134469-3-kumar.singh@oss.qualcomm.com/ Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com> Signed-off-by: Karthik S <karthik.s@oss.qualcomm.com>
…ver to support additional sampling rates Expand the existing constraints in the q6dsp-lpass-ports driver to allow a wider range of sampling rates, from 8000 Hz to 192000 Hz. This change improves compatibility with diverse audio hardware and provides greater flexibility for audio stream configurations. Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> Signed-off-by: Karthik S <karthik.s@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251210065157.2775514-2-ravi.hothi@oss.qualcomm.com/
…t 32-bit PCM format Expand the existing constraints by introducing support for the 32-bit PCM format (SNDRV_PCM_FMTBIT_S32_LE) alongside the existing 16-bit and 24-bit formats. This enhancement enables handling of high-resolution audio streams and improves audio quality for supported hardware. Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com> Signed-off-by: Karthik S <karthik.s@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251210065157.2775514-3-ravi.hothi@oss.qualcomm.com/
…for QPS615 Add an overlay devicetree to enable Rb3Gen2 industrial board's 4 ethernet ports provided by two QPS615 PCIe Ethernet switches. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
…emory pool The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Link: https://lore.kernel.org/all/20260407100508.1027-2-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…tion fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if any other thread removes the entry from list while unmap operation is ongoing. Remove the entry before calling unmap operation. Link: https://lore.kernel.org/all/20260409062617.1182-3-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
… in probe Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Allocate the entire Audio PD reserved-memory region upfront during rpmsg probe and tie its lifetime to the rpmsg channel. This avoids userspace- controlled alloc/free and ensures memory is reclaimed only when the DSP shuts down. Link: https://lore.kernel.org/all/20260409062617.1182-4-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing callers to avoid open-coded NULL checks. Link: https://lore.kernel.org/all/20260409062617.1182-5-jianping.li@oss.qualcomm.com/ Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…eset polarity Fix issues with the Monaco EVK IFP Mezz staging overlay for QPS615: 1) Setting the VendorDtbOverlays EFI variable to "staging" causes UEFI to fail the overlay application entirely. The staging overlay references &eeprom1, a label introduced by the ifp-mezzanine overlay. When overlays are stacked, ufdt does not propagate __symbols__ from previously applied overlays into the working DTB, so &eeprom1 cannot be resolved as a fixup target and the firmware aborts with FDT_ERR_NOTFOUND. Fix this by defining the eeprom node inline under &i2c15, which is present in the base DTB __symbols__. 2) The QCA8081 port does not come out of reset and is therefore never detected. The PHY reset line is declared GPIO_ACTIVE_HIGH, but the QCA8081 has an active-low reset input. With GPIO_ACTIVE_HIGH the driver's deassert call maps logical 0 to physical LOW, holding RESETN asserted throughout probe. Correct it to GPIO_ACTIVE_LOW. Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
… heap On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap" reserved-memory region overlaps with firmware allocations (UEFI/EFI runtime). The kernel then reports failure to reserve the region and subsequent EFI runtime activity may trigger aborts. The remote heap node was described as a fixed "no-map" region, which turns it into a hard carveout. Replace it with a "shared-dma-pool" reserved memory region with reusable CMA-backed allocation, specifying alignment and size. This avoids hard carveouts and reduces the chance of conflicting with firmware memory maps while keeping an explicit pool for ADSP remote heap usage. Link: https://lore.kernel.org/all/20260423063502.484-1-jianping.li@oss.qualcomm.com/ Fixes: 90a58ff ("arm64: dts: qcom: kodiak: Add memory region for audiopd") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Enable CONFIG_CONNECTOR and CONFIG_PROC_EVENTS to allow userspace to receive process lifecycle events (fork/exec/exit) via the proc connector over netlink. Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
FROMLIST: misc: fastrpc: Add missing bug fixes
…lcomm-linux#499) arm64: dts: qcom: sc7280: avoid EFI overlap for ADSP remote heap
This reverts commit 374c98d. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
…truct" This reverts commit 62babf2. The v13 version of this patch series introduced a regression in of_msi_xlate(). This patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
This reverts commit 7a3860c. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-1-fd02f11b6c38@oss.qualcomm.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [Conflict: irq-gic-its-msi-parent.c was refactored to split of_pmsi_get_msi_info() into of_pmsi_get_dev_id() and of_v5_pmsi_get_msi_info(); updated both of_map_id() calls.] Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Add an explicit filter_np parameter to of_map_id() and of_map_msi_id() to separate the filter input from the output. Previously, the target parameter served dual purpose: as an input filter (if non-NULL, only match entries targeting that node) and as an output (receiving the matched node with a reference held). Now filter_np is the explicit input filter and arg->np is the pure output. Previously, of_map_id() would call of_node_put() on the matched node when a filter was provided, making reference ownership inconsistent. Remove this internal of_node_put() call so that of_map_id() now always transfers ownership of the matched node reference to the caller via arg->np. Callers are now consistently responsible for releasing this reference with of_node_put(arg->np) when done. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-2-fd02f11b6c38@oss.qualcomm.com/ Acked-by: Frank Li <Frank.Li@nxp.com> Suggested-by: Rob Herring (Arm) <robh@kernel.org> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> [Conflict: irq-gic-its-msi-parent.c was refactored to split of_pmsi_get_msi_info() into of_pmsi_get_dev_id() and of_v5_pmsi_get_msi_info(); updated both of_map_id() calls.] Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use in being able to map at least single
input IDs to multi-cell output specifiers (and properly support 0-cell
outputs as well), add support for properly parsing and using the target
nodes' #cells values, albeit with the unfortunate complication of still
having to work around expectations of the old behaviour too.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-3-fd02f11b6c38@oss.qualcomm.com/
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
…I-RX is used as MSI controller"" Commit bf62c12 ("Revert "FROMLIST: PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is used as MSI controller"") was applied due to excessive AER logging and functional breakage after INTx fallback. The AER issue is now mitigated by disabling L0s, so restore the original behavior and remove MSI/MSI-X capabilities from Root Ports using iMSI-RX. This reverts commit bf62c12 ("Revert "FROMLIST: PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is used as MSI controller""). Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Commit f5cd8a9 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") removed MSI/MSI-X capabilities from the Root Port on platforms using iMSI-RX (including SA8775P, which has no msi-parent/msi-map in DT). This causes PME and AER service drivers to fall back from MSI to INTx. There are lot of AER's seen after this change, the reason for this AER's can be board specific, and recently discovered refgen voting required by phy driver. [ 13.069528] pcieport 0000:00:00.0: PME: Signaling with IRQ 332 [ 13.082436] pcieport 0000:00:00.0: AER: enabled with IRQ 332 [ 13.082447] pcieport 0000:00:00.0: AER: Correctable error message received from 0000:01:00.0 [ 13.101347] pci 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) [ 13.111281] pci 0000:01:00.0: device [17cb:1103] error status/mask=00001000/0000e000 [ 13.111284] pci 0000:01:00.0: [12] Timeout [ 13.111313] pcieport 0000:00:00.0: AER: Multiple Correctable error message received from 0000:01:00.0 [ 13.130512] pcieport 0000:00:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) [ 13.130514] pcieport 0000:00:00.0: device [17cb:0115] error status/mask=00001000/0000e000 [ 13.130516] pcieport 0000:00:00.0: [12] Timeout Fix this temporarly on SA8775P/Lemans platform by adding no_l0s = true to cfg_1_34_0 for SA8775P, so that PCI_EXP_LNKCAP_ASPM_L0S is cleared from the Root Port and ASPM L0s is prevented from being negotiated. Fixes: f5cd8a9 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") Assisted-by: Claude:claude-4-6-sonnet Link: https://lore.kernel.org/all/20260419093934.1223027-1-shengchao.guo@oss.qualcomm.com/ Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
…nux#474) ASoC: qcom: q6apm-lpass-dai: move graph start to trigger
…ux#462) arm64: dts: qcom: lemans: Enable audio over DisplayPort
…rity (qualcomm-linux#501) arm64: dts: qcom: monaco-evk: fix overlay stacking and PHY reset polarity
Disable L0s to fix wlan functionality
…m-linux#507) of/irq: Fix MSI map walk regression and NULL deref in of_msi…
…linux#511) arm64: configs: qcom.config: Enable CONNECTOR, PROC_EVENTS
qualcomm-linux#488) arm64: dts: qcom: rb3gen2-industrial-mezzanine: add overlay for QPS615
…ualcomm-linux#466) prune.config: Enable Realtek PHY config for Rb3Gen2 Industrial board
PCIe-to-USB bridge UPD720201 does not advertise D3cold support until firmware is loaded post pci enumeration. This results in upd blocking D3cold entry during system suspend and causing overall failure to enter XO shutdown. Hence, add a quirk to advertise D3cold PME capability since the HW actually supports and advertises it post firmware loading. Link: https://lore.kernel.org/all/20260430-d3cold_support-v1-1-6734f280c481@oss.qualcomm.com/ Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
When other drivers attempt I2C transfers during early resume phase, the I2C controller is still runtime suspended, causing pm_runtime_get_sync() to fail with -EACCES (-13): [ 101.914202] geni_i2c 980000.i2c: error turning SE resources:-13 The PM runtime core returns -EACCES when runtime PM is disabled (dev->power.disable_depth > 0). This occurs because: 1. During suspend_noirq, I2C driver calls geni_i2c_runtime_suspend() and then pm_runtime_disable() 2. I2C driver's noirq_resume only marks adapter as resumed but doesn't re-enable runtime PM or power up the hardware 3. Other drivers resuming later attempt I2C transfers 4. pm_runtime_get_sync() returns -EACCES because runtime PM is still disabled Fix this by calling pm_runtime_force_resume() in geni_i2c_resume_noirq() to properly resume the hardware and re-enable runtime PM during the noirq phase. This ensures the I2C controller is powered and ready for use when other drivers need it during resume. Upstream-Status: Pending Signed-off-by: Viken Dadhaniya <viken.dadhaniya@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 preseve 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/all/20260407-d3cold-v4-5-bb171f75b465@oss.qualcomm.com/ Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…need pwrctrl
pci_pwrctrl_is_required() is used to detect whether a device really
needs the PCI pwrctrl support or not. It is currently used in
pci_pwrctrl_create_device(), but not in pci_pwrctrl_power_{on/off}_device()
APIs. This leads to pwrctrl core trying to power on/off the incompatible
devices like USB hub downstream ports defined in DT.
Hence, add this check to prevent pwrctrl core from poking at wrong
devices. For this purpose, move the pci_pwrctrl_is_required() helper
definition to the top.
Link: https://lore.kernel.org/linux-pci/20260421104102.12322-1-manivannan.sadhasivam@oss.qualcomm.com/
Fixes: b35cf3b ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices")
Reported-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
PCI: qcom: Add D3cold support
…rl (qualcomm-linux#480) PCI/pwrctrl: Do not try to power on/off devices that don't need pwrctrl
…x#483) i2c: qcom-geni: Fix -EACCES error during system resume
…x#525) pci: quirks: Advertise D3cold capability for UPD720201
Add support for the Qualcomm SA8775P SoC to the protection domain mapper. SA8775P share the same protection domain configuration as SC8280XP with an additional gpdsp domain, except for charger_pd. Add an entry to the kernel, to avoid the need for userspace to provide this service. Link: https://lore.kernel.org/all/20260209112947.930853-2-mohammad.rafi.shaik@oss.qualcomm.com/ Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Add support for the Qualcomm QCS8300 SoC to the protection domain mapper. QCS8300 share the same protection domain configuration as SC8280XP, except charger_pd. Add an entry to the kernel, to avoid the need for userspace to provide this service. Link: https://lore.kernel.org/all/20260209112947.930853-3-mohammad.rafi.shaik@oss.qualcomm.com/ Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Lemans monaco audio pd mapper support
Signed-off-by: Hasibur Rahman Mohammed <hasiburr@qti.qualcomm.com>
PR #63 — validate-patchPR: #63
|
PR #63 — checker-log-analyzerPR: #63
Detailed report:
|
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
17 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.
No description provided.