summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-10-28drm/amd/display: Change MPC Tree visual confirm coloursJoshua Aberback
[Why] MPC background colours that use fractional components look different if MPC OGAM is in use vs in bypass mode. The current red and orange colours look very similar when OGAM is in bypass, so the colours need to change to be consistently very easy to tell apart. [How] Use colours that only have 0 or MAX values in each component Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Simplify dcn35_is_ips_supported()Alex Hung
[WHAT & HOW] The variable "ips_supported" is redundant and we can return from dcn35_smu_get_ips_supported directly. This fixes 1 UNUSED_VALUE issue reported by Coverity. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Remove useless assignments and variablesAlex Hung
[WHAT & HOW] misc0, temp and split_pipe are assigned but immediately re-assigned to other values. The early assignments are useless and are removed. Unused variables are removed as well. This fixes 5 UNUSED_VALUE issues reported by Coverity. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: fix handling of max_downscale_src_width fail check in SPLSamson Tam
[Why] If max_downscale_src_width check fails, we exit early from spl_calculate_scaler_params but dscl_prog_data is not fully populated. If viewport is left at 0, it can cause crash in dml. [How] Call spl_set_dscl_prog_data before we exit early from spl_calculate_scaler_params to populate dscl_prog_data Populate taps in spl_get_optimal_number_of_taps Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Fix underflow when playing 8K video in full screen modeLeo Ma
[Why&How] Flickering observed while playing 8k HEVC-10 bit video in full screen mode with black border. We didn't support this case for subvp. Make change to the existing check to disable subvp for this corner case. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Leo Ma <hanghong.ma@amd.com> Signed-off-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Refactoring if and endif statements to enable DC_LOGGERLohita Mudimela
[Why] For Header related changes for core [How] Refactoring if and endif statements to enable DC_LOGGER Reviewed-by: Mounika Adhuri <mounika.adhuri@amd.com> Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Lohita Mudimela <lohita.mudimela@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Reduce HPD Detection Interval for IPSFangzhi Zuo
Fix DP Compliance test 4.2.1.3, 4.2.2.8, 4.3.1.12, 4.3.1.13 when IPS enabled. Original HPD detection interval is set to 5s which violates DP compliance. Reduce the interval parameter, such that link training can be finished within 5 seconds. Fixes: afca033f10d3 ("drm/amd/display: Add periodic detection for IPS") Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28Revert "drm/amd/display: update DML2 policy ↵Ovidiu Bunea
EnhancedPrefetchScheduleAccelerationFinal DCN35" This reverts commit 9dad21f910fc ("drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35") [why & how] The offending commit exposes a hang with lid close/open behavior. Both issues seem to be related to ODM 2:1 mode switching, so there is another issue generic to that sequence that needs to be investigated. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Ovidiu Bunea <Ovidiu.Bunea@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Add P-State Stall Timeout Recovery Support for dcn401Dillon Varone
[WHY&HOW] Adds support for P-State stall timeout detection in DCHUBBUB. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Add a boot option to reduce phy ssc for HBR3Hansen Dsouza
[Why] Spread on DPREFCLK by 0.3 percent can have a negative effect on sink when PHY SSC is also spread by 0.3 percent [How] Add boot option for DMU to lower PHY SSC Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amd/display: Optimize power up sequence for specific OLEDOvidiu Bunea
[why & how] OLED power up sequence takes an extra 150ms via hardcoded delay, but there is a strict requirement on DisplayOn resume time. For customer panel, remove these delays to meet target until a cleaner solution is can be put in place. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Ovidiu Bunea <Ovidiu.Bunea@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/amdgpu: drop volatile from ring bufferChristian König
Volatile only prevents the compiler from re-ordering reads and writes. Since we always only modify the ring buffer from one CPU thread and have an explicit barrier before signaling the HW this should have no effect at all and just prevents compiler optimisations. While at it drop the local variables as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-28drm/i915: Use string enable/disable choice helpersSai Teja Pottumuttu
Replace the last few remaining instances of string enable(d)/disable(d) choices with the linux string choice helpers to avoid further cocci warnings. Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023054655.4017489-1-sai.teja.pottumuttu@intel.com
2024-10-28drm/i915/xe2lpd: Update C20 algorithm to include tx_miscGustavo Sousa
There has been an update to the BSpec in which we need to set tx_misc=0x5 field for C20 TX Context programming for HDMI TMDS for Xe2_LPD and newer. That field is mapped to the bits 7:0 of SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, which in turn translates to tx[1] of our state struct. Update the algorithm to reflect this change. v2: - Fix Bspec reference (Sai Teja) - Use struct intel_display instead of drm_i915_private. (Jani) - Use the correct bit width for C20_PHY_TX_MISC_MASK. (Jani) Bspec: 74491 Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> #v1 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-3-gustavo.sousa@intel.com
2024-10-28drm/i915/cx0: Pass crtc_state to intel_c20_compute_hdmi_tmds_pll()Gustavo Sousa
The variable crtc_state already contains everything that intel_c20_compute_hdmi_tmds_pll() needs. Simplify the function's signature by passing that struct instead of separate variables. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-2-gustavo.sousa@intel.com
2024-10-28drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIMMatthew Brost
drm_gpu_scheduler.submit_wq is used to submit jobs, jobs are in the path of dma-fences, and dma-fences are in the path of reclaim. Mark scheduler work queue with WQ_MEM_RECLAIM to ensure forward progress during reclaim; without WQ_MEM_RECLAIM, work queues cannot make forward progress during reclaim. v2: - Fixes tags (Philipp) - Reword commit message (Philipp) Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Philipp Stanner <pstanner@redhat.com> Cc: stable@vger.kernel.org Fixes: 34f50cc6441b ("drm/sched: Use drm sched lockdep map for submit_wq") Fixes: a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than kthread") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023235917.1836428-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-28drm/msm/a6xx: Fix excessive stack usageAkhil P Oommen
Clang-19 and above sometimes end up with multiple copies of the large a6xx_hfi_msg_bw_table structure on the stack. The problem is that a6xx_hfi_send_bw_table() calls a number of device specific functions to fill the structure, but these create another copy of the structure on the stack which gets copied to the first. If the functions get inlined, that busts the warning limit: drivers/gpu/drm/msm/adreno/a6xx_hfi.c:631:12: error: stack frame size (1032) exceeds limit (1024) in 'a6xx_hfi_send_bw_table' [-Werror,-Wframe-larger-than] Fix this by kmalloc-ating struct a6xx_hfi_msg_bw_table instead of using the stack. Also, use this opportunity to skip re-initializing this table to optimize gpu wake up latency. Cc: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/621814/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-28drm/etnaviv: etnaviv_cmdbuf.c: Drop the unneeded include of drm_mm.hSui Jingfeng
The etnaviv_cmdbuf.c doesn't reference any functions or data members defined in drm_mm.h, remove unneeded headers may reduce kernel compile times. Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Drop the 'struct etnaviv_iommu_global::pta_lock' data memberSui Jingfeng
Because it is not get used, drop it. Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: flush shader L1 cache after user commandstreamLucas Stach
The shader L1 cache is a writeback cache for shader loads/stores and thus must be flushed before any BOs backing the shader buffers are potentially freed. Cc: stable@vger.kernel.org Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: always allocate 4K for kernel ringbuffersLucas Stach
Since the kernel ringbuffers are allocated from a larger suballocated area, same as the user commandbufs, they don't need to be CPU page sized. Allocate 4KB for the kernel ring buffers, as we never use more than that. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Map and unmap GPUVA range with respect to the GPUVA sizeSui Jingfeng
Etnaviv assumes that GPU page size is 4KiB, however, GPUVA ranges collision when using softpin capable GPUs on a non 4KiB CPU page size configuration. The root cause is that kernel side BO takes up bigger address space than userspace expect, the size of backing memory of GEM buffer objects are required to align to the CPU PAGE_SIZE. Therefore, results in userspace allocated GPUVA range fails to be inserted to the specified hole exactly. To solve this problem, record the GPU visiable size of a BO firstly, then map and unmap the SG entry strictly with respect to the total GPUVA size. Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Record GPU visible size of GEM BO separatelySui Jingfeng
The GPU visible size of a GEM BO is not necessarily PAGE_SIZE aligned, which happens when CPU page size is not equal to GPU page size. Extra precious resources such as GPU page tables and GPU TLBs may being paid because of this but never get used. Track the size of GPU visible part of GEM BO separately, ensure no GPUVA range wasting by aligning that size to GPU page size. Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: take current primitive into account when checking for hung GPULucas Stach
Large draws can make the GPU appear to be stuck to the current hangcheck logic as the FE address will not move until the draw is finished. However, the FE has a debug register, which records the current primitive ID within a draw. Using this debug register we can extend the timeout as long as the draw progresses. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: update hardware headers from rnndbLucas Stach
Update state_hi.xml.h header from etna_viv commit 8f43a34fd9cd ("rndb: document FE current primitve debug reg") Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: unconditionally enable debug registersLucas Stach
A later change will use the FE debug registers to improve GPU progress monitoring. Instead of having to keep track of the usage state of the debug registers and lock access to the VIVS_HI_CLOCK_CONTROL register, statically enable debug register access during GPU init. The Vivante downstream driver seems to do the same thing since a while, so it should be okay to keep access enabled. (See gckHARDWARE_InitializeHardware in 6.4.11 downstream driver). Many debug registers contain bogus data if clock gating is enabled, so even if they are always accessible performance profiling still needs to manage some prerequisites. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: assert GPU lock held in perfmon pipe_*_read functionsLucas Stach
The perf counter read functions don't just read registers, but they also mutate state to direct the reads towards the correct pipe and engine. Assert that the GPU mutex is held at this point, so that those state changes don't interfere with others. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: hold GPU lock across perfmon samplingLucas Stach
The perfmon sampling mutates shared GPU state (e.g. VIVS_HI_CLOCK_CONTROL to select the pipe for the perf counter reads). To avoid clashing with other functions mutating the same state (e.g. etnaviv_gpu_update_clock) the perfmon sampling needs to hold the GPU lock. Fixes: 68dc0b295dcb ("drm/etnaviv: use 'sync points' for performance monitor requests") Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Replace the '&pdev->dev' with 'dev'Sui Jingfeng
In the etnaviv_pdev_probe() and etnaviv_gpu_platform_probe() function, the value of '&pdev->dev' has been cached to the local auto variable 'dev'. But some callers use 'dev', while the rest use '&pdev->dev'. To keep it consistent, use 'dev' uniformly. Tested-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Fix missing mutex_destroy()Sui Jingfeng
Currently, the calling of mutex_destroy() is ignored on error handling code path. It is safe for now, since mutex_destroy() actually does nothing in non-debug builds. But the mutex_destroy() is used to mark the mutex uninitialized on debug builds, and any subsequent use of the mutex is forbidden. It also could lead to problems if mutex_destroy() gets extended, add missing mutex_destroy() to eliminate potential concerns. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Drop the <linux/pm_runtime.h> headerSui Jingfeng
Currently, the etnaviv_gem_submit.c isn't call any runtime power management functions. So drop this unused header, we can include it back when it really get used though. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Use 'unsigned' type to count the number of pagesSui Jingfeng
The unpin_user_pages() function takes an 'unsigned long' argument to store the number of userspace pages, and the struct drm_gem_object::size is a size_t type. The number of pages can not be negative, hence, use 'unsigned' variable to count the number of pages. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Use unsigned type to count the number of pagesSui Jingfeng
The drm_prime_pages_to_sg() function takes an 'unsigned int' argument to store the length of the page vector. The size of the object in number of CPU pages can not be negative, hence, use 'unsigned' variable to store the number of pages, instead of the 'signed' one. Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/etnaviv: Request pages from DMA32 zone on addressing_limitedXiaolei Wang
Remove __GFP_HIGHMEM when requesting a page from DMA32 zone, and since all vivante GPUs in the system will share the same DMA constraints, move the check of whether to get a page from DMA32 to etnaviv_bind(). Fixes: b72af445cd38 ("drm/etnaviv: request pages from DMA32 zone when needed") Suggested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2024-10-28drm/bridge: tc358767: Fix use of unadjusted mode in the driverMarek Vasut
The driver configures mostly Pixel PLL from the clock cached in local copy of the mode. Make sure the driver uses adjusted mode which contains the updated Pixel PLL settings negotiated in tc_dpi_atomic_check()/tc_edp_atomic_check(). Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241026041057.247640-1-marex@denx.de
2024-10-28drm/xe/hdcp: Fix gsc structure check in fw check statusSuraj Kandpal
Fix the condition for gsc structure validity in gsc_cs_status_check(). It needs to be an OR and not an AND condition Fixes: b4224f6bae38 ("drm/xe/hdcp: Check GSC structure validity") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160834.8785-1-suraj.kandpal@intel.com
2024-10-28drm/omap: Clean up deadcode functionsDr. David Alan Gilbert
dispc_enable_fifomerge() last use was removed by 2012's commit 85099f11bd03 ("Revert "OMAPDSS: APPLY: add fifo merge support funcs"") dispc_has_writeback(), dispc_wb_get_framedone_irq(), dispc_wb_go(), dispc_wb_go_busy() and dispc_wb_setup() were changed from statics to public symbols and unwired from a structure by 2020's commit dac62bcafeaa ("drm/omap: remove dispc_ops") but didn't have any users. dispc_mgr_get_clock_div() got renamed from dispc_get_clock_div() and it's last use was removed in 2011 by commit 42c9dee82129 ("OMAP: DSS2: Remove FB_OMAP_BOOTLOADER_INIT support") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241026220010.93773-1-linux@treblig.org
2024-10-28drm/i915/display: Add Wa_16023981245Nemesa Garg
Disable the support for odd panning in x direction. v2: Replace HSD with WA in commit message [Suraj] Modified the condition for handling odd panning v3: Simplified the condition for checking hsub Using older framework for wa as rev1[Jani] v4: Modify the condition for hsub [Sai Teja] Initialize hsub in else path [Dan] v5: Replace IS_LUNARLAKE with display version. Resolve nitpicks[Jani] v6: Replace -EINVAL with hsub [Suraj] Remove src_w check as not required v7: Remove check for NV12. Add check for PTL as well [Matt] v8: Alignment fix Continuing discussions from: https://patchwork.freedesktop.org/series/136416/ Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028044153.1605209-1-nemesa.garg@intel.com
2024-10-27drm/msm/gpu: Check the status of registration to PM QoSLukasz Luba
There is a need to check the returned value of the registration function. In case of returned error, print that and stop the init process. Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Patchwork: https://patchwork.freedesktop.org/patch/620336/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-27drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()Jinjie Ruan
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Patchwork: https://patchwork.freedesktop.org/patch/614075/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-27drm/msm: Fix some typos in commentShen Lichuan
Fixed some spelling errors, the details are as follows: -in the code comments: collpase->collapse firwmare->firmware everwhere->everywhere Fixes: 2401a0084614 ("drm/msm: gpu: Add support for the GPMU") Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support") Fixes: f97decac5f4c ("drm/msm: Support multiple ringbuffers") Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/614109/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-27drm/msm/a6xx: Add support for A663Puranam V G Tejaswi
Add support for Adreno 663 found on sa8775p based platforms. Signed-off-by: Puranam V G Tejaswi <quic_pvgtejas@quicinc.com> Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/620768/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-27drm/msm/a6xx: Remove logically deadcode in a6xx_preempt.cEverest K.C.
The ternary operator never returns -1 as `ring` will never be NULL. Thus, the ternary operator is not needed. Fix this by removing the ternary operation and only including the value it will return when the `ring` is not NULL. This was reported by Coverity Scan. https://scan7.scan.coverity.com/#/project-view/51525/11354?selectedIssue=1600286 Fixes: 35d36dc1692f ("drm/msm/a6xx: Add traces for preemption") Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> Patchwork: https://patchwork.freedesktop.org/patch/619349/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-10-27drm/msm: Simplify NULL checking in msm_disp_state_dump_regs()Douglas Anderson
The msm_disp_state_dump_regs(): - Doesn't allocate if the caller already allocated. ...but there's one caller and it doesn't allocate so we don't need this check. - Checks for allocation failure over and over even though it could just do it once right after the allocation. Clean this up. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/619660/ Link: https://lore.kernel.org/r/20241014093605.3.I66049c2c17bd82767661f0ecd741b20453da02b2@changeid Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-10-25drm/i915/xe3lpd: Load DMCGustavo Sousa
Load the DMC for Xe3LPD. Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241022155115.50989-1-gustavo.sousa@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2024-10-25drm/i915/display: Cover all possible pipes in TP_printk()Gustavo Sousa
Tracepoints that display frame and scanline counters for all pipes were added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint") and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable tracepoints"). At that time, we only had pipes A, B and C. Now that we can also have pipe D, the TP_printk() calls are missing it. As a quick and dirty fix for that, let's define two common macros to be used for the format and values respectively, and also ensure we raise a build bug if more pipes are added to enum pipe. In the future, we should probably have a way of printing information for available pipes only. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-6-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Do not use ids from enum pipe in TP_printk()Gustavo Sousa
Because much of kernel tracepoints is implemented at the C preprocessor level, C identifiers used in TP_printk() are saved verbatim in the event format, even when they represent compile-time constant values. As an example, we can look at the format for the intel_pipe_enable event: # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt' print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C] We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format. Because tools that interact with kernel tracepoints don't know about those ids, they'll endup failing to parse the format or produce corrupted output. For example, we can see below that trace-cmd repeats PIPE_A's frame/scanline counts for all pipes (probably because it evaluates unknown ids as zero): $ trace-cmd report -F intel_pipe_enable | tail -n5 testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480 testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480 testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400 testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170 testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632 , while in fact we have different values for each pipe, which can be confirmed with the raw view of the events: $ trace-cmd report -R -F intel_pipe_enable | tail -n5 testdisplay-8616 [000] 22048.276758: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [001] 22048.490287: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [003] 22048.700181: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [002] 22049.054220: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A testdisplay-8616 [002] 22049.166851: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B To fix that, we need a fix that looks more like a hack: use macros that result to integer constants instead of enum pipe values. This fixes the issue, but could break if, for whatever unlikely reason, the underlying values in the enum are changed. In the future, we should find a better way to handle this, but for now, the hack took care of the job: $ trace-cmd report -F intel_pipe_enable | tail -n5 testdisplay-9224 [003] 24324.455375: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [002] 24324.669845: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [003] 24324.900105: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [002] 24325.256408: intel_pipe_enable: dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0 testdisplay-9224 [003] 24325.380789: intel_pipe_enable: dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0 v2: - Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Store pipe name in trace eventsGustavo Sousa
The first part[1] of the LWN series on using TRACE_EVENT() mentions about TP_printk(): "Do not create new tracepoint-specific helpers, because that will confuse user-space tools that know about the TRACE_EVENT() helper macros but will not know how to handle ones created for individual tracepoints." It seems this is what we ended up doing when using pipe_name() in TP_printk(). For example, the format for the intel_pipe_update_start event is as follows: # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format name: intel_pipe_update_start ID: 1136 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:__data_loc char[] dev; offset:8; size:4; signed:0; field:enum pipe pipe; offset:12; size:4; signed:1; field:u32 frame; offset:16; size:4; signed:0; field:u32 scanline; offset:20; size:4; signed:0; field:u32 min; offset:24; size:4; signed:0; field:u32 max; offset:28; size:4; signed:0; print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A') and that's how the format is saved. Even though the output from /sys/kernel/debug/tracing/trace will look correct (because it is generated in the kernel), we will see corrupted lines when using a tool like trace-cmd to view the data. While the output looks correct when looking at /sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the trace data with "trace-cmd report": $ trace-cmd report \ > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \ > | cat -v | uniq -c 34 pipe ^A , where ^A is a non-printable character. As a fix, let's store the pipe name directly in the event. The fix was done by applying the following sed script: s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/ s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/ s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/ After these changes, using the same example, we have the following: $ trace-cmd report \ > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \ > | cat -v | sort | uniq -c 396 pipe A 34 pipe B [1] https://lwn.net/Articles/379903/ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Zero-initialize frame/scanline counts in tracepointsGustavo Sousa
In an upcoming change, we will also add support for logging frame/scanline counts for pipe D in relevant tracepoints. In [1], Matt mentioned the possibility of having garbage in those counts for pipe D on a platform containing only 3 pipes. Indeed, it has been verified that the counts for the extra pipe would not be zero-initialized by the tracing system. Since it is also possible that the same would happen for a fused-off pipe, let's go ahead and add the logic to zero-initialize the arrays now. [1] https://lore.kernel.org/all/20240918224927.GU5091@mdroper-desk1.amr.corp.intel.com/ Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-3-gustavo.sousa@intel.com
2024-10-25drm/i915/display: Fix out-of-bounds access in pipe-related tracepointsGustavo Sousa
Some display trace events use array members to store frame and scanline counts for each pipe. However, those arrays are declared with 3 as the hardcoded size, which cause out-of-bounds access when the trace event is enabled on a platform that contains pipe D. For example, when looking at the last 10 intel_pipe_enable events after running IGT's testdisplay, we see the following on a MTL machine that has pipe D available: $ trace-cmd report -R -F intel_pipe_enable \ > | tail \ > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,' testdisplay-6715 [002] 17591.063491: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [003] 17591.264742: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [003] 17591.464541: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [001] 17591.695827: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17591.915841: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17592.127114: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [002] 17592.358351: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [002] 17592.580467: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [000] 17592.950946: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-6715 [004] 17593.079597: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1 Which shows zeros for pipe A's scanline counts. That happens because pipe D's frame counts are overwriting them. Let's fix that by making the arrays bring able to store info for all possible pipes. With the fix, we get the following: $ trace-cmd report -R -F intel_pipe_enable \ > | tail \ > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t \1\n\t\2,' testdisplay-7040 [003] 18067.489565: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18067.699312: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18067.908868: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.122802: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [003] 18068.331019: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.529067: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [003] 18068.742033: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18068.956229: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [002] 18069.295322: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0 testdisplay-7040 [010] 18069.423527: intel_pipe_enable: dev=0000:00:02.0 frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1 Which makes more sense now. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-2-gustavo.sousa@intel.com
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-30 09:19:09 +0000