mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>,
	Srinivas Kandagatla <srini@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>
Cc: linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: sound: qcom,q6apm-dai: add stage-2 (SCM/VMID) access model
Date: Thu, 27 Aug 2026 08:03:24 +0200	[thread overview]
Message-ID: <006617c6-e3b0-4a3b-85e5-6b5af8f11879@kernel.org> (raw)
In-Reply-To: <20260826-a2a-shikra-vmid-v5-v2-1-c3dc62354eee@oss.qualcomm.com>

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.


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

  parent reply	other threads:[~2026-08-27  6:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25 18:40 [PATCH v2 0/3] ASoC: qcom: enable audio on stage-2 protected DSPs (mDSP) Ajay Kumar Nandam
2026-08-25 18:40 ` [PATCH v2 1/3] dt-bindings: sound: qcom,q6apm-dai: add stage-2 (SCM/VMID) access model Ajay Kumar Nandam
2026-08-26 22:44   ` Mark Brown
2026-08-27  6:03   ` Krzysztof Kozlowski [this message]
2026-08-25 18:40 ` [PATCH v2 2/3] ASoC: qcom: q6apm-dai: add VMID-based SCM assignment for mDSP buffers Ajay Kumar Nandam
2026-08-26 22:52   ` Mark Brown
2026-08-25 18:40 ` [PATCH v2 3/3] ASoC: qcom: qdsp6: generalize GPR service domain Ajay Kumar Nandam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=006617c6-e3b0-4a3b-85e5-6b5af8f11879@kernel.org \
    --to=krzk@kernel.org \
    --cc=ajay.nandam@oss.qualcomm.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=robh@kernel.org \
    --cc=srini@kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®