[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9145c0f7-c82c-4b33-b421-a0af24accb39@oss.qualcomm.com>
Date: Wed, 22 Oct 2025 19:26:03 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Vikash Garodia <vikash.garodia@....qualcomm.com>,
Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
Abhinav Kumar <abhinav.kumar@...ux.dev>,
Bryan O'Donoghue <bod@...nel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley
<conor+dt@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Vishnu Reddy <quic_bvisredd@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Subject: Re: [PATCH v2 0/8] media: iris: add support for video codecs on Qcom
kaanapali platform
On 10/17/25 4:16 PM, Vikash Garodia wrote:
> Qualcomm kaanapali platform have a newer generation of video IP, iris4
> or vpu4. The hardware have evolved mostly w.r.t higher number of power
> domains as well as multiple clock sources. It has support for new
> codec(apv), when compared to prior generation.
>
> The series describes the binding interfaces of the hardware, buffer
> calculation and power sequence for vpu4, and add the platform data at
> the end.
>
> Please review and share your comments.
>
> Following are the compliance and functional validation reports
>
> v4l2-compliance report, for decoder followed by encoder, including
> streaming tests:
[...]
> Changes in v2:
> - Dropped dependencies from binding (Dmitry).
> - Dropped optional items from binding (Dmitry, Krzysztof, Konrad).
> - Updated binding in sorted order and proper alignment (Krzysztof).
> - Fixed order of newly introduced kaanapali struct (Dmitry, Bryan)
> - Improved readability of buffer size calculation (Bryan)
> - Optimized fuse register read (Konrad).
You're still reading it at every power_on/off, which I generally
believe is superflouous.. Unless the hardware has some unusual
properties, a *fuse* value does not change at runtime and doing it
once should be perfectly sufficient
That said, this is not a hill to die on..
Konrad
Powered by blists - more mailing lists