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

[Ajay Kumar Nandam]

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

I understand the concern. The qcom,vmids property describes which 
Virtual machines the SoC firmware has configured to own the memory space 
on a given board. similar to how iommus describes which SMMU the device 
is wired to.

There is existing precedent for this in the tree:

- fastrpc (Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml) 
uses qcom,vmids to describe remote processor VMIDs. The driver reads 
them from DT and calls qcom_scm_assign_mem(). The compatible stays 
generic (qcom,fastrpc).

- rmtfs-mem 
(Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml) 
uses qcom,vmid the same way with a single generic compatible 
(qcom,rmtfs-mem).

We are following the same pattern here. Happy to discuss further if you 
see a difference between these cases and ours.

Thanks & Regards
Ajay Kumar Nandam
> Best regards,
> Krzysztof