- 07 Jan, 2019 3 commits
-
-
Chris Wilson authored
Include the total size of closed vma when reporting the per_ctx_stats of debugfs/i915_gem_objects. Whilst adjusting the context tracking, note that we can simply use our list of contexts in i915->contexts rather than circumlocute via dev->filelist and the per-file context idr, with the result that we can show objects allocated to different vm (i.e. contexts within a file). We change the output to show every context of each client, with its own unique set of objects (for full-ppgtt machines, i.e. gen7+, for older hardware all objects are in the global gtt and so can not be associated with a single context). That should result in no loss of information, and for gen7+, no duplication of active objects. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107115509.12523-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Haswell also requires the RING_IMR flush for its unique vebox setup to avoid losing interrupts, as per 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR"): On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. References: 476af9c2 ("drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR") Signed-off-by:
-
Chris Wilson authored
CC [M] drivers/gpu/drm/i915/intel_device_info.o drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or member 'dev_priv' not described in 'intel_device_info_runtime_init' drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function parameter 'info' description in 'intel_device_info_runtime_init' Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105014652.3472-1-chris@chris-wilson.co.uk
-
- 05 Jan, 2019 1 commit
-
-
Chris Wilson authored
Our attempt to account for bit17 swizzling of pread/pwrite onto tiled objects was flawed due to the simple fact that we do not always know the swizzling for a particular page (due to the swizzling varying based on location in certain unbalanced configurations). Furthermore, the pread/pwrite paths are now unbalanced in that we are required to use the GTT as in some cases we do not have direct CPU access to the backing physical pages (thus some paths trying to account for the swizzle, but others neglecting, chaos ensues). There are no known users who do use pread/pwrite into a tiled object (you need to manually detile anyway, so why now just use mmap and avoid the copy?) and no user bug reports to indicate that it is being used in the wild. As no one is hitting the buggy path, we can just remove the buggy code. v2: Just use the fault allowing kmap() + normal copy_(to|from)_user v3: Avoid int overflow in computing 'length' from 'remain' (Tvrtko) References: fe115628 ("drm/i915: Implement pwrite without struct-mutex") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190105120758.9237-1-chris@chris-wilson.co.uk
-
- 04 Jan, 2019 1 commit
-
-
Chris Wilson authored
If we declare the driver wedged during early initialisation, we leave the driver in an undefined state (with respect to GEM execution). As this leads to unexpected behaviour if we allow the user to unwedge the device (through debugfs, and performed by igt at test start), do not. Signed-off-by:
-
- 03 Jan, 2019 3 commits
-
-
Chris Wilson authored
When we first introduced the reset to sanitize the GPU on taking over from the BIOS and before returning control to third parties (the BIOS!), we restricted it to only systems utilizing HW contexts as we were uncertain of how stable our reset mechanism truly was. We now have reasonable coverage across all machines that expose a GPU reset method, and so we should be safe to sanitize the GPU state everywhere. v2: We _have_ to skip the reset if it would clobber the display. Signed-off-by:
-
Chris Wilson authored
As the question of 32b/64b kernels became relevant in the light of certain bugs, include that information in the error state. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103101245.15100-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
On Baytail, notably, we can still detect missed interrupt syndrome (where we never spot a completed request). In this case, it can be alleviated by always keeping the interrupt unmasked, implying that the interrupt is being lost in the window after modifying the IMR. (This is the reason we still have the posting reads on enable_irq, if we remove them we miss interrupts!) Having narrowed the issue down to the IMR, rather than keeping it always enabled, applying the usual posting read/flush of the RING_IMR before unmasking the GT IMR also seems to prevent the missed interrupt. So be it. Signed-off-by:
-
- 02 Jan, 2019 7 commits
-
-
Chris Wilson authored
With kasan on a slow machine, it can take an age to check all the partial mappings in a single iteration, so break it up with a cond_resched) to avoid RCU stall reports. Signed-off-by:
-
Jani Nikula authored
Encourage use of INTEL_INFO() to access dev_priv->info to not accumulate more direct users of ->info, making further changes easier. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The debugfs, error state and regular dmesg logging dump needs seem to be different. Remove the generic dump function only used for the welcome message. This may be added back later when better abstractions are identified, but at the moment this seems to be the simplest considering the device info rework in progress. No longer rely on device info being a substruct of dev_priv. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Hide the way device info is stored, in preparation of making device info a pointer to the const rodata in i915_pci.c. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
With the static/runtime device info split, this makes more sense. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Add a macro wrapper for display_mmio_offset access in register definitions. Prep work for reducing direct dev_priv->info usage. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
First move the low hanging fruit, the fields that are only initialized runtime. Use RUNTIME_INFO() exclusively to access the fields. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
- 31 Dec, 2018 13 commits
-
-
Chris Wilson authored
Now that we have eliminated the CPU-side irq_seqno_barrier by moving the delays on the GPU before emitting the MI_USER_INTERRUPT, we can remove the engine->irq_seqno_barrier infrastructure. Though intentionally slowing down the GPU is nasty, so is the code we can now remove! Signed-off-by:
-
Chris Wilson authored
The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, for Ironlake, the workaround is a pretty hideous usleep() and so even though it was found we need to repeat the MI_STORE_DWORD_IMM 8 times, or about 1us of GPU time, doing so is preferrable than requiring a sleep of 125-250us on the CPU where we desire to respond immediately (ideally from within the interrupt handler)! The additional MI_STORE_DWORD_IMM also have the side-effect of flushing MI operations from userspace which are not caught by MI_FLUSH! Testcase: igt/gem_sync Testcase: igt/gem_exec_whisper Signed-off-by:
-
Chris Wilson authored
The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, the current w/a for Ivybridge is an implicit delay that currently fails sporadically and consistently if we move the w/a into the irq handler itself. This makes the CPU barrier untenable for upcoming interrupt handler changes and so we need to replace it with a delay on the GPU before we send the MI_USER_INTERRUPT. As it turns out that delay is 32x MI_STORE_DWORD_IMM, or about 0.6us per request! Quite nasty, but the lesser of two evils looking to the future. Testcase: igt/gem_sync Signed-off-by:
-
Chris Wilson authored
The MI_FLUSH_DW does appear coherent with the following MI_USER_INTERRUPT, but only on Sandybridge. Ivybridge requires a heavier hammer, but on Sandybridge we can stop requiring the irq_seqno barrier. Testcase: igt/gem_sync Signed-off-by:
-
Chris Wilson authored
Having transitioned to using PIPECONTROL to combine the flush with the breadcrumb write using their post-sync functions, assume that this will resolve the serialisation with the subsequent MI_USER_INTERRUPT. That is when inspecting the breadcrumb after an interrupt we can rely on the write being posted (i.e. the HWSP will be coherent). Testing using gem_sync shows that the PIPECONTROL + CS stall does serialise the command streamer sufficient that the breadcrumb lands before the MI_USER_INTERRUPT. The same is not true for MI_FLUSH_DW. Signed-off-by:
-
Chris Wilson authored
Now that we perform the request flushing inline with emitting the breadcrumb, we can remove the now redundant manual flush. And we can also remove the infrastructure that remained only for its purpose. v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'cur' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'new' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'plane' description in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'state' description in 'intel_wm_need_update' References: cd1d3ee9 ("drm/i915: Use intel_ types more consistently for watermark code (v2)") Signed-off-by:
-
Jani Nikula authored
Macros with this much magic in them deserve some explanatory text. Reviewed-by:
-
Tvrtko Ursulin authored
It is only initialized to zero once so does not need an explicit initializer. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
i915.enable_hangcheck has been an outlier since its introduction in commit 3e0dc6b0 ("drm/i915: hangcheck disable parameter") with 0644 permissions, while all the rest are either 0400 or 0600. Follow suit with 0600. IGT never reads the value, so there should be no impact. Reviewed-by:
-
Jani Nikula authored
Reveals the build fail fixed in the last hunk. Also prep work. v2: name it i915 instead of dev_priv (Michal) Reviewed-by:
-
Jani Nikula authored
Abstract the one user in anticipation of more. Set the dangling pointers to NULL while at it. Reviewed-by:
-
Jani Nikula authored
Abstract the one user in anticipation of more. Reviewed-by:
-
- 28 Dec, 2018 7 commits
-
-
Chris Wilson authored
In preparation for removing the manual EMIT_FLUSH prior to emitting the breadcrumb implement the flush inline with writing the breadcrumb for ringbuffer emission. With a combined flush+breadcrumb, we can use a single operation to both flush and after the flush is complete (post-sync) write the breadcrumb. This gives us a strongly ordered operation that should be sufficient to serialise the write before we emit the interrupt; and therefore we may take the opportunity to remove the irq_seqno_barrier w/a for gen6+. Although using the PIPECONTROL to write the breadcrumb is slower than MI_STORE_DWORD_IMM, by combining the operations into one and removing the extra flush (next patch) it is faster For gen2-5, we simply combine the MI_FLUSH into the breadcrumb emission, though maybe we could find a solution here to the seqno-vs-interrupt issue on Ironlake by mixing up the flush? The answer is no, adding an MI_FLUSH before the interrupt is insufficient. Signed-off-by:
-
Chris Wilson authored
In preparation for removing the manual EMIT_FLUSH prior to emitting the breadcrumb implement the flush inline with writing the breadcrumb for execlists. Using one command to both flush and write the breadcrumb is naturally a tiny bit faster than splitting it into two. Signed-off-by:
-
Chris Wilson authored
Having just gutted the implementation as there is no global seqno tracking, remove the vestigal write-only stub for debugfs/i915_next_seqno. Signed-off-by:
-
Chris Wilson authored
The writing is on the wall for the existence of a single execution queue along each engine, and as a consequence we will not be able to track dependencies along the HW queue itself, i.e. we will not be able to use HW semaphores on gen7 as they use a global set of registers (and unlike gen8+ we can not effectively target memory to keep per-context seqno and dependencies). On the positive side, when we implement request reordering for gen7 we also can not presume a simple execution queue and would also require removing the current semaphore generation code. So this bring us another step closer to request reordering for ringbuffer submission! The negative side is that using interrupts to drive inter-engine synchronisation is much slower (4us -> 15us to do a nop on each of the 3 engines on ivb). This is much better than it was at the time of introducing the HW semaphores and equally important userspace weaned itself off intermixing dependent BLT/RENDER operations (the prime culprit was glyph rendering in UXA). So while we regress the microbenchmarks, it should not impact the user. References: https://bugs.freedesktop.org/show_bug.cgi?id=108888Signed-off-by:
-
Chris Wilson authored
After we found a workaround for a hang on context load, Ben Widawsky found confirmation that it was for an issue with waking from rc6 and loading a context image. The workaround from on high suggests that we should I915_WRITE(RING_WAIT_FOR_RC6_EXIT(engine->mmio_base), _MASKED_FIELD(RING_RC6_SEL_WRITE_ADDR_MASK, RING_RC6_SEL_WRITE_ADDR_UPPER_LEFT)); in our rc6 setup for Haswell GT1, but on applying that we find instead that the machine encounters a GT forcewake error and locks up. As we are removing HW semaphore usage in the next patch, and the suggested workaround is no improvement, we need to decouple the PSMI workaround from HAS_SEMAPHORES to IS_HSW_GT1. References: 2c550183 ("drm/i915: Disable PSMI sleep messages on all rings around context switches") Signed-off-by:
-
Young Xiao authored
If for some unexpected reason the registers all read zero it's better to WARN and return instead of dividing by zero and completely freezing the machine. See commit 0e005888 ("drm/i915: avoid division by zero on cnl_calc_wrpll_link") for detail. Signed-off-by:
Young Xiao <YangX92@hotmail.com> Signed-off-by:
-
Brajeswar Ghosh authored
Remove video/mipi_display.h which is included more than once Signed-off-by:
Brajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by:
-
- 27 Dec, 2018 2 commits
-
-
Chris Wilson authored
The information presented here is not relevant to current development. We can either use the context information, but more often we want to inspect the active gpu state. The ulterior motive is to eradicate dev->filelist. Signed-off-by:
-
Brajeswar Ghosh authored
Remove i915_scheduler.h which is included more than once Signed-off-by:
-
- 25 Dec, 2018 3 commits
-
-
Hans de Goede authored
Call intel_psr_enable() and intel_edp_drrs_enable() on pipe updates to make sure that we enable PSR / DRRS (when applicable) on fastsets. Note calling these functions when PSR / DRRS has already been enabled is a no-op, so it is safe to do this on every encoder->update_pipe callback. Changes in v2: -Merge the patches adding the intel_psr_enable() and intel_edp_drrs_enable() calls into a single patch Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-3-hdegoede@redhat.com
-
Hans de Goede authored
Do not make it an error to call intel_edp_drrs_enable while drrs has already been enabled, instead exit silently in this case. This is a preparation patch for ensuring that DRRS is enabled on fastsets. Note that the removed WARN_ON could also be triggered from userspace through the i915_drrs_ctl debugfs entry which was added by commit 35954e88 ("drm/i915: Runtime disable for eDP DRRS") Reviewed-by:
-
Hans de Goede authored
When we are doing a fastset (needs_modeset=false, update_pipe=true) we may need to update some encoder-level things such as checking that PSR is enabled. This commit adds an update_pipe callback to intel_encoder and a new intel_encoders_update_pipe helper which calls this for all encoders connected to a crtc. The new intel_encoders_update_pipe helper is called from intel_update_crtc when doing a fastset. Changes in v2: -Name the new encoder callback update_pipe instead of just update Reviewed-by:
-
