Chris Wilson [Mon, 3 Feb 2020 09:41:49 +0000 (09:41 +0000)]
drm/i915/gt: Warn about the hidden i915_vma_pin in timeline_get_seqno
On seqno rollover, we need to allocate ourselves a new cacheline. This
might incur grabbing a new page and pinning it into the GGTT, with some
rather unfortunate lockdep implications.
To avoid a mutex, and more specifically pinning in the GGTT from inside
the kernel context being used to flush the GGTT in emergencies, we will
likely need to lift the next-cacheline allocation to a pre-reservation.
Chris Wilson [Mon, 3 Feb 2020 09:41:48 +0000 (09:41 +0000)]
drm/i915: Initialise basic fence before acquiring seqno
Inside the intel_timeline_get_seqno(), we currently track the retirement
of the old cachelines by listening to the new request. This requires
that the new request is ready to be used and so requires a minimum bit
of initialisation prior to getting the new seqno.
Chris Wilson [Mon, 3 Feb 2020 09:41:47 +0000 (09:41 +0000)]
drm/i915: Hold reference to previous active fence as we queue
Take a reference to the previous exclusive fence on the i915_active, as
we wish to add an await to it in the caller (and so must prevent it from
being freed until we have completed that task).
drm/i915: Move ringbuffer WAs to engine workaround list
Now that intel_engine_apply_workarounds is called on all gens, we can
use the engine workaround lists for pre-gen8 workarounds as well to be
consistent in the way we handle and dump the WAs.
v2: Ignore the sanity check of MI_MODE on Broadwater, for whatever reason
it is not sticking.
drm/i915: extract engine WA programming to common resume function
The workarounds are a common "feature" across gens and submission
mechanisms and we already call the other WA related functions from
common engine ones (<setup/cleanup>_common), so it makes sense to
do the same with WA application. Medium-term, This will help us
reduce the duplication once the GuC resume function is added, but short
term it will also allow us to use the workaround lists for pre-gen8
engine workarounds.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Matthew Brost <matthew.brost@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/20200131075716.2212299-2-chris@chris-wilson.co.uk
Michal Wajdeczko [Fri, 31 Jan 2020 15:37:06 +0000 (15:37 +0000)]
drm/i915/guc: Introduce guc_is_ready
We already have guc_is_running function, but it only reflects
firmware status, while to fully use GuC we need to know if we've
already established communication with it.
v2: also s/intel_guc_is_running/intel_guc_is_fw_running (Chris)
Chris Wilson [Fri, 31 Jan 2020 08:15:42 +0000 (08:15 +0000)]
drm/i915/gt: Also use async bind for PIN_USER into bsw/bxt ggtt
In the rare cases where we are using the global GGTT for execution in
the selftests, we have marked them with PIN_USER knowing that they will
be bound as PIN_GLOBAL as well. However, we need to catch the extra flag
in deciding to use the async worker for such binds as well.
Chris Wilson [Thu, 30 Jan 2020 16:45:53 +0000 (16:45 +0000)]
drm/i915/gem: Require per-engine reset support for non-persistent contexts
To enable non-persistent contexts, we require a means of cancelling any
inflight work from that context. This is first done "gracefully" by
using preemption to kick the active context off the engine, and then
forcefully by resetting the engine if it is active. If we are unable to
reset the engine to remove hostile userspace, we should not allow
userspace to opt into using non-persistent contexts.
If the per-engine reset fails, we still do a full GPU reset, but that is
rare and usually indicative of much deeper issues. The damage is already
done. However, the goal of the interface to allow long running compute
jobs without causing collateral damage elsewhere, and if we are unable
to support that we should make that known by not providing the
interface (and falsely pretending we can).
Fixes: a0e047156cde ("drm/i915/gem: Make context persistence optional") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130164553.1937718-1-chris@chris-wilson.co.uk
Ville Syrjälä [Mon, 20 Jan 2020 17:47:28 +0000 (19:47 +0200)]
drm/i915: Store active_pipes bitmask in cdclk state
Let's add a copy of the active_pipes bitmask into the cdclk_state.
While this is duplicating a bit of information we may already
have elsewhere, I think it's worth it to decopule the cdclk stuff
from whatever else wants to use that bitmask. Also we want to get
rid of all the old ad-hoc global state which is what the current
bitmask is, so this removes one obstacle.
The one extra thing we have to remember is write locking the cdclk
state whenever the bitmask changes.
Ville Syrjälä [Tue, 21 Jan 2020 14:03:53 +0000 (16:03 +0200)]
drm/i915: Convert cdclk to global state
Let's convert cdclk_state to be a proper global state. That allows
us to use the regular atomic old vs. new state accessor, hopefully
making the code less confusing.
We do have to deal with a few more error cases in case the cdclk
state duplication fails. But so be it.
v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
Ville Syrjälä [Mon, 20 Jan 2020 17:47:26 +0000 (19:47 +0200)]
drm/i915: Introduce intel_calc_active_pipes()
Extract a small helper to compute the active pipes bitmask
based on the old bitmask + the crtcs in the atomic state.
I want to decouple the cdclk state entirely from the current
global state so I want to track the active pipes also inside
the (to be introduced) full cdclk state.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:25 +0000 (19:47 +0200)]
drm/i915: Convert bandwidth state to global state
Now that we have the more formal global state thing let's
use if for memory bandwidth tracking. No real difference
to the current private object usage since we already
tried to avoid taking the single serializing lock needlessly.
But since we're going to roll the global state out to more
things probably a good idea to unify the approaches a bit.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:24 +0000 (19:47 +0200)]
drm/i915: Introduce better global state handling
Our current global state handling is pretty ad-hoc. Let's try to
make it better by imitating the standard drm core private object
approach.
The reason why we don't want to directly use the private objects
is locking; Each private object has its own lock so if we
introduce any global private objects we get serialized by that
single lock across all pipes. The global state apporoach instead
uses a read/write lock type of approach where each individual
crtc lock counts as a read lock, and grabbing all the crtc locks
allows one write access.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:21 +0000 (19:47 +0200)]
drm/i915: s/init_cdclk/init_cdclk_hw/
Give the cdclk init/uninit functions a _hw suffix to make
it clear they are about initializing the actual hardware.
I'll be wanting to to add a intel_cdclk_init() which is
purely initializing software structures.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:16 +0000 (19:47 +0200)]
drm/i915: s/need_cd2x_updare/can_cd2x_update/
intel_cdclk_needs_cd2x_update() is named rather confusingly.
We don't have to do a cd2x update, rather we are allowed to
do one (as opposed to a full PLL reprogramming with its heavy
handed modeset). So let's rename the function to
intel_cdclk_can_cd2x_update().
Ville Syrjälä [Mon, 20 Jan 2020 17:47:15 +0000 (19:47 +0200)]
drm/i915: Collect more cdclk state under the same roof
Move the min_cdclk[] and min_voltage_level[] arrays under the
rest of the cdclk state. And while at it provide a simple
helper (intel_cdclk_clear_state()) to clear the state during
the ww_mutex backoff dance.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:14 +0000 (19:47 +0200)]
drm/i915: Move more cdclk state handling into the cdclk code
Move the initial setup of state->{cdclk,min_cdclk[],min_voltage_level[]}
into intel_modeset_calc_cdclk(), and we'll move the counterparts into
intel_cdclk_swap_state(). This encapsulates the cdclk state much better.
Ville Syrjälä [Mon, 20 Jan 2020 17:47:12 +0000 (19:47 +0200)]
drm/i915: Move linetime wms into the crtc state
The linetime watermarks really have very little in common with the
plane watermarks. It looks to be cleaner to simply track them in
the crtc_state and program them from the normal modeset/fastset
paths.
The only dark cloud comes from the fact that the register is
still supposedly single buffered. So in theory it might still
need some form of two stage programming. Note that even though
HSW/BDWhave two stage programming we never computed any special
intermediate values for the linetime watermarks, and on SKL+
we don't even have the two stage stuff plugged in since everything
else is double buffered. So let's assume it's all fine and
continue doing what we've been doing.
Actually on HSW/BDW the value should not even change without
a full modeset since it doesn't account for pfit downscaling.
Thus only fastboot might be affected. But on SKL+ the pfit
scaling factor is take into consideration so the value may
change during any fastset.
As a bonus we'll plug this thing into the state
checker/dump now.
v2: Rebase due to bigjoiner prep
v2: Only compute ips linetime for IPS capable pipes.
Bspec says the register values is ignored for other
pipes, but in fact it can't even be written so the
state checker becomes unhappy if we don't compute
it as zero.
Vandita Kulkarni [Tue, 28 Jan 2020 16:28:49 +0000 (18:28 +0200)]
drm/i915/dsi: Enable ICL DSI transcoder as part of encoder->enable
Enable the dsi transcoder, panel and backlight as part of
encoder->enable and not encoder->pre_enable. We need to have pipe src
size, among other things, set before enabling the transcoder, to avoid
FIFO underruns and possibly other issues.
v2 by Jani:
- Rebase on the crtc enable sequence update
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.
José Roberto de Souza [Wed, 29 Jan 2020 23:23:45 +0000 (15:23 -0800)]
drm/i915: Fix preallocated barrier list append
Only the first and the last nodes were being added to
ref->preallocated_barriers.
Renaming variables to make it more easy to read.
Fixes: 841350223816 ("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 ac0e331a628b ("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.
projects / users / jedix / linux-maple.git / log