Re: [PATCH v2 1/3] dt-bindings: sound: qcom,q6apm-dai: add stage-2 (SCM/VMID) access model

[Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>   .../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@linaro.org>
>>   
>>   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