[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 at 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 at 4220000 {
>>>> @@ -1010,6 +1011,7 @@ vpu1: video-codec at 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