[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 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.

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