Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Brandon Brnich <b-brnich@ti.com>
Cc: "Kumar, Udit" <u-kumar1@ti.com>, <vigneshr@ti.com>,
	<kristo@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<afd@ti.com>
Subject: Re: [PATCH v2 4/6] arm64: dts: ti: k3-j784s4-j742s2-main-common: Assign SRAM to VPU nodes
Date: Mon, 21 Sep 2026 12:27:46 -0500	[thread overview]
Message-ID: <20260921172746.jge67yswqjeolwz3@impulse> (raw)
In-Reply-To: <01ff0252-1580-4934-af34-6ef70d874f10@ti.com>

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


  reply	other threads:[~2026-09-21 17:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10 20:52 [PATCH v2 0/6] Add SRAM Nodes for VPU Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 1/6] arm64: dts: ti: k3-j721s2-main: Add mmio-sram node to main_navss Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 2/6] arm64: dts: ti: k3-j784s4-j742s2-main-common: " Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 3/6] arm64: dts: ti: k3-j721s2-main: Assign SRAM to VPU node Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 4/6] arm64: dts: ti: k3-j784s4-j742s2-main-common: Assign SRAM to VPU nodes Brandon Brnich
2026-09-05 12:48   ` Kumar, Udit
2026-09-21 15:31     ` Brandon Brnich
2026-09-21 17:27       ` Nishanth Menon [this message]
2026-09-21 18:04         ` Brandon Brnich
2026-09-21 18:35           ` Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 5/6] arm64: dts: ti: k3-am62a-main: Assign SRAM to VPU node Brandon Brnich
2026-08-10 20:52 ` [PATCH v2 6/6] arm64: dts: ti: k3-am62p-j722s-common-main: " Brandon Brnich
2026-09-05 12:59   ` Kumar, Udit
2026-08-11 14:47 ` [PATCH v2 0/6] Add SRAM Nodes for VPU Andrew Davis

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=20260921172746.jge67yswqjeolwz3@impulse \
    --to=nm@ti.com \
    --cc=afd@ti.com \
    --cc=b-brnich@ti.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kristo@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=u-kumar1@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