Jani Nikula [Tue, 28 Jan 2020 16:28:48 +0000 (18:28 +0200)]
drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms
To allow better flexibility for encoder specific code, push
intel_enable_pipe(), lpt_pch_enable() and intel_crtc_vblank_on() down to
the encoders from hsw_crtc_enable().
There's slight duplication, but also more clarity with the reduced
conditional statements.
Chris Wilson [Thu, 30 Jan 2020 18:17:10 +0000 (18:17 +0000)]
drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex
On Braswell and Broxton (also known as Valleyview and Apollolake), we
need to serialise updates of the GGTT using the big stop_machine()
hammer. This has the side effect of appearing to lockdep as a possible
reclaim (since it uses the cpuhp mutex and that is tainted by per-cpu
allocations). However, we want to use vm->mutex (including ggtt->mutex)
from within the shrinker and so must avoid such possible taints. For this
purpose, we introduced the asynchronous vma binding and we can apply it
to the PIN_GLOBAL so long as take care to add the necessary waits for
the worker afterwards.
Chris Wilson [Thu, 30 Jan 2020 18:17:09 +0000 (18:17 +0000)]
drm/i915/gt: Rename i915_gem_restore_ggtt_mappings() for its new placement
The i915_ggtt now sits beneath gt/ outside of the auspices of gem/ and
should be given a fresh name to reflect that. We also want to give it a
name that reflects its role in the system suspend/resume, with the
intention of pulling together all the GGTT operations (e.g. restoring
the fence registers once they are pulled under gt/intel_ggtt_detiler.c)
Chris Wilson [Thu, 30 Jan 2020 13:51:36 +0000 (13:51 +0000)]
drm/i915/fbc: __intel_fbc_cleanup_cfb() may be called multiple times
Avoid releasing the same stolen nodes causing a use-after-free and/or
explosions as the self-checks fail, as __intel_fbc_cleanup_cfb() may be
called multiple times during module unload.
Chris Wilson [Thu, 30 Jan 2020 09:22:38 +0000 (09:22 +0000)]
drm/i915/gt: Skip global serialisation of clear_range for bxt vtd
VT'd on Broxton and on Braswell require serialisation of GGTT updates.
However, it seems to only be required for insertion, so drop the
complication and heavyweight stop_machine() for clears. The range will
be serialised again before use.
Wambui Karuga [Tue, 28 Jan 2020 07:14:36 +0000 (10:14 +0300)]
drm/i915/ring: convert to new logging macros in gt/intel_ring_submission.c
Manually convert the remaining instance of the printk based drm logging
macros to the struct drm_device based logging macros in
i915/gt/intel_ring_submission.c
Wambui Karuga [Tue, 28 Jan 2020 07:14:31 +0000 (10:14 +0300)]
drm/i915/ggtt: use new drm logging macros in gt/intel_ggtt.c
Manual conversion of the printk based logging macros to the new struct
drm_based logging macros in drm/i915/gt/intel_ggtt.c.
Also includes extracting the struct drm_i915_private device from various
intel types to use in the new macros.
Only the first and the last nodes were being added to
ref->preallocated_barriers.
Renaming variables to make it more easy to read.
Fixes: 243f5ed4c03e ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200129232345.84512-1-jose.souza@intel.com
Chris Wilson [Wed, 29 Jan 2020 16:59:35 +0000 (16:59 +0000)]
drm/i915/execlists: Ignore discrepancies in pending[] across resets
When we reset the engine, we first remove the guilty request from the
active list. If it so happens that there is a pending preemption event
to process before we handle the reset, when we inspect that event we
find ourselves a little confused as we have bent the rules slightly to
perform the reset.
Just ignore any discrepancies inside reset, we know we'll start again
from scratch afterwards.
Chris Wilson [Tue, 28 Jan 2020 20:43:15 +0000 (20:43 +0000)]
drm/i915/gt: Hook up CS_MASTER_ERROR_INTERRUPT
Now that we have offline error capture and can reset an engine from
inside an atomic context while also preserving the GPU state for
post-mortem analysis, it is time to handle error interrupts thrown by
the command parser.
This provides a much, much faster mechanism for us to detect known
problems than using heartbeats/hangchecks, and also provides a mechanism
for when those are disabled. However, it is limited to problems the HW
can detect in the CS and so not a complete solution for detecting lockups.
Chris Wilson [Tue, 28 Jan 2020 17:16:14 +0000 (17:16 +0000)]
drm/i915/execlist: Mark up racy read of execlists->pending[0]
We write to execlists->pending[0] in process_csb() to acknowledge the
completion of the ESLP update, outside of the main spinlock. When we
check the current status of the previous submission in
__execlists_submission_tasklet() we should therefore use READ_ONCE() to
reflect and document the unsynchronized read.
Jani Nikula [Mon, 27 Jan 2020 18:26:10 +0000 (20:26 +0200)]
drm/i915/psr: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:09 +0000 (20:26 +0200)]
drm/i915/hdcp: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:08 +0000 (20:26 +0200)]
drm/i915/dp: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:07 +0000 (20:26 +0200)]
drm/i915/display_power: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:06 +0000 (20:26 +0200)]
drm/i915/display: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:05 +0000 (20:26 +0200)]
drm/i915/ddi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:04 +0000 (20:26 +0200)]
drm/i915/combo_phy: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Mon, 27 Jan 2020 18:26:03 +0000 (20:26 +0200)]
drm/i915/icl_dsi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Chris Wilson [Mon, 27 Jan 2020 23:15:40 +0000 (23:15 +0000)]
drm/i915/gt: Lift set-wedged engine dumping out of user paths
The user (e.g. gem_eio) can manipulate the driver into wedging itself,
allowing the user to trigger voluminous logging of inconsequential
details. If we lift the dump to direct calls to intel_gt_set_wedged(),
out of the intel_reset failure handling, we keep the detail logging for
what we expect are true HW or test failures without being tricked.
Chris Wilson [Mon, 27 Jan 2020 23:15:36 +0000 (23:15 +0000)]
drm/i915/gt: Reorganise gen8+ interrupt handler
We always use a deferred bottom-half (either tasklet or irq_work) for
processing the response to an interrupt which means we can recombine the
GT irq ack+handler into one. This simplicity is important in later
patches as we will need to handle and then ack multiple interrupt levels
before acking the GT and master interrupts.
Chris Wilson [Tue, 28 Jan 2020 11:34:26 +0000 (11:34 +0000)]
drm/i915: Skip capturing errors from internal contexts
We don't want to report errors on the internal contexts to userspace,
suppressing their own, so treat them as simulated errors. These mostly
arise inside selftests and so are simulated anyway. For the rest, we can
rely on the normal debug channels in CI.
Chris Wilson [Mon, 27 Jan 2020 15:28:29 +0000 (15:28 +0000)]
drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Similar to commit 86911e6f2c30 ("drm/i915: Tighten atomicity of
i915_active_acquire vs i915_active_release") we have the same race of
trying to pin the context underneath a mutex while allowing the
decrement to be atomic outside of that mutex. This leads to the problem
where two threads may simultaneously try to pin the context and the
second not notice that they needed to repin the context.
Jani Nikula [Fri, 24 Jan 2020 13:25:54 +0000 (15:25 +0200)]
drm/i915/vlv_dsi_pll: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:53 +0000 (15:25 +0200)]
drm/i915/vlv_dsi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:51 +0000 (15:25 +0200)]
drm/i915/vdsc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:49 +0000 (15:25 +0200)]
drm/i915/sprite: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:47 +0000 (15:25 +0200)]
drm/i915/psr: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:46 +0000 (15:25 +0200)]
drm/i915/pipe_crc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Ville Syrjälä [Thu, 23 Jan 2020 15:45:42 +0000 (17:45 +0200)]
drm/i915: Give aux channels a better name
The aux ch is used for more than DDC, so let's give it a better
name. For maximum ease let's include both the AUX ch identifier
and the port identifier (for cases where the VBT has redefined
the relationship of the two).
Chris Wilson [Sun, 26 Jan 2020 10:23:43 +0000 (10:23 +0000)]
drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
So thread A has acquired the ref->active_count but since the ref was
still active at the time, it did not initialise it. By switching the
check inside the mutex to an atomic increment only if already active, we
close the race.
Jani Nikula [Fri, 24 Jan 2020 13:25:52 +0000 (15:25 +0200)]
drm/i915/vga: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:50 +0000 (15:25 +0200)]
drm/i915/tv: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:48 +0000 (15:25 +0200)]
drm/i915/sdvo: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:45 +0000 (15:25 +0200)]
drm/i915/panel: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:44 +0000 (15:25 +0200)]
drm/i915/overlay: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:43 +0000 (15:25 +0200)]
drm/i915/lvds: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:42 +0000 (15:25 +0200)]
drm/i915/lpe_audio: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:41 +0000 (15:25 +0200)]
drm/i915/hdmi: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:39 +0000 (15:25 +0200)]
drm/i915/gmbus: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:38 +0000 (15:25 +0200)]
drm/i915/fifo_underrun: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:37 +0000 (15:25 +0200)]
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:36 +0000 (15:25 +0200)]
drm/i915/dvo: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:35 +0000 (15:25 +0200)]
drm/i915/dsb: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:34 +0000 (15:25 +0200)]
drm/i915/dp_mst: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:33 +0000 (15:25 +0200)]
drm/i915/dpll_mgr: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:32 +0000 (15:25 +0200)]
drm/i915/dpio_phy: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:27 +0000 (15:25 +0200)]
drm/i915/crt: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:25 +0000 (15:25 +0200)]
drm/i915/color: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:24 +0000 (15:25 +0200)]
drm/i915/cdclk: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Jani Nikula [Fri, 24 Jan 2020 13:25:23 +0000 (15:25 +0200)]
drm/i915/audio: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
Ville Syrjälä [Wed, 22 Jan 2020 20:43:29 +0000 (22:43 +0200)]
drm/i915: Fix modeset locks in sanitize_watermarks()
We've added more internal things that use modeset locks and
thus we need to be prepared for intel_atomic_check() grabbing
more locks than what our initial drm_modeset_lock_all_ctx()
took. So we're missing the backoff handling here.
Also drm_atomic_helper_duplicate_state() works against us
by clearing state->acquire_ctx in anticipation of
drm_atomic_helper_commit_duplicated_state() being used to
commit the state.
We could probably just reset acquire_ctx back, but instead
let's just rewrite the whole thing without using either of
those "helpers". There's also no need to add any connectors
to the state here since we just want the new watermarks
which don't depend on connectors.
drm/i915: Fix inconsistance between pfit.enable and scaler freeing
Despite that during hw readout we seem to have scalers assigned
to pipes, then call atomic_setup_scalers, at the commit stage in
skl_update_scaler there is a check, that if we have fb src and
dest of same size, we stage freeing of that scaler.
However we don't update pfit.enabled flag then, which makes
the state inconsistent, which in turn triggers a WARN_ON
in skl_pfit_enable, because we have pfit enabled,
but no assigned scaler.
To me this looks weird that we kind of do the decision
to use or not use the scaler at skl_update_scaler stage
but not in intel_atomic_setup_scalers, moreover
not updating the whole state consistently.
This fix is to not free the scaler if we have pfit.enabled
flag set, so that the state is now consistent
and the warnings are gone.
v2: - Put pfit.enable check into crtc specific place
(Ville Syrjälä)
Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/577 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200124172301.16484-1-stanislav.lisovskiy@intel.com
Chris Wilson [Fri, 24 Jan 2020 23:06:56 +0000 (23:06 +0000)]
drm/i915: Remove 'prefault_disable' modparam
The 'prefault_disable' modparam was used by IGT to prevent a few
prefaulting operations to make fault handling under struct_mutex more
prominent. With the removal of struct_mutex, this is not as important
any more and we have almost completely stopped using the parameter. The
remaining use in execbuf is now immaterial and can be dropped without
affecting coverage.
We must re-address the idea of fault injection though.
Chris Wilson [Sun, 26 Jan 2020 19:56:54 +0000 (19:56 +0000)]
drm/i915/display: Squelch kerneldoc complaints
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'state' not described in 'intel_connector_needs_modeset'
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'connector' not described in 'intel_connector_needs_modeset'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or member 'state' not described in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'crtc_state' description in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'plane_state' description in 'intel_fbc_enable'
Wambui Karuga [Wed, 22 Jan 2020 12:57:50 +0000 (15:57 +0300)]
drm/i915/gem: manual conversion to struct drm_device logging macros.
Convert most of the remaining uses of the printk based logging macros to
the new struct drm_device based logging macros in drm/i915/gem.
This also involves extracting the struct drm_i915_private device
from various types, and using it in the various macros.
Wambui Karuga [Wed, 22 Jan 2020 12:57:49 +0000 (15:57 +0300)]
drm/i915/gem: initial conversion to new logging macros using coccinelle
First pass of conversion to the new struct drm_based device logging
macros in the drm/i915/gem directory. This conversion was achieved using
the following coccinelle script that transforms based on the existence
of a straightforward struct drm_i915_private device:
Wambui Karuga [Wed, 22 Jan 2020 11:08:44 +0000 (14:08 +0300)]
drm/i915/hdcp: conversion to struct drm_device based logging macros.
Converts various instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros using
coccinelle. The script matches based on the existence of an existing
struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
Wambui Karuga [Wed, 22 Jan 2020 11:08:43 +0000 (14:08 +0300)]
drm/i915/opregion: conversion to struct drm_device logging macros.
This converts various instances of the printk based logging macros in
i915/display/intel_opregion.c with the new struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
Wambui Karuga [Wed, 22 Jan 2020 11:08:42 +0000 (14:08 +0300)]
drm/i915/dp: conversion to struct drm_device logging macros.
This converts various instances of printk based logging macros in
i915/display/intel_dp.c with the new struct drm_device based logging
macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
Wambui Karuga [Wed, 22 Jan 2020 11:08:41 +0000 (14:08 +0300)]
drm/i915/power: convert to struct drm_device macros in display/intel_display_power.c
Converts various instances of the printk based logging macros in
i915/display/intel_display_power.c to the struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
Wambui Karuga [Wed, 22 Jan 2020 11:08:39 +0000 (14:08 +0300)]
drm/i915/dsi: conversion to struct drm_device log macros.
This converts the more straightforward instances of the printk based
logging macros with the struct drm_device based logging macros.
This transformation was achieved using coccinelle and the following
script for matching an existing struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
Wambui Karuga [Tue, 21 Jan 2020 21:46:41 +0000 (00:46 +0300)]
drm/i915/display: conversion to new struct drm_device logging macros.
This patch converts various instances of the printk based logging macros
in drm/i915/display/intel_display.c to the new struct drm_device based
logging macros.
In some instances, this involves extracting the struct drm_i915_private
device from various intel types and using it in the macros.
v2: use correct variable name in assignment over variable type.
Michal Wajdeczko [Mon, 20 Jan 2020 19:18:17 +0000 (19:18 +0000)]
drm/i915/guc: Don't GEM_BUG_ON on corrupted H2G CTB
We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indicate that we will not process
any further messages over this CTB (until reset).
Chris Wilson [Fri, 24 Jan 2020 11:51:33 +0000 (11:51 +0000)]
drm/i915/gt: Poison GTT scratch pages
Using a clear page for scratch means that we have relatively benign
errors in case it is accidentally used, but that can be rather too
benign for debugging. If we poison the scratch, ideally it quickly
results in an obvious error.
v2: Set each page individually just in case we are using highmem for our
scratch page.
v3: Pick a new scratch register as MI_STORE_REGISTER_MEM does not work
with GPR0 on gen7, unbelievably.
v4: Haswell still considers 3DPRIM a privileged register!
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200124115133.53360-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 24 Jan 2020 14:33:39 +0000 (14:33 +0000)]
drm/i915/gt: Flush engine parking before release
Due to the asynchronous nature of releasing our wakerefs, we can signal
the main GT wakeref as complete before the individual engines have
cleared their own wakerefs. During shutdown we assert that the engines
are indeed parked before we release them, but for this to be always true
we need to flush their workers as well.
Vivek Kasireddy [Tue, 21 Jan 2020 23:58:48 +0000 (15:58 -0800)]
drm/i915/ehl: Ensure that the DDI selection MUX is programmed correctly
Perhaps in some cases the BIOS/GOP or other firmware may turn on
PHY A but may not program the MUX correctly. Therefore, re-program
PHY A if it is determined after reading the VBT that the value
programmed for the MUX bit does not match the expected value.
drm/i915/dc3co: Avoid full modeset when EXITLINE needs to be changed
A recent change in BSpec allow us to change EXTLINE while transcoder
is enabled so this allow us to change it even when doing the first
fastset after taking over previous hardware state set by BIOS.
BIOS don't enable PSR, so if sink supports PSR it will be enabled on
the first fastset, so moving the EXTLINE compute and set to PSR flows
allow us to simplfy a bunch of code.
This will save a lot of time in all the IGT tests that uses CRC, as
when PSR2 is enabled CRCs are not generated, so we switch to PSR1, so
the previous code would compute dc3co_exitline=0 causing a full
modeset that would shutdown pipe, enable and train link.
v2: only programming EXTLINE when DC3CO is enabled
Vivek Kasireddy [Sat, 18 Jan 2020 00:58:48 +0000 (16:58 -0800)]
drm/i915/dsi: Ensure that the ACPI adapter lookup overrides the bus num
Remove the i2c_bus_num >= 0 check from the adapter lookup function
as this would prevent ACPI bus number override. This check was mainly
there to return early if the bus number has already been found but we
anyway return in the next line if the slave address does not match.
Fixes: 19f655c20234 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200118005848.20382-1-vivek.kasireddy@intel.com
Rajat Jain [Fri, 20 Dec 2019 20:03:51 +0000 (12:03 -0800)]
drm/i915/acpi: Move the code to populate ACPI device ID into intel_acpi
Move the code that populates the ACPI device ID for devices, into more
appripriate intel_acpi.c. This is done in preparation for more users of
this code.
Chris Wilson [Thu, 23 Jan 2020 22:44:59 +0000 (22:44 +0000)]
drm/i915: Wait on vma activity before taking the mutex
Optimistically wait for the prior vma activity before taking the mutex
to minimise the mutex hold time while unbinding. We will then verify the
vma is idle with a second wait under the mutex to ensure it is safe to
unbind.
Chris Wilson [Thu, 23 Jan 2020 22:44:58 +0000 (22:44 +0000)]
drm/i915: Check activity on i915_vma after confirming pin_count==0
Only assert that the i915_vma is now idle if and only if no other pins
are present. If another user has the i915_vma pinned, they may submit
more work to the i915_vma skipping the vm->mutex used to serialise the
unbind. We need to wait again, if we want to continue and unbind this
vma.
However, if we own the i915_vma (we hold the vm->mutex for the unbind
and the pin_count is 0), we can assert that the vma remains idle as we
unbind.
Fixes: 587eefbe9921 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Closes: https://gitlab.freedesktop.org/drm/intel/issues/530 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123224459.38128-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Jan 2020 15:26:02 +0000 (15:26 +0000)]
drm/i915/gem: Prevent NULL pointer dereference on missing ctx->vm
If the ctx->vm is freed before we can acquire a local reference to it,
we proceed to call i915_vm_put(NULL), which is invalid.
Reported-by: Colin Ian King <colin.king@canonical.com> Fixes: 20c4c5ceff9d ("drm/i915/gem: Convert vm idr to xarray") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Colin Ian King <colin.king@canonical.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123152602.1432282-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Jan 2020 14:57:55 +0000 (14:57 +0000)]
drm/i915/selftests: Show the RC6 residency on parking failure
Include the current RC6 residency counter in the error message, so that
if we fail to park and manually enter RC6 we can see if the counter has
a particularly suspect value (such as 0).
Wambui Karuga [Tue, 21 Jan 2020 13:45:59 +0000 (16:45 +0300)]
drm/i915/cdclk: use new struct drm_device logging macros
Converts instances of the printk based debugging macros with the new
struct drm_device based logging macros in i915/display/intel_cdclk.c.
The conversion is achieved using the following coccinelle script that
transforms based on the existence of a struct drm_i915_private device in
the function:
Wambui Karuga [Tue, 21 Jan 2020 13:45:58 +0000 (16:45 +0300)]
drm/i915/bw: convert to drm_device based logging macros
This replaces the printk based logging macros with the struct drm_based
macros in i915/display/intel_bw.c
This transformation was achieved by using the following coccinelle
script that matches based on the existence of a struct drm_i915_private
device in the functions:
projects / kernel.git / log