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.qualc... --- 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,
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; elsefdata.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.qualc...
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;
base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28 change-id: 20251121-venus-vp9-fix-1ff602724c02
Tested-by: Renjiang Han renjiang.han@oss.qualcomm.com
Best regards,
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; elsefdata.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.qualc...
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;
base-commit: 1f2353f5a1af995efbf7bea44341aa0d03460b28 change-id: 20251121-venus-vp9-fix-1ff602724c02
Best regards,
Dikshita Agarwal dikshita.agarwal@oss.qualcomm.com
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; elsefdata.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.qualc...
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;
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.qualc...
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 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.qualc...
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.qualc...
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
linux-stable-mirror@lists.linaro.org
-
Dikshita Agarwal -
Dmitry Baryshkov -
Renjiang Han