- 20 Aug, 2019 4 commits
-
-
Chris Wilson authored
Before we acquire the vma for GPU activity, ensure that the underlying object is not already in the process of being freed. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190820100531.8430-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently, we remove the from per-file request list for throttling and retirement under a dedicated spinlock, but insertion is governed by struct_mutex. This needs to be the same lock so that the retirement/insertion of neighbouring requests (at the tail) doesn't break the list. Signed-off-by:
-
Imre Deak authored
To work around a DMC/Punit issue on ICL where the driver's ICL_PORT_COMP_DW8/IREFGEN PHY setting is lost when entering/exiting DC6 state, make sure to reinit the PHY whenever disabling DC states. Similarly the driver's PHY/DBUF/CDCLK settings should have been preserved across DC5/6 transitions, so check this on all platforms. This gets rid of the following WARN during suspend: Combo PHY A HW state changed unexpectedly Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190816095523.15800-1-imre.deak@intel.com
-
Imre Deak authored
The conversion during HDMI HW readout from port_clock to crtc_clock was missed when HDMI 10bpc support was added, so fix that. v2: - Unscrew the non-HDMI case. Fixes: cd9e11a8 ("drm/i915/icl: Add 10-bit support for hdmi") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109593 Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808162547.7009-1-imre.deak@intel.com
-
- 19 Aug, 2019 8 commits
-
-
Chris Wilson authored
Inside gtt_restore_mappings() we currently take the obj->resv->lock, but in the future we need to avoid taking this fs-reclaim tainted lock as we need to extend the coverage of the vm->mutex. Take advantage of the single-threaded nature of the early resume phase, and do a single wbinvd() to flush all the GTT objects en masse. Signed-off-by:
-
Chris Wilson authored
Since commit 078dec33 ("dma-buf: add dma_fence_get_stub") the 0 fence context became an impossible match as it is used for an always signaled fence. We can simplify our timeline tracking by knowing that 0 always means no match. Signed-off-by:
-
Chris Wilson authored
Check that i915_active.retire() exists before calling. Signed-off-by:
-
Matt Roper authored
Our pin mapping tables for ICP and MCC currently only list the standard GPIO pins used for various output ports. Even through ICP's standard pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin usage only uses pins 1, 2, and 9, these platforms do still have GPIO registers to address pins in the range 1-3 and 9-14. OEM's may remap GPIO usage in non-standard ways (and provide the actual mapping via VBT settings), so we shouldn't exclude pins on these platforms just because they aren't part of the standard mappings. TGP's standard pin tables contains all the possible pins, so let's rename them to "icp" and use them for all PCH >= PCH_ICP. This will prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage that an OEM specifies via the VBT. Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc" in debug messages on platforms with the MCC PCH, but that may actually help avoid confusion since the text strings will now be the same on all gen11+ platforms instead of being different on just EHL. v2: Drop now-unused MCC_DDC_BUS_DDI_* names. v3: We want to compare against INTEL_PCH_TYPE, not INTEL_PCH_ID. Bspec: 8417 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Chris Wilson authored
Make sure that when submitting requests, we always serialize against potential vma moves and clflushes. Time for a i915_request_await_vma() interface! Signed-off-by:
-
Chris Wilson authored
Use a locked xchg to ensure that the global log message giving instructions on how to send a bug report is emitted precisely once. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
We use a fake timeline->mutex lock to reassure lockdep that the timeline is always locked when emitting requests. However, the use inside __engine_park() may be inside hardirq and so lockdep now complains about the mixed irq-state of the nested locked. Disable irqs around the lockdep tracking to keep it happy. Fixes: 6c69a454 ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex") Signed-off-by:
-
Chris Wilson authored
We were passing in an unwrapped offset into intel_ring_reset() on unpinning. Sooner or later that had to land on ring->size. <3> [314.872147] intel_ring_reset:1237 GEM_BUG_ON(!intel_ring_offset_valid(ring, tail)) <4> [314.872272] ------------[ cut here ]------------ <2> [314.872276] kernel BUG at drivers/gpu/drm/i915/gt/intel_ringbuffer.c:1237! <4> [314.872320] invalid opcode: 0000 [#1] PREEMPT SMP PTI <4> [314.872331] CPU: 1 PID: 3466 Comm: i915_selftest Tainted: G U 5.3.0-rc4-CI-Patchwork_14061+ #1 <4> [314.872346] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT PC/3647h, BIOS 786G7 v01.02 10/22/2009 <4> [314.872477] RIP: 0010:intel_ring_reset+0x51/0x70 [i915] <4> [314.872487] Code: 9e db 51 e0 48 8b 35 b6 c7 22 00 49 c7 c0 f8 d9 d6 a0 b9 d5 04 00 00 48 c7 c2 70 5b d4 a0 48 c7 c7 6c fc c0 a0 e8 cf be 58 e0 <0f> 0b 89 77 20 89 77 1c 89 77 24 e9 4f ed ff ff 0f 1f 44 00 00 66 <4> [314.872512] RSP: 0018:ffffc9000034fa98 EFLAGS: 00010282 <4> [314.872523] RAX: 0000000000000010 RBX: ffff8881019412c8 RCX: 0000000000000000 <4> [314.872534] RDX: 0000000000000001 RSI: 0000000000000008 RDI: 0000000000000f20 <4> [314.872545] RBP: ffff888104e0f740 R08: 0000000000000000 R09: 0000000000000f20 <4> [314.872557] R10: 0000000000000000 R11: ffff888117094518 R12: ffffffffa0d3d2c0 <4> [314.872569] R13: ffffffffa0e2a250 R14: ffffffffa0e2a1e0 R15: ffffc9000034fe88 <4> [314.872581] FS: 00007fe6d49f6e40(0000) GS:ffff888117a80000(0000) knlGS:0000000000000000 <4> [314.872595] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [314.872605] CR2: 000055e3283e9cc8 CR3: 0000000108842000 CR4: 00000000000406e0 <4> [314.872616] Call Trace: <4> [314.872701] intel_ring_unpin+0x1a/0x220 [i915] <4> [314.872787] ring_destroy+0x48/0xc0 [i915] <4> [314.872870] intel_engines_cleanup+0x24/0x40 [i915] <4> [314.872964] i915_gem_driver_release+0x1b/0xf0 [i915] <4> [314.872984] i915_driver_release+0x1c/0x80 [i915] Signed-off-by:
-
- 18 Aug, 2019 4 commits
-
-
Chris Wilson authored
Errors spread like wildfire, and must eventually be returned to the user. They need to be captured and passed along the flow of fences, infecting each in turn with the existing error, until finally they fall out of a user visible result. Signed-off-by:
-
Michal Wajdeczko authored
There is no need to mark whole GPU as wedged just because of the custom HuC fw failure as users can always verify actual HuC firmware status using existing HUC_STATUS ioctl. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
If we failed to fetch default GuC firmware and we didn't plan to use it for the submission and we never have used GuC before then we may continue normal driver load, no need to declare GPU wedged (we can use execlist for submission) and it is safe to run without the HuC (users will check HuC status anyway). Signed-off-by:
-
Michal Wajdeczko authored
As we plan to continue driver load after GuC initialization failure, we can't assume that GuC log data will be available just because GuC was initially enabled. We must check that GuC is still running instead. Signed-off-by:
-
- 17 Aug, 2019 5 commits
-
-
Michal Wajdeczko authored
Let's wait with decision about importance of uC failure to hardware initialization step. Signed-off-by:
-
Michal Wajdeczko authored
Be consistent and always perform fw fetch cleanup in GuC/HuC specific init functions on every failure. Also while converting firmware status to error, stop treating SELECTED as non-error, as long term we should not see it. Signed-off-by:
-
Michal Wajdeczko authored
We can rely on firmware status AVAILABLE to determine if any firmware cleanup is required. Also don't unconditionally reset fw status to SELECTED as we will loose MISSING/ERROR codes. Signed-off-by:
-
Chris Wilson authored
Add a redzone to our context image and check the HW does not write into after a context save, to verify that we have the correct context size. (This does vary with feature bits, so test with a live setup that should match how we run userspace.) v2: Check the redzone on every context unpin v3: Use a kernel context to prevent loading garbage for ringbuffer submission Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190817073711.5897-1-chris@chris-wilson.co.uk
-
Mika Kuoppala authored
As we give page directory pointer (lvl 3) structure for pte insertion, we can fold both versions into one function by teaching it to get pdp regardless of top level. v2: naming and asserts (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 16 Aug, 2019 17 commits
-
-
Michal Wajdeczko authored
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
To reduce the number of explicit dev_priv->uncore calls in the display code ahead of the introduction of dev_priv->de_uncore, this patch introduces a wrapper for one of the main usages of it, the register waits. When we transition to the new uncore, we can just update the wrapper to point to the appropriate structure. Since the vast majority of waits are on a set or clear of a bit or mask, add set & clear flavours of the wrapper to simplify the code. Signed-off-by:
-
Daniele Ceraolo Spurio authored
They're not related to registers, so move them to the more appropriate intel_gmbus.h Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
To remove the dependency between the GT headers and i915_reg.h, move the definition of the engine IDs/classes to intel_engine_types.h Signed-off-by:
-
Daniele Ceraolo Spurio authored
It has nothing to do with registers, so move it to the more appropriate intel_display_power.h Signed-off-by:
-
Chris Wilson authored
If we only call process_csb() from the tasklet, though we lose the ability to bypass ksoftirqd interrupt processing on direct submission paths, we can push it out of the irq-off spinlock. The penalty is that we then allow schedule_out to be called concurrently with schedule_in requiring us to handle the usage count (baked into the pointer itself) atomically. As we do kick the tasklets (via local_bh_enable()) after our submission, there is a possibility there to see if we can pull the local softirq processing back from the ksoftirqd. v2: Store the 'switch_priority_hint' on submission, so that we can safely check during process_csb(). Signed-off-by:
-
Chris Wilson authored
As every i915_active_request should be serialised by a dedicated lock, i915_active consists of a tree of locks; one for each node. Markup up the i915_active_request with what lock is supposed to be guarding it so that we can verify that the serialised updated are indeed serialised. Signed-off-by:
-
Chris Wilson authored
We use timeline->mutex to protect modifications to context->active_count, and the associated enable/disable callbacks. Due to complications with engine-pm barrier there is a path where we used a "superlock" to provide serialised protect and so could not unconditionally assert with lockdep that it was always held. However, we can mark the mutex as taken (noting that we may be nested underneath ourselves) which means we can be reassured the right timeline->mutex is always treated as held and let lockdep roam free. Signed-off-by:
-
Michal Wajdeczko authored
Move SPDX tag to first line, and update year to 2019. Signed-off-by:
-
Michal Wajdeczko authored
All WOPCM error messages are device specific, so use device specific error functions. Signed-off-by:
-
Michal Wajdeczko authored
If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit. This should enable us to reload driver with slightly different HuC firmware (or even without HuC) without need to reboot. v2: reordered/rebased Signed-off-by:
-
Michal Wajdeczko authored
We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min v3: consolidate overflow checks (Daniele) Signed-off-by:
-
Michał Winiarski authored
While we need to know WOPCM size to do this sanity check, it has more to do with FW than with WOPCM. Let's move the check to fetch phase, it's not like WOPCM is going to grow in the meantime. v2: rebased v3: use __intel_uc_fw_get_upload_size (Daniele) Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Matthew Auld authored
Since nodes are cached in a free-list, and potentially marked as free without actually being destroyed, thus allowing them to be opportunistically re-allocated, we should apply kmemleak_update_trace every time a node is given a new owner and marked as allocated, to aid in debugging. Suggested-by:
-
Matthew Auld authored
If we are leaking nodes don't hide it. Also stop trying to be "defensive" and instead embrace Kasan et al. Signed-off-by:
-
Chris Wilson authored
We store the gt&uncore to use in the i915_address_space, so use it! Signed-off-by:
-
Chris Wilson authored
Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as the frontbuffer tracking wishes to sleep as it flushes. Signed-off-by:
-
- 15 Aug, 2019 2 commits
-
-
Chris Wilson authored
Forgo the struct_mutex requirement for request retirement as we have been transitioning over to only using the timeline->mutex for controlling the lifetime of a request on that timeline. Signed-off-by:
-
Chris Wilson authored
In preparation for removing struct_mutex from around context retirement, we need to make timeline pinning and unpinning safe. Since multiple engines/contexts can share a single timeline, we cannot rely on borrowing the context mutex (otherwise we could state that the timeline is only pinned/unpinned inside the context pin/unpin and so guarded by it). However, we only perform a sequence of atomic operations inside the timeline pin/unpin and the sequence of those operations is safe for a concurrent unpin / pin, so we can relax the struct_mutex requirement. Signed-off-by:
-
