[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <035e9f34-f28f-47fd-ac36-6277171b0e28@oss.qualcomm.com>
Date: Fri, 16 Jan 2026 16:57:55 +0530
From: Vikash Garodia <vikash.garodia@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
Bryan O'Donoghue <bod@...nel.org>
Cc: Abhinav Kumar <abhinav.kumar@...ux.dev>, Rob Herring <robh@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Vishnu Reddy <busanna.reddy@....qualcomm.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>
Subject: Re: [PATCH v4 6/6] media: iris: Introduce vpu ops for vpu4 with
necessary hooks
On 1/16/2026 4:16 PM, Krzysztof Kozlowski wrote:
> On 16/01/2026 10:51, Dikshita Agarwal wrote:
>>
>>
>> On 12/10/2025 6:06 PM, Vikash Garodia wrote:
>>> Add power sequence for vpu4 by reusing from previous generation wherever
>>> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from
>>> earlier generation wherever feasible, like clock calculation in this
>>> case.
>>>
>>> Co-developed-by: Vishnu Reddy <busanna.reddy@....qualcomm.com>
>>> Signed-off-by: Vishnu Reddy <busanna.reddy@....qualcomm.com>
>>> Signed-off-by: Vikash Garodia <vikash.garodia@....qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/iris/Makefile | 1 +
>>> .../platform/qcom/iris/iris_platform_common.h | 7 +
>>> drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++
>>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
>>> 4 files changed, 378 insertions(+)
>>>
>>
>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
>
>
> Thank you for reviewing this code. I would like to point that it took
> one month for Qualcomm to review this Qualcomm patch and in the same
> time Vikash is sending emails (more than one!) that Bryan does not
> review that fast as expected.
Firstly, the ask to Bryan have been to pull patches (not stressed on
review part), infact, even fixes are waiting for merge window while they
can easily go into RCs. This part of the process need some improvement.
I have also appreciated him when he pulled long series for initial codec
enablement, i think you missed those part.
>
> I do not find it acceptable approach to harass community reviewers that
> way. Even if you do it internally, not on the lists.
>
> I think this review timeline is final argument for Vikash to stop
> pushing such narratives and complains, because your review is expected
> to be BEFORE the maintainer upper in the upstream flow.
My understanding is that, if maintainer raise patches, then its more of
reviews from community and having RB tag from any of community member or
no open comments implies the series is good to go.
This series is lying there for a month without any open comment, there
is nothing pending here to pull them.
Regards,
Vikash
>
> Best regards,
> Krzysztof
Powered by blists - more mailing lists