[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce9cf017-5447-457c-9579-700782f9f0c2@linaro.org>
Date: Thu, 7 Aug 2025 07:35:35 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Jorge Ramirez <jorge.ramirez@....qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: quic_dikshita@...cinc.com, quic_vgarodia@...cinc.com,
konradybcio@...nel.org, krzk+dt@...nel.org, mchehab@...nel.org,
conor+dt@...nel.org, andersson@...nel.org, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and
resource data
On 05/08/2025 11:44, Jorge Ramirez wrote:
> yes, in V7 I did implement this functionality plus a fix for EOS
> handling (broken in pre 6.0.55 firmwares).
>
> This added some complexity to the driver. And so in internal discussions
> it was agreed that it was not worth to carry it and that it should be dropped.
>
> I'll let Vikash and Bryan comment on the decision.
TBH I think there's not alot of value in supporting a broken firmware
which only does decode.
There's not alot of value to the user in that configuration.
Provided you have done the work to get the fixed firmware into
linux-firmware just cut at that point and have the driver reject lesser
versions.
I as a user have no use-case or value in a broken old firmware which
supports decode only, I'd much rather have the full transcoder.
Its Vikash/Dikshita's call though.
---
bod
Powered by blists - more mailing lists