linux-kernel - Re: [PATCH v2] dt-bindings: media: Add sram-size Property for Wave5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fccdc181727307f52a36f3bb621d6a4e192096da.camel@ndufresne.ca>
Date: Fri, 09 Feb 2024 12:42:40 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Devarsh Thakkar <devarsht@...com>, Brandon Brnich <b-brnich@...com>, 
	Nishanth Menon
	 <nm@...com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Nas Chung
 <nas.chung@...psnmedia.com>, Jackson Lee <jackson.lee@...psnmedia.com>, 
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring
 <robh+dt@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
 linux-media@...r.kernel.org, devicetree@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Vignesh Raghavendra <vigneshr@...com>, Darren
 Etheridge <detheridge@...com>
Subject: Re: [PATCH v2] dt-bindings: media: Add sram-size Property for Wave5

Le jeudi 08 février 2024 à 11:52 +0530, Devarsh Thakkar a écrit :
> I think even with the approach selected in [1] i.e. referring the
> mmio-sram node using DT property, you can still use dynamic SRAM
> allocation.
> The driver can still allocate from global sram pool dynamically using
> of_gen_pool API as being explained here [3] i.e allocate when first
> instance is opened and free up later when no instances are running.
> 
> But I agree with Nishanth's point too that we may not want to give all
> of SRAM to VPU. For e.g. on AM62A we have 64KiB SRAM and a 1080p
> use-case requires 48KiB and even higher for 4K so if there is another
> peripheral who is referring this sram node, then it may not get enough
> as VPU will hog the major chunk (or all) of it while it is running and
> this is where an optional property like sram-size will help to cap the
> max sram usage for VPU and so this helps especially on platforms with
> limited SRAM availability.
> 
> As I understand, the sram size allocation is dependent on resolution and
> once programmed can't be changed until all instances of VPU are done,
> and we can't predict how many instances user will launch and with what
> resolutions.
> 
> So here's the flow we had thought of some time back :
> 1) Define worst case sram size (per 4K use-case as I believe that's the
> max for CnM wave521c) as a macro in driver
> 
> Then the condition for determining sram size to be allocated should be
> as below  :
> 
> 2) When first instance of VPU is opened, allocate as per sram-size if
> sram-size property is specified.
> 
> 3) If sram-size is not specified then :
>    -> Allocate as per worst case size macro defined in driver from sram
> pool,
>    -> If worst case size of SRAM > max SRAM size, then allocate
>       max SRAM size
> 
> 4). When all of the instances of VPU are closed, then free up all
> allocated SRAM.
> 
> [3] :
> https://wiki.analog.com/resources/tools-software/linuxdsp/docs/linux-kernel-and-drivers/sram

Only issue here is that DT is not a use case configuration file. That DT
parameter is meant for HW that simply cannot be operated without it. This is
also edgy, because it also means that it should only be used if that information
is not static and vary unpredictably per SoC, which seems generally unlikely. 

The Wave5 IP *can* work without it, so it should resort to something more
dynamic. User configuration should be sorted out at the OS level.

Nicolas