On 05/06/2025 13:33, Krzysztof Kozlowski wrote:

On 05/06/2025 14:30, Dmitry Baryshkov wrote:

quoted

On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski [off-list ref] wrote:

quoted

On 02/06/2025 08:16, Dmitry Baryshkov wrote:

quoted

On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:

quoted

On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:

quoted

On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:

quoted

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.

quoted

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.

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.

@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