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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Fri, 2 Feb 2024 14:56:31 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Nishanth Menon <nm@...com>
Cc: Brandon Brnich <b-brnich@...com>, 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

On 02/02/2024 13:52, Nishanth Menon wrote:
> On 11:47-20240202, Krzysztof Kozlowski wrote:
>> On 01/02/2024 19:42, Brandon Brnich wrote:
>>> Wave521c has capability to use SRAM carveout to store reference data with
>>> purpose of reducing memory bandwidth. To properly use this pool, the driver
>>> expects to have an sram and sram-size node. Without sram-size node, driver
>>> will default value to zero, making sram node irrelevant.
>>
>> I am sorry, but what driver expects should not be rationale for new
>> property. This justification suggests clearly it is not a property for DT.
>>
> 
> Yup, the argumentation in the commit message is from the wrong
> perspective. bindings are OS agnostic hardware description, and what
> driver does with the description is driver's problem.
> 
> I will at least paraphrase my understanding:
> In this case, however, the hardware block will limp along with
> the usage of DDR (as is the current description), due to the
> latencies involved for DDR accesses. However, the hardware block
> has capability to use a substantially lower latency SRAM to provide
> proper performance and hence for example, deal with higher resolution
> data streams. This SRAM is instantiated at SoC level rather than
> embedded within the hardware block itself.

That sounds like OS policy. Why would different boards with the same
component have this set differently? Based on amount of available
memory? This, I believe, is runtime configuration because it might
depend on user-space you run. Based on purpose (e.g. optimize for
decoding or general usage)? Again, run-time because same hardware board
can be used for different purposes.

Best regards,
Krzysztof