Re: [PATCH v7 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors

[Judith Mendez <jm@ti.com>]

Hi Bryan,

On 4/21/25 11:26 AM, Bryan Brattlof wrote:
> On April 21, 2025 thus sayeth Nishanth Menon:
>> On 10:04-20250419, Bryan Brattlof wrote:
>>> On April 15, 2025 thus sayeth Judith Mendez:
>>>> From: Devarsh Thakkar <devarsht@ti.com>
>>>>
>>>> For each remote proc, reserve memory for IPC and bind the mailbox
>>>> assignments. Two memory regions are reserved for each remote processor.
>>>> The first region of 1MB of memory is used for Vring shared buffers
>>>> and the second region is used as external memory to the remote processor
>>>> for the resource table and for tracebuffer allocations.
>>>>
>>>> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
>>>> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> Acked-by: Andrew Davis <afd@ti.com>
>>>> Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
>>>> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
>>>> ---
>>>>   arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 96 +++++++++++++++++++++++--
>>>>   1 file changed, 90 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> index 1c9d95696c839..7d817b447c1d0 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -52,6 +52,42 @@ linux,cma {
>>>>   			linux,cma-default;
>>>>   		};
>>>>   
>>>> +		c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
>>>> +			compatible = "shared-dma-pool";
>>>> +			reg = <0x00 0x99800000 0x00 0x100000>;
>>>> +			no-map;
>>>> +		};
>>>> +
>>>> +		c7x_0_memory_region: c7x-memory@99900000 {
>>>> +			compatible = "shared-dma-pool";
>>>> +			reg = <0x00 0x99900000 0x00 0xf00000>;
>>>> +			no-map;
>>>> +		};
>>>> +
>>>
>>> I know this has been a push for our IPC and MCU+ teams for a couple
>>> windows now, though I do want to point out that some AM62A devices
>>> (AM62A12AQMSIAMBRQ1) will not even have a C7x.
>>>
>>> It's relatively easy to cut nodes out that describe the hardware in the
>>> bootloaders, but once we start configuring them to demo something it
>>> becomes impossible to unwind that during boot.
>>>
>>> We can clam we only support the superset devices but I just wanted to
>>> make this email so I could point people to it when they inevitably ask
>>> why their parts do not work out of the box with Linux.
>>>
>>> Naked-by: Bryan Brattlof <bb@ti.com>
>>
>>
>> I am confused. I do not see support for AM62A1 in upstream. We have
>> AM62A7-SK in upstream. I am not sure what direction you are suggesting
>> here.
> 
> All I'm trying to point out is for every part we upstream there are >10
> times the number of parts that for one reason or another will not make
> it to these upstream repositories.
> 
> Most of these parts will have trivial changes like having lower CPU
> counts, some will not have a GPU, MCU, PRU, or display, or maybe it's
> just a package change and the thermal zones are different, or it's just
> the speeds the IP can confidently run at, or it could be as simple as
> DDR part changes. Each variant will be mostly the superset device with
> one or two nodes disabled or modified in some way.
> 
> For a while now, without configuring the remote cores to demo anything,
> it's been relatively seamless to support these variants in the
> bootloaders by disabling or modifying the nodes that do not exist so
> Linux can at least boot to a shell and provides a great foundation for
> others to start their development
> 
> If we want to use these boards to demo a advanced usecases we can do
> that but I worry it will come at the cost of supporting all the part
> variants.
> 
> My hope was we could define the board as minimally as possible here so
> we can maximize their flexibility with what timers, mailboxes and memory
> carve-outs each remote processor uses.
> 

Is it not agreed upon to support the superset device upstream? It seems
like what we need is a detailed whitepaper on board bring-up for each
part variant instead of NOT adding support for the superset device
upstream approach.

~ Judith