drivers/media/platform/qcom/venus/vdec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
not handle a dummy device address for EOS buffers, so a NULL device
address is sent instead. The existing check used IS_V6() alongside a
firmware version gate:
if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
fdata.device_addr = 0;
else
fdata.device_addr = 0xdeadb000;
However, SC7280 which is also V6, uses a firmware string of the form
"1.0.<commit-hash>", which the version parser translates to 1.0.0. This
unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
condition on SC7280. Combined with IS_V6() matching there as well, the
quirk is incorrectly applied to SC7280, causing VP9 decode failures.
Constrain the check to IRIS2 (SM8250) only, which is the only platform
that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
restores correct behavior on SC7280 (no forced NULL EOS buffer address).
Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
Cc: stable@vger.kernel.org
Reported-by: Mecid <mecid@mecomediagroup.de>
Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
---
Changes in v2:
- Fixed email address for Mecid (Konrad)
- Added inline comment for the quirk (Konrad)
- Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
---
drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
fdata.buffer_type = HFI_BUFFER_INPUT;
fdata.flags |= HFI_BUFFERFLAG_EOS;
- if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
+
+ /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
+ * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
+ * avoids misapplying this quirk and breaking VP9 decode on SC7280.
+ */
+
+ if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
fdata.device_addr = 0;
else
fdata.device_addr = 0xdeadb000;
---
base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
change-id: 20251121-venus-vp9-fix-1ff602724c02
Best regards,
--
Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
On Tue, Nov 25, 2025 at 11:04:19AM +0530, Dikshita Agarwal wrote:
> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
Hmm, interesting. In linux-firmware we have VIDEO.IR.1.0-00005-PROD-4
for SM8250 firmware. This version wouldn't be parsed at all for SM8250
(nor does it follow the format string). Why? Would you please fix
version parsing for this firmware?
> not handle a dummy device address for EOS buffers, so a NULL device
> address is sent instead. The existing check used IS_V6() alongside a
> firmware version gate:
>
> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
> fdata.device_addr = 0;
> else
> fdata.device_addr = 0xdeadb000;
>
> However, SC7280 which is also V6, uses a firmware string of the form
> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
I still think that using commit-hash is a mistake. It doesn't allow any
version checks.
> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
> condition on SC7280. Combined with IS_V6() matching there as well, the
> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
>
> Constrain the check to IRIS2 (SM8250) only, which is the only platform
> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
>
> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
> Cc: stable@vger.kernel.org
> Reported-by: Mecid <mecid@mecomediagroup.de>
> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fixed email address for Mecid (Konrad)
> - Added inline comment for the quirk (Konrad)
> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
> ---
> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
>
> fdata.buffer_type = HFI_BUFFER_INPUT;
> fdata.flags |= HFI_BUFFERFLAG_EOS;
> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> +
> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
> + */
> +
> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> fdata.device_addr = 0;
> else
> fdata.device_addr = 0xdeadb000;
>
> ---
> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
> change-id: 20251121-venus-vp9-fix-1ff602724c02
>
> Best regards,
> --
> Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
--
With best wishes
Dmitry
On 11/26/2025 6:43 AM, Dmitry Baryshkov wrote:
> On Tue, Nov 25, 2025 at 11:04:19AM +0530, Dikshita Agarwal wrote:
>> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
>
> Hmm, interesting. In linux-firmware we have VIDEO.IR.1.0-00005-PROD-4
> for SM8250 firmware. This version wouldn't be parsed at all for SM8250
> (nor does it follow the format string). Why? Would you please fix
> version parsing for this firmware?
Right, Seems this firmware doesn't have the proper version string, I will
upload a new binary with proper version string soon.
>
>> not handle a dummy device address for EOS buffers, so a NULL device
>> address is sent instead. The existing check used IS_V6() alongside a
>> firmware version gate:
>>
>> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
>> fdata.device_addr = 0;
>> else
>> fdata.device_addr = 0xdeadb000;
>>
>> However, SC7280 which is also V6, uses a firmware string of the form
>> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
>
> I still think that using commit-hash is a mistake. It doesn't allow any
> version checks.
Agree, we had this discussion with firmware team sometime back and for all
latest firmware they are having rel version in the firmware binary, but
SC7280 firmware binary would still have commit hash in version string.
Thanks,
Dikshita
>
>> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
>> condition on SC7280. Combined with IS_V6() matching there as well, the
>> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
>>
>> Constrain the check to IRIS2 (SM8250) only, which is the only platform
>> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
>> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
>>
>> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
>> Cc: stable@vger.kernel.org
>> Reported-by: Mecid <mecid@mecomediagroup.de>
>> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
>> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
>> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
>> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Fixed email address for Mecid (Konrad)
>> - Added inline comment for the quirk (Konrad)
>> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
>> ---
>> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
>> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
>> --- a/drivers/media/platform/qcom/venus/vdec.c
>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
>>
>> fdata.buffer_type = HFI_BUFFER_INPUT;
>> fdata.flags |= HFI_BUFFERFLAG_EOS;
>> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
>> +
>> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
>> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
>> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
>> + */
>> +
>> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
>> fdata.device_addr = 0;
>> else
>> fdata.device_addr = 0xdeadb000;
>>
>> ---
>> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
>> change-id: 20251121-venus-vp9-fix-1ff602724c02
>>
>> Best regards,
>> --
>> Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>
>
On Wed, 26 Nov 2025 at 08:02, Dikshita Agarwal
<dikshita.agarwal@oss.qualcomm.com> wrote:
>
>
>
> On 11/26/2025 6:43 AM, Dmitry Baryshkov wrote:
> > On Tue, Nov 25, 2025 at 11:04:19AM +0530, Dikshita Agarwal wrote:
> >> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
> >
> > Hmm, interesting. In linux-firmware we have VIDEO.IR.1.0-00005-PROD-4
> > for SM8250 firmware. This version wouldn't be parsed at all for SM8250
> > (nor does it follow the format string). Why? Would you please fix
> > version parsing for this firmware?
>
> Right, Seems this firmware doesn't have the proper version string, I will
> upload a new binary with proper version string soon.
That's fine, but also we need to fix the driver to correctly work with
the firmware we currently have in linux-firmware.
>
> >
> >> not handle a dummy device address for EOS buffers, so a NULL device
> >> address is sent instead. The existing check used IS_V6() alongside a
> >> firmware version gate:
> >>
> >> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
> >> fdata.device_addr = 0;
> >> else
> >> fdata.device_addr = 0xdeadb000;
> >>
> >> However, SC7280 which is also V6, uses a firmware string of the form
> >> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
> >
> > I still think that using commit-hash is a mistake. It doesn't allow any
> > version checks.
>
> Agree, we had this discussion with firmware team sometime back and for all
> latest firmware they are having rel version in the firmware binary, but
> SC7280 firmware binary would still have commit hash in version string.
What prevents us from updating SC7280 firmware to also include :rel-NNN part?
>
> Thanks,
> Dikshita
> >
> >> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
> >> condition on SC7280. Combined with IS_V6() matching there as well, the
> >> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
> >>
> >> Constrain the check to IRIS2 (SM8250) only, which is the only platform
> >> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
> >> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
> >>
> >> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
> >> Cc: stable@vger.kernel.org
> >> Reported-by: Mecid <mecid@mecomediagroup.de>
> >> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
> >> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> >> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> >> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> >> ---
> >> Changes in v2:
> >> - Fixed email address for Mecid (Konrad)
> >> - Added inline comment for the quirk (Konrad)
> >> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
> >> ---
> >> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> >> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
> >> --- a/drivers/media/platform/qcom/venus/vdec.c
> >> +++ b/drivers/media/platform/qcom/venus/vdec.c
> >> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
> >>
> >> fdata.buffer_type = HFI_BUFFER_INPUT;
> >> fdata.flags |= HFI_BUFFERFLAG_EOS;
> >> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> >> +
> >> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
> >> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
> >> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
> >> + */
> >> +
> >> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> >> fdata.device_addr = 0;
> >> else
> >> fdata.device_addr = 0xdeadb000;
> >>
> >> ---
> >> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
> >> change-id: 20251121-venus-vp9-fix-1ff602724c02
> >>
> >> Best regards,
> >> --
> >> Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> >>
> >
--
With best wishes
Dmitry
On 11/26/2025 2:13 PM, Dmitry Baryshkov wrote:
> On Wed, 26 Nov 2025 at 08:02, Dikshita Agarwal
> <dikshita.agarwal@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 11/26/2025 6:43 AM, Dmitry Baryshkov wrote:
>>> On Tue, Nov 25, 2025 at 11:04:19AM +0530, Dikshita Agarwal wrote:
>>>> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
>>>
>>> Hmm, interesting. In linux-firmware we have VIDEO.IR.1.0-00005-PROD-4
>>> for SM8250 firmware. This version wouldn't be parsed at all for SM8250
>>> (nor does it follow the format string). Why? Would you please fix
>>> version parsing for this firmware?
>>
>> Right, Seems this firmware doesn't have the proper version string, I will
>> upload a new binary with proper version string soon.
>
> That's fine, but also we need to fix the driver to correctly work with
> the firmware we currently have in linux-firmware.
>
The current firmware with version string VIDEO.IR.1.0-00005-PROD-4 works
correctly with this logic. Since VIDEO.IR.1.0-00005 is not a valid version,
it is parsed as 0.0.0, so the condition is not met—which is expected for
this firmware, as it supports EOS using a dummy address.
>>
>>>
>>>> not handle a dummy device address for EOS buffers, so a NULL device
>>>> address is sent instead. The existing check used IS_V6() alongside a
>>>> firmware version gate:
>>>>
>>>> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
>>>> fdata.device_addr = 0;
>>>> else
>>>> fdata.device_addr = 0xdeadb000;
>>>>
>>>> However, SC7280 which is also V6, uses a firmware string of the form
>>>> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
>>>
>>> I still think that using commit-hash is a mistake. It doesn't allow any
>>> version checks.
>>
>> Agree, we had this discussion with firmware team sometime back and for all
>> latest firmware they are having rel version in the firmware binary, but
>> SC7280 firmware binary would still have commit hash in version string.
>
> What prevents us from updating SC7280 firmware to also include :rel-NNN part?
>
We are working with firmware team on this, future firmware releases for
SC7280 would have video.firmware.1.0-<rel_version_number>
Thanks,
Dikshita
>>
>> Thanks,
>> Dikshita
>>>
>>>> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
>>>> condition on SC7280. Combined with IS_V6() matching there as well, the
>>>> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
>>>>
>>>> Constrain the check to IRIS2 (SM8250) only, which is the only platform
>>>> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
>>>> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
>>>>
>>>> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
>>>> Cc: stable@vger.kernel.org
>>>> Reported-by: Mecid <mecid@mecomediagroup.de>
>>>> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
>>>> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
>>>> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
>>>> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>>> ---
>>>> Changes in v2:
>>>> - Fixed email address for Mecid (Konrad)
>>>> - Added inline comment for the quirk (Konrad)
>>>> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
>>>> ---
>>>> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
>>>> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
>>>> --- a/drivers/media/platform/qcom/venus/vdec.c
>>>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>>>> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
>>>>
>>>> fdata.buffer_type = HFI_BUFFER_INPUT;
>>>> fdata.flags |= HFI_BUFFERFLAG_EOS;
>>>> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
>>>> +
>>>> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
>>>> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
>>>> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
>>>> + */
>>>> +
>>>> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
>>>> fdata.device_addr = 0;
>>>> else
>>>> fdata.device_addr = 0xdeadb000;
>>>>
>>>> ---
>>>> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
>>>> change-id: 20251121-venus-vp9-fix-1ff602724c02
>>>>
>>>> Best regards,
>>>> --
>>>> Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>>>
>>>
>
>
>
On Wed, 26 Nov 2025 at 11:49, Dikshita Agarwal
<dikshita.agarwal@oss.qualcomm.com> wrote:
>
>
>
> On 11/26/2025 2:13 PM, Dmitry Baryshkov wrote:
> > On Wed, 26 Nov 2025 at 08:02, Dikshita Agarwal
> > <dikshita.agarwal@oss.qualcomm.com> wrote:
> >>
> >>
> >>
> >> On 11/26/2025 6:43 AM, Dmitry Baryshkov wrote:
> >>> On Tue, Nov 25, 2025 at 11:04:19AM +0530, Dikshita Agarwal wrote:
> >>>> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
> >>>
> >>> Hmm, interesting. In linux-firmware we have VIDEO.IR.1.0-00005-PROD-4
> >>> for SM8250 firmware. This version wouldn't be parsed at all for SM8250
> >>> (nor does it follow the format string). Why? Would you please fix
> >>> version parsing for this firmware?
> >>
> >> Right, Seems this firmware doesn't have the proper version string, I will
> >> upload a new binary with proper version string soon.
> >
> > That's fine, but also we need to fix the driver to correctly work with
> > the firmware we currently have in linux-firmware.
> >
>
> The current firmware with version string VIDEO.IR.1.0-00005-PROD-4 works
> correctly with this logic. Since VIDEO.IR.1.0-00005 is not a valid version,
> it is parsed as 0.0.0, so the condition is not met—which is expected for
> this firmware, as it supports EOS using a dummy address.
The firmware was there for almost 8 months, e.g. hitting Debian
stable. Please send a patch, fixing parsing of the version string.
> >>>> not handle a dummy device address for EOS buffers, so a NULL device
> >>>> address is sent instead. The existing check used IS_V6() alongside a
> >>>> firmware version gate:
> >>>>
> >>>> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
> >>>> fdata.device_addr = 0;
> >>>> else
> >>>> fdata.device_addr = 0xdeadb000;
> >>>>
> >>>> However, SC7280 which is also V6, uses a firmware string of the form
> >>>> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
> >>>
> >>> I still think that using commit-hash is a mistake. It doesn't allow any
> >>> version checks.
> >>
> >> Agree, we had this discussion with firmware team sometime back and for all
> >> latest firmware they are having rel version in the firmware binary, but
> >> SC7280 firmware binary would still have commit hash in version string.
> >
> > What prevents us from updating SC7280 firmware to also include :rel-NNN part?
> >
>
> We are working with firmware team on this, future firmware releases for
> SC7280 would have video.firmware.1.0-<rel_version_number>
>
> Thanks,
> Dikshita
> >>
> >> Thanks,
> >> Dikshita
> >>>
> >>>> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
> >>>> condition on SC7280. Combined with IS_V6() matching there as well, the
> >>>> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
> >>>>
> >>>> Constrain the check to IRIS2 (SM8250) only, which is the only platform
> >>>> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
> >>>> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
> >>>>
> >>>> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
> >>>> Cc: stable@vger.kernel.org
> >>>> Reported-by: Mecid <mecid@mecomediagroup.de>
> >>>> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
> >>>> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> >>>> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> >>>> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> >>>> ---
> >>>> Changes in v2:
> >>>> - Fixed email address for Mecid (Konrad)
> >>>> - Added inline comment for the quirk (Konrad)
> >>>> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
> >>>> ---
> >>>> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
> >>>> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> >>>> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
> >>>> --- a/drivers/media/platform/qcom/venus/vdec.c
> >>>> +++ b/drivers/media/platform/qcom/venus/vdec.c
> >>>> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
> >>>>
> >>>> fdata.buffer_type = HFI_BUFFER_INPUT;
> >>>> fdata.flags |= HFI_BUFFERFLAG_EOS;
> >>>> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> >>>> +
> >>>> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
> >>>> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
> >>>> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
> >>>> + */
> >>>> +
> >>>> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> >>>> fdata.device_addr = 0;
> >>>> else
> >>>> fdata.device_addr = 0xdeadb000;
> >>>>
> >>>> ---
> >>>> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
> >>>> change-id: 20251121-venus-vp9-fix-1ff602724c02
> >>>>
> >>>> Best regards,
> >>>> --
> >>>> Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> >>>>
> >>>
> >
> >
> >
--
With best wishes
Dmitry
On 11/25/2025 1:34 PM, Dikshita Agarwal wrote:
> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
> not handle a dummy device address for EOS buffers, so a NULL device
> address is sent instead. The existing check used IS_V6() alongside a
> firmware version gate:
>
> if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
> fdata.device_addr = 0;
> else
> fdata.device_addr = 0xdeadb000;
>
> However, SC7280 which is also V6, uses a firmware string of the form
> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
> condition on SC7280. Combined with IS_V6() matching there as well, the
> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
>
> Constrain the check to IRIS2 (SM8250) only, which is the only platform
> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
>
> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
> Cc: stable@vger.kernel.org
> Reported-by: Mecid <mecid@mecomediagroup.de>
> Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222
> Co-developed-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fixed email address for Mecid (Konrad)
> - Added inline comment for the quirk (Konrad)
> - Link to v1: https://lore.kernel.org/r/20251124-venus-vp9-fix-v1-1-2ff36d9f2374@oss.qualcomm.com
> ---
> drivers/media/platform/qcom/venus/vdec.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> index 4a6641fdffcf79705893be58c7ec5cf485e2fab9..6b3d5e59133e6902353d15c24c8bbaed4fcb6808 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -565,7 +565,13 @@ vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd)
>
> fdata.buffer_type = HFI_BUFFER_INPUT;
> fdata.flags |= HFI_BUFFERFLAG_EOS;
> - if (IS_V6(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> +
> + /* Send NULL EOS addr for only IRIS2 (SM8250),for firmware <= 1.0.87.
> + * SC7280 also reports "1.0.<hash>" parsed as 1.0.0; restricting to IRIS2
> + * avoids misapplying this quirk and breaking VP9 decode on SC7280.
> + */
> +
> + if (IS_IRIS2(inst->core) && is_fw_rev_or_older(inst->core, 1, 0, 87))
> fdata.device_addr = 0;
> else
> fdata.device_addr = 0xdeadb000;
>
> ---
> base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28
> change-id: 20251121-venus-vp9-fix-1ff602724c02
Tested-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
>
> Best regards,
--
Best regards,
Renjiang Han
© 2016 - 2025 Red Hat, Inc.