linux-kernel - Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver

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]

Message-ID: <d4b70cc9-8d37-4249-875f-b0d80256c9e6@kernel.org>
Date: Mon, 20 Oct 2025 19:18:44 +0100
From: Bryan O'Donoghue <bod@...nel.org>
To: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>,
 Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
 Loic Poulain <loic.poulain@....qualcomm.com>, Robert Foss
 <rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Todor Tomov <todor.too@...il.com>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: linux-i2c@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, aiqun.yu@....qualcomm.com,
 tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
 yijie.yang@....qualcomm.com, Jingyi Wang <jingyi.wang@....qualcomm.com>,
 Atiya Kailany <atiya.kailany@....qualcomm.com>
Subject: Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss
 driver

On 20/10/2025 14:38, Vijay Kumar Tumati wrote:
>>
>> Ack. Thanks.
> Just adding my thoughts on this, as you know the peak/avg bandwidth 
> should primarily depends on the sensor data rate and additionally, the 
> average BW vote should depend on the buffer sizes in the NIUs/NOCs and 
> (although irrelevant here) whether it's an RT or NRT module (file system 
> reads/writes from the NRT modules can be averaged and controlled 
> better). Fundamentally, the votes from all modules go into the 
> calculation of the DDR clock. The current driver does not take into 
> account anything. So either way, it is not ideal I think. We can discuss 
> and come up with a cleaner approach in a different patch series covering 
> all chip sets. Thanks.

Yeah we can.

But please put something more sensible in for v3.

---
bod