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

Krzysztof Kozlowski <[email protected]>
Newsgroups gmane.linux.sound,gmane.linux.ports.arm.msm,gmane.linux.drivers.devicetree,gmane.linux.kernel
Message-ID <[email protected]>
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 <[email protected]>
> ---
>  .../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 <[email protected]>
>  
>  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.


>  
> +  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.

> +
> +    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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.