Video shikra enablement#921
Open
dikshita-agarwal wants to merge 23 commits intoqualcomm-linux:early/hwe/shikra/driversfrom
Open
Video shikra enablement#921dikshita-agarwal wants to merge 23 commits intoqualcomm-linux:early/hwe/shikra/driversfrom
dikshita-agarwal wants to merge 23 commits intoqualcomm-linux:early/hwe/shikra/driversfrom
Conversation
…SC7280 Follow the commit bfe1326 ("venus: Fix for H265 decoding failure.") and increase H265D_MAX_SLICE following firmware requirements on that platform. Otherwise decoding of the H.265 streams fails withthe "insufficient scratch_1 buffer size" from the firmware. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Currently the driver switches the vcodec GDSC to hardware (HW) mode before firmware load and boot sequence. GDSC can be powered off, keeping in hw mode, thereby the vcodec registers programmed in TrustZone (TZ) carry default (reset) values. Move the transition to HW mode after firmware load and boot sequence. The bug was exposed with driver configuring different stream ids to different devices via iommu-map. With registers carrying reset values, VPU would not generate desired stream-id, thereby leading to SMMU fault. The efuse tells us which hardware blocks are actually present. If efuse status is disabled for a block, the driver will skip powering it on or resetting it. otherwise the driver will perform the necessary resets and then switch that block into hardware mode. This makes sure we only touch hardware that really exists and is enabled on the silicon. Fixes: dde659d ("media: iris: Introduce vpu ops for vpu4 with necessary hooks") Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
The PAS ID, the authentication service ID, used by the Iris is a constant and it is not expected to change anytime. Drop it from the platform data and use the constant instead. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The set_preset_registers is (currently) common to all supported devices. Extract it to a iris_vpu_common.c and call it directly from iris_vpu_power_on(). Later, if any of the devices requires special handling, it can be sorted out separately. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
To note that iris_set_num_comv() is gen2-internal, rename it to iris_hfi_gen2_set_num_comv() and then stop using hfi_ops indirection to set session property (like other functions in this file do). Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Calling HFI instance-specific ops should not require double indirection through the core ops. Split instance-specific ops to a separate struct, keep a pointer to it in struct iris_inst and set it directly in the get_instance function. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
There is little point in having two different structures for HFI-related core ops. Merge both of them into the new iris_hfi_ops structure. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The get_instance() is a callback tightly connected to the HFI implementation. Move it into the new iris_hfi_sys_ops structure, merging all core callbacks into a single vtable. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The HW response time is a constant between platforms. Remove it from the iris_platform_data structure and use it directly. Suggested-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Having firmware-related fields in platform data results in the tying platform data to the HFI firmware data rather than the actual hardware. For example, SM8450 uses Gen2 firmware, so currently its platform data should be placed next to the other gen2 platforms, although it has the VPU2.0 core, similar to the one found on SM8250 and SC7280 and so the hardware-specific platform data is also close to those devices. Split firmware data to a separate struct, separating hardware-related data from the firmware interfaces. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Finalize the logical separation of the software and hardware interface descriptions by moving hardware properties to the files specific to the particular VPU version. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The linux-firmware is providing the vpuNN_pM.mbn firmware for SM8250 since August of 2024. Stop using the legacy firmware name (vpu-1.0/venus.mbn) and switch to the standard firmware name schema (vpu/vpu20_p4.mbn). Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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. Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
UBWC configuration is not applicable to all SoCs. Add a check to avoid configuring UBWC during sys init on unsupported platforms. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
The raw formats supported by Iris were previously advertised unconditionally, assuming UBWC support on all platforms. However, some platforms do not support UBWC which results in incorrect format capability exposure. Use the UBWC configuration provided by the platform to dynamically filter raw formats at runtime. If UBWC is not supported, UBWC-based formats are omitted from the advertised capability list, while linear formats remain available. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
The set_preset_registers sequence is currently shared across all supported devices. Starting with Qualcomm QCM2290 (AR50LT), the register programming would differ. Move set_preset_register into a vpu_op to allow per-device customization. This change prepares the driver for upcoming hardware variants. No functional change so far for existing devices. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
The interruot_init sequence is currently shared across all supported devices. Starting with Qualcomm QCM2290 (AR50LT), the register programming would differ. Move interrupt_init into a vpu_op to allow per-device customization. This change prepares the driver for upcoming hardware variants. No functional change so far for existing devices. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
On AR50LT platforms AbsolutelyPerfectRouting (ARP) needs to be disabled so firmware can configure the ARP internal buffer as non-secure for encoder usage. In preparation of adding support for AR50LT platforms, add an optional disable_arp callback to the VPU ops and invoke it from core init and resume paths. No functional change for existing platforms. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
For AR50LT core, the value of WRAPPER_INTR_STATUS_A2HWD_BMASK differs from the currently supported VPUs. In preparation for adding AR50LT support in subsequent patches, introduce a platform data field, wd_intr_mask, to capture the watchdog interrupt bitmask per platform. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
AR50LT require explicit instantaneous bandwidth (IB) voting in addition to average bandwidth (AB) when configuring interconnect QoS. In preparation of adding support for AR50LT core, introduce a platform data flag, icc_ib_vote, to allow platforms to opt for IB voting. When enabled, the peak bandwidth vote is set to 2x the average bandwidth, while existing platforms continue to use AB-only voting (IB = 0). Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Add power sequence for ar5lt core. Add register handling for ar50lt by hooking up vpu op with ar50lt specific implemtation or resue from earlier generation wherever feasible. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Introduces AR50LT buffer size calculation for both encoder and decoder. Reuse the buffer size calculation which are common, while adding the AR50LT specific ones separately. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
Add support for the qcm2290 SoC by introducing a new compatible string for the AR50LT core and the corresponding platform data. This change: - Adds qcm2290 as a supported compatible for the AR50LT core. - Introduces AR50LT-specific platform data describing VPU configuration. - Adds a qcm2290-specific header describing firmware capabilities. Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds the changes to enable support for AR50LT SoC on Iris driver which are needed for Shikra enablement.