summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-10-28drm/etnaviv: flush shader L1 cache after user commandstreamLucas Stach1-1/+2
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 Stach1-2/+1
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 Jingfeng1-25/+13
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 Jingfeng2-6/+10
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 Stach2-2/+16
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 Stach1-11/+12
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 Stach1-12/+2
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 Stach1-0/+4
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 Stach1-6/+14
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 Jingfeng2-13/+13
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 Jingfeng5-1/+10
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 Jingfeng1-1/+0
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 Jingfeng1-1/+1
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 Jingfeng1-1/+1
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 Wang2-8/+10
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 Vasut1-1/+1
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 Kandpal1-1/+1
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 Gilbert2-159/+0
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 Garg1-0/+6
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 Luba1-2/+7
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 Ruan1-3/+1
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 Lichuan3-3/+3
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 Tejaswi4-1/+67
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.1-2/+1
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 Anderson1-11/+8
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 Sousa1-1/+7
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 Sousa1-14/+29
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 Sousa1-9/+24
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 Sousa1-63/+63
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 Sousa1-0/+13
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 Sousa1-6/+7
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
2024-10-25drm/sched: warn about drm_sched_job_init()'s partial initPhilipp Stanner1-0/+4
drm_sched_job_init()'s name suggests that after the function succeeded, parameter "job" will be fully initialized. This is not the case; some members are only later set, notably drm_sched_job.sched by drm_sched_job_arm(). Document that drm_sched_job_init() does not set all struct members. Document the lifetime of drm_sched_job.sched. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023141530.113370-2-pstanner@redhat.com
2024-10-25drm/panfrost: Remove unused id_mask from struct panfrost_modelSteven Price1-1/+0
The id_mask field of struct panfrost_model has never been used. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025140008.385081-1-steven.price@arm.com
2024-10-25Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann15-106/+199
Backmerging to get the latest fixes from upstream. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-10-25drm/meson: Allow build with COMPILE_TEST=yVille Syrjälä1-1/+1
Allow meson to be built with COMPILE_TEST=y for greater coverage. Builds fine on x86/x86_64 at least. Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: linux-amlogic@lists.infradead.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003111851.10453-11-ville.syrjala@linux.intel.com Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
2024-10-25drm/mediatek: Allow build with COMPILE_TEST=yVille Syrjälä1-2/+2
Allow mediatek to be built with COMPILE_TEST=y for greater coverage. Builds fine on x86/x86_64 at least. Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: linux-mediatek@lists.infradead.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003111851.10453-10-ville.syrjala@linux.intel.com Reviewed-by: CK Hu <ck.hu@mediatek.com>
2024-10-25drm/imx/dcss: Allow build with COMPILE_TEST=yVille Syrjälä1-1/+1
Allow imx/dcss to be built with COMPILE_TEST=y for greater coverage. Builds fine on x86/x86_64 at least. Cc: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003111851.10453-8-ville.syrjala@linux.intel.com Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
2024-10-25drm/imx/dcss: Fix 64bit divisionsVille Syrjälä1-2/+2
Use the appropriate 64bit division helpers to make the code build on 32bit architectures. Cc: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241003111851.10453-7-ville.syrjala@linux.intel.com Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
2024-10-25Merge tag 'drm-xe-fixes-2024-10-24-1' of ↵Dave Airlie5-7/+42
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Increase invalidation timeout to avoid errors in some hosts (Shuicheng) - Flush worker on timeout (Badal) - Better handling for force wake failure (Shuicheng) - Improve argument check on user fence creation (Nirmoy) - Don't restart parallel queues multiple times on GT reset (Nirmoy) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/trlkoiewtc4x2cyhsxmj3atayyq4zwto4iryea5pvya2ymc3yp@fdx5nhwmiyem
2024-10-25Merge tag 'drm-misc-fixes-2024-10-24' of ↵Dave Airlie2-1/+3
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: bridge: - aux: Fix assignment of OF node - tc358767: Add missing of_node_put() in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241024124921.GA20475@localhost.localdomain
2024-10-25drm/amdgpu: Fix amdgpu_ip_block_hw_fini()Dan Carpenter1-1/+1
This NULL check is reversed so the function doesn't work. Fixes: dad01f93f432 ("drm/amdgpu: validate hw_fini before function call") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/f4fc849e-4e76-4448-8657-caa4c69910b0@stanley.mountain Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25amdgpu: Don't print L2 status if there's nothing to printKent Russell4-3/+18
If a 2nd fault comes in before the 1st is handled, the 1st fault will clear out the FAULT STATUS registers before the 2nd fault is handled. Thus we get a lot of zeroes. If status=0, just skip the L2 fault status information, to avoid confusion of why some VM fault status prints in dmesg are all zeroes. Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amd/display: add missing tracepoint event in DM atomic_commit_tailMelissa Wen1-0/+2
There are two events to trace the beginning and the end of amdgpu_dm_atomic_commit_tail, but only the one ate the beginning was placed. Place amdgpu_dm_atomic_commit_tail_finish tracepoint at the end than. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amdkfd: sever xgmi io link if host driver has disable sharingJonathan Kim3-0/+22
Host drivers can create partial hives per guest by disabling xgmi sharing between certain peers in the main hive. Typically, these partial hives are fully connected per guest session. In the event that the host makes a mistake by adding a non-shared node to a guest session, have the KFD reflect sharing disabled by severing the IO link. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Tested-by: James Yao <yiqing.yao@amd.com> Reviewed-by: Harish Kasiviswanathan <harish.kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amdgpu: refine error handling in amdgpu_ttm_tt_pin_userptrLang Yu1-1/+3
Free sg table when dma_map_sgtable() failed to avoid memory leak. Signed-off-by: Lang Yu <lang.yu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amdgpu: Fix the logic for NPS request failureLijo Lazar1-12/+16
On a hive, NPS request is placed by the first one for all devices in the hive. If the request fails, mark the mode as UNKNOWN so that subsequent devices on unload don't request it. Also, fix the mutex double lock issue in error condition, should have been mutex_unlock. Fixes: ee52489d1210 ("drm/amdgpu: Place NPS mode request on unload") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amdkfd: remove extra use of volatileVictor Zhao2-2/+2
as the adding of mb() should be sufficient in function unmap_queues_cpsch, remove the add of volatile type as recommended Signed-off-by: Victor Zhao <Victor.Zhao@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25drm/amdgpu: Reduce redundant gpu resets on nbio v7.4YiPeng Chai1-2/+1
On nbio v7.4, ras controller interrupt and athub interrupt are generated after injecting UE to PCIE, but gpu reset only needs to be triggered once. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-10-25Merge tag 'drm-intel-fixes-2024-10-24' of ↵Dave Airlie1-2/+1
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix DRM_I915_GVT_KVMGT dependencies in Kconfig Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZxniUlDg59RxOO-6@jlahtine-mobl.ger.corp.intel.com
2024-10-25gpu: drm: omapdrm: use new of_graph functionsKuninori Morimoto2-2/+4
Now we can use new port related functions for port parsing. Use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Acked-by: Helge Deller <deller@gmx.de> Link: https://lore.kernel.org/r/87cyjqb5sh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>