summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gt
AgeCommit message (Collapse)AuthorFilesLines
2024-02-13drm/i915/selftests: Increasing the sleep time for live_rc6_manualAnirban Sk1-2/+2
Sometimes gt_pm live_rc6_manual selftest fails due to no power being measured for the rc6 disabled period. Therefore increasing the rc6 disable period from 250ms to 1000ms to rule out such sporadic failure. v3: - More descriptive and improved commit message (Anshuman) Signed-off-by: Anirban Sk <sk.anirban@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212050738.1162198-1-sk.anirban@intel.com
2024-02-09drm/i915: use drm_printf() with the drm_err_printer intead of pr_err()Jani Nikula1-3/+3
There's already a related drm_printer. Use it to preserve the context instead of a separate pr_err(). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/246c0c275d05c919d959983e1784e3f7347f4540.1705410327.git.jani.nikula@intel.com
2024-02-09drm/i915: switch from drm_debug_printer() to device specific drm_dbg_printer()Jani Nikula4-4/+8
Prefer the device specific debug printer. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/f2614dfcba295be20c650cdab24c3979d265f422.1705410327.git.jani.nikula@intel.com
2024-02-09drm/print: make drm_err_printer() device specific by using drm_err()Jani Nikula1-2/+2
With few users for drm_err_printer(), it's still feasible to convert it to be device specific. Use drm_err() under the hood. While at it, make the prefix optional. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/2a9cdcfc1df44568078f7c131e2e7e0f7c94e97e.1705410327.git.jani.nikula@intel.com
2024-02-07drm/i915: Rename the DSM/GSM registersVille Syrjälä2-2/+2
0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. v2: Rebase Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-7-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Disable the "binder"Ville Syrjälä1-1/+2
Now that the GGTT PTE updates go straight to GSMBASE (bypassing GTTMMADR) there should be no more risk of system hangs? So the "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer necessary, disable it. My main worry with the MI_UPDATE_GTT are: - only used on this one platform so very limited testing coverage - async so more opprtunities to screw things up - what happens if the engine hangs while we're waiting for MI_UPDATE_GTT to finish? - requires working command submission, so even getting a working display now depends on a lot more extra components working correctly TODO: MI_UPDATE_GTT might be interesting as an optimization though, so perhaps someone should look into always using it (assuming the GPU is alive and well)? v2: Keep using MI_UPDATE_GTT on VM guests v3: use i915_direct_stolen_access() Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-6-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory accessVille Syrjälä1-1/+9
On MTL accessing stolen memory via the BARs is somehow borked, and it can hang the machine. As a workaround let's bypass the BARs and just go straight to DSMBASE/GSMBASE instead. Note that on every other platform this itself would hang the machine, but on MTL the system firmware is expected to relax the access permission guarding stolen memory to enable this workaround, and thus direct CPU accesses should be fine. The raw stolen memory areas won't be passed to VMs so we'll need to risk using the BAR there for the initial setup. Once command submission is up we should switch to MI_UPDATE_GTT which at least shouldn't hang the whole machine. v2: Don't use direct GSM/DSM access on guests Add w/a number v3: Check register 0x138914 to see if pcode did its job Add some debug prints Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Remove ad-hoc lmem/stolen debugsVille Syrjälä1-3/+0
Now that intel_memory_regions_hw_probe() prints out each and every memory region there's no reason to have ad-hoc debugs to do similar things elsewhere. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-4-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Use struct resource for memory region IO as wellVille Syrjälä2-10/+5
mem->region is a struct resource, but mem->io_start and mem->io_size are not for whatever reason. Let's unify this and convert the io stuff into a struct resource as well. Should make life a little less annoying when you don't have juggle between two different approaches all the time. Mostly done using cocci (with manual tweaks at all the places where we mutate io_size by hand): @@ struct intel_memory_region *M; expression START, SIZE; @@ - M->io_start = START; - M->io_size = SIZE; + M->io = DEFINE_RES_MEM(START, SIZE); @@ struct intel_memory_region *M; @@ - M->io_start + M->io.start @@ struct intel_memory_region M; @@ - M.io_start + M.io.start @@ expression M; @@ - M->io_size + resource_size(&M->io) @@ expression M; @@ - M.io_size + resource_size(&M.io) Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-2-ville.syrjala@linux.intel.com
2024-01-24drm/i915/gt: Reflect the true and current status of rc6_enableJuan Escamilla1-2/+2
The sysfs file is named 'enabled', thus users might want to know the true state of the RC6 instead of only the indication if the RC6 should be enabled. Let's use rc6.enable directly instead of rc6.supported. Signed-off-by: Juan Escamilla <jcescami@wasd.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240116172922.3460695-1-jcescami@wasd.net
2024-01-19drm/i915/xelpg: Extend some workarounds/tuning to gfx version 12.74Matt Roper2-11/+17
Some of our existing Xe_LPG workarounds and tuning are also applicable to the version 12.74 variant. Extend the condition bounds accordingly. Also fix the comment on Wa_14018575942 while we're at it. v2: Extend some more workarounds (Harish) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240108122738.14399-4-haridhar.kalvala@intel.com
2024-01-19drm/i915/xelpg: Extend driver code of Xe_LPG to Xe_LPG+Harish Chegondi3-3/+4
Xe_LPG+ (IP version 12.74) should take the same general code paths as Xe_LPG (versions 12.70 and 12.71). Xe_LPG+'s workaround list will be handled by the next patch. Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240108122738.14399-3-haridhar.kalvala@intel.com
2024-01-10drm/i915/gt: Use rc6.supported flag from intel_gt for rc6_enable sysfsJuan Escamilla1-16/+2
Currently if rc6 is supported, it gets enabled and the sysfs files for rc6_enable_show and rc6_enable_dev_show uses masks to check information from drm_i915_private. However rc6_support functions take more variables and conditions into consideration and thus these masks are not enough for most of the modern hardware and it is simpley lyting to the user. Let's fix it by at least use the rc6.supported flag from intel_gt information. Signed-off-by: Juan Escamilla <jcescami@wasd.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240110010302.553597-1-jcescami@wasd.net
2024-01-10drm/i915/guc: reconcile Excess struct member kernel-doc warningsRandy Dunlap1-33/+42
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'num_guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_bitmap' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_id_list' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_in_use' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_contexts' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_mask' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_delay_ms' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_gucid_threshold' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'gt_stamp' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'ping_delay' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'work' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'shift' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'last_stat_jiffies' description in 'intel_guc' 18 warnings as Errors Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231226195432.10891-3-rdunlap@infradead.org (cherry picked from commit e4cf1a70fad3e2107503e99cfe9cc0c9cba19dad) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-01-10drm/i915/gt: reconcile Excess struct member kernel-doc warningsRandy Dunlap1-2/+5
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in 'intel_gsc' Also add missing field member descriptions. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231228234946.12405-1-rdunlap@infradead.org (cherry picked from commit cd1d91115ff1929ec346d85f512ef260ddf8131e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-01-10Merge tag 'drm-intel-gt-next-2023-12-15' of ↵Dave Airlie3-4/+7
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Eliminate use of kmap_atomic() in i915 (Zhao) - Add Wa_14019877138 for DG2 (Haridhar) - Static checker and spelling fixes (Colin, Karthik, Randy) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZXxCibZZQqlqhDN3@jlahtine-mobl.ger.corp.intel.com
2024-01-09drm/i915/guc: Avoid circular locking issue on busyness flushJohn Harrison2-2/+48
Avoid the following lockdep complaint: <4> [298.856498] ====================================================== <4> [298.856500] WARNING: possible circular locking dependency detected <4> [298.856503] 6.7.0-rc5-CI_DRM_14017-g58ac4ffc75b6+ #1 Tainted: G N <4> [298.856505] ------------------------------------------------------ <4> [298.856507] kworker/4:1H/190 is trying to acquire lock: <4> [298.856509] ffff8881103e9978 (&gt->reset.backoff_srcu){++++}-{0:0}, at: _intel_gt_reset_lock+0x35/0x380 [i915] <4> [298.856661] but task is already holding lock: <4> [298.856663] ffffc900013f7e58 ((work_completion)(&(&guc->timestamp.work)->work)){+.+.}-{0:0}, at: process_scheduled_works+0x264/0x530 <4> [298.856671] which lock already depends on the new lock. The complaint is not actually valid. The busyness worker thread does indeed hold the worker lock and then attempt to acquire the reset lock (which may have happened in reverse order elsewhere). However, it does so with a trylock that exits if the reset lock is not available (specifically to prevent this and other similar deadlocks). Unfortunately, lockdep does not understand the trylock semantics (the lock is an i915 specific custom implementation for resets). Not doing a synchronous flush of the worker thread when a reset is in progress resolves the lockdep splat by never even attempting to grab the lock in this particular scenario. There are situatons where a synchronous cancel is required, however. So, always do the synchronous cancel if not in reset. And add an extra synchronous cancel to the end of the reset flow to account for when a reset is occurring at driver shutdown and the cancel is no longer synchronous but could lead to unallocated memory accesses if the worker is not stopped. Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20231219195957.212600-1-John.C.Harrison@Intel.com
2024-01-09drm/i915/guc: Close deregister-context race against CT-lossAlan Previn1-5/+68
If we are at the end of suspend or very early in resume its possible an async fence signal (via rcu_call) is triggered to free_engines which could lead us to the execution of the context destruction worker (after a prior worker flush). Thus, when suspending, insert rcu_barriers at the start of i915_gem_suspend (part of driver's suspend prepare) and again in i915_gem_suspend_late so that all such cases have completed and context destruction list isn't missing anything. In destroyed_worker_func, close the race against CT-loss by checking that CT is enabled before calling into deregister_destroyed_contexts. Based on testing, guc_lrc_desc_unpin may still race and fail as we traverse the GuC's context-destroy list because the CT could be disabled right before calling GuC's CT send function. We've witnessed this race condition once every ~6000-8000 suspend-resume cycles while ensuring workloads that render something onscreen is continuously started just before we suspend (and the workload is small enough to complete and trigger the queued engine/context free-up either very late in suspend or very early in resume). In such a case, we need to unroll the entire process because guc-lrc-unpin takes a gt wakeref which only gets released in the G2H IRQ reply that never comes through in this corner case. Without the unroll, the taken wakeref is leaked and will cascade into a kernel hang later at the tail end of suspend in this function: intel_wakeref_wait_for_idle(&gt->wakeref) (called by) - intel_gt_pm_wait_for_idle (called by) - wait_for_suspend Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_- contexts if guc_lrc_desc_unpin fails due to CT send falure. When unrolling, keep the context in the GuC's destroy-list so it can get picked up on the next destroy worker invocation (if suspend aborted) or get fully purged as part of a GuC sanitization (end of suspend) or a reset flow. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Tested-by: Mousumi Jana <mousumi.jana@intel.com> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231229215143.581619-1-alan.previn.teres.alexis@intel.com
2024-01-09drm/i915/guc: Flush context destruction worker at suspendAlan Previn3-0/+9
When suspending, flush the context-guc-id deregistration worker at the final stages of intel_gt_suspend_late when we finally call gt_sanitize that eventually leads down to __uc_sanitize so that the deregistration worker doesn't fire off later as we reset the GuC microcontroller. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Mousumi Jana <mousumi.jana@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231228045558.536585-2-alan.previn.teres.alexis@intel.com
2024-01-06drm/i915/huc: Allow for very slow HuC loadingJohn Harrison2-11/+63
A failure to load the HuC is occasionally observed where the cause is believed to be a low GT frequency leading to very long load times. So a) increase the timeout so that the user still gets a working system even in the case of slow load. And b) report the frequency during the load to see if that is the cause of the slow down. Also update the similar code on the GuC load to not use uncore->gt when there is a local gt available. The two should match, but no need for unnecessary de-referencing. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102222202.310495-1-John.C.Harrison@Intel.com
2024-01-05drm/i915/xelpg: Add workaround 14019877138Tejas Upadhyay1-0/+3
WA 14019877138 needed for Graphics 12.70/71 both V2(Jani): - Use drm/i915 Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103053111.763172-1-tejas.upadhyay@intel.com
2024-01-02drm/i915/guc: Change wa and EU_PERF_CNTL registers to MCR typeShuicheng Lin1-8/+13
Some of the wa registers are MCR register, and EU_PERF_CNTL registers are MCR register. MCR register needs extra process for read/write. As normal MMIO register also could work with the MCR register process, change all wa registers to MCR type for code simplicity. Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102010231.843778-1-shuicheng.lin@intel.com
2023-12-29drm/i915/guc: reconcile Excess struct member kernel-doc warningsRandy Dunlap1-33/+42
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'num_guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_bitmap' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_id_list' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_in_use' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_contexts' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_mask' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_delay_ms' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_gucid_threshold' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'gt_stamp' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'ping_delay' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'work' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'shift' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'last_stat_jiffies' description in 'intel_guc' 18 warnings as Errors Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231226195432.10891-3-rdunlap@infradead.org
2023-12-29drm/i915/gt: reconcile Excess struct member kernel-doc warningsRandy Dunlap1-2/+5
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in 'intel_gsc' Also add missing field member descriptions. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231228234946.12405-1-rdunlap@infradead.org
2023-12-15drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.cZhao Liu1-4/+1
The use of kmap_atomic() is being deprecated in favor of kmap_local_page()[1], and this patch converts the call from kmap_atomic() to kmap_local_page(). The main difference between atomic and local mappings is that local mappings doesn't disable page faults or preemption (the preemption is disabled for !PREEMPT_RT case, otherwise it only disables migration). With kmap_local_page(), we can avoid the often unwanted side effect of unnecessary page faults or preemption disables. In drm/i915/gt/uc/intel_us_fw.c, the function intel_uc_fw_copy_rsa() just use the mapping to do memory copy so it doesn't need to disable pagefaults and preemption for mapping. Thus the local mapping without atomic context (not disable pagefaults / preemption) is enough. Therefore, intel_uc_fw_copy_rsa() is a function where the use of memcpy_from_page() with kmap_local_page() in place of memcpy() with kmap_atomic() is correctly suited. Convert the calls of memcpy() with kmap_atomic() / kunmap_atomic() to memcpy_from_page() which uses local mapping to copy. [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com/T/#u Suggested-by: Ira Weiny <ira.weiny@intel.com> Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231203132947.2328805-8-zhao1.liu@linux.intel.com
2023-12-15drm/i915: Add Wa_14019877138Haridhar Kalvala2-0/+6
Enable Force Dispatch Ends Collection for DG2. BSpec: 46001 Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213064612.480032-1-haridhar.kalvala@intel.com
2023-12-13Merge tag 'drm-intel-gt-next-2023-12-08' of ↵Dave Airlie45-133/+547
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - drm/i915: Implement fdinfo memory stats printing Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. Cross-subsystem Changes: - Backmerge of drm-next (to bring drm-intel-next for PXP changes) Driver Changes: - Wa_18028616096 now applies to all DG2 (Matt R) - Drop Wa_22014600077 on all DG2 (Matt R) - Add new ATS-M device ID (Haridhar) - More Meteorlake (MTL) workarounds (Matt R, Dnyaneshwar, Jonathan, Gustavo, Radhakrishna) - PMU WARN_ON cleanup on driver unbind (Umesh) - Limit GGTT WC flushing workaround to pre BXT/ICL platforms - Complement implementation for Wa_16018031267 / Wa_16018063123 (Andrzej, Jonathan, Nirmoy, Chris) - Properly print internal GSC engine in trace logs (Tvrtko) - Track gt pm wakerefs (Andrzej) - Fix null deref bugs on perf code when perf is disabled (Harshit, Tvrtko) - Fix __i915_request_create memory leak on driver unbind (Andrzej) - Remove spurious unsupported HuC message on MTL (Daniele) - Read a shadowed mmio register for ggtt flush (Vinay) - Add missing new-line to GT_TRACE (Andrzej) - Add drm_dbgs for critical PXP events (Alan) - Skip pxp init if gt is wedged (Zhanjun) - Replace custom intel runtime_pm tracker with ref_tracker library (Andrzej) - Compiler warning/static checker/coding style cleanups (Arnd, Nirmoy, Soumya, Gilbert, Dorcas, Kunwu, Sam, Tvrtko) - Code structure and helper cleanups (Jani, Tvrtko, Andi) - Selftest improvements (John, Tvrtko, Andrzej) Signed-off-by: Dave Airlie <airlied@redhat.com> # Conflicts: # drivers/gpu/drm/i915/gt/intel_gt_mcr.c From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZXNBcsSwJEVsq9On@jlahtine-mobl.ger.corp.intel.com
2023-12-12Backmerge tag 'v6.7-rc5' into drm-nextDave Airlie1-17/+22
Linux 6.7-rc5 Alex requested this for some amdkfd work relying on the symbols exports. Signed-off-by: Dave Airlie <airlied@redhat.com>
2023-12-08drm/i915/guc: Create the guc_to_i915() wrapperAndi Shyti8-12/+17
Given a reference to "guc", the guc_to_i915() returns the pointer to "i915" private data. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206184322.57111-1-andi.shyti@linux.intel.com
2023-12-08drm/i915/selftests: wait for active idle event in i915_active_unlock_waitAndrzej Hajda1-1/+1
After i915_active_unlock_wait i915_active can be still non-idle due to barrier async handling in signal_irq_work. As a result one can observe following errors: bcs0: heartbeat pulse did not flush idle tasks *ERROR* pulse active pulse_active [i915]:pulse_retire [i915] *ERROR* pulse count: 0 *ERROR* pulse preallocated barriers? no To prevent it let's wait explicitly for idleness. v2: wait only in live_idle tests Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205-selftest_wait_for_active_idle_event-v2-1-1437d0bf9829@intel.com
2023-12-07drm/i915: Use internal class when counting engine resetsTvrtko Ursulin2-3/+4
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") made the GSC0 engine not have a valid uabi class and so broke the engine reset counting, which in turn was made class based in cb823ed9915b ("drm/i915/gt: Use intel_gt as the primary object for handling resets"). Despite the title and commit text of the latter is not mentioning it (and has left the storage array incorrectly sized), tracking by class, despite it adding aliasing in hypthotetical multi-tile systems, is handy for virtual engines which for instance do not have a valid engine->id. Therefore we keep that but just change it to use the internal class which is always valid. We also add a helper to increment the count, which aligns with the existing getter. What was broken without this fix were out of bounds reads every time a reset would happen on the GSC0 engine, or during selftests when storing and cross-checking the counts in igt_live_test_begin and igt_live_test_end. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: dfed6b58d54f ("drm/i915/gsc: Mark internal GSC engine with reserved uabi class") [tursulin: fixed Fixes tag] Reported-by: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231201122109.729006-2-tvrtko.ursulin@linux.intel.com
2023-12-01drm/i915/guc: Add a selftest for FAST_REQUEST errorsJohn Harrison3-0/+128
There is a mechanism for reporting errors from fire and forget H2G messages. This is the only way to find out about almost any error in the GuC backend submission path. So it would be useful to know that it is working. v2: Fix some dumb over-complications and a couple of typos - review feedback from Daniele. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231114010016.234570-3-John.C.Harrison@Intel.com
2023-12-01drm/i915/guc: Fix for potential false positives in GuC hang selftestJohn Harrison1-1/+1
Noticed that the hangcheck selftest is submitting a non-preemptoble spinner. That means that even if the GuC does not die, the heartbeat will still kick in and trigger a reset. Which is rather defeating the purpose of the test - to verify that the heartbeat will kick in if the GuC itself has died. The test is deliberately killing the GuC, so it should never hit the case of a non-dead GuC. But it is not impossible that the kill might fail at some future point due to other driver re-work. So, make the spinner pre-emptible. That way the heartbeat can get through if the GuC is alive and context switching. Thus a reset only happens if the GuC dies. Thus, if the kill should stop working the test will now fail rather than claim to pass. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231114010016.234570-2-John.C.Harrison@Intel.com
2023-11-30drm/i915/pxp: Add drm_dbgs for critical PXP events.Alan Previn1-0/+2
Debugging PXP issues can't even begin without understanding precedding sequence of important events. Add drm_dbg into the most important PXP events. v5 : - rebase. v4 : - rebase. v3 : - move gt_dbg to after mutex block in function i915_gsc_proxy_component_bind. (Vivaik) v2 : - remove __func__ since drm_dbg covers that (Jani). - add timeout dbg of the restart from front-end (Alan). Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231122191523.58379-1-alan.previn.teres.alexis@intel.com
2023-11-29drm/i915/gsc: Mark internal GSC engine with reserved uabi classTvrtko Ursulin1-17/+22
The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and instance to identify the engine, so leaving uabi class unset makes the GSC CS show up as the RCS in those logs. Given that the engine is not exposed to the user, we can't add a new case in the uabi enum, so we insted internally define a kernel internal class as -1. At the same time remove special handling for the name and complete the uabi_classes array so internal class is automatically correctly assigned. Engine will show as 65535:0 other0 in the logs/traces which should be unique enough. v2: * Fix uabi class u8 vs u16 type confusion. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command streamer to the user") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116084456.291533-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit dfed6b58d54f3a5d7e6bc1fb060e2c936330eba2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2023-11-28drm/i915/dg2: Drop Wa_22014600077Matt Roper1-8/+0
This workaround has been dropped from all DG2 variants in the latest workaround database update. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231127190043.4099109-2-matthew.d.roper@intel.com
2023-11-28Merge v6.7-rc3 into drm-nextDaniel Vetter1-11/+0
Thomas Zimermann needs 8d6ef26501 ("drm/ast: Disconnect BMC if physical connector is connected") for further ast work in -next. Minor conflicts in ivpu between 3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware") and 3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset") changing adjacent lines. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-11-23Merge tag 'drm-intel-next-2023-11-23' of ↵Daniel Vetter3-1/+16
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull for v6.8: Features and functionality: - Major DP MST improvements on bandwidth management, DSC (Imre, Stan, Ville) - DP panel replay enabling (Animesh, Jouni) - MTL C20 phy state verification (Mika) - MTL DP DSC fractional bpp support (Ankit, Vandita, Swati, Imre) - Audio fastset support (Ville) Refactoring and cleanups: - Use dma fence interfaces instead of i915_sw_fence (Jouni) - Separate gem and display code (Jouni, Juha-Pekka) - AUX register macro refactoring (Jani) - Separate display module/device parameters from the rest (Jouni) - Move display capabilities debugfs under display (Vinod) - Makefile cleanup (Jani) - Register cleanups (Ville) - Enginer iterator cleanups (Tvrtko) - Move display lock inits under display/ (Jani) - VLV/CHV DPIO PHY register and interface refactoring (Jani) - DSI VBT sequence refactoring (Jani, Andy Shevchenko) - C10/C20 PHY PLL hardware readout and calculation abstractions (Lucas) - DPLL code cleanups (Ville) - Cleanup PXP plane protection checks (Jani) Fixes: - Replace VLV/CHV DSI GPIO direct access with proper GPIO API usage (Andy Shevchenko) - Fix VLV/CHV DSI GPIO wrong initial value (Hans de Goede) - Fix UHBR data, link M/N/TU and PBN values (Imre) - Fix HDCP state on an enable/disable cycle (Suraj) - Fix DP MST modeset sequence to be according to spec (Ville) - Improved atomicity for multi-pipe commits (Ville) - Update URLs in i915 MAINTAINERS entry and code (Jani) - Check for VGA converter presence in eDP probe (Ville) - Fix surface size checks (Ville) - Fix LNL port/phy assignment (Lucas) - Reset C10/C20 message bus harder to avoid sporadic failures (Mika) - Fix bogus VBT HDMI level shift on BDW (Ville) - Add workaround for LNL underruns when enabling FBC (Vinod) - DSB refactoring (Animesh) - DPT refactoring (Juha-Pekka) - Disable DSC on DP MST on ICL (Imre) - Fix PSR VSC packet setup timing (Mika) - Fix LUT rounding and conversions (Ville) DRM core display changes: - DP MST fixes, helpers, refactoring to support bandwidth management (Imre) - DP MST PBN divider value refactoring and fixes (Imre) - DPCD register definitions (Ankit, Imre) - Add helper to get DSC bpp precision (Ankit) - Fix color LUT rounding (Ville) From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87v89sl2ao.fsf@intel.com [sima: Some conflicts in the amdgpu dp mst code] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-11-20drm/i915: Track gt pm wakerefsAndrzej Hajda17-63/+111
Track every intel_gt_pm_get() until its corresponding release in intel_gt_pm_put() by returning a cookie to the caller for acquire that must be passed by on released. When there is an imbalance, we can see who either tried to free a stale wakeref, or who forgot to free theirs. v2: track recently added calls in gen8_ggtt_bind_get_ce and destroyed_worker_func Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030-ref_tracker_i915-v1-2-006fe6b96421@intel.com
2023-11-20drm/i915/gsc: Mark internal GSC engine with reserved uabi classTvrtko Ursulin1-17/+22
The GSC CS is not exposed to the user, so we skipped assigning a uabi class number for it. However, the trace logs use the uabi class and instance to identify the engine, so leaving uabi class unset makes the GSC CS show up as the RCS in those logs. Given that the engine is not exposed to the user, we can't add a new case in the uabi enum, so we insted internally define a kernel internal class as -1. At the same time remove special handling for the name and complete the uabi_classes array so internal class is automatically correctly assigned. Engine will show as 65535:0 other0 in the logs/traces which should be unique enough. v2: * Fix uabi class u8 vs u16 type confusion. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command streamer to the user") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116084456.291533-1-tvrtko.ursulin@linux.intel.com
2023-11-20drm/i915: do not clean GT table on error pathAndrzej Hajda1-11/+0
The only task of intel_gt_release_all is to zero gt table. Calling it on error path prevents intel_gt_driver_late_release_all (called from i915_driver_late_release) to cleanup GTs, causing leakage. After i915_driver_late_release GT array is not used anymore so it does not need cleaning at all. Sample leak report: BUG i915_request (...): Objects remaining in i915_request on __kmem_cache_shutdown() ... Object 0xffff888113420040 @offset=64 Allocated in __i915_request_create+0x75/0x610 [i915] age=18339 cpu=1 pid=1454 kmem_cache_alloc+0x25b/0x270 __i915_request_create+0x75/0x610 [i915] i915_request_create+0x109/0x290 [i915] __engines_record_defaults+0xca/0x440 [i915] intel_gt_init+0x275/0x430 [i915] i915_gem_init+0x135/0x2c0 [i915] i915_driver_probe+0x8d1/0xdc0 [i915] v2: removed whole intel_gt_release_all Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8489 Fixes: bec68cc9ea42 ("drm/i915: Prepare for multiple GTs") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115-dont_clean_gt_on_error_path-v2-1-54250125470a@intel.com (cherry picked from commit e899505533852bf1da133f2f4c9a9655ff77f7e5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2023-11-18drm/i915/mtl: Update Wa_22018931422Radhakrishna Sripada1-2/+1
Commit 78cc55e0b64c ("drm/i915/mcr: Hold GT forcewake during steering operations") introduced the workaround which was in early stages. With a valid lineage number update Workaround for future tracking. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116212511.1760446-1-radhakrishna.sripada@intel.com
2023-11-17drm/i915/dg2: Wa_18028616096 now applies to all DG2Matt Roper1-5/+3
The workaround database was just updated to extend this workaround to DG2-G11 (whereas previously it applied only to G10 and G12). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115182117.2551522-2-matthew.d.roper@intel.com
2023-11-17drm/i915/huc: Stop printing about unsupported HuC on MTLDaniele Ceraolo Spurio1-5/+0
On MTL, the HuC is only supported on the media GT, so our validation check on the module parameter detects an inconsistency on the root GT (the modparams asks to enable HuC, but the support is not there) and prints the following info message: [drm] GT0: Incompatible option enable_guc=3 - HuC is not supported! This can be confusing to the user and make them think that something is wrong when it isn't, so we need to silence it. Given that any platform that supports HuC also supports GuC, if a user tries to enable HuC on a platform that really doesn't support it they'll already see a message about GuC not being supported, so instead of just silencing the HuC message on newer platforms we can just get rid of it entirely. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231109235436.2349963-1-daniele.ceraolospurio@intel.com
2023-11-16drm/i915: do not clean GT table on error pathAndrzej Hajda1-11/+0
The only task of intel_gt_release_all is to zero gt table. Calling it on error path prevents intel_gt_driver_late_release_all (called from i915_driver_late_release) to cleanup GTs, causing leakage. After i915_driver_late_release GT array is not used anymore so it does not need cleaning at all. Sample leak report: BUG i915_request (...): Objects remaining in i915_request on __kmem_cache_shutdown() ... Object 0xffff888113420040 @offset=64 Allocated in __i915_request_create+0x75/0x610 [i915] age=18339 cpu=1 pid=1454 kmem_cache_alloc+0x25b/0x270 __i915_request_create+0x75/0x610 [i915] i915_request_create+0x109/0x290 [i915] __engines_record_defaults+0xca/0x440 [i915] intel_gt_init+0x275/0x430 [i915] i915_gem_init+0x135/0x2c0 [i915] i915_driver_probe+0x8d1/0xdc0 [i915] v2: removed whole intel_gt_release_all Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8489 Fixes: bec68cc9ea42 ("drm/i915: Prepare for multiple GTs") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115-dont_clean_gt_on_error_path-v2-1-54250125470a@intel.com
2023-11-16drm/i915/gt: add missing new-line to GT_TRACEAndrzej Hajda1-1/+1
Trace requires new-line at the end of message (in opposition to printk), otherwise trace dump becomes messy. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115-eols-v1-1-d47a2f52b807@intel.com
2023-11-16drm/i915: Read a shadowed mmio register for ggtt flushVinay Belgaumkar1-1/+1
We read RENDER_HEAD as a part of the flush. If GT is in deeper sleep states, this could lead to read errors since we are not using a forcewake. Safer to read a shadowed register instead. Cc: John Harrison <john.c.harrison@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231109192148.475156-1-vinay.belgaumkar@intel.com
2023-11-11Merge tag 'drm-next-2023-11-10' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2-17/+34
Pull drm fixes from Daniel Vetter: "Dave's VPN to the big machine died, so it's on me to do fixes pr this and next week while everyone else is at plumbers. - big pile of amd fixes, but mostly for hw support newly added in 6.7 - i915 fixes, mostly minor things - qxl memory leak fix - vc4 uaf fix in mock helpers - syncobj fix for DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE" * tag 'drm-next-2023-11-10' of git://anongit.freedesktop.org/drm/drm: (78 commits) drm/amdgpu: fix error handling in amdgpu_vm_init drm/amdgpu: Fix possible null pointer dereference drm/amdgpu: move UVD and VCE sched entity init after sched init drm/amdgpu: move kfd_resume before the ip late init drm/amd: Explicitly check for GFXOFF to be enabled for s0ix drm/amdgpu: Change WREG32_RLC to WREG32_SOC15_RLC where inst != 0 (v2) drm/amdgpu: Use correct KIQ MEC engine for gfx9.4.3 (v5) drm/amdgpu: add smu v13.0.6 pcs xgmi ras error query support drm/amdgpu: fix software pci_unplug on some chips drm/amd/display: remove duplicated argument drm/amdgpu: correct mca debugfs dump reg list drm/amdgpu: correct acclerator check architecutre dump drm/amdgpu: add pcs xgmi v6.4.0 ras support drm/amdgpu: Change extended-scope MTYPE on GC 9.4.3 drm/amdgpu: disable smu v13.0.6 mca debug mode by default drm/amdgpu: Support multiple error query modes drm/amdgpu: refine smu v13.0.6 mca dump driver drm/amdgpu: Do not program PF-only regs in hdp_v4_0.c under SRIOV (v2) drm/amdgpu: Skip PCTL0_MMHUB_DEEPSLEEP_IB write in jpegv4.0.3 under SRIOV drm: amd: Resolve Sphinx unexpected indentation warning ...
2023-11-10drm/i915: Account ring buffer and context state storageTvrtko Ursulin1-0/+14
Account ring buffers and logical context space against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-4-tvrtko.ursulin@linux.intel.com
2023-11-10drm/i915: Track page table backing store usageTvrtko Ursulin1-0/+6
Account page table backing store against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-3-tvrtko.ursulin@linux.intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 01:25:32 +0300