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: 91c6fbd51328 ("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 5e6659998c75 ("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: 5e6659998c75 ("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 cf9bdea4285b ("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: ce5dbe1e951d ("drm/i915: Introduce intel_context.pin_mutex for pin management") Fixes: eaac073f8c2e ("drm/i915: Protect request retirement with timeline->mutex")
References: bded6da1dde9 ("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.
Jani Nikula [Wed, 5 Feb 2020 08:29:59 +0000 (10:29 +0200)]
drm/i915/mst: fix pipe and vblank enable
Commit 83a124d73500 ("drm/i915: move pipe, pch and vblank enable to
encoders on DDI platforms") pushed pipe and vblank enable to encoders on
DDI platforms, however it missed the DP MST encoder. Fix it.
Fixes: 83a124d73500 ("drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Tested-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205082959.31317-1-jani.nikula@intel.com
Chris Wilson [Sun, 9 Feb 2020 13:19:16 +0000 (13:19 +0000)]
drm/i915/execlists: Ignore tracek for nop process_csb
Recording the frequent inspection of CSB head/tail when there is
expected to be no update adds noise to the debug trace. (Not entirely
useless, but since we know the sequence of function calls, we can
surmise the function was called -- so redundant.)
Chris Wilson [Sun, 9 Feb 2020 13:19:15 +0000 (13:19 +0000)]
drm/i915/gt: Fix hold/unhold recursion
In eliminating the recursion from walking the tree of signalers/waiters
for processing the hold/unhold operations, a crucial error crept in
where we looked at the parent request and not the list element when
processing the list.
Brown paper bag, much?
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1166 Fixes: 7de814b5692e ("drm/i915/gt: Allow temporary suspension of inflight requests") Fixes: 63ca7b340551 ("drm/i915/execlists: Offline error capture") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@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/20200209131922.180287-1-chris@chris-wilson.co.uk
Mika Kuoppala [Mon, 3 Feb 2020 16:33:12 +0000 (18:33 +0200)]
drm/i915: Remove lite restore defines
We have switched from tail manipulation to forced context restore
to implement WaIdleLiteRestore. Remove the old defines and comments.
Note: we still do emit the WA tail, and use it as our first attempt to
avoid forcing a full-restore instead of a lite-restore, we just have a
much stronger backup mechanism for repeated preemptions.
References: a3174b4c9601 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20200203163312.15475-1-mika.kuoppala@linux.intel.com
drm/i915: Never allow userptr into the new mapping types
Commit 59eb8eef948b ("drm/i915/userptr: Never allow userptr into the
mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when attempted
on a userptr object in order to protect from a lockdep splat. Later
on, new mapping types were introduced by commit 1798fee1aa68
("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET"). Those new mapping
types suffer from the same lockdep splat issue but they now succeed
when tried on top of a userptr object. Fix it.
v2: Don't play with the -ENODEV driver response (Chris)
Chris Wilson [Fri, 7 Feb 2020 21:14:52 +0000 (21:14 +0000)]
drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
If we rewind the RING_TAIL on a context, due to a preemption event, we
must force the context restore for the RING_TAIL update to be properly
handled. Rather than note which preemption events may cause us to rewind
the tail, compare the new request's tail with the previously submitted
RING_TAIL, as it turns out that timeslicing was causing unexpected
rewinds.
<idle>-0 0d.s2 1280851190us : __execlists_submission_tasklet: 0000:00:02.0 rcs0: expired last=130:4698, prio=3, hint=3
<idle>-0 0d.s2 1280851192us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 66:119966, current 119964
<idle>-0 0d.s2 1280851195us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4698, current 4695
<idle>-0 0d.s2 1280851198us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
^---- Note we unwind 2 requests from the same context
<idle>-0 0d.s2 1280851208us : __i915_request_submit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
<idle>-0 0d.s2 1280851213us : __i915_request_submit: 0000:00:02.0 rcs0: fence 134:1508, current 1506
^---- But to apply the new timeslice, we have to replay the first request
before the new client can start -- the unexpected RING_TAIL rewind
Fixes: b0ea7ccafad8 ("drm/i915/execlists: Minimalistic timeslicing")
Referenecs: d6f83f7ad830 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Link: https://patchwork.freedesktop.org/patch/msgid/20200207211452.2860634-1-chris@chris-wilson.co.uk
Mika Kuoppala [Fri, 7 Feb 2020 15:51:38 +0000 (17:51 +0200)]
drm/i915: Implement Wa_1607090982
SIMD16 with Src0 scalar might conflict between Src1/Src2 and cause
GRF read issue. Workaround this issue by setting bit 14 in 0xe4f4
which will disable early read/src swap of Src0.
Chris Wilson [Fri, 7 Feb 2020 12:58:27 +0000 (12:58 +0000)]
drm/i915/gt: Use the kernel_context to measure the breadcrumb size
We set up a dummy ring in order to measure the size we require for our
breadcrumb emission, so that we don't have to manually count dwords! We
can pass in the kernel_context to use for this so that if required it is
known for the breadcrumb emitter, and we can reuse some details from the
kernel_context to reduce the number of temporaries we have to mock.
We are sanitizing firmware status and old mmio message, but
we forget to sanitize CT status.
Fixes: e0068b0f5445 ("drm/i915/guc: Introduce guc_is_ready") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200207131938.2787828-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So, turns out that this ended up just breaking things. While many
laptops incorrectly advertise themselves as supporting PWM backlight
controls, they actually will only work with DPCD backlight controls.
Unfortunately, it also seems there are a number of systems which
advertise DPCD backlight controls in their eDP DPCD but don't actually
support them. Talking with some laptop manufacturers has shown it might
be possible to probe this support via the EDID (!?!?) but I haven't been
able to confirm that this would work on any other manufacturer's
systems.
So in the mean time, we'll just revert this commit for now and go back
to the old way of doing things.
which is us consuming a partially initialised new waiter in
defer_requests(). We can prevent this by initialising the i915_dependency
prior to making it visible, and since we are using a concurrent
list_add/iterator mark them up to the compiler.
Chris Wilson [Thu, 6 Feb 2020 20:49:12 +0000 (20:49 +0000)]
drm/i915/gt: Prevent queuing retire workers on the virtual engine
Virtual engines are fleeting. They carry a reference count and may be freed
when their last request is retired. This makes them unsuitable for the
task of housing engine->retire.work so assert that it is not used.
Tvrtko tracked down an instance where we did indeed violate this rule.
In virtual_submit_request, we flush a completed request directly with
__i915_request_submit and this causes us to queue that request on the
veng's breadcrumb list and signal it. Leading us down a path where we
should not attach the retire.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 27418a6c19a0 ("drm/i915/gt: Schedule request retirement when signaler idles") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206204915.2636606-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 7 Feb 2020 02:29:35 +0000 (12:29 +1000)]
Merge tag 'amd-drm-next-5.6-2020-02-05' of git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-next-5.6-2020-02-05:
amdgpu:
- EDC fixes for Arcturus
- GDDR6 memory training fixe
- Fix for reading gfx clockgating registers while in GFXOFF state
- i2c freq fixes
- Misc display fixes
- TLB invalidation fix when using semaphores
- VCN 2.5 instancing fixes
- Switch raven1 gfxoff to a blacklist
- Coreboot workaround for KV/KB
- Root cause dongle fixes for display and revert workaround
- Enable GPU reset for renoir and navi
- Navi overclocking fixes
- Fix up confusing warnings in display clock validation on raven
Matthew Auld [Thu, 6 Feb 2020 17:03:40 +0000 (17:03 +0000)]
drm/i915/selftests: drop igt_ppgtt_exhaust_huge
We already have tests that exhaustively exercise the most interesting
page-size combinations, along with tests that offer randomisation, and
so we should already be testing objects(local, system) with a varying
mix of page-sizes, which leaves igt_ppgtt_exhaust_huge providing not
much in terms of extra coverage.
drm/i915/display: Set TRANS_DDI_MODE_SELECT to default value when clearing DDI select
TGL is suffering of timeouts and fifo underruns when disabling
transcoder in MST mode, this is fixed by set TRANS_DDI_MODE_SELECT to
0(HDMI mode) when clearing DDI select.
Although BSpec disable sequence don't require this step, it is a
harmless change and it is also done by Windows driver.
Anyhow HW team was notified about that but it can take some time to
documentation to be updated.
A case that always lead to those issues is:
- do a modeset enabling pipe A and pipe B in the same MST stream
leaving A as master
- disable pipe A, promote B as master doing a full modeset in A
- enable pipe A, changing the master transcoder back to A(doing a
full modeset in B)
- Pow: underruns and timeouts
The transcoders involved will only work again when complete disabled
and their power wells turned off causing a reset in their registers.
v2: Setting TRANS_DDI_MODE_SELECT to default when clearing DDI select
not anymore when disabling TRANS_DDI, both work but this one looks
more safe. (Ville comment)
Chris Wilson [Thu, 6 Feb 2020 01:44:38 +0000 (01:44 +0000)]
drm/i915/gt: Set the PP_DIR registers upon enabling ring submission
Always prime the page table registers before starting the ring. Even
though we will update these to the per-context page tables during
dispatch, it is prudent to ensure that the registers always point to a
valid PD.
Thierry Reding [Tue, 4 Feb 2020 13:59:25 +0000 (14:59 +0100)]
drm/tegra: Reuse IOVA mapping where possible
This partially reverts the DMA API support that was recently merged
because it was causing performance regressions on older Tegra devices.
Unfortunately, the cache maintenance performed by dma_map_sg() and
dma_unmap_sg() causes performance to drop by a factor of 10.
The right solution for this would be to cache mappings for buffers per
consumer device, but that's a bit involved. Instead, we simply revert to
the old behaviour of sharing IOVA mappings when we know that devices can
do so (i.e. they share the same IOMMU domain).
Thierry Reding [Tue, 4 Feb 2020 13:59:24 +0000 (14:59 +0100)]
drm/tegra: Relax IOMMU usage criteria on old Tegra
Older Tegra devices only allow addressing 32 bits of memory, so whether
or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU
attachment is only needed on devices that can address memory beyond the
32-bit boundary and where the host1x doesn't support the wide GATHER
opcode that allows it to access buffers at higher addresses.
Chris Wilson [Wed, 5 Feb 2020 09:54:40 +0000 (09:54 +0000)]
drm/i915: Flush execution tasklets before checking request status
Rather than flushing the submission tasklets just before we sleep, flush
before we check the request status. Ideally this gives us a moment to
process the tasklets after sleeping just before we timeout.
v2: Compromise by pushing the flush prior to the timeout, but after the
check on completion so that we do not further delay the ready client.
Chris Wilson [Wed, 5 Feb 2020 12:37:57 +0000 (12:37 +0000)]
drm/i915: Mark i915.reset as unsigned
We have been using '-1' to mean the maximum i915.reset level in the
belief that it was unsigned... This turns out to have been a grave
error, and instead of setting the default reset mechanism in igt,
we have been disabling reset!
Added proper DBuf slice mapping to correspondent
pipes, depending on pipe configuration as stated
in BSpec.
v2:
- Remove unneeded braces
- Stop using macro for DBuf assignments as
it seems to reduce readability.
v3: Start using enabled slices mask in dev_priv
v4: Renamed "enabled_slices" used in dev_priv
to "enabled_dbuf_slices_mask"(Matt Roper)
v5: - Removed redundant parameters from
intel_get_ddb_size function.(Matt Roper)
- Made i915_possible_dbuf_slices static(Matt Roper)
- Renamed total_width into total_width_in_range
so that it now reflects that this is not
a total pipe width but the one in current
dbuf slice allowed range for pipe.(Matt Roper)
- Removed 4th pipe for ICL in DBuf assignment
table(Matt Roper)
- Fixed wrong DBuf slice in DBuf table for TGL
(Matt Roper)
- Added comment regarding why we currently not
using pipe ratio for DBuf assignment for ICL
v6: - Changed u32 to unsigned int in
icl_get_first_dbuf_slice_offset function signature
(Ville Syrjälä)
- Changed also u32 to u8 in dbuf slice mask structure
(Ville Syrjälä)
- Switched from DBUF_S1_BIT to enum + explicit
BIT(DBUF_S1) access(Ville Syrjälä)
- Switched to named initializers in DBuf assignment
arrays(Ville Syrjälä)
- DBuf assignment arrays now use autogeneration tool
from
https://patchwork.freedesktop.org/series/70493/
to avoid typos.
- Renamed i915_find_pipe_conf to *_compute_dbuf_slices
(Ville Syrjälä)
- Changed platforms ordering in skl_compute_dbuf_slices
to be from newest to oldest(Ville Syrjälä)
v7: - Now ORing assigned DBuf slice config always with DBUF_S1
because slice 1 has to be constantly powered on.
(Ville Syrjälä)
v8: - Added pipe_name for neater printing(Ville Syrjälä)
- Renamed width_before_pipe to width_before_pipe_in_range,
to better reflect that now all the calculations are happening
inside DBuf range allowed by current pipe configuration mask
(Ville Syrjälä)
- Shortened FIXME comment message, regarding constant ORing with
DBUF_S1(Ville Syrjälä)
- Added .dbuf_mask named initializer to pipe assignment array
(Ville Syrjälä)
- Edited pipe assignment array to use only single DBuf slice
for gen11 single pipe configurations, until "pipe ratio"
thing is finally sorted out(Ville Syrjälä)
- Removed unused parameter crtc_state for now(Ville Syrjälä)
from icl/tgl_compute_dbuf_slices function
Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).
Removed wrong code from intel_get_ddb_size as
it doesn't match to BSpec. For now still just
use DBuf slice until proper algorithm is implemented.
Other minor code refactoring to get prepared
for major DBuf assignment changes landed:
- As now enabled slices contain a mask
we still need some value which should
reflect how much DBuf slices are supported
by the platform, now device info contains
num_supported_dbuf_slices.
- Removed unneeded assertion as we are now
manipulating slices in a more proper way.
v2: Start using enabled_slices in dev_priv
v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
as this now sits in dev_priv independently.
v4: - Fixed debug print formatting to hex(Matt Roper)
- Optimized dbuf slice updates to be used only
if slice union is different from current conf(Matt Roper)
- Fixed some functions to be static(Matt Roper)
- Created a parameterized version for DBUF_CTL to
simplify DBuf programming cycle(Matt Roper)
- Removed unrequred field from GEN10_FEATURES(Matt Roper)
v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
- Started to use parameterized loop for hw readout to get slices
(Ville Syrjälä)
- Added back assertion checking amount of DBUF slices enabled
after DC states 5/6 transition, also added new assertion
as starting from ICL DMC seems to restore the last DBuf
power state set, rather than power up all dbuf slices
as assertion was previously expecting(Ville Syrjälä)
v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
- Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
back, as we really need to have a single unified assert here
however currently enabling always slice 1 is enforced by BSpec,
so we will have to OR enabled slices mask with 1 in order
to be consistent with BSpec, that way we can unify that
assertion and against the actual state from the driver, but
not some hardcoded value.(concluded with Ville)
- Remove parameterized DBUF_CTL version, to extract it to another
patch.(Ville Syrjälä)
v7:
- Removed unneeded hardcoded return value for older gens from
intel_enabled_dbuf_slices_mask - this now is handled in a
unified manner since device info anyway returns max dbuf slices
as 1 for older platforms(Matthew Roper)
- Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead
of intel_dbuf_max_slices function as it is trivial(Matthew Roper)
v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä)
v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä)
- Now using power_domain mutex to protect from race condition, which
can occur because intel_dbuf_slices_update might be running in
parallel to gen9_dc_off_power_well_enable being called from
intel_dp_detect for instance, which causes assertion triggered by
race condition, as gen9_assert_dbuf_enabled might preempt this
when registers were already updated, while dev_priv was not.
Now start using parameterized DBUF_CTL instead
of hardcoded, this would allow shorter access
functions when reading or storing entire state.
Tried to implement it in a MMIO_PIPE manner, however
DBUF_CTL1 address is higher than DBUF_CTL2, which
implies that we have to now subtract from base
rather than add.
v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR
macros. Started to use _PICK construct as suggested
by Matt Roper.
v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice"
in macro(Ville Syrjälä)
- Introduced enum for enumerating DBUF slices(Ville Syrjälä)
drm/i915: Update dbuf slices only with full modeset
During full modeset, global state(i.e dev_priv) is protected
by locking the crtcs in state, otherwise global state is not
serialized. Also if it is not a full modeset, we anyway
don't need to change DBuf slice configuration as Pipe configuration
doesn't change.
Current DBuf slices update wasn't done in proper
place, especially its "post" part, which should
disable those only once vblank had passed and
all other changes are committed.
v2: Fix to use dev_priv and intel_atomic_state
instead of skl_ddb_values
(to be nuked in Villes patch)
v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num"
(Matt Roper)
v4: - Rebase against drm-tip.
- Move post_update closer to optimize_watermarks,
to prevent unneeded noise from underrun reporting
(Ville Syrjälä)
Current consensus that it is redundant as
we already have skl_ddb_values struct out there,
also this struct contains only single member
which makes it unnecessary.
v2: As dirty_pipes soon going to be nuked away
from skl_ddb_values, evacuating enabled_slices
to safer in dev_priv.
v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num"
(Matt Roper)
v4: - Wrapped the line getting number of dbuf slices(Matt Roper)
- Removed indeed redundant skl_ddb_values declaration(Matt Roper)
Chris Wilson [Tue, 4 Feb 2020 09:48:02 +0000 (09:48 +0000)]
drm/i915/display: Be explicit in handling the preallocated vma
As only the display codes tries to pin its preallocated framebuffer into
an exact location in the GGTT, remove the convenience function and make
the pin management explicit in the display code. Then throughout the
display management, we track the framebuffer and its plane->vma; with
less single purpose code and ready for first class i915_vma.
In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka.
I am about to stuff more objects into the plane_config and would like to
have it clean up after itself. Move the current framebuffer release into
a common function so it can be extended with the new object with
relative ease.
Jani Nikula [Tue, 28 Jan 2020 16:38:03 +0000 (18:38 +0200)]
drm/i915/hdcp: move update pipe code to hdcp
The DDI encoder code shouln't have to know about the guts of
HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in
intel_hdcp.c. No functional changes.
Lyude Paul [Fri, 24 Jan 2020 19:10:46 +0000 (14:10 -0500)]
drm/amd/dm/mst: Ignore payload update failures
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the topology and as such, it's a good
idea to ignore payload update failures when disabling displays.
Currently, amdgpu makes the mistake of halting the payload update
process when any payload update failures occur, resulting in leaving
DC's local copies of the payload tables out of date.
This ends up causing problems with hotplugging MST topologies, and
causes modesets on the second hotplug to fail like so:
Note as well, I have only been able to reproduce this on setups with 2
MST displays.
Changes since v1:
* Don't return false when part 1 or part 2 of updating the payloads
fails, we don't want to abort at any step of the process even if
things fail
Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 4 Feb 2020 14:07:19 +0000 (09:07 -0500)]
drm/amdgpu: update default voltage for boot od table for navi1x
It needed to be updated as well so it will show the proper values
if you reset to the defaults.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Chris Wilson [Mon, 3 Feb 2020 20:21:10 +0000 (20:21 +0000)]
drm/i915/gt: Fix rc6 on Ivybridge
The current rc6 threshold is larger than the evaluation interval on
Ivybridge; it never enters rc6. Remove the special casing so it behaves
like the other gen6/gen7, and we see rc6 residencies before we manually
park the system.
Ville Syrjälä [Tue, 21 Jan 2020 17:10:52 +0000 (19:10 +0200)]
drm/i915/crt: Configure connector->polled and encoder->hpd_pin consistently
Let's make sure encoder->hpd_pin and connector->polled are mirror
images of each other (when we want to use polling). The other
potentially polled connectors (sdvo and tv) already get this right.
Also nuke the redundant force_hotplug_required initialization
(the thing is kzalloc()ed).
Ville Syrjälä [Tue, 21 Jan 2020 17:10:51 +0000 (19:10 +0200)]
drm/i915: Introduce intel_connector_hpd_pin()
Simplify the hotplug code connector->encoder->hpd_pin handling
by introducing a helper for exactly this purpose.
In the helper we can neatly deal with the potential lack of an
attached encoder on fresh MST connectors leaving the rest of the
hpd code oblivious to such details.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Only send non-0 clocks to DC for validation. This mirrors
what the windows driver does.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
projects / kernel.git / log