Shaikra audio support - #1749
Closed
mohsRafi wants to merge 91 commits into
Closed
Conversation
Add the Iris video codec device tree node for the Shikra platform. Shikra reuses the QCM2290-class video hardware and programming model. The video node is added to describe the Iris based video decoder encoder block, allowing the media driver to probe and initialize the hardware. Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Vishnu Reddy <[email protected]> Signed-off-by: Vikash Garodia <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Enable video en/decoder on the Shikra EVK board. Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Vishnu Reddy <[email protected]> Signed-off-by: Vikash Garodia <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…GMII clocks Add support for 2.5MHz and 25MHz GCC EMAC RGMII clock frequencies required for EMAC 10M and 100M speeds respectively on Qualcomm Shikra SoC. Tested-by: Mohd Ayaan Anwar <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Taniya Das <[email protected]> Signed-off-by: Imran Shaik <[email protected]> Link: https://lore.kernel.org/r/20260722-b4-shikra-gcc-emac-freqs-v2-1-2e480e2de8de@oss.qualcomm.com
SoC LPM stats are present in RPM MSGRAM and subsystem LPM stats are present in SMEM for Shikra. A generic "qcom,rpm-stats" compatible only reads SoC LPM stats like vmin and vlow. Document shikra rpm compatible to read subsystem LPM stats too along with SoC LPM stats. Reviewed-by: Maulik Shah <[email protected]> Signed-off-by: Sneh Mankad <[email protected]> Link: https://lore.kernel.org/r/[email protected]
SoC LPM stats are present in RPM MSGRAM and subsystem LPM stats are present in SMEM for Shikra. For earlier targets using RPM processor like msm8974, rpm_master_stat.c was used for subsystem LPM stats since those stats were populated in RPM MSGRAM. Here is a brief summary of previous targets and their stats configuration, along with the drivers used to display them. +---------------|----------------------------|---------------------------+ | SoC | subsystem LPM stats | SoC LPM stats | |---------------|----------------------------|---------------------------| | msm8974, | RPM processor MSGRAM | RPM processor MSGRAM | | msm8226 | (rpm_master_stat.c) | (qcom_stats.c) | |---------------|----------------------------|---------------------------| | sm6350, | SMEM (DDR) | AOP processor MSGRAM | | sdm845, etc. | (qcom_stats.c) | (qcom_stats.c) | |---------------|----------------------------|---------------------------| | Shikra | SMEM (DDR) | RPM processor MSGRAM | | | (qcom_stats.c) | (qcom_stats.c) | +---------------|----------------------------|---------------------------+ qcom_stats.c supports both the configurations for shikra, reading subsystem LPM stats from SMEM and reading SoC LPM stats from RPM MSGRAM. A generic "qcom,rpm-stats" compatible only reads SoC LPM stats like vmin and vlow. Add shikra rpm compatible and config to read subsystem LPM stats too along with SoC LPM stats. Below is an example showing LPM stats for "apss" subsystem with this change: cat /sys/kernel/debug/qcom_stats/apss Count: 2192 Last Entered At: 5498618336 Last Exited At: 5498708046 Accumulated Duration: 2046572620. Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Maulik Shah <[email protected]> Signed-off-by: Sneh Mankad <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…C specific A generic "qcom,rpm-stats" compatible only reads stats for SoC level LPM stats like vmin and vlow. Shikra SoC specific compatible allows reading individual subsystem level LPM stats along with SoC level LPM stats. Change it. Keep "qcom,rpm-stats" as fallback compatible. Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Sneh Mankad <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add support for the Qualcomm Shikra SoC to the protection domain mapper. All Shikra SoC variants (CQM, CQS, IQS) share the same protection domain requirements: mpss_wlan_pd. Signed-off-by: Anurag Pateriya <[email protected]>
…errupt routing The intr_target_width field sets the mask width used when writing target processor into interrupt config register and deciding which processor receives summary interrupt for a given GPIO. Without it, pinctrl driver defaults to a 3-bit mask. On Shikra, this field is 4 bits wide, which could corrupt adjacent bits and mis-route interrupts. Set intr_target_width = 4 to match the hardware. Fixes: 9db68ec ("pinctrl: qcom: Add Shikra pinctrl driver") Signed-off-by: Komal Bajaj <[email protected]> Link: https://lore.kernel.org/all/20260728-shikra-pinctrl-intr-width-v1-1-46583734d808@oss.qualcomm.com/
…new SoC strictness split Couple of already merged SoCs(like sc7280, sm8750, kaanapali etc.) describe ICE as single clock historically which are recently updated with mandatory 2 clocks. Keep only the known legacy compatibles flexible, and make strict validation default(of power-domains and 2 clocks) for all other Soc compatibles. This ensures old DTs are valid while ensuring any new SoC (like hawi, milos, eliza, nord, maili or any upcoming ones) must follow latest requirements by default. Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-1-06a4ea97c209@oss.qualcomm.com
…kra ICE Document the Inline Crypto Engine (ICE) on the Qualcomm Shikra platform. Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-2-06a4ea97c209@oss.qualcomm.com
Document shikra compatible for the True Random Number Generator. Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-3-06a4ea97c209@oss.qualcomm.com
…gine Document the crypto engine on the Qualcomm Shikra platform. Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-4-06a4ea97c209@oss.qualcomm.com
Qualcomm Shikra platform describes the BAM DMA node with 7 iommus entries. The current schema limit to 6, so update the binding to allow up to 7 entries. Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-5-06a4ea97c209@oss.qualcomm.com
Add device tree nodes describing the crypto hardware blocks present on the Qualcomm Shikra platform: - BAM DMA controller used by the Qualcomm crypto engine - QCE (crypto) engine with DMA support - TRNG hardware random number generator - Inline crypto engine (ICE) Also connect the SDHC controller to ICE via "qcom,ice" property to support inline encryption. On Shikra, different BAM pipe pairs (for example 0x84/0x94 and 0x86/0x96) may still resolve to the same resulting SID due SMMU-side optimization. They are still distinct pipe pairs and therefore require separate DT IOMMU entries. Signed-off-by: Kuldeep Singh <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20260714-b4-shikra_crypto_changse-v4-6-06a4ea97c209@oss.qualcomm.com
…tree The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM interrupt, which overrides the trigger type specified in the device tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt to the apps processor; registering it as level-high causes the interrupt to not fire, resulting in missed DMA completions. Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the trigger type already configured by platform_get_irq() when it parsed the device tree interrupts property. This makes the driver platform-agnostic. Fixes: e7c0fe2 ("dmaengine: add Qualcomm BAM dma driver") Co-developed-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Vishnu Santhosh <[email protected]> Link: https://lore.kernel.org/r/20260717-qcom-bam-dma-irq-trigger-v1-1-6405eac86f00@oss.qualcomm.com
Document the compatible of the Shikra PCIe phy which supports Gen2x1. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add a dedicated schema for the PCIe controller found on the Shikra platform. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add devicetree bindings for TC9563 GPIO's which are used to control endpoint power and reset. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add support for the single PCIe controller on Shikra platform which is capable of Gen2x1 operation. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Add QMP PCIe PHY Gen2x1 support. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…reset Some platform utilise TC9563 GPIOs to enable power and control reset of endpoints. This patch adds support to parse endpoint reset and power enable gpios from each TC9563 port node in the devicetree. To configure these GPIO's during the POWER ON sequence, two new API's are introduced: tc9563_ep_pwr_en() and tc9563_ep_assert_deassert_reset(). Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Commit 47b5ac7 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states: atomic_create_state, a dedicated hook that allocates and initializes a pristine state without any side effect. The bridge atomic_reset callback is already fallible and in practice only allocates and initializes state without touching hardware. However, the reset name does not make this contract clear: callers and implementers cannot tell from the name alone whether the hardware will be affected or when the hook is safe to call. Add an atomic_create_state callback to drm_bridge_funcs to make the contract explicit: allocate a pristine state, initialize it, no side effects. The core calls it when available, falling back to atomic_reset otherwise. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…e_state() The drm_atomic_helper_bridge_reset() helper is deprecated in favour of the new atomic_create_state callback. Add drm_atomic_helper_bridge_create_state() as the counterpart helper for this new callback, and make drm_atomic_helper_bridge_reset() call this new helper. Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Shikra supports single PCIe instance with 5GT/s x1 lane. Add PCIe controller and PHY node for this single instance. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…or PCIe Add a node for the TC9563 PCIe switch connected to PCIe. The switch has three downstream ports.Two embedded Ethernet devices are present on one of the downstream ports. All the ports present in the node represent the downstream ports and embedded endpoints. Power to the TC9563 is supplied through two LDO regulators, which are on by default and are added as fixed regulators. TC9563 can be configured through I2C. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
… node Enable the PCIe PHY for the single PCIe intance on the Shikra CQS, CQM and the IQS platforms. IQS platform uses a different powergrid than CQS/CQM which explain the different PHY supplies for IQS variant. Signed-off-by: Sushrut Shree Trivedi <[email protected]> Link: https://lore.kernel.org/r/[email protected]
…ompatible On platforms where the modem DMAs into the BAM-DMUX RX data buffers and the XPU enforces per-region access control, each individually DMA-mapped RX buffer consumes an XPU resource group. With only ~16 groups available, the per-buffer mappings exhaust the table and inbound transfers fault. Add qcom,shikra-bam-dmux as an additional compatible for the Shikra SoC, paired with the generic qcom,bam-dmux fallback, so the driver can match on it via its of_device_id table. Co-developed-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Vishnu Santhosh <[email protected]> Link: https://lore.kernel.org/r/20260714-qcom-bam-dmux-vmid-ext-v1-1-3f29da7cca76@oss.qualcomm.com
…rent block On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 / NAV) is the AXI master for BAM-DMUX RX transfers and the XPU enforces per-region access control, each individually DMA-mapped RX buffer requires its own XPU resource group (RG). With ~16 RGs available, the 32 per-buffer dma_map_single() calls exhaust the table and the first inbound transfer faults with an XPU violation. BAM-DMUX is a singleton (exactly one instance per SoC), so the destination VMID does not need to be a DT property; it is looked up from the compatible string's match data instead. Add struct bam_dmux_data with a single vmid field, and a shikra_data instance hardcoding QCOM_SCM_VMID_NAV for qcom,shikra-bam-dmux. When match data is present, allocate all BAM_DMUX_NUM_SKB RX buffers as a single contiguous dma_alloc_coherent() block and SCM-assign that block to HLOS plus the VMID once at probe. This reduces RG consumption from 32 to 1. The block is never reclaimed across a modem power cycle (bam_dmux_power_off() does not touch it), so the probe-time assignment covers every subsequent restart without re-assigning or reclaiming. It is reclaimed to HLOS only once, at remove or on a probe error, and if that reclaim fails it is leaked rather than returned to the page allocator. Each rx_skbs[] slot is pre-assigned its virtual and DMA address from the block, so no per-buffer mapping is needed at power-on. Because the coherent block is not page-backed, received payload is copied into a regular netdev skb before handoff to the network stack; this is an unavoidable extra copy on the XPU-enforced RX path. Platforms without match data are unaffected: rx_virt stays NULL, no coherent memory is allocated, and the per-buffer dma_map_single() path is unchanged. Co-developed-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Vishnu Santhosh <[email protected]> Link: https://lore.kernel.org/r/20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com
…erty A SoC can have multiple BAM DMA instances. Some of these BAMs are powered by a remote processor that enforces XPU (eXternal Protection Unit) access control and reads the per-channel descriptor FIFOs as an AXI master under that remote processor's execution environment, so their FIFOs must be accessible to the remote processor's VMID; other BAM instances on the same SoC are not behind such a remote processor and must not have this property set. Add an optional qcom,vmid property listing the destination VMID(s) that the affected BAM instance's descriptor FIFOs must be accessible to. HLOS is always the source owner and must not be listed. Co-developed-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Deepak Kumar Singh <[email protected]> Signed-off-by: Vishnu Santhosh <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]> Link: https://lore.kernel.org/r/20260714-qcom-bam-dma-vmid-ext-v1-1-cef87c57b7dc@oss.qualcomm.com
…remote VMID
On Qualcomm SoCs where the BAM is powered by a remote processor that
enforces XPU access control (e.g. the mDSP on Shikra, VMID 43 / NAV),
the BAM reads the descriptor FIFO as an AXI master under the remote
execution environment. Without an SCM grant for the remote VMID, the
first descriptor enqueue faults with an XPU violation.
Parse the optional qcom,vmid DT property as a list of destination
VMIDs. When present, SCM-assign each channel's descriptor FIFO to HLOS
plus the listed VMIDs; num_vmids being non-zero is derived purely from
qcom,vmid, a board-integration property, not from the per-SoC IP data,
and is distinct from qcom,powered-remotely.
A BAM with configured VMIDs has two properties that shape the channel
lifecycle:
1. The remote firmware owns the BAM's power and reset. It may remove
power during error recovery before the driver releases its
channels, so any pipe/block register access at teardown can raise
a synchronous external abort, and a local reset is redundant as
the remote re-initialises the hardware on the next power-on.
2. TZ does not revoke the SCM grant when the remote powers down. A
FIFO assigned once stays assigned across every power cycle, and
re-assigning or reclaiming it while the remote is mid-teardown is
rejected by TZ with -EINVAL.
Handle both by keeping the descriptor FIFO as a persistent resource on
such BAMs: allocate and SCM-assign it once on the first
bam_alloc_chan(), keep it (and its grant) across power cycles, and
reclaim it to HLOS and free it only once in bam_dma_remove(). If the
final reclaim fails the remote still has access, so the buffer is
leaked rather than returned to the page allocator; the source-VMID
bitmask stored by qcom_scm_assign_mem() drives that reclaim.
bam_free_chan() on such a BAM therefore only drops local channel state
(clear ->initialized, decrement active_channels) with no MMIO and no
SCM call, so the block and pipe are re-initialised on the next
power-on while power is present. The bam_chan_init_hw() pipe reset in
bam_dma_terminate_all() is likewise skipped. reclaiming the FIFO is an
SCM call, not a register access, so bam_dma_remove() stays safe.
Platforms that do not set qcom,vmid keep num_vmids 0, make no SCM
call, and leave the alloc/free and register-access paths unchanged.
Co-developed-by: Deepak Kumar Singh <[email protected]>
Signed-off-by: Deepak Kumar Singh <[email protected]>
Signed-off-by: Vishnu Santhosh <[email protected]>
Link: https://lore.kernel.org/r/20260714-qcom-bam-dma-vmid-ext-v1-2-cef87c57b7dc@oss.qualcomm.com
Provide the Shikra DMA-to-DAI mappings, DMA and SHRAM layout, clock names, DAI driver data and power-management hooks required by the QAIF driver. Add the Kconfig symbol and Makefile entries needed to build the new variant. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Harendra Gautam <[email protected]>
…tibles Add Shikra sound-card compatible strings to the Qualcomm sound card binding so DT can describe board-specific audio topologies: - qcom,shikra-cqm-sndcard - qcom,shikra-cqs-sndcard - qcom,shikra-iqs-sndcard Shikra EVK variants use different codec/interface combinations and DSP processing paths. Describing these variants explicitly in DT allows the machine driver to select the correct DAPM routes, controls, and clocking behavior for each board. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Mohammad Rafi Shaik <[email protected]> Signed-off-by: Ajay Kumar Nandam <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add machine-driver support for Qualcomm Shikra EVK variants by matching dedicated compatible strings and applying board-specific audio behavior. Shikra platforms are available as CQM, CQS, and IQS variants with different audio components and processing architectures: - CQM/CQS use an I2S-based path with WSA885x amplifiers and PM4125 + Rouleur codec components. - CQM runs in DSP-bypass mode, where the complete audio pipeline runs on CPU only and no DSP is involved. - CQS uses modem-DSP based audio processing. - IQS uses a third-party MAX98091 codec with modem-DSP support. Introduce variant-specific handling so codec controls, DAPM widgets, and clock programming match the board design and avoid invalid clock setup on variants where it is not applicable. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Mohammad Rafi Shaik <[email protected]> Signed-off-by: Ajay Kumar Nandam <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add bindings for Qualcomm shikra rx and va macro codec. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add shikra RX macro compatible data and hook it into the existing LPASS codec v4.0 flow. Map codec v4.0 to the 2.5+ RX register handling paths, and enable the FS counter bypass bit during MCLK enable when the platform requests LPASS_MACRO_FLAG_BYPASS_FS_CONTROL. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add shikra specific VA macro data and register programming needed by the LPASS codec v4.0 implementation. This adds a shikra regmap/default table covering the ADPT register range, wires new match data flags (bypass FS control and ADPT block presence), and enables the ADPT control programming path during TX decimator bring-up. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
…operty Add documentation for the qcom,swr-master-ee-val Device Tree property used by Qualcomm SoundWire masters to describe the execution-environment value for interrupt routing. This property allows platform DTs to specify the EE value used to direct SoundWire master interrupts to the appropriate CPU target. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
…tion Some Qualcomm SoundWire masters expose interrupt, FIFO and status registers in EE-specific register windows on v2.0 and newer hardware. Add support for selecting the SoundWire execution environment from DT and use it to program the correct register window for the active EE. The driver now reads the EE value from the new qcom,swr-master-ee-val property, with qcom,ee as a fallback for backward compatibility. For v2.0+ hardware, the IRQ/FIFO/status register layout is adjusted by the EE window stride so the driver programs the correct bank for the selected EE. The interrupt enable path is also updated to always use the selected EE window. This change allows SoundWire interrupt routing and register accesses to work correctly on platforms where the master is not mapped to the default EE1 window. In Shikra, the soundwire execution environment is set to 0 unlike other Qualcomm boards. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
…or shikra Add support for the modem_apps GLINK channel on Shikra, as audio processing is handled through the modem DSP. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add the QAIF CPU endpoint in shikra.dtsi so board files can connect LPASS front-end links to backend codecs. Describe the MMIO region, interrupt, IOMMU mapping and required clocks for the QAIF block. Keep the node disabled at SoC level; board dts files enable and consume it in subsequent patches. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Harendra Gautam <[email protected]> Signed-off-by: Harendra Gautam <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add GPR(Generic Pack router) node along with APM(Audio Process Manager) and PRM(Proxy resource Manager) audio services. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Pratyush Meduri <[email protected]> Signed-off-by: Pratyush Meduri <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Add SoC-level SoundWire masters and LPASS RX/VA macro nodes, along with DMIC and SWR pinctrl states required by the audio data path. Keep these nodes disabled in shikra.dtsi so board dts files can selectively enable and configure them. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Enable the sound card on the shikra-cqm-evk platform, including the PM4125 (Rouleur) headset codec, WSA885x external speaker path, and QAIF backend links. Also enable the required LPASS macro and SoundWire nodes, along with the necessary pinctrl configurations for DMIC and I2S interfaces. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Enable the sound card on the shikra-cqs-evk platform, including WSA885x external speaker path and DMIC via VA macro Also enable the required LPASS macro along with the necessary pinctrl configurations for DMIC and I2S interfaces. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Pratyush Meduri <[email protected]> Signed-off-by: Pratyush Meduri <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Enable the IQS EVK audio card using MAX98091 on I2S0 for primary playback/capture and VA DMIC capture through q6apm backend links. Add board clock and pinctrl states required for codec IRQ, external mclk and digital mic routing. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Ajay Kumar Nandam <[email protected]> Signed-off-by: Ajay Kumar Nandam <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Enable the QAIF CPU DAI and WSA885X I2C codec as modules in arm64 defconfig. These options are required to exercise the Shikra EVK audio paths enabled by the preceding DTS changes. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
Enable the Qualcomm PM4125 audio codec as a loadable module, as it is now required on the Shikra evk platform. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Mohammad Rafi Shaik <[email protected]>
…k IDs The QAIF clock IDs were introduced with a LAPSS prefix typo. Rename them to use the existing LPASS naming convention and update all corresponding in-tree users. Since these IDs are new, rename them directly instead of keeping backward-compatible aliases. Reported-by: Sashiko <[email protected]> Link: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: Prasad Kumpatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
q6apm_dai_prepare() and q6apm_dai_compr_set_params() build an AudioReach module config on the stack and populate only the fields needed for the stream type. Audio IF media-format setup treats zero slot_mask, nslots_per_frame and slot_width as a request to use the topology defaults. Leave those fields uninitialized and random stack data can override the topology values sent to the DSP. Initialize the whole config structure so omitted fields reliably retain their zero/default meaning. Reported-by: Sashiko <[email protected]> Link: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: Prasad Kumpatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
Treat -ENOENT from TDM slot parsing as the optional "configuration not present" case and continue to propagate real configuration errors. Also ignore -ENOTSUPP from optional DAI format and codec sysclk callbacks, apply codec_dai_fmt to codec DAIs on TDM links, and use a signed bclk_freq variable so errors from snd_soc_tdm_params_to_bclk() are handled correctly. Reported-by: Sashiko <[email protected]> Link: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: Prasad Kumpatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
… configuration qcom_snd_parse_dai_tdm_slots() uses -EINVAL for both missing DAI-link TDM configuration and malformed TDM slot properties. As a result, qcom_snd_apply_dai_tdm_slots() silently ignores configuration errors. Return -ENOENT for missing DAI-link configuration and preserve -EINVAL for malformed TDM slot properties. Reported-by: Sashiko <[email protected]> Link: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: Prasad Kumpatla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
…access model The APM DAIs expose PCM buffers that the backing DSP must be able to reach. On existing targets the DSP runs in a stage-1 context and the buffers are described to the SMMU via the iommus property. On platforms such as Qualcomm Shikra, where audio is served by the modem DSP (mDSP) rather than the ADSP, the DSP runs in a stage-2 protected context and cannot use the SMMU. The buffers are reachable only after hypervisor (SCM) memory assignment to the fixed set of consumer Virtual Machine IDs (VMIDs) that own that protected context. Describe those consumers with a new qcom,vmids property. The two access models are mutually exclusive: a node carries either iommus (stage-1/SMMU) or qcom,vmids (stage-2/SCM), expressed with a oneOf constraint. iommus is therefore no longer unconditionally required. SCM assignment replaces the buffer's current owners with the supplied destination set, so the driver always adds HLOS to that set itself to retain host access; HLOS must not be listed in qcom,vmids. When qcom,vmids is present the PCM buffers must reside in reserved-memory carveouts that are SCM-assigned to the consumer VMIDs. Add an optional memory-region property listing those carveouts. The first entry is the control-path buffer and subsequent entries are data-path buffers. memory-region is only meaningful alongside qcom,vmids, enforced via dependentRequired. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Ajay Kumar Nandam <[email protected]>
…SP buffers On platforms such as Qualcomm Shikra, audio is served by the modem DSP (mDSP) which runs in a stage-2 protected context. Unlike ADSP targets where SMMU-mapped system RAM is directly accessible, the mDSP cannot reach the PCM buffers unless they are explicitly SCM-assigned to the appropriate Virtual Machine IDs (VMIDs). Without this assignment, audio does not function on these platforms. Parse the qcom,vmids DT property and, when present, SCM-assign all memory regions to HLOS (retained as source owner, RW) plus the listed consumer VMIDs (all RW). The two access models are mutually exclusive: a node uses the SMMU path (iommus) or the SCM path (qcom,vmids), never both. Memory assignment follows the upstream pattern used by rmtfs_mem and qcom_q6v5_pas: reserved-memory carveouts are SCM-assigned once at probe() time and restored to HLOS-only ownership via devm_add_action_or_reset() at device removal. For the non-reserved-mem path (qcom,vmids without memory-region), the fixed DMA buffer is assigned at pcm_new() time since its address is only known after allocation. When memory-region is present (has_reserved_mem), the data-path carveout is attached as a DMA pool via of_reserved_mem_device_init_by_idx() and PCM buffers allocate directly from the carveout instead of system RAM. Buffer constraints are capped at reserved_buf_size and snd_pcm_set_managed_buffer_all() replaces snd_pcm_set_fixed_buffer_all(). All new code paths are gated on use_scm_assign (false when qcom,vmids is absent), ensuring existing ADSP/iommus targets are completely unaffected. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Mohit Sharma <[email protected]> Signed-off-by: Mohit Sharma <[email protected]> Signed-off-by: Ajay Kumar Nandam <[email protected]>
AudioReach builds APM and PRM command packets with the GPR destination domain hardcoded to GPR_DOMAIN_ID_ADSP. This assumes audio is always served by the ADSP, which is true for all currently supported targets. On platforms such as Qualcomm Shikra, audio is served by the modem DSP (mDSP) instead. The GPR node in DT already describes which DSP backs the service via its qcom,domain property (e.g. GPR_DOMAIN_ID_MODEM), and the GPR core exposes it as gdev->domain_id. But the AudioReach packet builders ignore this and always target the ADSP, so every APM/PRM command is routed to the wrong DSP on mDSP targets and audio does not function. Fix this by reading the GPR destination domain from gdev->domain_id and stamping it in the send helpers (q6apm_send_cmd_sync, audioreach_graph_send_cmd_sync, q6prm_send_cmd_sync) just before dispatch. This centralizes the domain decision at the send layer rather than threading it through every packet-allocation call site. For the small number of async data-path sends that bypass the sync helpers (write, read, compr, EOS), the domain is stamped inline before gpr_send_port_pkt(). When no domain is available the helper falls back to GPR_DOMAIN_ID_ADSP, so all existing ADSP targets remain unchanged. Link: https://lore.kernel.org/all/[email protected]/ Co-developed-by: Pratyush Meduri <[email protected]> Signed-off-by: Pratyush Meduri <[email protected]> Signed-off-by: Ajay Kumar Nandam <[email protected]>
…te APM DAIs memory regions Add a dedicated MDSP carveout memory region for audio usecases on Shikra and mark both existing audio heap and MDSP carveout regions as shared DMA pools. Update the Q6 APM DAI node to reference multiple memory regions, where index 0 is used for control path buffers and index 1 is used for MDSP data path buffers. This separation ensures proper memory allocation and access for APM communication between APSS and MDSP. Also add shared-dma-pool compatibility to the existing audio heap region to align with upstream DMA pool usage. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Ajay Kumar Nandam <[email protected]> Signed-off-by: Mohammad Rafi Shaik <[email protected]>
mohsRafi
force-pushed
the
Shaikra_audio_support
branch
from
August 26, 2026 05:03
6437ca4 to
52ddb09
Compare
Komal Bajaj (Komal-Bajaj)
force-pushed
the
tech/all/shikra
branch
3 times, most recently
from
August 26, 2026 13:54
2c70cbd to
3cb7372
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
16 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.
Add audio support for shikra. This PR will backport all changes from upstream.
CRs-Fixed: 4656876