[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98481299-4db3-41f3-a974-d9d0075d92e0@kernel.org>
Date: Fri, 16 Jan 2026 11:46:07 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
Vikash Garodia <vikash.garodia@....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 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.
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.
Best regards,
Krzysztof
Powered by blists - more mailing lists