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