From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bod@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 11/11] media: qcom: iris: extract firmware description data
Date: Tue, 24 Mar 2026 10:31:46 +0530 [thread overview]
Message-ID: <435aac26-ca29-299c-f054-9e91d474c267@oss.qualcomm.com> (raw)
In-Reply-To: <3wp2puizxtd65wdskfzmkst3ju6erk7tv73qhwyl2pmfbbnvz4@3ixjc3a2nvxo>
On 3/23/2026 1:03 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 12:50:32PM +0530, Dikshita Agarwal wrote:
>>
>>
>> On 3/19/2026 11:29 AM, Dmitry Baryshkov wrote:
>>> In preparation to adding support for several firmware revisions to be
>>> used for a platform, extract the firmware description data. It
>>> incorporates firmware name, HFI ops and buffer requirements of the
>>> particular firmware build.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/iris/iris_buffer.c | 2 +-
>>> drivers/media/platform/qcom/iris/iris_core.h | 1 +
>>> drivers/media/platform/qcom/iris/iris_firmware.c | 2 +-
>>> .../platform/qcom/iris/iris_hfi_gen1_command.c | 2 +-
>>> .../platform/qcom/iris/iris_platform_common.h | 15 ++++----
>>> .../media/platform/qcom/iris/iris_platform_vpu2.c | 20 +++++++----
>>> .../media/platform/qcom/iris/iris_platform_vpu3x.c | 41 +++++++++++++++-------
>>> drivers/media/platform/qcom/iris/iris_probe.c | 3 +-
>>> 8 files changed, 57 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
>>> index fbe136360aa1..ef7f6f931557 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
>>> @@ -295,7 +295,7 @@ static void iris_fill_internal_buf_info(struct iris_inst *inst,
>>> {
>>> struct iris_buffers *buffers = &inst->buffers[buffer_type];
>>>
>>> - buffers->size = inst->core->iris_platform_data->get_vpu_buffer_size(inst, buffer_type);
>>> + buffers->size = inst->core->iris_firmware_desc->get_vpu_buffer_size(inst, buffer_type);
>>> buffers->min_count = iris_vpu_buf_count(inst, buffer_type);
>>> }
>>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
>>> index e0ca245c8c63..7f36eb65dcbf 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_core.h
>>> +++ b/drivers/media/platform/qcom/iris/iris_core.h
>>> @@ -99,6 +99,7 @@ struct iris_core {
>>> struct reset_control_bulk_data *controller_resets;
>>> const struct iris_platform_data *iris_platform_data;
>>> const struct iris_firmware_data *iris_firmware_data;
>>> + const struct iris_firmware_desc *iris_firmware_desc;
>>
>> Missing documentation.
>
> Will fix in v10.
>
>>
>>> const struct qcom_ubwc_cfg_data *ubwc_cfg;
>>> enum iris_core_state state;
>>> dma_addr_t iface_q_table_daddr;
>>
>> <snip>
>>
>>> index dd87504c2e67..d36f0c0e785b 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>>> @@ -251,7 +251,8 @@ static int iris_probe(struct platform_device *pdev)
>>> return core->irq;
>>>
>>> core->iris_platform_data = of_device_get_match_data(core->dev);
>>> - core->iris_firmware_data = core->iris_platform_data->firmware_data;
>>> + core->iris_firmware_desc = core->iris_platform_data->firmware_desc;
>>
>> How will iris_firmware_desc be selected once a SoC supports both Gen1 and
>> Gen2 firmware?
>> Today it’s fixed in platform_data, but eventually probe would need to
>> choose between firmware_desc_gen1 / firmware_desc_gen2 based on the generation.
>
> Yes. Looking at the past firmware releases, we might need to implement
> more than one "description", e.g. when upgrading between firmware
> branches would also cause extra side effects (additional codecs, changes
> to the buffer sizes, etc.). But... I'd really prefer to do that in
> steps and only when required.
>
> I'd leave concurrent gen1 / gen2 support that to be implemented in your
> series, if you consider this interface to be worthwhile. Currently every
> platform supports only one firmware "description".
Ack, Thanks.
Regards,
Dikshita
>
next prev parent reply other threads:[~2026-03-24 5:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 5:59 [PATCH v8 00/11] media: qcom: iris: rework platform data handling Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 01/11] media: qcom: iris: drop pas_id from the iris_platform_data struct Dmitry Baryshkov
2026-03-19 9:01 ` Vikash Garodia
2026-03-19 11:44 ` Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 02/11] media: qcom: iris: use common set_preset_registers function Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 03/11] media: qcom: iris: don't use function indirection in gen2-specific code Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 04/11] media: qcom: iris: split HFI session ops from core ops Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 05/11] media: qcom: iris: merge hfi_response_ops and hfi_command_ops Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 06/11] media: qcom: iris: move get_instance to iris_hfi_sys_ops Dmitry Baryshkov
2026-03-19 5:59 ` [PATCH v8 07/11] media: qcom: iris: drop hw_response_timeout_val from platform data Dmitry Baryshkov
2026-03-19 9:03 ` Vikash Garodia
2026-03-23 6:36 ` Dikshita Agarwal
2026-03-19 5:59 ` [PATCH v8 08/11] media: qcom: iris: split firmware_data from raw " Dmitry Baryshkov
2026-03-23 12:29 ` Dikshita Agarwal
2026-03-19 5:59 ` [PATCH v8 09/11] media: qcom: iris: split platform data from firmware data Dmitry Baryshkov
2026-03-23 12:29 ` Dikshita Agarwal
2026-03-19 5:59 ` [PATCH v8 10/11] media: qcom: iris: use new firmware name for SM8250 Dmitry Baryshkov
2026-03-19 9:07 ` Vikash Garodia
2026-03-23 6:37 ` Dikshita Agarwal
2026-03-19 5:59 ` [PATCH v8 11/11] media: qcom: iris: extract firmware description data Dmitry Baryshkov
2026-03-23 7:20 ` Dikshita Agarwal
2026-03-23 7:33 ` Dmitry Baryshkov
2026-03-24 5:01 ` Dikshita Agarwal [this message]
2026-03-23 8:11 ` Dikshita Agarwal
2026-03-23 9:58 ` Dmitry Baryshkov
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=435aac26-ca29-299c-f054-9e91d474c267@oss.qualcomm.com \
--to=dikshita.agarwal@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=bod@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=vikash.garodia@oss.qualcomm.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