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

[Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>]

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