Let me give it some background:--- a/drivers/media/platform/qcom/venus/helpers.cThis function doesn't appear to have alot to do with AR50_LITE as it
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -230,6 +230,24 @@ int venus_helper_alloc_dpb_bufs(struct venus_inst *inst)
}
EXPORT_SYMBOL_GPL(venus_helper_alloc_dpb_bufs);
+void venus_helper_prepare_eos_data(struct venus_inst *inst,
+ struct hfi_frame_data *data)
+{
+ struct venus_core *core = inst->core;
+
+ data->buffer_type = HFI_BUFFER_INPUT;
+ data->flags = HFI_BUFFERFLAG_EOS;
+
+ if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
+ return;
+
+ if (IS_V4(core) && is_lite(core) && is_fw_rev_or_older(core, 6, 0, 53))
+ data->alloc_len = 1;
+
+ data->device_addr = 0xdeadb000;
+}
+EXPORT_SYMBOL_GPL(venus_helper_prepare_eos_data);
pertains to IS_V6() and IS_V4().
This I think should be a separate patch with its own commit log to describe
the quite complex logic of version numbers going on here.
According to the HFI specification, EOS (End-of-Stream) buffers must
have 'valid' addresses. While the firmware currently appears to make no
use of the EOS buffer contents, allocating and mapping them would have
been a better driver choice IMO. Hoever this one has better performance
which is probably the reason why it has stayed.
The firmware then does perform operations involving the buffer's size
and length fields, and enforces boundary checks accordingly. On the
AR50_LITE platform, an earlier firmware version lacked a check on
alloc_len, leading to a division-by-zero scenario.
This has been addressed, and we plan to release firmware version 6.0.54,
which includes the necessary boundary check for alloc_len.
I should probaly replace IS_V4(core) && is_lite(core) with
IS_AR50_LITE() instead of trying to give it the appearence of a design
feature.
seems the sensible thing to do, right?