linux-kernel - Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

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: <nr2je5ssn22npl2dqu5aj2xcwinnjmhvl3tvuz5smr4dd2rxaj@dfkk6aktkafy>
Date: Thu, 5 Jun 2025 19:02:58 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...ndries.io>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Renjiang Han <quic_renjiang@...cinc.com>, 
	Vikash Garodia <quic_vgarodia@...cinc.com>, Dikshita Agarwal <quic_dikshita@...cinc.com>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, Bjorn Andersson <andersson@...nel.org>, 
	Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-media@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	Nicolas Dufresne <nicolas.dufresne@...labora.com>
Subject: Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote:
> On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
> > On 05/06/2025 14:30, Dmitry Baryshkov wrote:
> > > On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > > 
> > > > On 02/06/2025 08:16, Dmitry Baryshkov wrote:
> > > > > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
> > > > > > 
> > > > > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> > > > > > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> > > > > > > > QCS615 uses the same video core as SC7180, so reuse the same resource
> > > > > > > > data of SC7180 for QCS615 to enable video functionality.
> > > > > > > > 
> > > > > > > > There are no resources for the video-decoder and video-encoder nodes
> > > > > > > > in the device tree, so remove these two nodes from the device tree. In
> > > > > > > > addition, to ensure that the video codec functions properly, use [3]
> > > > > > > > to add encoder and decoder node entries in the venus driver.
> > > > > > > > 
> > > > > > > > Validated this series on QCS615 and SC7180.
> > > > > > > > 
> > > > > > > > Note:
> > > > > > > > This series consist of DT patches and a venus driver patch. The patch
> > > > > > > > 1/3, which is venus driver patch, can be picked independently without
> > > > > > > > having any functional dependency. But patch 2/3 & patch 3/3, which are
> > > > > > > > DT patches, still depend on [1].
> > > > > > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> > > > > > > on QCS615 over(?)clocked.
> > > > > > Agree, so we need to make sure that the driver patch is not picked after the
> > > > > > DT patch.
> > > > > 
> > > > > Worse: we need to make sure that the driver patch is present in the
> > > > > branch which picks up DT patches. Otherwise building & testing that
> > > > 
> > > > 
> > > > Well, that's a NAK then (although depends what you mean by DT).
> > > 
> > > I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
> > 
> > Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
> > one branch.

Surely it can... Like any other cross-subsystem dependency.

> > 
> > > patch. Or just merging the patches in two consequent releases.
> > 
> > That's a new device nodes, new hardware so it should not be blocked by
> > any driver patch. This is just totally broken process / patchset / work.
> > 
> > Best regards,
> > Krzysztof
> 
> Reading this thread, I don't think that is the case.
> 
> I don't see how patches 2/3 or 3/3 depend on 1/3.

Please correct me if I'm wrong. Without driver changes from patch 1, the
driver will always use frequency table from the driver itself. In this
case it will be the frequency table (and corners) for SC7180, which
would make venus driver overclock the hardware on QCS615.

> 
> The frequency table is a fallback in the driver and the DT changes are
> completely straight forward.
> 
> TBH, I think we are hitting an email comms/social barrier here, not a
> technical one.

I assume so.

> 
> @Renjiang can you please confirm that freq_table is a fallback, qcs615 will
> work without OPP table and the DTS stuff doesn't depend on the driver.
> 
> TBH, I don't see how the DTS can or should but...
> 
> ---
> bod
> 

-- 
With best wishes
Dmitry