Re: [PATCH v2 1/3] dt-bindings: sound: qcom,q6apm-dai: add stage-2 (SCM/VMID) access model
From: Ajay Kumar Nandam
Date: Wed Sep 02 2026 - 02:09:39 EST
On 8/27/2026 11:33 AM, Krzysztof Kozlowski wrote:
On 25/08/2026 20:40, Ajay Kumar Nandam wrote:
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.
Signed-off-by: Ajay Kumar Nandam <ajay.nandam@xxxxxxxxxxxxxxxx>
---
.../devicetree/bindings/sound/qcom,q6apm-dai.yaml | 72 +++++++++++++++++++++-
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
index 9e5b30d9c6e6..d9a6bc4a14f2 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
@@ -10,7 +10,15 @@ maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
description: |
- This binding describes the Qualcomm APM DAIs in DSP
+ This binding describes the Qualcomm APM DAIs in DSP.
+
+ The DSP that runs the APM must be able to reach the PCM buffers. On
+ existing targets the DSP runs in a stage-1 context and the buffers are
+ described to the SMMU via iommus. On targets whose APM DSP runs in a
+ stage-2 protected context that cannot use the SMMU, the buffers are
+ reachable only after hypervisor (SCM) memory assignment to the fixed
+ set of consumer VMIDs that own that protected context, described by
+ qcom,vmids. The two access models are mutually exclusive.
properties:
compatible:
@@ -20,9 +28,42 @@ properties:
minItems: 1
maxItems: 2
As I said last time, different hardware, different programming
interface, different features, so a different compatible.
The APM DAI block is the same packet format. The driver uses a single of_device_id entry with no match data; there is no code path dispatched by the compatible string.
The iommu vs VMID distinction is a property of the memory topology,
not the DAI hardware, and is already described by the mutually exclusive
iommus / qcom,vmids properties. The DSP identity (ADSP vs mDSP) is
carried by the GPR node's qcom,domain property and read at the send
layer — the DAI node itself does not need to know which DSP it talks to.
Happy to add a new compatible if there is a concrete functional
difference I'm missing.
+ memory-region:
+ description:
+ Reserved-memory carveouts (shared-dma-pool, no-map) that hold the
+ PCM buffers and must be SCM-assigned to the VMIDs in qcom,vmids.
+ The first entry is the control-path buffer; the second entry is
+ the data-path buffer. Only used together with qcom,vmids.
+ minItems: 1
+ maxItems: 2
List the items with description, isntead of free form text
items:
- description:
- description:
+
+ qcom,vmids:
+ description:
+ Virtual Machine IDs (VMIDs) of the processors that consume the PCM
+ buffers and therefore must be granted access through SCM memory
+ assignment. Required on targets whose APM DSP runs in a stage-2
+ protected context and cannot use the SMMU; mutually exclusive with
+ iommus. SCM assignment replaces the buffer's current owners with the
+ supplied set, so the driver always adds HLOS to the destination list
+ itself to retain host access; HLOS must not be listed here. All
+ listed VMIDs and HLOS receive read-write access.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ uniqueItems: true
+
required:
- compatible
- - iommus
+
+oneOf:
+ - required:
+ - iommus
+ - required:
+ - qcom,vmids
+
+dependentRequired:
+ memory-region:
+ - qcom,vmids
additionalProperties: false
@@ -32,3 +73,30 @@ examples:
compatible = "qcom,q6apm-dais";
iommus = <&apps_smmu 0x1801 0x0>;
};
+ - |
+ #include <dt-bindings/firmware/qcom,scm.h>
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ audio_heap_mem: audio-heap@a1000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0xa1000000 0x0 0x100000>;
+ no-map;
+ };
+
+ audio_mdsp_carveout_mem: audio-carveout@a1100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0xa1100000 0x0 0x400000>;
+ no-map;
+ };
+ };
Drop entire node, not really relevant.
ACK, will update in V3
Thanks & Regards
Ajay Kumar
+
+ dais {
+ compatible = "qcom,q6apm-dais";
+ /* index 0: control path, index 1: data path */
+ memory-region = <&audio_heap_mem>, <&audio_mdsp_carveout_mem>;
+ qcom,vmids = <QCOM_SCM_VMID_LPASS QCOM_SCM_VMID_MSS_MSA>;
+ };
Best regards,
Krzysztof