From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>
Cc: quic_vgarodia@quicinc.com, quic_dikshita@quicinc.com,
krzk+dt@kernel.org, konradybcio@kernel.org, mchehab@kernel.org,
andersson@kernel.org, conor+dt@kernel.org,
amit.kucheria@oss.qualcomm.com, linux-media@vger.kernel.org,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/7] media: venus: Conditionally register codec nodes based on firmware version
Date: Thu, 17 Jul 2025 09:55:08 +0100 [thread overview]
Message-ID: <0dd1f38e-eaba-4c99-b386-4ff8fade5b9b@linaro.org> (raw)
In-Reply-To: <aHidibqhMyexExXJ@trex>
On 17/07/2025 07:51, Jorge Ramirez wrote:
> On 17/07/25 00:37:33, Bryan O'Donoghue wrote:
>> On 15/07/2025 21:47, Jorge Ramirez-Ortiz wrote:
>>> The encoding and decoding capabilities of a VPU can vary depending on the
>>> firmware version in use.
>>>
>>> This commit adds support for platforms with OF_DYNAMIC enabled to
>>> conditionally skip the creation of codec device nodes at runtime if the
>>> loaded firmware does not support the corresponding functionality.
>>>
>>> Note that the driver becomes aware of the firmware version only after the
>>> HFI layer has been initialized.
>>>
>>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/venus/core.c | 76 +++++++++++++++---------
>>> drivers/media/platform/qcom/venus/core.h | 8 +++
>>> 2 files changed, 57 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>>> index 4c049c694d9c..b7d6745b6124 100644
>>> --- a/drivers/media/platform/qcom/venus/core.c
>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>> @@ -28,6 +28,15 @@
>>> #include "pm_helpers.h"
>>> #include "hfi_venus_io.h"
>>> +static inline bool venus_fw_supports_codec(struct venus_core *core,
>>> + const struct venus_min_fw *ver)
>>> +{
>>> + if (!ver)
>>> + return true;
>>> +
>>> + return is_fw_rev_or_newer(core, ver->major, ver->minor, ver->rev);
>>> +}
>>> +
>>> static void venus_coredump(struct venus_core *core)
>>> {
>>> struct device *dev;
>>> @@ -103,7 +112,9 @@ static void venus_sys_error_handler(struct work_struct *work)
>>> core->state = CORE_UNINIT;
>>> for (i = 0; i < max_attempts; i++) {
>>> - if (!pm_runtime_active(core->dev_dec) && !pm_runtime_active(core->dev_enc))
>>> + /* Not both nodes might be available */
>>
>> "Neither node available" the latter for preference.
>
> what about "One or both nodes may be unavailable" ?
Ah great that actually explains it then, as you can see I didn't get the
meaning from the comment.
>>
>>> + if ((!core->dev_dec || !pm_runtime_active(core->dev_dec)) &&
>>> + (!core->dev_enc || !pm_runtime_active(core->dev_enc)))
>>
>> Is this change about registration or is it a fix trying to sneak in under
>> the radar ?
>
> I think this functionality - the ability to enable or disable individual
> encode/decode nodes based on firmware capabilities - should be standard
> across multimedia drivers.
>
> For example, on the AR50_LITE platform, the _current_ driver/firmware
> combo does not support encoding as it requires secure buffer handling
> which is not yet implemented in the kernel (changes to iommu, etc)
>
> So, rather than disabling Venus entirely, I think it makes sense to
> expose the decoder node, which remains fully functional and unaffected
> by the secure buffer requirement.
>
> Hence this commit (so yeah, I am not trying to sneak a fix, I swear!)
grand so.
>
>>
>>> break;
>>> msleep(10);
>>> }
>>> @@ -202,7 +213,8 @@ static u32 to_v4l2_codec_type(u32 codec)
>>> }
>>> }
>>> -static int venus_enumerate_codecs(struct venus_core *core, u32 type)
>>> +static int venus_enumerate_codecs(struct venus_core *core, u32 type,
>>> + const struct venus_min_fw *ver)
>>> {
>>> const struct hfi_inst_ops dummy_ops = {};
>>> struct venus_inst *inst;
>>> @@ -213,6 +225,9 @@ static int venus_enumerate_codecs(struct venus_core *core, u32 type)
>>> if (core->res->hfi_version != HFI_VERSION_1XX)
>>> return 0;
>>> + if (!venus_fw_supports_codec(core, ver))
>>> + return 0;
>> Its not really a codec you're checking there, its a version.
>>
>> The name should reflect that.
>
> but the check isn't just about the firmware version: it is about whether
> the firmware in use supports a specific coded based on the firmware
> version knowledge built in the driver.
No OK "codec" is the right word.
---
bod
next prev parent reply other threads:[~2025-07-17 8:55 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 20:47 [PATCH v7 0/7] media: venus: Add QCM2290 support with AR50_LITE core Jorge Ramirez-Ortiz
2025-07-15 20:47 ` [PATCH v7 1/7] media: dt-bindings: venus: Add qcm2290 dt schema Jorge Ramirez-Ortiz
2025-07-16 23:22 ` Bryan O'Donoghue
2025-07-17 6:35 ` Jorge Ramirez
2025-07-17 6:45 ` Krzysztof Kozlowski
2025-07-17 11:16 ` Jorge Ramirez
2025-07-17 17:00 ` Jorge Ramirez
2025-07-17 17:08 ` Jorge Ramirez
2025-07-18 6:27 ` Krzysztof Kozlowski
2025-07-18 10:02 ` Konrad Dybcio
2025-07-18 10:04 ` Krzysztof Kozlowski
2025-07-18 10:21 ` Konrad Dybcio
2025-07-18 10:21 ` Bryan O'Donoghue
2025-08-04 11:08 ` Jorge Ramirez
2025-07-15 20:47 ` [PATCH v7 2/7] media: venus: Conditionally register codec nodes based on firmware version Jorge Ramirez-Ortiz
2025-07-16 23:37 ` Bryan O'Donoghue
2025-07-17 6:51 ` Jorge Ramirez
2025-07-17 8:55 ` Bryan O'Donoghue [this message]
2025-08-04 11:12 ` Jorge Ramirez
2025-07-15 20:47 ` [PATCH v7 3/7] media: venus: Add support for AR50_LITE video core Jorge Ramirez-Ortiz
2025-07-16 23:50 ` Bryan O'Donoghue
2025-07-17 7:19 ` Jorge Ramirez
2025-07-17 9:29 ` Bryan O'Donoghue
2025-07-17 12:33 ` Jorge Ramirez
2025-08-04 11:15 ` Jorge Ramirez
2025-07-15 20:47 ` [PATCH v7 4/7] media: venus: hfi_plat_v4: Add capabilities for the 4XX lite core Jorge Ramirez-Ortiz
2025-07-17 9:43 ` Bryan O'Donoghue
2025-08-04 10:40 ` Jorge Ramirez
2025-07-15 20:47 ` [PATCH v7 5/7] media: venus: core: Add qcm2290 DT compatible and resource data Jorge Ramirez-Ortiz
2025-07-28 6:16 ` Dikshita Agarwal
2025-07-28 9:39 ` Dmitry Baryshkov
2025-07-15 20:47 ` [PATCH v7 6/7] arm64: dts: qcom: qcm2290: Add Venus video node Jorge Ramirez-Ortiz
2025-07-15 20:47 ` [PATCH v7 7/7] arm64: dts: qcom: qrb2210-rb1: Enable Venus Jorge Ramirez-Ortiz
2025-07-17 9:45 ` Bryan O'Donoghue
2025-07-17 12:33 ` Jorge Ramirez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0dd1f38e-eaba-4c99-b386-4ff8fade5b9b@linaro.org \
--to=bryan.odonoghue@linaro.org \
--cc=amit.kucheria@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=quic_dikshita@quicinc.com \
--cc=quic_vgarodia@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).