public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Devarsh Thakkar <devarsht@ti.com>
To: Jai Luthra <jai.luthra@ideasonboard.com>
Cc: Andrew Davis <afd@ti.com>, Judith Mendez <jm@ti.com>,
	Devarsh Thakkar <devarsht@lewv0571a.ent.ti.com>,
	Nishanth Menon <nm@ti.com>, Hari Nagalla <hnagalla@ti.com>,
	Tero Kristo <kristo@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Beleswar Padhi <b-padhi@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Markus Schneider-Pargmann <msp@baylibre.com>, <praneeth@ti.com>,
	"Khasim, Syed Mohammed" <khasim@ti.com>,
	<tomi.valkeinen@ideasonboard.com>, <v-krishnamoorthy@ti.com>,
	<s-tripathy@ti.com>, <s-tripathi1@ti.com>, <c-shilwant@ti.com>,
	<r-ravikumar@ti.com>
Subject: Re: [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors
Date: Thu, 10 Apr 2025 17:08:57 +0530	[thread overview]
Message-ID: <5969e1e8-0bb7-4334-a0c5-b4c396b8b6af@ti.com> (raw)
In-Reply-To: <czmir7yvss3oreveesyrjqfdcawyn2axtstomsj3yx5sntqwo2@r3udnsyrxvkp>

Hi Jai,

On 10/04/25 15:48, Jai Luthra wrote:
> Hi Devarsh,
> 
> Thanks for the cc here.

Thanks for the quick comments.

> 
<snip>

> On the basic camera + ISP usecase, afaiu the downstream edgeAI SDK uses
> custom gstreamer elements that make calls to the aforementioned R5 core
> that controls the ISP. On top of that there are additional gstreamer
> patches that are not yet posted upstream for review from the community,
> so the userspace design isn't really set in stone, or upstream-friendly
> yet.
> 

I don't see much relation of carve-outs with Gstreamer or it's pending 
downstream patches. The memory is mainly managed from firmwares (mainly 
openvx layer being used underneath) and there are even non-gstreamer 
pure openvx based use-cases/tests which use these carveouts. At the end 
of the day, the firmwares from the only SDK which is released publicly 
for AM62A uses all these carveouts.


> IMO if that architecture is still under discussion, it might be better
> to keep the edgeAI specific carveouts out of the upstream DTs.. just in
> case the carevouts have to go away, or change significantly.
> 
> If you are sure that the regions and firmware architecture is set in
> stone and won't be updated even if there is a complete redesign of the
> userspace/application level stack for accessing the ISP (let's say u
sing> libcamera), only then it makes sense to add the carveouts right now.


Yes as I said if whole firmware arch is getting updated then better to 
wait. I think probably the firmware team marked in cc can comment on 
that. Moreover I don't see any point of adding only half the regions as 
that would anyway not work with SDK supplied firmwares, for e.g. 
RTOS-to-RTOS ipc test run by firmwares on bootup would fail, along with 
other camera+ISP and AI use-cases.

Regards
Devarsh

>>>>
>>>> I understand your point, currently with this patch remoteproc loading
>>>> will not work for some cores. However, the goal here is to standardize
>>>> as much as possible the memory carveout sizes, push the "demo firmware"
>>>> to request resources the correct way from resource table, and move away
>>>> from this dependency and limitations that we have with our firmware.
>>
>> I understand this, but my view is that w.r.t firmware only goal should not
>> just be tp demonstrate correct way of requesting resources from
>> resource-tables, optimize the carve-outs etc but also to demonstrate the
>> primary use-cases (camera+ISP+edgeAI) which the device is capable of.
>>
>>>> should soon be able to generate our own firmware using Zephyr,  which
>>>> Andrew is pioneering, so with this firmware we should move to the
>>>> correct direction upstream. Downstream we are still using the memory
>>>> carveout sizes that the firmware folk want so desperately to keep, for
>>>> now..
>>>>
>>>
>>> +1
>>>
>>> I have this Zephyr based firmware for AM62A working and it uses the
>>> standard IPC regions as specified in this patch. I'll be posting the PR
>>> for it in Zephyr upstream by the end of week.
>>>
>>
>> I understand this, but will this zephyr based firmware support vision +
>> edgeAI analytics ? Does it demonstrate all the unique capabilities of AM62A
>> SoC ? If not, then what would be utility of such firmware on AM62A where
>> these are the primary use-cases w.r.t AM62A ?
>>
>> Why should upstream device-tree use carve-outs which match to this demo
>> zephyr based firmware (which apparently not many are using and is not going
>> into any official SDK release) instead of official firmwares going into SDK
>> ? SDK released firmwares are being used by so many customers and SDK
>> documentation maps to it, but zephyr firmware that is being pitched here,
>> who would be the potential users and what would be it's utility ?
>>
>> [1]: https://www.ti.com/tool/PROCESSOR-SDK-J721E
>>
>> Regards
>> Devarsh
>>
>>> For this patch as it is:
>>>
>>> Acked-by: Andrew Davis <afd@ti.com>
>>>
>>
>>
>>> Andrew
>>>
>>> [0] https://lore.kernel.org/lkml/20241011123922.23135-1-richard@nod.at/
>>> [1] https://git.ti.com/cgit/edgeai/meta-edgeai/tree/recipes-kernel/
>>> linux/linux-ti-staging/j721e-evm/0001-arm64-dts-ti-Add-DTB-overlays-for-
>>> vision-apps-and-ed.patch?h=kirkstone
>>>
>>>> ~ Judith
>>>>
>>>>>
>>>>> [1]:
>>>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/
>>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts?h=ti-linux-6.6.y-cicd#n103
>>>>> [2]: https://www.ti.com/tool/PROCESSOR-SDK-AM62A
>>>>>
>>>>> Regards
>>>>> Devarsh
>>>>>
>>>>>>        opp-table {
>>>>>> @@ -741,3 +771,57 @@ dpi1_out: endpoint {
>>>>>>            };
>>>>>>        };
>>>>>>    };
>>>>>> +
>>>>>> +&mailbox0_cluster0 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_r5_0: mbox-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster1 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_c7x_0: mbox-c7x-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&mailbox0_cluster2 {
>>>>>> +    status = "okay";
>>>>>> +
>>>>>> +    mbox_mcu_r5_0: mbox-mcu-r5-0 {
>>>>>> +        ti,mbox-rx = <0 0 0>;
>>>>>> +        ti,mbox-tx = <1 0 0>;
>>>>>> +    };
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&wkup_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
>>>>>> +    memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&wkup_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0 {
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_r5fss0_core0 {
>>>>>> +    mboxes = <&mailbox0_cluster2>, <&mbox_mcu_r5_0>;
>>>>>> +    memory-region = <&mcu_r5fss0_core0_dma_memory_region>,
>>>>>> +            <&mcu_r5fss0_core0_memory_region>;
>>>>>> +};
>>>>>> +
>>>>>> +&c7x_0 {
>>>>>> +    mboxes = <&mailbox0_cluster1>, <&mbox_c7x_0>;
>>>>>> +    memory-region = <&c7x_0_dma_memory_region>,
>>>>>> +            <&c7x_0_memory_region>;
>>>>>> +    status = "okay";
>>>>>> +};
>>>>>
>>>>
>>>
>>
>>
> 


  reply	other threads:[~2025-04-10 11:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-05  0:15 [PATCH v6 00/11] Add R5F and C7xv device nodes Judith Mendez
2025-04-05  0:15 ` [PATCH v6 01/11] arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges Judith Mendez
2025-04-05  0:15 ` [PATCH v6 02/11] arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F node Judith Mendez
2025-04-05  0:15 ` [PATCH v6 03/11] arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc node Judith Mendez
2025-04-05  0:15 ` [PATCH v6 04/11] arm64: dts: ti: k3-am62a-wakeup: Add R5F device node Judith Mendez
2025-04-05  0:15 ` [PATCH v6 05/11] arm64: dts: ti: k3-am62a-main: Add C7xv " Judith Mendez
2025-04-05  0:15 ` [PATCH v6 06/11] arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors Judith Mendez
     [not found]   ` <6868f593-0728-4e92-a57b-87db6a0037f6@ti>
2025-04-07 14:13     ` Judith Mendez
2025-04-07 15:58       ` Andrew Davis
2025-04-10  9:00         ` Devarsh Thakkar
2025-04-10 10:18           ` Jai Luthra
2025-04-10 11:38             ` Devarsh Thakkar [this message]
2025-04-10 18:22               ` Andrew Davis
2025-04-11  4:50                 ` Beleswar Prasad Padhi
2025-04-11  6:45                 ` Jai Luthra
2025-04-08  4:00       ` Beleswar Prasad Padhi
2025-04-09 22:32         ` Judith Mendez
2025-04-10  8:55           ` Beleswar Prasad Padhi
2025-04-10 17:44             ` Judith Mendez
2025-04-11  4:36               ` Beleswar Prasad Padhi
2025-04-10 17:50             ` Andrew Davis
2025-04-11  4:12               ` Beleswar Prasad Padhi
2025-04-05  0:15 ` [PATCH v6 07/11] arm64: dts: ti: k3-am62p5-sk: " Judith Mendez
2025-04-05  0:15 ` [PATCH v6 08/11] arm64: dts: ti: k3-am62x-sk-common: " Judith Mendez
2025-04-05  0:15 ` [PATCH v6 09/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSP Judith Mendez
2025-04-05  0:15 ` [PATCH v6 10/11] arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 " Judith Mendez
2025-04-05  0:15 ` [PATCH v6 11/11] arm64: dts: ti: k3-am64: Reserve timers used by MCU FW Judith Mendez
2025-04-07 12:35   ` Andrew Davis
2025-04-07 14:38     ` Judith Mendez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5969e1e8-0bb7-4334-a0c5-b4c396b8b6af@ti.com \
    --to=devarsht@ti.com \
    --cc=afd@ti.com \
    --cc=b-padhi@ti.com \
    --cc=c-shilwant@ti.com \
    --cc=conor+dt@kernel.org \
    --cc=devarsht@lewv0571a.ent.ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hnagalla@ti.com \
    --cc=jai.luthra@ideasonboard.com \
    --cc=jm@ti.com \
    --cc=khasim@ti.com \
    --cc=kristo@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msp@baylibre.com \
    --cc=nm@ti.com \
    --cc=praneeth@ti.com \
    --cc=r-ravikumar@ti.com \
    --cc=robh@kernel.org \
    --cc=s-tripathi1@ti.com \
    --cc=s-tripathy@ti.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=v-krishnamoorthy@ti.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox