Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

[Andrew Davis]

On 10/4/24 6:26 AM, Nishanth Menon wrote:
> On 16:06-20241003, Bryan Brattlof wrote:
> > Hi Andrew!
> >
> > On October  3, 2024 thus sayeth Andrew Davis:
> > > From: Hari Nagalla <hnagalla@xxxxxx>
> > >
> > > The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
> > > domain. This core can be used by non safety applications as a remote
> > > processor. When used as a remote processor with virtio/rpmessage IPC,
> > > two carveout reserved memory nodes are needed. The first region is used
> > > as a DMA pool for the rproc device, and the second region will furnish
> > > the static carveout regions for the firmware memory.
> > >
> > > The current carveout addresses and sizes are defined statically for
> > > each rproc device. The M4F processor does not have an MMU, and as such
> > > requires the exact memory used by the firmware to be set-aside.
> > >
> > > Signed-off-by: Hari Nagalla <hnagalla@xxxxxx>
> > > Signed-off-by: Andrew Davis <afd@xxxxxx>
> > > ---
> > >   .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
> > >   1 file changed, 19 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> > > index 44ff67b6bf1e4..6957b3e44c82f 100644
> > > --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> > > +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> > > @@ -56,6 +56,18 @@ linux,cma {
> > >   			linux,cma-default;
> > >   		};
> > >   
> > > +		mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x00 0x9cb00000 0x00 0x100000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		mcu_m4fss_memory_region: m4f-memory@9cc00000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x00 0x9cc00000 0x00 0xe00000>;
> > > +			no-map;
> > > +		};
> > > +
> >
> > The only issue I have here is this takes away memory from people who do
> > not use these firmware or causes them to work around this patch if they
> > choose to have different carveouts.
>
> They can define their own overlays.
>
> > Would an overlay be appropriate for this?
>
> Why is this any different from existing boards? Are you suggesting a
> change for all existing boards as well?

Yes, I believe that is what is being suggested, and I agree with it.
It would also help with all these non-SK boards we now have, they
would simply apply the same overlay when using the firmware that
requires these carveouts.

I've been thinking on doing that for a while, but I wanted to keep
the same pattern just for this one last series. Then we can attempt
to refactor next.

Andrew