Re: [PATCH v4 1/3] ASoC: dt-bindings: support imx95's CM7 core

[Laurentiu Mihalcea <laurentiumihalcea111@gmail.com>]

On 2/13/2025 8:47 AM, Marco Felsch wrote:
> Hi Laurentiu, Daniel,
>
> On 25-02-12, Laurentiu Mihalcea wrote:
>> On 2/12/2025 2:38 PM, Mark Brown wrote:
>>> On Wed, Feb 12, 2025 at 12:11:49PM +0200, Daniel Baluta wrote:
>>>> On Wed, Feb 12, 2025 at 11:38 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>>>>> On 25-02-11, Laurentiu Mihalcea wrote:
>>>>>> +    const: fsl,imx95-cm7-sof
>>>>> Albeit Krzysztof already add his Reviewed-by, can I ask why we need to
>>>>> add the -sof suffix instead of -audio or so? SOF is a software project
>>>>> but you can clearly run different software on the audio-copro as well.
>>>> Sure you can run a different software project on the audio DSP but
>>>> you will need a way to distinguish between the different projects.
>>>> There might be different mailbox, memory configurations. So you will  need
>>>> to invent another suffix specific to the new project.
>>>> We can make  const: fsl,imx95-cm7-audio as the one used with SOF
>>>> and think about a different name later for when another project will
>>>> want to use the DSP.
>>> I think the point here was that the DT should stay the same even if the
>>> DSP firwmare changes, just as how changing the main OS shouldn't affect
>>> the DT.
>> It's rather unfortunate but based on the experience from the 8 series
>> (imx8qm, imx8qxp, imx8mp), the programming model can differ quite
>> a bit (e.g: remoteproc vs SOF) even if the core is the same (i.e: DSP core).
>>
>> The different programming models also required different DT configurations
>> (e.g: dif. mboxes as Daniel mentioned, some extra properties (i.e: reg-names), etc...)
>>
>> The "-sof" suffix was chosen here instead of the more generic "-audio" (or whatever else
>> alternative) because the DT configuration is specific to SOF's programming model. Other
>> audio applications running on the same core may have dif. configurations (e.g: use
>> DTCM/ITCM for memory instead of DDR, dif. mbox count, etc...). I suppose this kind of thing
>> is bound to happen to some degree since the DT node doesn't just describe the CM7 core
>> (but, rather, it also encompasses information on the memory, mboxes, etc. used)
>> but perhaps I'm wrong?
> Time will tell if there will be any other user except for SOF for the
> DSP but and this is what I wanted to point out: the DTS should abstract
> the HW. IMHO The CM7-Audio node should contain all properties required
> to turn power and reset the core (e.g. clocks, reset, pm-domains). I get
> your point regarding different configs but please have a look at
> mt8183-kukui.dtsi. Here the rpmsg config is a subnode of the actual
> system-control-proc. This makes much more sense to me since the HW part
> is part of the generic core-node and all the software config goes into a
> separate subnode.
>
> Regards,
>   Marco

I understand your point but we're dealing with 2 different programming
models here: SOF and remoteproc as opposed to just remoteproc as it's
the case for Mediatek.

Going for a similar approach would also mean quite a bit of software
changes as we'd need to factor out the common bits (most importantly here:
core operations like start/stop) and placing them in a common driver. This is not
trivial and I'm not sure it's worth the effort right now given that:

    1) The current way we model the hardware inside the DT is not exactly inaccurate.
    The core does physically use those memory regions, mailboxes, etc.

    2) Whatever we do, the information in the DT will still depend on the programming model.
    It's just that you're placing it in a child node, instead of the parent, which is arguably not that
    big of an improvement?