[PATCH v2 0/6] Add SRAM Nodes for VPU

[PATCH v2 0/6] Add SRAM Nodes for VPU

[Brandon Brnich]

Hello All,

This series is responsible for adding the SRAM nodes for the Wave5 VPU 
to use. The first 2 patches are responsible for carving out the SRAM
pool from main_navss that the VPU will then reference in patches 3 and
4. The last 2 patches use the existing oc_sram pool already found in the
relevant device trees.

v2 properly updates the nodename in the first two patches to pass
dtbs_check. I have talked with Andrew offline and he has said I can keep
his reviewed-by on the first 4 patches based on v1[0].

Best,
Brandon

[0]: https://lore.kernel.org/all/7d8582bc-e88d-40a7-be39-57045fa4c010@ti.com/

Brandon Brnich (6):
  arm64: dts: ti: k3-j721s2-main: Add mmio-sram node to main_navss
  arm64: dts: ti: k3-j784s4-j742s2-main-common: Add mmio-sram node to
    main_navss
  arm64: dts: ti: k3-j721s2-main: Assign SRAM to VPU node
  arm64: dts: ti: k3-j784s4-j742s2-main-common: Assign SRAM to VPU nodes
  arm64: dts: ti: k3-am62a-main: Assign SRAM to VPU node
  arm64: dts: ti: k3-am62p-j722s-common-main: Assign SRAM to VPU node

 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi              |  1 +
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi |  1 +
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi             |  9 +++++++++
 .../boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi      | 10 ++++++++++
 4 files changed, 21 insertions(+)

-- 
2.43.0

[PATCH v2 1/6] arm64: dts: ti: k3-j721s2-main: Add mmio-sram node to main_navss

[Brandon Brnich]

The NavigatorSS (NAVSS) address space contains a 64 KiB on-chip SRAM
region at its base address. Add an mmio-sram node to expose this region
to consumers via the generic SRAM allocator API.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 1228ac5711bf0..1fd173a68c0b2 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -784,6 +784,14 @@ main_navss: bus@30000000 {
 		dma-coherent;
 		dma-ranges;
 
+		main_navss_sram: sram@30000000 {
+			compatible = "mmio-sram";
+			reg = <0x00 0x30000000 0x00 0x10000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x00 0x30000000 0x10000>;
+		};
+
 		main_navss_intr: interrupt-controller@310e0000 {
 			compatible = "ti,sci-intr";
 			reg = <0x00 0x310e0000 0x00 0x4000>;
-- 
2.43.0

[PATCH v2 2/6] arm64: dts: ti: k3-j784s4-j742s2-main-common: Add mmio-sram node to main_navss

[Brandon Brnich]

The NavigatorSS (NAVSS) address space contains a 64 KiB on-chip SRAM
region at its base address. Add an mmio-sram node to expose this region
to consumers via the generic SRAM allocator API.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

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 c2636e624f18b..e836f0f42e30d 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
@@ -1254,6 +1254,14 @@ main_navss: bus@30000000 {
 		dma-coherent;
 		dma-ranges;
 
+		main_navss_sram: sram@30000000 {
+			compatible = "mmio-sram";
+			reg = <0x00 0x30000000 0x00 0x10000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x00 0x30000000 0x10000>;
+		};
+
 		main_navss_intr: interrupt-controller@310e0000 {
 			compatible = "ti,sci-intr";
 			reg = <0x00 0x310e0000 0x00 0x4000>;
-- 
2.43.0

[PATCH v2 3/6] arm64: dts: ti: k3-j721s2-main: Assign SRAM to VPU node

[Brandon Brnich]

The Wave5 VPU supports connecting to on-chip SRAM through its secondary
AXI interface. This allows temporal buffers to be stored on a per-stream
basis, reducing DDR memory traffic.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 1fd173a68c0b2..233aedcbf2ec3 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -716,6 +716,7 @@ vpu: video-codec@4210000 {
 		interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&k3_clks 179 2>;
 		power-domains = <&k3_pds 179 TI_SCI_PD_EXCLUSIVE>;
+		sram = <&main_navss_sram>;
 	};
 
 	main_sdhci0: mmc@4f80000 {
-- 
2.43.0

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

[Brandon Brnich]

The Wave5 VPU supports connecting to on-chip SRAM through its secondary
AXI interface. This allows temporal buffers to be stored on a per-stream
basis, reducing DDR memory traffic.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

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>;
 	};
 
 	main_sdhci0: mmc@4f80000 {
-- 
2.43.0

[PATCH v2 5/6] arm64: dts: ti: k3-am62a-main: Assign SRAM to VPU node

[Brandon Brnich]

The Wave5 VPU supports connecting to on-chip SRAM through its secondary
AXI interface. This allows temporal buffers to be stored on a per-stream
basis, reducing DDR memory traffic.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 9e5b75a4e88e2..92dd1b96cef4d 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -1149,6 +1149,7 @@ vpu: video-codec@30210000 {
 		reg = <0x00 0x30210000 0x00 0x10000>;
 		clocks = <&k3_clks 204 2>;
 		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
+		sram = <&oc_sram>;
 	};
 
 	c7x_0: dsp@7e000000 {
-- 
2.43.0

[PATCH v2 6/6] arm64: dts: ti: k3-am62p-j722s-common-main: Assign SRAM to VPU node

[Brandon Brnich]

The Wave5 VPU supports connecting to on-chip SRAM through its secondary
AXI interface. This allows temporal buffers to be stored on a per-stream
basis, reducing DDR memory traffic.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
---
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index f130c7cb998d7..61e3588bbfdc5 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -1117,6 +1117,7 @@ vpu: video-codec@30210000 {
 		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&k3_clks 204 2>;
 		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
+		sram = <&oc_sram>;
 	};
 
 	hsm: remoteproc@43c00000 {
-- 
2.43.0

Re: [PATCH v2 0/6] Add SRAM Nodes for VPU

[Andrew Davis]

On 8/10/26 3:52 PM, Brandon Brnich wrote:
> Hello All,
> 
> This series is responsible for adding the SRAM nodes for the Wave5 VPU
> to use. The first 2 patches are responsible for carving out the SRAM
> pool from main_navss that the VPU will then reference in patches 3 and
> 4. The last 2 patches use the existing oc_sram pool already found in the
> relevant device trees.
> 
> v2 properly updates the nodename in the first two patches to pass
> dtbs_check. I have talked with Andrew offline and he has said I can keep
> his reviewed-by on the first 4 patches based on v1[0].
> 

The two new patches for the Sitara platforms also look good, so for the
whole series,

Acked-by: Andrew Davis <afd@ti.com>

> Best,
> Brandon
> 
> [0]: https://lore.kernel.org/all/7d8582bc-e88d-40a7-be39-57045fa4c010@ti.com/
> 
> Brandon Brnich (6):
>    arm64: dts: ti: k3-j721s2-main: Add mmio-sram node to main_navss
>    arm64: dts: ti: k3-j784s4-j742s2-main-common: Add mmio-sram node to
>      main_navss
>    arm64: dts: ti: k3-j721s2-main: Assign SRAM to VPU node
>    arm64: dts: ti: k3-j784s4-j742s2-main-common: Assign SRAM to VPU nodes
>    arm64: dts: ti: k3-am62a-main: Assign SRAM to VPU node
>    arm64: dts: ti: k3-am62p-j722s-common-main: Assign SRAM to VPU node
> 
>   arch/arm64/boot/dts/ti/k3-am62a-main.dtsi              |  1 +
>   arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi |  1 +
>   arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi             |  9 +++++++++
>   .../boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi      | 10 ++++++++++
>   4 files changed, 21 insertions(+)
> 

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

[Kumar, Udit]

On 8/11/2026 2:22 AM, Brandon Brnich wrote:
> The Wave5 VPU supports connecting to on-chip SRAM through its secondary
> AXI interface. This allows temporal buffers to be stored on a per-stream
> basis, reducing DDR memory traffic.
> 
> Signed-off-by: Brandon Brnich <b-brnich@ti.com>
> Reviewed-by: Andrew Davis <afd@ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 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 ?

LTM, each block need 64KB of SRAM
https://elixir.bootlin.com/linux/v7.2.2/source/drivers/media/platform/chips-media/wave5/wave5-vpu.c#L463


>  
>  	main_sdhci0: mmc@4f80000 {

Re: [PATCH v2 6/6] arm64: dts: ti: k3-am62p-j722s-common-main: Assign SRAM to VPU node

[Kumar, Udit]

On 8/11/2026 2:22 AM, Brandon Brnich wrote:
> The Wave5 VPU supports connecting to on-chip SRAM through its secondary
> AXI interface. This allows temporal buffers to be stored on a per-stream
> basis, reducing DDR memory traffic.
> 
> Signed-off-by: Brandon Brnich <b-brnich@ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> index f130c7cb998d7..61e3588bbfdc5 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
> @@ -1117,6 +1117,7 @@ vpu: video-codec@30210000 {
>  		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
>  		clocks = <&k3_clks 204 2>;
>  		power-domains = <&k3_pds 204 TI_SCI_PD_EXCLUSIVE>;
> +		sram = <&oc_sram>;

Reviewed-by: Udit Kumar <u-kumar1@ti.com>

>  	};
>  
>  	hsm: remoteproc@43c00000 {

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

[Brandon Brnich]

Hi Udit,

On 9/5/26 7:48 AM, Kumar, Udit wrote:
> 
> 
> On 8/11/2026 2:22 AM, Brandon Brnich wrote:
>> The Wave5 VPU supports connecting to on-chip SRAM through its secondary
>> AXI interface. This allows temporal buffers to be stored on a per-stream
>> basis, reducing DDR memory traffic.
>>
>> Signed-off-by: Brandon Brnich <b-brnich@ti.com>
>> Reviewed-by: Andrew Davis <afd@ti.com>
>> ---
>>   arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> 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.

Best,
Brandon

> 
> LTM, each block need 64KB of SRAM
> https://elixir.bootlin.com/linux/v7.2.2/source/drivers/media/platform/chips-media/wave5/wave5-vpu.c#L463>
> 
>>   
>>   	main_sdhci0: mmc@4f80000 {
> 

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

[Nishanth Menon]

On 10:31-20260921, Brandon Brnich wrote:
> > > 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?

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource

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

[Brandon Brnich]

Hi Nishanth,

On 9/21/26 12:27 PM, Nishanth Menon wrote:
> On 10:31-20260921, Brandon Brnich wrote:
>>>> 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

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

[Brandon Brnich]

On 9/21/26 1:04 PM, Brandon Brnich wrote:
> Hi Nishanth,
> 
> On 9/21/26 12:27 PM, Nishanth Menon wrote:
>> On 10:31-20260921, Brandon Brnich wrote:
>>>>> 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.

I am going to send a v3 for now that drops 84s4 patches from the series 
while I find another SRAM node to give to the 2nd instance.

> 
> Best,
> Brandon