Re: [PATCH v2 4/6] arm64: dts: ti: k3-j784s4-j742s2-main-common: Assign SRAM to VPU nodes

Hi Nishanth,

On 9/21/26 12:27 PM, Nishanth Menon wrote:

On 10:31-20260921, Brandon Brnich wrote:

quoted

quoted

quoted

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index e836f0f42e30d..21ec9f207ff63 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi

@@ -1002,6 +1002,7 @@ vpu0: video-codec@4210000 {
   		interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
   		clocks = <&k3_clks 241 2>;
   		power-domains = <&k3_pds 241 TI_SCI_PD_EXCLUSIVE>;
+		sram = <&main_navss_sram>;
   	};
   	vpu1: video-codec@4220000 {

@@ -1010,6 +1011,7 @@ vpu1: video-codec@4220000 {
   		interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
   		clocks = <&k3_clks 242 2>;
   		power-domains = <&k3_pds 242 TI_SCI_PD_EXCLUSIVE>;
+		sram = <&main_navss_sram>;
   	};

Hello Brandon,
Could you check, how two instances of hardware can share same sram ?

If both instances are used in parallel, then only 1 would get the benefits
of b/w savings with this current patch. These VPU instances are in a race to
see who gets the pool depending on which instance allocates the first
stream. Current Wave5 driver will take the entire 64 KB pool once a stream
is opened. The pool is not released until all associated streams with that
instance are freed.

I will look to see if the driver can be modified at all here. If it can't,
then I will find another node of available SRAM that I can hook up to 2nd
instance. For now, we can drop this patch and associated patch adding
main_navss_sram to J784s4 in this series.

OK - What do i translate this as? We may need to change SRAM / need
more SRAM? Since this is a pool, I'd rather have the driver use SRAM
optimally before pulling in more SoC SRAM - if we really need it, lets
send an update explaining the usecase where more SRAM was needed.

Am I correct?

Yes, you are correct.

Driver should use the pool more efficiently so that if both instances are pointing at same pool, they could at least do lower resolution streams without hogging all 64KB. This would also help in case of other IPs using this pool. VPU could take what it needs and allow other IPs to still allocate from here.

However, if both instances are doing 4K60 encode and decode, then each will need 64KB to get full benefits of b/w savings.

If allocating for max case (which driver plans for) is the path that should be taken, then carving out a 2nd 64KB pool and attaching it to vpu1 is the correct approach.

Best,
Brandon