From: Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>,
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 08:51:53 +0200 [thread overview]
Message-ID: <aHidibqhMyexExXJ@trex> (raw)
In-Reply-To: <2fd0d1a7-70ee-43ac-af84-d2321c40e8f8@linaro.org>
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" ?
>
> > + 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!)
>
> > 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.
so really, while the logic involves a version check, it is really about
the codec capability.
I could rename it as is_codec_enabled_by_fw() if the current naming is
not clear.
>
> > +
> > inst = kzalloc(sizeof(*inst), GFP_KERNEL);
> > if (!inst)
> > return -ENOMEM;
> > @@ -288,14 +303,14 @@ static irqreturn_t venus_isr_thread(int irq, void *dev_id)
> > #if defined(CONFIG_OF_DYNAMIC)
> > static int venus_add_video_core(struct venus_core *core, const char *node_name,
> > - const char *compat)
> > + const char *compat, const struct venus_min_fw *ver)
> > {
> > struct of_changeset *ocs = core->ocs;
> > struct device *dev = core->dev;
> > struct device_node *np, *enp;
> > int ret;
> > - if (!node_name)
> > + if (!node_name || !venus_fw_supports_codec(core, ver))
> > return 0;
> > enp = of_find_node_by_name(dev->of_node, node_name);
> > @@ -330,11 +345,13 @@ static int venus_add_dynamic_nodes(struct venus_core *core)
> > of_changeset_init(core->ocs);
> > - ret = venus_add_video_core(core, core->res->dec_nodename, "venus-decoder");
> > + ret = venus_add_video_core(core, core->res->dec_nodename, "venus-decoder",
> > + core->res->dec_minfw);
> > if (ret)
> > goto err;
> > - ret = venus_add_video_core(core, core->res->enc_nodename, "venus-encoder");
> > + ret = venus_add_video_core(core, core->res->enc_nodename, "venus-encoder",
> > + core->res->enc_minfw);
> > if (ret)
> > goto err;
> > @@ -363,6 +380,9 @@ static void venus_remove_dynamic_nodes(struct venus_core *core)
> > #else
> > static int venus_add_dynamic_nodes(struct venus_core *core)
> > {
> > + WARN_ONCE(core->res->enc_minfw || core->res->dec_minfw,
> > + "Feature not supported");
> > +
> > return 0;
> > }
> > @@ -432,7 +452,7 @@ static int venus_probe(struct platform_device *pdev)
> > IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> > "venus", core);
> > if (ret)
> > - goto err_core_put;
> > + goto err_hfi_destroy;
> > venus_assign_register_offsets(core);
> > @@ -448,19 +468,9 @@ static int venus_probe(struct platform_device *pdev)
> > if (ret < 0)
> > goto err_runtime_disable;
> > - if (core->res->dec_nodename || core->res->enc_nodename) {
> > - ret = venus_add_dynamic_nodes(core);
> > - if (ret)
> > - goto err_runtime_disable;
> > - }
> > -
> > - ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
> > - if (ret)
> > - goto err_remove_dynamic_nodes;
> > -
> > ret = venus_firmware_init(core);
> > if (ret)
> > - goto err_of_depopulate;
> > + goto err_runtime_disable;
> > ret = venus_boot(core);
> > if (ret)
> > @@ -474,34 +484,46 @@ static int venus_probe(struct platform_device *pdev)
> > if (ret)
> > goto err_venus_shutdown;
> > - ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_DEC);
> > + if (core->res->dec_nodename || core->res->enc_nodename) {
> > + ret = venus_add_dynamic_nodes(core);
> > + if (ret)
> > + goto err_core_deinit;
> > + }
> > +
> > + ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
> > if (ret)
> > - goto err_core_deinit;
> > + goto err_remove_dynamic_nodes;
> > +
> > + ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_DEC,
> > + core->res->dec_minfw);
> > + if (ret)
> > + goto err_of_depopulate;
> > - ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_ENC);
> > + ret = venus_enumerate_codecs(core, VIDC_SESSION_TYPE_ENC,
> > + core->res->enc_minfw);
> > if (ret)
> > - goto err_core_deinit;
> > + goto err_of_depopulate;
> > ret = pm_runtime_put_sync(dev);
> > if (ret) {
> > pm_runtime_get_noresume(dev);
> > - goto err_core_deinit;
> > + goto err_of_depopulate;
> > }
> > venus_dbgfs_init(core);
> > return 0;
> > +err_of_depopulate:
> > + of_platform_depopulate(dev);
> > +err_remove_dynamic_nodes:
> > + venus_remove_dynamic_nodes(core);
> > err_core_deinit:
> > hfi_core_deinit(core, false);
> > err_venus_shutdown:
> > venus_shutdown(core);
> > err_firmware_deinit:
> > venus_firmware_deinit(core);
> > -err_of_depopulate:
> > - of_platform_depopulate(dev);
> > -err_remove_dynamic_nodes:
> > - venus_remove_dynamic_nodes(core);
> > err_runtime_disable:
> > pm_runtime_put_noidle(dev);
> > pm_runtime_disable(dev);
> > diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> > index 5b1ba1c69adb..3af8386b78be 100644
> > --- a/drivers/media/platform/qcom/venus/core.h
> > +++ b/drivers/media/platform/qcom/venus/core.h
> > @@ -50,6 +50,12 @@ struct bw_tbl {
> > u32 peak_10bit;
> > };
> > +struct venus_min_fw {
> > + u32 major;
> > + u32 minor;
> > + u32 rev;
> > +};
>
> I'd call this venus_firmware_version
I guess you right- doing so will enable future extensibility if we need
to do some different version checks. ok.
>
> > +
> > enum vpu_version {
> > VPU_VERSION_AR50,
> > VPU_VERSION_AR50_LITE,
> > @@ -92,6 +98,8 @@ struct venus_resources {
> > u32 cp_nonpixel_start;
> > u32 cp_nonpixel_size;
> > const char *fwname;
> > + const struct venus_min_fw *enc_minfw;
> > + const struct venus_min_fw *dec_minfw;
>
> and then I'd do as you have done here, indicate that the struct
> venus_firmware_version is a *enc_min_fw_ver;
ack
>
> > const char *enc_nodename;
> > const char *dec_nodename;
> > };
next prev parent reply other threads:[~2025-07-17 6:51 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 [this message]
2025-07-17 8:55 ` Bryan O'Donoghue
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=aHidibqhMyexExXJ@trex \
--to=jorge.ramirez@oss.qualcomm.com \
--cc=amit.kucheria@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.