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

[Krzysztof Kozlowski]

On 03/09/2026 11:39, Krzysztof Kozlowski wrote:
> 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@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.
> 
> 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.


Additionally, as explained to me in off-list channel, the qcom,vmids is
not a hardware property at all (because hardware is the same), thus does
not look suitable for DT.

Best regards,
Krzysztof