Thread (45 messages) 45 messages, 8 authors, 2025-06-11

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

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: 2025-06-06 12:56:36
Also in: linux-arm-msm, linux-media, lkml

On 06/06/2025 14:51, Renjiang Han wrote:
On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
quoted
On 06/06/2025 14:37, Renjiang Han wrote:
quoted
On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
quoted
On 31/05/2025 01:05, Renjiang Han wrote:
quoted
quoted
quoted
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.
This statement is confusing.

1/3 states that there will be a fallback if there is no OPP table
present.

Giving the code a glance, I believe that is so, freq_table should be
used if there is no OPP specified in the DT.

I think we are having a hard time here understanding what you are saying.

My understanding:

- venus modification is standalone 1/3
   Qcs615 will fallback if no OPP is present

- dt modification 2/3 3/3 is therefore also independent of driver

---
bod
yes, let me re-spin this with driver patch alone. Once that gets in,
will bring in the DT patches.
Did you read my feedback? There is no "once that gets in". DTS is an
independent hardware description and your patchset claiming there is
dependency is just broken.

I am repeating this since few emails, so shall I NAK it that you will
address the main issue you have?

Best regards,
Krzysztof
Hi Krzysztof

SC7180 and QCS615 use the same video core. Only difference lies in the
freq_table for the video. Freq_table is generally determined at SOC level.
The Venus driver does not currently handle freq_table compatibility well
across platforms. This patch enables the driver to use the OPP-table from
the DT, addressing the frequency compatibility issue.
This does not resolve the main problem at all. If SW cannot use the
fallback alone, your fallback has no meaning and is not only confusing
but actually incorrect. And based on previous statements like
"overclocking" it is not only incorrect, but even harmful.

Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help