Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:02 +0000 (22:25 +0530)]
drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:01 +0000 (22:25 +0530)]
drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
Kees Cook [Fri, 21 Feb 2020 00:05:17 +0000 (16:05 -0800)]
drm/i915: Distribute switch variables for initialization
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, move such variables into the "case" where
they're used or lift them up into the main function body.
drivers/gpu/drm/i915/display/intel_display.c: In function ‘check_digital_port_conflicts’:
drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement will never be executed [-Wswitch-unreachable]
12963 | unsigned int port_mask;
| ^~~~~~~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’:
drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be executed [-Wswitch-unreachable]
474 | u32 dsparb, dsparb2, dsparb3;
| ^~~~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’:
drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be executed [-Wswitch-unreachable]
1997 | u32 dsparb, dsparb2, dsparb3;
| ^~~~~~
Jani Nikula [Wed, 19 Feb 2020 13:37:56 +0000 (15:37 +0200)]
drm/i915: split i915_driver_modeset_probe() to pre/post irq install
Pair the irq install and uninstall in the same layer. There are no
functional changes in the happy day scenario. The cleanup paths are
currently a mess though.
Note that modeset probe pre-irq + post-irq install are matched by
modeset driver remove pre-irq + post-irq uninstall, together, but not
independently. They are not symmetric pairs.
Chris Wilson [Fri, 21 Feb 2020 23:51:35 +0000 (23:51 +0000)]
drm/i915/gt: Push the GPU cancellation to the backend
Upon unregistering the user interface, we mark the GPU as wedged to
ensure we push no new work to the GPU, and to flush all current work
from the GPU. Move this call to the GT backend.
Chris Wilson [Fri, 21 Feb 2020 22:18:18 +0000 (22:18 +0000)]
drm/i915: Avoid recursing onto active vma from the shrinker
We mark the vma as active while binding it in order to protect outselves
from being shrunk under mempressure. This only works if we are strict in
not attempting to shrink active objects.
Matt Roper [Wed, 19 Feb 2020 21:56:55 +0000 (13:56 -0800)]
drm/i915/tgl: Add Wa_22010178259:tgl
We need to explicitly set the TLB Request Timer initial value in the
BW_BUDDY registers to 0x8 rather than relying on the hardware default.
v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct
bits during the rmw. (Jose)
Bspec: 52890
Bspec: 50044 Fixes: 3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200219215655.2923650-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Chris Wilson [Fri, 21 Feb 2020 12:19:40 +0000 (12:19 +0000)]
drm/i915: Check that the vma hasn't been closed before we insert it
As there is a delay before we pin a vma, there is an opportunity for
another thread to have closed the vm and its vma (including us).
Check as soon as we acquire the vm->mutex and know the vm/vma is stable.
Michał Winiarski [Wed, 19 Feb 2020 16:18:22 +0000 (17:18 +0100)]
drm/i915/pmu: Avoid using globals for PMU events
Attempting to bind / unbind module from devices where we have both
integrated and discreete GPU handled by i915, will cause us to try and
double free the global state, hitting null ptr deref in free_event_attributes.
Let's move it to i915_pmu.
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@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/20200219161822.24592-2-michal.winiarski@intel.com
Michał Winiarski [Wed, 19 Feb 2020 16:18:21 +0000 (17:18 +0100)]
drm/i915/pmu: Avoid using globals for CPU hotplug state
Attempting to bind / unbind module from devices where we have both
integrated and discreete GPU handled by i915 can lead to leaks and
warnings from cpuhp:
Error: Removing state XXX which has instances left.
Let's move the state to i915_pmu.
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@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/20200219161822.24592-1-michal.winiarski@intel.com
Wambui Karuga [Tue, 18 Feb 2020 17:39:36 +0000 (20:39 +0300)]
drm/i915/perf: conversion to struct drm_device based logging macros.
Manual conversion of instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/i915_perf.c.
Also involves extraction of the struct drm_i915_private device from
various intel types for use in the macros.
Instances of the DRM_DEBUG printk macro were not converted due to the
lack of an analogous struct drm_device based logging macro.
v2: remove instances of DRM_DEBUG that were converted.
Matt Roper [Tue, 4 Feb 2020 01:10:32 +0000 (17:10 -0800)]
drm/i915/tgl: Program MBUS_ABOX{1,2}_CTL during display init
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
during display initialization, but on gen12 we're now supposed to
program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.
v2:
- Program registers with rmw to preserve contents of unrelated bits.
- Switch to the new display uncore helpers.
Matt Roper [Tue, 4 Feb 2020 01:10:31 +0000 (17:10 -0800)]
drm/i915: Program MBUS with rmw during initialization
It wasn't terribly clear from the bspec's wording, but after discussion
with the hardware folks, it turns out that we need to preserve the
pre-existing contents of the MBUS ABOX control register when
initializing a few specific bits.
Ville Syrjälä [Wed, 12 Feb 2020 16:17:32 +0000 (18:17 +0200)]
drm/i915: Use intel_de_write_fw() for skl+ scaler registers
We have to write quite a few registers when programming the
pipe scaler. Let's use intel_de_write_fw() for these to reduce
the lockdep overhead a bit. All plane registers (including plane
scaler) already do this.
We already had a few accidental intel_de_write_fw() in there.
Ville Syrjälä [Wed, 5 Feb 2020 18:35:43 +0000 (20:35 +0200)]
drm/i915: Mark all HPD capabled connectors as such
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT}
bits in intel_connector->polled (the base setting), leading to
some confusing looking code to reset drm_connector->polled
(the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set
intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd
capable connectors, and then we don't need so many special
cases in the hotplug code.
Ville Syrjälä [Wed, 5 Feb 2020 18:35:42 +0000 (20:35 +0200)]
drm/i915/hpd: Replace the loop-within-loop with two independent loops
No point in looping over all connectors for each hpd pin. Just loop
over each connector first and deal with each one's hpd pin. Then
loop over all the hpd pins to mark them as enabled again.
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from gem_driver_release, so let's stop cleaning up from
all the other paths.
The fact that we're not cleaning the firmware immediately means that
we can't consider firmware availability as an indication of
initialization success. A "LOADABLE" status has been added to
indicate that the initialization was successful, to be used to
selectively load HuC only if HuC init has completed (HuC init failure
is not considered a fatal error).
v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the
fw is in loadable state
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-9-daniele.ceraolospurio@intel.com
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related objects; if we get such a failure better to bail out
immediately instead of wedging later, like we do for e.g.
intel_engines_init, since without objects we can't use the HW, including
not being able to attempt the firmware load.
While at it, remove the unneeded fw_cleanup call (this is handled
outside of gt_init) and add a probe failure injection point for testing.
Also, update the logs for <g/h>uc_init failures to probe_failure() since
they will cause the driver load to fail.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-8-daniele.ceraolospurio@intel.com
drm/i915/guc: Apply new uC status tracking to GuC submission as well
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't really
fall-back to anything, we can "officialize" the FW fetching completion
as the moment at which we're committing to using GuC.
To better differentiate this case, the uses_guc check, which indicates
that GuC is supported and was selected in modparam, is renamed to
wants_guc and a new uses_guc is introduced to represent the case were
we're committed to using the GuC. Note that uses_guc does still not imply
that the blob is actually loaded on the HW (is_running is the check for
that). Also, since we need to have attempted the fetch for the result
of uses_guc to be meaningful, we need to make sure we've moved away
from INTEL_UC_FIRMWARE_SELECTED.
All the GuC changes have been mirrored on the HuC for coherency.
v2: split fetch return changes and new macros to their own patches,
support HuC only if GuC is wanted, improve "used" state
description (Michal)
v3: s/wants_huc/uses_huc in uc_init_wopcm
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: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
drm/i915/uc: Update the FW status on injected fetch error
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-4-daniele.ceraolospurio@intel.com
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-1-daniele.ceraolospurio@intel.com
Chris Wilson [Thu, 20 Feb 2020 12:36:07 +0000 (12:36 +0000)]
drm/i915: Double check bumping after the spinlock
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
Chris Wilson [Thu, 20 Feb 2020 07:50:20 +0000 (07:50 +0000)]
drm/i915/gt: Protect signaler walk with RCU
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new waiters") Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220075025.1539375-1-chris@chris-wilson.co.uk
Manasi Navare [Fri, 14 Feb 2020 11:41:25 +0000 (03:41 -0800)]
drm/i915/dp: Compute port sync crtc states post compute_config()
This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.
v3:
* Make crtc_state const, remove crtc state NULL init (Ville)
v2:
* Correct indentation
* Rename to intel_ddi_port_sync_transcoders (Ville)
* remove unwanted debug (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-2-manasi.d.navare@intel.com
Add an optional secondary encoder state compute hook. This gets
called after the normak .compute_config() has been called for
all the encoders in the state. Thus in the new hook we can rely
on all derived state populated by .compute_config() to be already
set up. Should be useful for MST and port sync master/slave
transcoder selection.
Chris Wilson [Wed, 19 Feb 2020 12:34:18 +0000 (12:34 +0000)]
drm/i915/selftests: Mark GPR checking more hostile
Currently, we check that a new context has a clear set of general
purpose registers. Add a little bit of hostility by preempting our new
context and re-poisoning the GPR to ensure that there is no context
leakage from preemption.
Chris Wilson [Sun, 16 Feb 2020 16:34:45 +0000 (16:34 +0000)]
drm/i915: Read rawclk_freq earlier
Read the rawclk_freq during runtime info probing, prior to its first use
in computing the CS timestamp frequency. Then store it in the runtime
info, and include it in the debug printouts.
Chris Wilson [Tue, 18 Feb 2020 16:21:48 +0000 (16:21 +0000)]
drm/i915/gt: Refactor l3cc/mocs availability
On dgfx, we only use l3cc and not mocs, but we share the table
containing both register definitions with Tigerlake. This confuses our
selftest that verifies that both sets of registers do contain the values
in our tables after various events (idling, reset, activity etc).
When constructing the table of register definitions, also include the
flags for which registers are valid so that information is computed
centrally and available to all callers.
Jani Nikula [Fri, 14 Feb 2020 13:50:58 +0000 (15:50 +0200)]
drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
Jani Nikula [Fri, 14 Feb 2020 13:50:57 +0000 (15:50 +0200)]
drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall. Move
irq_unintall() closer to the layer it belongs.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
Jani Nikula [Mon, 17 Feb 2020 18:42:19 +0000 (20:42 +0200)]
drm/i915/gem: use spinlock_t instead of struct spinlock
spinlock_t is one case where the typedef is to be preferred over struct
spinlock.
Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200217184219.15325-1-jani.nikula@intel.com
Chris Wilson [Tue, 18 Feb 2020 21:12:15 +0000 (21:12 +0000)]
drm/i915/selftests: Flush tasklet on wait_for_submit()
Always flush the tasklet if we have pending submissions in
wait_for_submit(), so that even if we see the HW has started before we
process its ack, when we return the execlists state is well defined.
Jani Nikula [Fri, 14 Feb 2020 14:09:10 +0000 (16:09 +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 [Fri, 14 Feb 2020 14:09:09 +0000 (16:09 +0200)]
drm/i915/csr: 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, 17 Feb 2020 09:58:35 +0000 (09:58 +0000)]
drm/i915/gt: Rearrange code to silence compiler
Without selftests enabled, I915_SELFTEST_ONLY becomes a dummy,
generating a bare '0'. This causes the compiler to complain about a
useless line, and while we could use I915_SELFTEST_DECLARE instead, it
is a bit messier. Move the selftest-only code to a helper and make that
conditional on having selftests enabled.
Jani Nikula [Wed, 12 Feb 2020 14:40:57 +0000 (16:40 +0200)]
drm/i915: split out vlv/chv specific suspend/resume code
i915_drv.c is a fairly big file, and having very specific vlv/chv
suspend/resume code in it is a distraction. Split it out to a new
vlv_suspend.[ch] file.
Chris Wilson [Sun, 16 Feb 2020 16:17:46 +0000 (16:17 +0000)]
drm/i915: Avoid potential division-by-zero in computing CS timestamp period
Since we use a HW readback or estimation of the CS timestamp frequency,
sometimes it may result in 0. Avoid the division-by-zero in computing
its reciprocal, the timestamp period.
Tvrtko Ursulin [Sun, 16 Feb 2020 13:36:20 +0000 (13:36 +0000)]
drm/i915: Track hw reported context runtime
GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
which will be useful for us in cases when we are not able to track context
busyness ourselves (like with GuC). Keep a copy of this in struct
intel_context from where it can be easily read even if the context is not
pinned.
v2:
(Chris)
* Do not store pphwsp address in intel_context.
* Log CS wrap-around.
* Simplify calculation by relying on integer wraparound.
v3:
* Include total/avg in traces and error state for debugging
Ville Syrjälä [Thu, 13 Feb 2020 14:04:12 +0000 (16:04 +0200)]
drm/i915: Force state->modeset=true when distrust_bios_wm==true
Currently when we load the driver we set distrust_bios_wm=true, which
will cause active_pipe_changes to get flagged even when we're not
toggling any pipes on/off. The reason being that we want to fully
redistribute the dbuf among the active pipes and ignore whatever
state the firmware left behind.
Unfortunately when the code flags active_pipe_changes it doesn't
set state->modeset to true, which means the hardware dbuf state
won't actually get updated. Hence the hardware and software
states go out of sync, which can result in planes trying to use a
disabled dbuf slice. Suprisingly that only seems to corrupt the
display rather than making the whole display engine keel over.
Let's fix this for now by flagging state->modeset whenever
distrust_bios_wm is set.
Eventually we'll likely want to rip out all of this mess and
introduce proper statye tracking for dbuf. But that requires
more work. Toss in a FIXME to that effect.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200213140412.32697-4-stanislav.lisovskiy@intel.com
Jani Nikula [Thu, 13 Feb 2020 14:04:11 +0000 (16:04 +0200)]
drm/i915/dsc: force full modeset whenever DSC is enabled at probe
We lack full state readout of DSC config, which may lead to DSC enable
using a config that's all zeros, failing spectacularly. Force full
modeset and thus compute config at probe to get a sane state, until we
implement DSC state readout. Any fastset that did appear to work with
DSC at probe, worked by coincidence. [1] is an example of a change that
triggered the issue on TGL DSI DSC.
drm/i915: Ensure no conflicts with BIOS when updating Dbuf
TGL BIOS seems to enable both DBuf slices ocasionally, depending
how many displays are connected, while i915 according to BSpec
was powering on S1 DBuf slice, until a modeset was done.
This was causing a brief flash during the boot as we were
disabling slice, previously used by BIOS with that.
To prevent this, now we are ensuring tht we are enabling
_at least_ one slice, but if there are more, let's not
power them off.
drm/i915/mst: Set intel_dp_set_m_n() for MST slaves
Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for
DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
to intel_ddi_pre_enable_dp() but it missed add it to
intel_mst_pre_enable_dp() causing MST slaves to not work.
v2: Not setting intel_ddi_set_dp_msa() twice for MST master
Fixes: 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for DDI platforms") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211185008.30806-1-jose.souza@intel.com
Chris Wilson [Fri, 14 Feb 2020 12:06:59 +0000 (12:06 +0000)]
drm/i915/selftests: Check for the error interrupt before we wait!
Sometimes the error interrupt can fire even before we have seen the
request go active -- in which case, we end up waiting until the timeout
as the request is already completed. Double check for this case!
Jani Nikula [Tue, 11 Feb 2020 16:14:51 +0000 (18:14 +0200)]
drm/i915: split out display debugfs to a separate file
The i915_debugfs.c has grown more than a little unwieldy. Split out the
display related debugfs code to a file of its own under display/,
initialized with a separate call. No functional changes.
v2:
- Also moved i915_frontbuffer_tracking, i915_gem_framebuffer,
i915_power_domain_info, i915_dmc_info, i915_ipc_status (Ville)
Move vga switcheroo and dsm handler register later in
i915_driver_register(), and unregister in i915_driver_unregister(). The
dsm handler unregister is a nop, and is only added for completeness.
My unsubstantiated suspicion is that the vga switcheroo state change
would not work as early as we register the hooks currently. In any case
exposing the interfaces to the world only after we've got everything set
up seems prudent.
Also replace the error handling in vga switcheroo register with a simple
error message. This is done at the same time due to lack of error
propagation from i915_driver_register().
Jani Nikula [Tue, 11 Feb 2020 13:44:27 +0000 (15:44 +0200)]
drm/i915/hdmi: prefer to_i915() over drm->dev_private to get at i915
drm->dev_private is to be avoided. Use to_i915() on the struct
drm_device pointer instead. Rename the affected local dev_priv variables
to i915 while at it.
Chris Wilson [Thu, 13 Feb 2020 14:01:50 +0000 (14:01 +0000)]
drm/i915/selftests: Exercise timeslice rewinding
Originally, I did not expect having to rewind a context upon
timeslicing: the point was to replace the executing context with a
non-executing one! However, given a second context that depends on
requests from the first, we may have to split the requests along the
first context to execute the second, causing us to partially replay the
first context and so have to rewind its RING_TAIL.
Chris Wilson [Tue, 11 Feb 2020 20:56:14 +0000 (20:56 +0000)]
drm/i915: Poison rings after use
On retiring the request, we should not re-use these elements in the ring
(at least not until we fill the ringbuffer and knowingly reuse the space).
Leave behind some poison to (hopefully) trap ourselves if we make a
mistake.
Chris Wilson [Tue, 11 Feb 2020 14:48:31 +0000 (14:48 +0000)]
drm/i915/gem: Don't leak non-persistent requests on changing engines
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no longer being
tracked by the user's context (in order to prevent a lost request
causing an untracked and so unstoppable GPU hang), we need to apply the
same context cancellation upon changing engines.
v2: Track stale engines[] so we only reap at context closure.
v3: Tvrtko spotted races with closing contexts and set-engines, so add a
veneer of kill-everything paranoia to clean up after losing a race.
Ville Syrjälä [Tue, 4 Feb 2020 15:48:03 +0000 (17:48 +0200)]
drm/i915: Fix the docs for intel_set_cdclk_post_plane_update()
s/before/after/ again after accidentally changing it the
other way in commit 5604e9ceaed5 ("drm/i915: Simplify
intel_set_cdclk_{pre,post}_plane_update() calling convention")
Chris Wilson [Mon, 10 Feb 2020 20:57:20 +0000 (20:57 +0000)]
drm/i915: Disable use of hwsp_cacheline for kernel_context
Currently on execlists, we use a local hwsp for the kernel_context,
rather than the engine's HWSP, as this is the default for execlists.
However, seqno wrap requires allocating a new HWSP cacheline, and may
require pinning a new HWSP page in the GGTT. This operation requiring
pinning in the GGTT is not allowed within the kernel_context timeline,
as doing so may require re-entering the kernel_context in order to evict
from the GGTT. As we want to avoid requiring a new HWSP for the
kernel_context, we can use the permanently pinned engine's HWSP instead.
However to do so we must prevent the use of semaphores reading the
kernel_context's HWSP, as the use of semaphores do not support rollover
onto the same cacheline. Fortunately, the kernel_context is mostly
isolated, so unlikely to give benefit to semaphores.
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200210205722.794180-5-chris@chris-wilson.co.uk
Chris Wilson [Mon, 10 Feb 2020 20:57:18 +0000 (20:57 +0000)]
drm/i915/selftests: Relax timeout for error-interrupt reset processing
We can not require that the system process a tasklet in reasonable time
(thanks be to ksoftirqd), but we can insist that having waited
sufficiently for the error interrupt to have been raised and having
kicked the tasklet, the reset has begun and the request will be marked
as in error (if not already completed).
Wambui Karuga [Thu, 6 Feb 2020 08:00:13 +0000 (11:00 +0300)]
drm/i915/dpio_phy: convert to drm_device based logging macros.
Conversion of the printk based logging macros to the struct drm_device
based logging macros in i915/display/intel_dpio_phy.c.
This was achieved using the following coccinelle semantic patch that
matches based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
Wambui Karuga [Thu, 6 Feb 2020 08:00:11 +0000 (11:00 +0300)]
drm/i915/dsi_vbt: convert to drm_device based logging macros.
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_dsi_vbt.c.
This also involves extracting the drm_i915_private device from the
intel_dsi type for use in the logging macros.
This converts DRM_DEBUG/DRM_DEBUG_DRIVER to drm_dbg().
Wambui Karuga [Thu, 6 Feb 2020 08:00:09 +0000 (11:00 +0300)]
drm/i915/combo_phy: convert to struct drm_device logging macros.
Conversion of the printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_combo_phy.c.
This transformation was achieved using the following coccinelle script
that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
Wambui Karuga [Thu, 6 Feb 2020 08:00:08 +0000 (11:00 +0300)]
drm/i915/dpll_mgr: convert to drm_device based logging macros.
Conversion of instances of printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_dpll_mgr.c.
This also involves extracting the struct drm_i915_private device pointer
from various intel types to use in the drm_device based macros.
Note that this converts DRM_DEBUG_DRIVER to drm_dbg().
Wambui Karuga [Thu, 6 Feb 2020 08:00:06 +0000 (11:00 +0300)]
drm/i915/crt: automatic conversion to drm_device based logging macros.
Replaces various instances of the printk based logging macros with the
struct drm_device based logging macros in i915/display/intel_crt.c using
the following coccinelle script that matches based on the existence of a
drm_i915_private device pointer:
@@
identifier fn, T;
@@
Wambui Karuga [Thu, 6 Feb 2020 08:00:04 +0000 (11:00 +0300)]
drm/i915/atomic: conversion to drm_device based logging macros.
Conversion of the printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_atomic.c
This change was achieved using the following coccinelle script that
matches based on the existence of a drm_i915_private device pointer:
@@
identifier fn, T;
@@
Wambui Karuga [Thu, 6 Feb 2020 08:00:03 +0000 (11:00 +0300)]
drm/i915/dp_link_training: convert to drm_device based logging macros.
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in
i915/display/intel_dp_link_training.c.
This also involves extracting the drm_i915_private device pointer from
the intel_dp type to use in the various macros.
Chris Wilson [Tue, 11 Feb 2020 12:01:31 +0000 (12:01 +0000)]
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex
We manipulate ring->head while active in i915_request_retire underneath
the timeline manipulation. We cannot rely on a stable ring->head outside
of the timeline->mutex, in particular while setting up the context for
resume and reset.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1126 Fixes: 0881954965e3 ("drm/i915: Introduce intel_context.pin_mutex for pin management") Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex")
References: f3c0efc9fe7a ("drm/i915/execlists: Leave resetting ring to intel_ring") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211120131.958949-1-chris@chris-wilson.co.uk
Anshuman Gupta [Fri, 7 Feb 2020 14:41:16 +0000 (20:11 +0530)]
drm/i915: HDCP support on above PORT_E
As Gen12 onwards there are HDCP instances for each transcoder
instead of port, remove the (port < PORT_E) hdcp support
limitation for platform >= Gen12.
v2:
- Nuke the comment and cosmetic changes. [Jani]
Chris Wilson [Thu, 30 Nov 2017 18:07:02 +0000 (18:07 +0000)]
drm/i915: Skip CPU synchronisation on dmabuf attachments
dma-bufs are device coherent, with explicit CPU synchronisation provided
via the begin/end cpu access ioctls. As the coherency of the dma-buf is
explicitly defined to be under user control, flushing any caches on
attach/detach of the dma-buf is additional work that doesn't aide the
user in the slightest.
Matt Roper [Fri, 7 Feb 2020 00:14:16 +0000 (16:14 -0800)]
drm/i915/ehl: Update port clock voltage level requirements
Voltage level depends not only on the cdclk, but also on the DDI clock.
Last time the bspec voltage level table for EHL was updated, we only
updated the cdclk requirements, but forgot to account for the new port
clock criteria.
Add a basic description about how DC3CO works to help people not
familiar with it.
While at it, I also improved the delayed work handle and function
names and removed a debug message that is ambiguous and not much
useful, no changes in behavior here.
Chris Wilson [Sun, 9 Feb 2020 23:08:36 +0000 (23:08 +0000)]
drm/i915/selftests: Drop live_preempt_hang
live_preempt_hang's use of hang injection has been superseded by
live_preempt_reset's use of an non-preemptible spinner. The latter does
not require intrusive hacks into the code.
projects / kernel.git / log