[PATCH v2 1/7] ASoC: dt-bindings: fsl_rpmsg: Add a property to assign the rpmsg channel

[Krzysztof Kozlowski]

On 23/09/2022 11:56, Chancel Liu wrote:
>>> Add a string property to assign the rpmsg channel this sound card sits
>>> on. It also represents the name of ASoC platform driver. This property
>>> can be omitted if there is only one sound card and it sits on
>>> "rpmsg-audio-channel".
>>>
>>> Signed-off-by: Chancel Liu <chancel.liu at nxp.com>
>>> ---
>>>  .../devicetree/bindings/sound/fsl,rpmsg.yaml  | 37 ++++++++++++++++++-
>>>  1 file changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
>> b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
>>> index d370c98a62c7..3744ae794c00 100644
>>> --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
>>> @@ -11,8 +11,11 @@ maintainers:
>>>
>>>  description: |
>>>    fsl_rpmsg is a virtual audio device. Mapping to real hardware devices
>>> -  are SAI, DMA controlled by Cortex M core. What we see from Linux
>>> -  side is a device which provides audio service by rpmsg channel.
>>> +  are SAI, MICFIL, DMA controlled by Cortex M core. What we see from
>>> +  Linux side is a device which provides audio service by rpmsg channel.
>>> +  We can create different sound cards which access different hardwares
>>> +  such as SAI, MICFIL, .etc through building rpmsg channels between
>>> +  Cortex-A and Cortex-M.
>>>
>>>  properties:
>>>    compatible:
>>> @@ -85,6 +88,17 @@ properties:
>>>        This is a boolean property. If present, the receiving function
>>>        will be enabled.
>>>
>>> +  fsl,rpmsg-channel-name:
>>> +    $ref: /schemas/types.yaml#/definitions/string
>>> +    description: |
>>> +      A string property to assign rpmsg channel this sound card sits on.
>>> +      It also represents the name of ASoC platform driver. This property
>>
>> That's a Linux detail which doesn't belong in DT.
>>
> 
> We pass hardware parameters in dts node to set up clocks or other
> configurations. These configurations are finally sent to Cortex-M by
> rpmsg channel because Cortex-M actually controls real hardware devices.
> If there's only one sound card sits on one rpmsg channel we will not
> need this property. But if there are several sound cards we need to
> specify correct rpmsg channel. Thus hardware configurations can be
> properly sent to Cortex-M. From this level to speak, this property is
> hardware-related since rpmsg channel represents the real hardware audio
> controller.
> 
> Here I attach the discussion in version 1 patches for your information:
> ---
> This property aims to tell the ASoC driver which rpmsg channel the
> sound card depends on. If there are several sound cards sit on rpmsg,
> we should pass correct information in dts node to specify the name of
> rpmsg channel. That is why I meant to add this property. 
> 
> Actually this property is hardware-related. As we discussed before,
> this kind of sound card based on rpmsg works under this mechanism
> Cortex-A core tells the Cortex-M core configuration of the PCM
> parameters then Cortex-M controls real hardware devices. This property
> specifying rpmsg channel represents the real hardware audio controller.
> ---
> 
> That's my idea adding this property. Do you have any suggstion?

I think you misunderstood the comment. Rob's comment was directly below
a line which he referred to. That line contained a statement referring
to Linux drivers. Anything related to Linux drivers does not belong to DT.


Best regards,
Krzysztof