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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 02/09/2026 08:07, Ajay Kumar Nandam wrote:
> 
> 
> 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.

I am still trying to grasp it. You have a device "APM" and it accesses
PCM buffers or other memory in some way needing IOMMU for that.

Now you add something which you call EXACTLY the same device, no
difference at all, same "APM", but this time this device operates
completely different, because it does not use IOMMU, but talks with
firmware via SCM.

Well, I really do not see how is this still exactly the same or even
compatible device.

The way device accesses its data is part of the programming model and
different programming models have different compatibles.

Best regards,
Krzysztof