- 03 Jun, 2020 2 commits
-
-
Chris Wilson authored
We infrequently use the direct i915 backpointer from the i915_request, so do we really need to waste the space in the struct for it? 8 bytes from the most frequently allocated struct vs an 3 bytes and pointer chasing in using rq->engine->i915? Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602220953.21178-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we injected an error (such as pretending the GuC firmware was broken), then suppress the error message as it is expected and our CI complains if it sees any *ERROR*. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603104657.25651-1-chris@chris-wilson.co.uk
-
- 02 Jun, 2020 9 commits
-
-
Chris Wilson authored
For reasons that be, the HW only allows usersace to read its own CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for all by adding it to the whitelists. v2: The change took effect from Cometlake. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602154839.6902-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Cometlake is a small refresh of Coffeelake, but since we have found out a difference in the plaforms, we need to identify them as separate platforms. Since we previously took Coffeelake/Cometlake as identical, update all IS_COFFEELAKE() to also include IS_COMETLAKE(). Signed-off-by:
-
Chris Wilson authored
As a timestamp will automatically update itself, it will not hold only contexts we write into it, and will change from the baseline value making us suspect that our writes are landing. As this confuses us and we would need more careful treatment to detect invalid stores into the timestamp, skip it when verifying the whitelists. Signed-off-by:
-
Vivek Kasireddy authored
If an error is encountered during the DSI initialization setup, the drm connector object also needs to be cleaned up along with the encoder. The error can happen due to a missing mode in the VBT or for other reasons. v2: Rephrase the commit message to make it more clear. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by:
-
Jani Nikula authored
Only support runtime changes through the debugfs. i915.verbose_state_checks remains an exception, and is not exposed via debugfs. This depends on IGT having been updated to use the debugfs for modifying the parameters. Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601215510.18379-3-jani.nikula@intel.com
-
Jani Nikula authored
fake_lmem_start does not need to be mutable via module param sysfs. It's only used during driver probe. Fixes: 16292243 ("drm/i915/lmem: add the fake lmem region") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
The parameter only makes sense as a module parameter only. Fixes: c43c5a88 ("drm/i915/params: add i915 parameters to debugfs") Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by:
-
Chris Wilson authored
Use the central mechanism for recording and verifying that we restore the w/a for the older devices as well. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601072446.19548-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pull the routines for writing CS packets out of intel_ring_submission into their own files. These are low level operations for building CS instructions, rather than the logic for filling the global ring buffer with requests, and we will want to reuse them outside of this context. Signed-off-by:
-
- 01 Jun, 2020 7 commits
-
-
Chris Wilson authored
Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f3975 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by:
-
José Roberto de Souza authored
Small updates in dkl_de_emphasis_control field. BSpec: 49292 Signed-off-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529232757.37832-1-jose.souza@intel.com
-
Chris Wilson authored
Ever noticed that our interrupt handlers are where we spend most of our time on a busy system? In part this is unavoidable as each interrupt requires to poll and reset several registers, but we can try and do so as efficiently as possible. Function old new delta ilk_irq_handler 2317 2156 -161 v2: Restore the irqreturn_t ret Function old new delta ilk_irq_handler.cold 63 72 +9 ilk_irq_handler 2221 2080 -141 A slight improvement in the baseline overnight as well! Signed-off-by:
-
Ville Syrjälä authored
While the current locking/serialization of the global state suffices for protecting the obj->state access and the actual hardware reprogramming, we do have a problem with accessing the old/new states during nonblocking commits. The state computation and swap will be protected by the crtc locks, but the commit_tails can finish out of order, thus also causing the atomic states to be cleaned up out of order. This would mean the commit that started first but finished last has had its new state freed as the no-longer-needed old state by the other commit. To fix this let's just refcount the states. obj->state amounts to one reference, and the intel_atomic_state holds extra references to both its new and old global obj states. Fixes: 0ef1905e ("drm/i915: Introduce better global state handling") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200527200245.13184-1-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Chris Wilson authored
Our forcewake utilisation is split into categories: automatic and manual. Around bare register reads, we look up the right forcewake domain and automatically acquire and release [upon a timer] the forcewake domain. For other access, where we know we require the forcewake across a group of register reads, we manually acquire the forcewake domain and release it at the end. Again, this currently arms the domain timer for a later release. However, looking at some energy utilisation profiles, we have tried to avoid using forcewake [and rely on the natural wake up to post register updates] due to that even keep the fw active for a brief period contributes to a significant power draw [i.e. when the gpu is sleeping with rc6 at high clocks]. But as it turns out, not posting the writes immediately also has unintended consequences, such as not reducing the clocks and so conserving power while busy. As a compromise, let us only arm the domain timer for automatic forcewake usage around bare register access, but immediately release the forcewake when manually acquired by intel_uncore_forcewake_get/_put. The corollary to this is that we may instead have to take forcewake more often, and so incur a latency penalty in doing so. For Sandybridge this was significant, and even on the latest machines, taking forcewake at interrupt frequency is a huge impact. [So we don't do that anymore! Hopefully, this will spare us from still needing the mitigation of the timer for steady state execution.] Signed-off-by:
-
Chris Wilson authored
If we fail during engine setup, we may leave some engines not yet setup. During the error cleanup, we have to be careful not to try and use the uninitialise engines before discarding them. [ 16.136152] RIP: 0010:__flush_work+0x198/0x1b0 [ 16.136168] Code: ff ff 8b 0b 48 8b 53 08 83 e1 08 48 0f ba 2b 03 80 c9 f0 e9 63 ff ff ff 0f 0b 48 83 c4 48 44 89 f0 5b 5d 41 5c 41 5d 41 5e c3 <0f> 0b 45 31 f6 e9 62 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f [ 16.136186] RSP: 0018:ffffc900003bb928 EFLAGS: 00010246 [ 16.136201] RAX: 0000000000000000 RBX: ffff88844f392168 RCX: 0000000000000000 [ 16.136216] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88844f392168 [ 16.136231] RBP: ffff88844f392130 R08: 0000000000000000 R09: 0000000000000001 [ 16.136246] R10: ffff888441e31e40 R11: ffff88845e329c70 R12: ffff88844f796988 [ 16.136261] R13: ffff888441e4fb80 R14: 0000000000000001 R15: ffff88844f790000 [ 16.136388] FS: 00007fecbd208880(0000) GS:ffff88845e380000(0000) knlGS:0000000000000000 [ 16.136405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.136420] CR2: 00007ff3ce748f90 CR3: 0000000457a6a001 CR4: 00000000000606e0 [ 16.136437] Call Trace: [ 16.136456] ? try_to_del_timer_sync+0x3a/0x50 [ 16.136529] intel_wakeref_wait_for_idle+0x87/0xb0 [i915] [ 16.136606] ? intel_engines_release+0x68/0xc0 [i915] [ 16.136680] intel_engines_release+0x49/0xc0 [i915] [ 16.136757] intel_gt_init+0x2f4/0x5e0 [i915] Signed-off-by:
-
Kishore Kadiyala authored
Currently the plane property doesn't have support for YCBCR_BT2020, which enables the corresponding color conversion mode on plane CSC. Enabling the plane property for the planes for GLK & ICL+ platforms. Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709 to YUV601_TO_RGB601. V2: Enabling support for YCBCT_BT2020 for HDR planes on platforms GLK & ICL V3: Refined the condition check to handle GLK & ICL+ HDR planes Also added BT2020 handling in glk_plane_color_ctl. V4: Combine If-else into single If V5: Drop the checking for HDR planes and enable YCBCR_BT2020 for platforms GLK & ICL+. V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709 to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's feedback. V7: Rebased Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Kishore Kadiyala <kishore.kadiyala@intel.com> Signed-off-by:
-
- 29 May, 2020 6 commits
-
-
Chris Wilson authored
Name the object classes and their offspring for easier lockdep debugging. Signed-off-by:
-
Chris Wilson authored
If we declare that an object type is shrinkable (any that we can reclaim to recover system pages), make sure we taint the object mutex so that lockdep expects us to use it within fs_reclaim. lockdep will then complain the first time we try to allocate while holding the plain mutex, as doing so invites potential recursion. Signed-off-by:
-
Chris Wilson authored
With the advent of preempt-to-busy, a request may still be on the GPU as we unwind. And in the case of a unpreemptible [due to HW] request, that request will remain indefinitely on the GPU even though we have returned it back to our submission queue, and cleared the active bit. We only run the execution callbacks on transferring the request from our submission queue to the execution queue, but if this is a bonded request that the HW is waiting for, we will not submit it (as we wait for a fresh execution) even though it is still being executed. As we know that there are always preemption points between requests, we know that only the currently executing request may be still active even though we have cleared the flag. However, we do not precisely know which request is in ELSP[0] due to a delay in processing events, and furthermore we only store the last request in a context in our state tracker. Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Testcase: igt/gem_exec_balancer/bonded-dual Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529143926.3245-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Let's assert that we only call the execute callbacks on making the request active, and that we do not execute the request without calling the callbacks. Signed-off-by:
-
Ville Syrjälä authored
There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag anymore. Just make it a boolean. v2: Deal with sanitize_watermarks() CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Replace the use of mode->private_flags with a truly private bitmaks in our own crtc state. We also need a copy in the crtc itself so the vblank code can get at it. We already have scanline_offset in there for a similar reason, as well as the vblank->hwmode which is assigned via drm_calc_timestamping_constants(). Fortunately we now have a nice place for doing the crtc_state->crtc copy in intel_crtc_update_active_timings() which gets called both for modesets and init/resume readout. The one slightly iffy spot is the INHERITED flag which we want to preserve until userspace/fb_helper does the first proper commit after actually calling .detecti() on the connectors. Otherwise we don't have the full sink capabilities (audio,infoframes,etc.) when .compute_config() gets called and thus we will fail to enable those features when the first userspace commit happens. The only internal commit we do prior to that should be from intel_initial_commit() and there we can simply preserve the INHERITED flag from the readout. v2: Deal with INHERITED in sanitize_watermarks() as well CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
-
- 28 May, 2020 5 commits
-
-
Chris Wilson authored
We may choose to only submit ELSP[0], even though we have sufficient requests to fill the whole ELSP. Normally, we only start timeslicing if we fill more than one port, but in this case we need to start timeslicing for the queue that we choose not to submit. Signed-off-by:
-
Chris Wilson authored
If the ring submission is stalled on an external request, nothing can be submitted, not even the heartbeat in the kernel context. Since nothing is running, resetting the engine/device does not unblock the system and is pointless. We can see if the heartbeat is supposed to be running before declaring foul. Signed-off-by:
-
Chris Wilson authored
Across suspend/resume, we clear the entire GGTT and rebuild from scratch. In particular, we want to only preserve the global entries for use by the HW, and delay reinstating the local binds until required by the user. This means that we can evict any local binds in the global GTT, saving any time in preserving their state, as they will be rebound on demand. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1947Signed-off-by:
-
Chris Wilson authored
We should be able to skip restoring LOCAL (user) binds within the GGTT on resume and let them be restored upon demand. However, our consistency checks demand that the bind flags match the node state, and we cannot simply clear the flags, we need to evict as well. For now, make sure we restore the bind flags exactly upon resume. Fixes: 0109a16e ("drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume") Fixes: bf0840cd ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with PIN_USER with no-ppgtt") Signed-off-by:
-
Chris Wilson authored
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier, pending. As such, restrict the timeslicing check to avoid preempting into the topmost priority band, leaving the unpreemptable requests in blissful peace running uninterrupted on the HW. v2: Set the I915_PRIORITY_BARRIER to be less than I915_PRIORITY_UNPREEMPTABLE so that we never submit a request (heartbeat or barrier) that can legitimately preempt the current non-premptable request. Fixes: 2a98f4e6 ("drm/i915: add infrastructure to hold off preemption on a request") Signed-off-by:
-
- 27 May, 2020 5 commits
-
-
Arnd Bergmann authored
gcc-9 gets confused by the code flow in check_dirty_whitelist: drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function 'check_dirty_whitelist': drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be used uninitialized in this function [-Werror=maybe-uninitialized] I could not figure out a good way to do this in a way that gcc understands better, so initialize the variable to zero, as last resort. Fixes: aee20aae ("drm/i915: Implement read-only support in whitelist selftest") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Arnd Bergmann authored
Conditional spinlocks make it hard for gcc and for lockdep to follow the code flow. This one causes a warning with at least gcc-9 and higher: In file included from include/linux/irq.h:14, from drivers/gpu/drm/i915/i915_pmu.c:7: drivers/gpu/drm/i915/i915_pmu.c: In function 'i915_sample': include/linux/spinlock.h:289:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] 289 | _raw_spin_unlock_irqrestore(lock, flags); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_pmu.c:288:17: note: 'flags' was declared here 288 | unsigned long flags; | ^~~~~ Split out the part between the locks into a separate function for readability and to let the compiler figure out what the logic actually is. Fixes: d79e1bd6 ("drm/i915/pmu: Only use exclusive mmio access for gen7") Signed-off-by: -
Chris Wilson authored
We only restore GLOBAL binds upon resume as we expect these to be pinned for use by HW, whereas the LOCAL binds can be recreated on demand once userspace is resumed. For the LOCAL bind to be recreated in the global GTT (for old systems without ppgtt), we need to clear its presence flag on deciding not to restore the mapping upon resume. Fixes: bf0840cd ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with PIN_USER with no-ppgtt") Signed-off-by:
-
Chris Wilson authored
When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! v2: Beware restriction of signal->execution_mask prior to submission. Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by:
-
Chris Wilson authored
Reorder the code so that we can reuse the await_execution from a special case in await_request in the next patch. Signed-off-by:
-
- 26 May, 2020 5 commits
-
-
Chris Wilson authored
Avoid a NULL dereference for a mismatched encoder type, hit when probing state for all encoders. This is a band aid to prevent the OOPS as the right fix is "probably to swap the psr vs infoframes.enable checks, or outright disappear from this function" (Ville). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1892Signed-off-by:
-
Chris Wilson authored
Reduce the irq_work llist for attaching the callbacks to the signal for both smaller structs (two fewer pointers!) and simpler [debug] code: Function old new delta irq_execute_cb 35 34 -1 __igt_breadcrumbs_smoketest 1684 1682 -2 i915_request_retire 2003 1996 -7 __i915_request_create 1047 1040 -7 __notify_execute_cb 135 126 -9 __i915_request_ctor 188 178 -10 __await_execution.part.constprop 451 440 -11 igt_wait_request 924 714 -210 One minor artifact is that the order of cb exection is reversed. No current use cases are affected by that change. Signed-off-by:
-
Chris Wilson authored
If there are no internal levels and the user priority-shift is zero, we can help the compiler eliminate some dead code: Function old new delta start_timeslice 169 154 -15 __execlists_submission_tasklet 4696 4659 -37 Signed-off-by:
-
Chris Wilson authored
Before we return control to the system, and letting it reuse all the pages being accessed by HW, we must disable the HW. At the moment, we dare not reset the GPU if it will clobber the display, but once we know the display has been disabled, we can proceed with the reset as we shutdown the module. We know the next user must reinitialise the HW for their purpose. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/489Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/display/intel_dsb.c:177 intel_dsb_reg_write() warn: variable dereferenced before check 'dsb' (see line 175) Fixes: afeda4f3 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200524233900.25598-1-chris@chris-wilson.co.uk
-
- 25 May, 2020 1 commit
-
-
Chris Wilson authored
In order to keep userptr distinct from ggtt mmaps in the eyes of lockdep, we need to avoid marking those userptr vma as PIN_GLOBAL. (So long as we comply with only using them as local PIN_USER!) References: https://gitlab.freedesktop.org/drm/intel/-/issues/1880Signed-off-by:
-
