Matt Roper [Tue, 12 Jan 2016 15:13:37 +0000 (07:13 -0800)]
drm/i915: Handle error paths during watermark sanitization properly (v3)
sanitize_watermarks() does not properly handle errors returned by
drm_atomic_helper_duplicate_state(). Make failures drop locks before
returning. We also change the lock of connection_mutex to a
drm_modeset_lock_all_ctx() to make sure any EDEADLK's are handled
earlier.
v2: Change call to lock connetion_mutex with a call to
drm_modeset_lock_all_ctx(). This ensures that any lock contention
is handled earlier and drm_atomic_helper_duplicate_state() won't
return EDEADLK. (Maarten)
v3: Drop locks properly in more error paths. (Maarten)
Ville Syrjälä [Tue, 12 Jan 2016 15:28:16 +0000 (17:28 +0200)]
drm/i915: Only complain about n_edp_entries with eDP ports
commit 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL")
added sanity checks to make sure we don't end up with too many ddi translation
values for eDP ports, but it actually failed to check if the port is eDP.
We still look up the edp translations for non-eDP ports, but don't use
them, so we shouldn't be complaining about them either.
Ville Syrjälä [Mon, 14 Dec 2015 16:23:49 +0000 (18:23 +0200)]
drm/i915: Use MI_BATCH_BUFFER_START on 830/845
MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
correct batch length.
Let's switch to using MI_BATCH_BUFFER_START instead (like we do on
other platforms). Then we don't have to specify the batch length
at all, and the CS will instead execute until it sees the
MI_BATCH_BUFFER_END.
We still need the batch length since we do the CS TLB workaround
and copy the batch into the permanently pinned scratch object
and execute it from there. But for this we can simply use the
batch object length when the user hasn't specified the actual
batch length. So specifying the batch length becomes just a
way to optimize the batch copy a little bit.
We lost batch_len from a bunch of igts (including the quiesce batch)
so without this igt is utterly broken on 830/845. Also some igts such
as gem_cpu_reloc never specified the batch_len and so didn't work.
With MI_BATCH_BUFFER_START we don't have to fix up igt every time
someone forgets that 830/845 exist.
Ville Syrjälä [Mon, 14 Dec 2015 16:23:46 +0000 (18:23 +0200)]
drm/i915: Allow 27 bytes child_dev for VBT <109
My 85x has VBT version 108 which has a child dev size of 27 bytes.
Let's allow that without printing an error.
We still want to reject the actual parsin since for that we need
the child device size to be at least 33 bytes. So we should still
check for that, but let's make it print a debug message only instead
of an error.
While at it, toss in a BUILD_BUG_ON() to verify our struct
old_child_dev_config is in fact 33 bytes.
Ville Syrjälä [Mon, 14 Dec 2015 16:23:43 +0000 (18:23 +0200)]
drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2
We use the vblank timestamps to generate the vblank frame counter value
on gen2. That means we need the pipe scanout position to be accurate
when we call drm_crtc_vblank_on(), otherwise the frame counter
guesstimate may jump when the pipe actually start.
What I observed on my 85x is that the DSL initially reads 0, and when
the pipe actually starts DSL jumps to vblank_start. On gen2 DSL==0 means
actually vtotal-1 (see update_scanline_offset()), so if we initially
get vtotal-1, and then very quickly vblank_start (or thereabouts), the
scanout position will appear to jump backwards by approximately one
vblank length. Which means the frame counter guesstimate will also
jump backwards. That's no good, so let's make sure the pipe has
started before we call drm_crtc_vblank_on().
Ville Syrjälä [Tue, 8 Dec 2015 17:59:44 +0000 (19:59 +0200)]
drm/i915: Kill intel_prepare_ddi()
Move the ddi buffer translation programming to occur from the encoder
.pre_enable() hook, for just the ddi port we are enabling. Previously
we used to reprogram the translations for all ddi ports during
init and during power well enabling.
v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel)
Resolve conflicts due to dev_priv->atomic_cdclk_freq
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
skl_get_buf_trans_edp() effectively contains another copy of
skl_get_buf_trans_dp(). Remove the duplication and just call
skl_get_buf_trans_dp() from skl_get_buf_trans_edp().
v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
Ville Syrjälä [Tue, 8 Dec 2015 17:59:39 +0000 (19:59 +0200)]
drm/i915: Remove pointless 'ddi_translations' local variable
skl_get_buf_trans_*() don't need the 'ddi_translations' local variable
since all they with is assign and return. Just return the right thing
directly and get rid of the local variable.
v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
Ville Syrjälä [Tue, 8 Dec 2015 17:59:36 +0000 (19:59 +0200)]
drm/i915: Pass the correct encoder to intel_ddi_clk_select() with MST
We're supposed to pass the primary DP encoder to intel_ddi_clk_select(),
not the fake MST encoder. Do so.
There's no real bug here though, since intel_ddi_clk_select() only
checks if the encoder type is EDP (which it isn't for either the
primary DP encoder or the fake MST encoder), and it gets the DDI port
via intel_ddi_get_encoder_port() (which knows how to do the
fake->primary->port dance itself).
Jani Nikula [Mon, 11 Jan 2016 13:15:02 +0000 (15:15 +0200)]
drm/i915/bios: add support for MIPI sequence block v3
The changes since the sequence block v2 are:
* The whole MIPI bios data block has a separate 32-bit size field since
v3, stored after the version. This facilitates big sequences.
* The size of the panel specific sequence blocks has grown to 32
bits. This facilitates big sequences.
* The elements within sequences now have an 8-bit size field following
the operation byte. This facilitates skipping unknown new operation
bytes, i.e. forward compatibility.
v2 (of the patch): use DRM_ERROR for unknown operation byte
v3 (of the patch): even more bounds checking (Ville)
Mika Kuoppala [Fri, 8 Jan 2016 13:51:20 +0000 (15:51 +0200)]
drm/i915: Arm the unclaimed mmio debugs on suspend path
If we go into suspend with unclaimed access detected,
it would be nice to catch that access on a next suspend path.
So instead of just notifying about it, arm the unclaimed
mmio checks on suspend side.
We want to keep the asymmetry on resume, as if it was
on resume path, it was not driver that is responsible so
no point in arming mmio debugs.
Mika Kuoppala [Fri, 8 Jan 2016 13:51:19 +0000 (15:51 +0200)]
drm/i915: Enable mmio_debug for vlv/chv
With commit 8ac3e1bb76cc ("drm/i915: Add non claimed mmio checking
for vlv/chv") we now have chv/vlv support in place for detecting
unclaimed access. Also the perf hit of extra mmio read
is now only suffered if mmio_debug is set.
This allows us to stuff the macro for unclaimed reg
detection inside a generic gen6 register access, as now all
gens using these macros uses also unclaimed debugs, the one
exception being snb. We gain more clean and generic macros
and only downside is that snb will suffer one branch perf hit
without upside.
Note that the hsw write path debug register check now
happens before fifo check, but this should not make
any real difference.
As vlv/chv use the generic gen6 access macros, the consequence
is that they gain the mmio_debug feature.
drm/i915: Widen return value for reservation_object_wait_timeout_rcu to long.
This fixes a spurious warning from an integer overflow on 64-bits systems.
The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1.
Explicitly handling this by casting to lret fixes it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-tested-by: Joseph Yasi <joe.yasi@gmail.com> Tested-by: Andreas Reis <andreas.reis@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 3c28ff22f6e20c ("i915: wait for fence in prepare_plane_fb") Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
Boyer, Wayne [Thu, 7 Jan 2016 01:15:29 +0000 (17:15 -0800)]
drm/i915: Don't warn if the workaround list is empty part 2.
Extend the same reasoning as in the patch listed below. It's not an
error for the workaround list to be empty if no workarounds are needed.
commit 02235808b61cd9382d224b0df263193006dd9913
Author: Francisco Jerez <currojerez@riseup.net>
Date: Wed Oct 7 14:44:01 2015 +0300
drm/i915: Don't warn if the workaround list is empty.
Rodrigo Vivi [Fri, 8 Jan 2016 00:49:39 +0000 (16:49 -0800)]
drm/i915/kbl: Adding missing IS_KABYLAKE checks.
When adding IS_KABYLAKE definition I didn't included the
DC states related because I was planing to include them
with the patch that fixes DMC firmware loading, but I
forgot them.
Meanwhile this runtime pm code changed a lot for
Skylake.
Well, I didn't expect that this would crash the machine
and I just noticed now that Sarah warned me our driver
wasn't working. Thanks Sarah.
Michel had found the main error first and his
fix had better details on the history and got
merged already:
citing the reason as pixel clock based calculation being recommended in
the MIPI host controller documentation. Remove the dead code, we can
always bring it back if it's needed.
Mika Kuoppala [Tue, 15 Dec 2015 17:45:42 +0000 (19:45 +0200)]
drm/i915: Add non claimed mmio checking for vlv/chv
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. Ville added that
both chv and vlv has this capability and he had already
made this way back [1]. Mimic what Ville's patch does
but adapt on top of less frequent mmio accesses by
omitting checking always on reg writes.
Mika Kuoppala [Wed, 16 Dec 2015 07:26:48 +0000 (09:26 +0200)]
drm/i915: Do one shot unclaimed mmio detection less frequently
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detecting correct spot at the first occurrence
by doing the one shot detection and arming of mmio_debug in hangcheck
and in modeset. This removes the write path performance burden.
v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris)
Mika Kuoppala [Tue, 15 Dec 2015 14:25:08 +0000 (16:25 +0200)]
drm/i915: Detect and clear unclaimed access on resume
If something, the usual suspect being bios, access hw
behind our back, don't let it slide into situation where
normal register access will detect this and spit out
a warn on into dmesg. On some bdw bioses this happens
during igt/bat run always and as there is not much we can
do about it, its better just to detect and flush this
explicitly on resume and only print a debug message.
v2: use DRM_DEBUG_DRIVER (Chris)
v3: s/access/mmio, s/prior/prior to, s/dev/dev_priv
Mika Kuoppala [Tue, 15 Dec 2015 14:25:07 +0000 (16:25 +0200)]
drm/i915: Introduce intel_uncore_unclaimed_mmio
Currently interrupt code is the only place checking
for the unclaimed register access prior to actual register
macros using the same functionality. Rename the function
and make it return bool so that the possible error message
context is clear in the caller side. The motivation is to allow
usage of unclaimed detection on arbitrary places.
Mika Kuoppala [Tue, 15 Dec 2015 17:24:47 +0000 (19:24 +0200)]
drm/i915: Consolidate unclaimed mmio detection
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio > 0.
Note that we post after clearing the bit. This makes sure
that the next unclaimed write access would get detected
also if it happened right after clearing, and not fold
into the previous detection.
v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris)
debug log on unclaimed detection on uncore init (Joonas)
Mika Kuoppala [Tue, 1 Dec 2015 15:56:12 +0000 (17:56 +0200)]
drm/i915: Inspect subunit states on hangcheck
If head seems stuck and engine in question is rcs,
inspect subunit state transitions from undone to done,
before deciding that this really is a hang instead of limited
progress. Only account the transitions of subunits from
undone to done once, to prevent unstable subunit states
to keep us falsely active.
As this adds one extra steps to hangcheck heuristics,
before hang is declared, it adds 1500ms to to detect hang
for render ring to a total of 7500ms. We could sample
the subunit states on first head stuck condition but
decide not to do so only in order to mimic old behaviour. This
way the check order of promotion from seqno > atchd > instdone
is consistently done.
v2: Deal with unstable done states (Arun)
Clear instdone progress on head and seqno movement (Chris)
Report raw and accumulated instdone's in in debugfs (Chris)
Return HANGCHECK_ACTIVE on undone->done
References: https://bugs.freedesktop.org/show_bug.cgi?id=93029 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448985372-19535-1-git-send-email-mika.kuoppala@intel.com
This fixes reprobing of display connectors on resume. After some
talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on
resume hasn't been working (this was observed on a T440s):
- We call hpd_init()
- We check each connector for a couple of things before marking
connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
active encoder. Of course, a disconnected port won't have an
active encoder, so we don't add the flag to any of the
connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
so we skip reprobing each connector except that one.
In addition, we also now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
handled by the mst helpers. This is probably what was originally
intended to happen here.
Changes since V1:
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a
check for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
Changes since V2:
* Put patch changelog above Signed-off-by
* Follow Daniel Vetter's suggestion for making the code here a bit more
legible
Ben Widawsky [Tue, 5 Jan 2016 18:30:07 +0000 (10:30 -0800)]
drm/i915: Extract CSB status read
This is a useful thing to have around as a function because the mechanism may
change in the future.
There is a net increase in LOC here, and it will continue to be the case on GEN8
and GEN9 - but future GENs may have an alternate mechanism for doing this.
Ben Widawsky [Tue, 5 Jan 2016 18:30:06 +0000 (10:30 -0800)]
drm/i915: Change WARN to ERROR in CSB count
There is no point in emitting a WARN since the backtrace will always be the
same. Errors have actually become easier to spot given the large number of WARNs
which exist today in modesetting paths.
Ben Widawsky [Tue, 5 Jan 2016 18:30:05 +0000 (10:30 -0800)]
drm/i915: Cleanup some of the CSB handling
I think this patch is a worthwhile cleanup even if it might look only marginally
useful. It gets more useful in upcoming patches and for handling of future GEN
platforms.
The only non-mechanical part of this is the removal of the extra & operation on
the ring->next_context_status_buffer. This is safe because right above this, we
already did a modulus operation.
Michel Thierry [Wed, 6 Jan 2016 12:08:36 +0000 (12:08 +0000)]
drm/i915/kbl: Enable PW1 and Misc I/O power wells
My kbl stopped working because of this.
Fixes regression from
commit 2f693e28b8df69f67beced5e18bb2b91c2bfcec2
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Wed Nov 4 19:24:12 2015 +0200
drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini
sequences
Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452082116-16770-1-git-send-email-michel.thierry@intel.com Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cursor planes grab the state from plane->state instead of the state
that was passed. The only updates are atomic now, so use the plane_state
that's passed in.
drm/i915: Use passed plane state for sprite planes, v4.
Don't use plane->state directly, use the pointer from commit_plane.
Changes since v1:
- Fix uses of plane->state->rotation and color key to use the passed state too.
- Only pass crtc_state and plane_state to update_plane.
Changes since v2:
- Rebased.
Changes since v3:
- Small whitespace changes and only assign 1 variable per line.
- Constify plane_state and crtc_state. (vsyrjala)
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank). Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.
v2: Significant rebasing/rewriting.
v3:
- Move 'need_postvbl_update' flag to CRTC state (Daniel)
- Don't forget to check intermediate watermark values for validity
(Maarten)
- Don't due async watermark optimization; just do it at the end of the
atomic transaction, after waiting for vblanks. We do want it to be
async eventually, but adding that now will cause more trouble for
Maarten's in-progress work. (Maarten)
- Don't allocate space in crtc_state for intermediate watermarks on
platforms that don't need it (gen9+).
- Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
now that ilk_update_wm is gone.
v4:
- Add a wm_mutex to cover updates to intel_crtc->active and the
need_postvbl_update flag. Since we don't have async yet it isn't
terribly important yet, but might as well add it now.
- Change interface to program watermarks. Platforms will now expose
.initial_watermarks() and .optimize_watermarks() functions to do
watermark programming. These should lock wm_mutex, copy the
appropriate state values into intel_crtc->active, and then call
the internal program watermarks function.
v5:
- Skip intermediate watermark calculation/check during initial hardware
readout since we don't trust the existing HW values (and don't have
valid values of our own yet).
- Don't try to call .optimize_watermarks() on platforms that don't have
atomic watermarks yet. (Maarten)
v6:
- Rebase
v7:
- Further rebase
v8:
- A few minor indentation and line length fixes
v9:
- Yet another rebase since Maarten's patches reworked a bunch of the
code (wm_pre, wm_post, etc.) that this was previously based on.
v10:
- Move wm_mutex to dev_priv to protect against racing commits against
disjoint CRTC sets. (Maarten)
- Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 820da7ae4633 ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"") Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452155350-14658-1-git-send-email-jani.nikula@intel.com
drm/i915: Allow fuzzy matching in intel_compare_link_m_n
This prevents a unnecessary modeset on a dell XPS 13 (2016).
N is always a power of 2, which means that for fuzzy matching we should
compare for inequality on the n values, then do fuzzy matching on the m
values.
Matt Roper [Thu, 3 Dec 2015 19:37:41 +0000 (11:37 -0800)]
drm/i915: Sanitize watermarks after hardware state readout (v4)
Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them. We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.
We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.
v2: Move watermark sanitization after our BIOS fb reconstruction; the
watermark calculations that we do here need to look at pstate->fb,
which isn't setup yet in intel_modeset_setup_hw_state(), even
though we have an enabled & visible plane.
v3:
- Don't move 'active = optimal' watermark assignment; we just undo
that change in the next patch anyway. (Ville)
- Move atomic helper locking fix to separate patch. (Maarten)
v4:
- Grab connection_mutex before calling atomic helper to duplicate
state. The connector loop inside the helper will throw a WARN
if we don't hold something to protect the connector list (and the
helper itself doesn't try to lock the list).
- Make failure to calculate watermarks for inherited state a WARN()
since it probably indicates a serious problem in either our state
readout code or our watermark code for this platform.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Matt Roper [Thu, 3 Dec 2015 19:37:40 +0000 (11:37 -0800)]
drm/i915: Add extra paranoia to ILK watermark calculations
Our low-level watermark calculation functions don't get called when the
CRTC is disabled or the relevant plane is invisible, so they should
never see a zero htotal or zero bpp. However add some checks to ensure
this is true so that we don't wind up dividing by zero if we make a
mistake elsewhere in the driver (which the atomic watermark series has
revealed we might be).
Matt Roper [Thu, 3 Dec 2015 19:37:39 +0000 (11:37 -0800)]
drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
When watermark calculation was moved up to the atomic check phase, the
code was updated to calculate based on in-flight atomic state rather
than already-committed state. However the hsw_compute_linetime_wm()
didn't get updated and continued to pull values out of the
currently-committed CRTC state. On platforms that call this function
(HSW/BDW only), this will cause problems when we go to enable the CRTC
since we'll pull the current mode (off) rather than the mode we're
calculating for and wind up with a divide by zero error.
Matt Roper [Thu, 3 Dec 2015 19:37:38 +0000 (11:37 -0800)]
drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)
Plane state objects contain two copies of src/dest coordinates: the
original (requested by userspace) coordinates in the base
drm_plane_state object, and a second, clipped copy (i.e., what we
actually want to program to the hardware) in intel_plane_state. We've
only been setting up the former set of values during boot time FB
reconstruction, but we should really be initializing both.
Note that the code here probably still needs some more work since we
make a lot of assumptions about how the BIOS programmed the hardware
that may not always be true, especially on gen9+; e.g.,
* Primary plane might not be positioned at 0,0
* Primary plane could have been rotated by the BIOS
* Primary plane might be scaled
* The BIOS fb might be a single "extended mode" FB that spans
multiple displays.
* ...etc...
v2: Reword/expand commit message description of assumptions we make
Chris Wilson [Fri, 27 Nov 2015 13:28:55 +0000 (13:28 +0000)]
drm/i915: Restore inhibiting the load of the default context
Following a GPU reset, we may leave the context in a poorly defined
state, and reloading from that context will leave the GPU flummoxed. For
secondary contexts, this will lead to that context being banned - but
currently it is also causing the default context to become banned,
leading to turmoil in the shared state.
which quietly introduced the removal of the MI_RESTORE_INHIBIT on the
default context.
v2: Mark the global default context as uninitialized on GPU reset so
that the context-local workarounds are reloaded upon re-enabling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org
[danvet: This seems to fix a gpu hand on after the first resume,
resulting in any future suspend operation failing with -EIO because
the gpu seems to be in a funky state. Somehow this patch fixes that.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 5 Jan 2016 16:54:07 +0000 (17:54 +0100)]
drm/i915: Tune down rpm wakelock debug checks
They're causing massive amounts of dmesg noise and hence CI noise all
over the place. Enabling them for a bit was good enough to refresh our
task list of what's still needed to enable rpm by default.
To make sure we're not forgetting to make this noisy again add a FIXME
comment.
Fixes: da5827c36607 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452012847-4737-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
drm/i915: Allow use of get_dma_address for stolen backed objects
i915_gem_object_get_dma_address function is used to retrieve the dma address
of a particular page so as to map it in a given GTT entry for CPU access.
This function would be used for stolen backed objects also for tasks like
pwrite, clearing of the pages etc. So the obj->get_page.sg needs to be
initialized for the stolen objects also.
Jani Nikula [Mon, 21 Dec 2015 13:10:55 +0000 (15:10 +0200)]
drm/i915/bios: have get_blocksize() support MIPI sequence block v3+
Have get_blocksize() support the special case of MIPI sequence block v3+
which has a separate field for size. Provide and use abstractions for
getting the blocksize given a pointer to the block "envelope",
i.e. pointer to the block id, and given a pointer to the block payload
data.
Alex Dai [Fri, 18 Dec 2015 20:00:11 +0000 (12:00 -0800)]
drm/i915/guc: Add GuC ADS - MMIO reg state
GuC needs to know which registers and how they will be saved and
restored during event such as engine reset or power state changes.
For now only the base address of reg state is initialized. The
detail register table probably will be setup in future GuC TDR or
Preemption patch series.
Alex Dai [Fri, 18 Dec 2015 20:00:10 +0000 (12:00 -0800)]
drm/i915/guc: Add GuC ADS - scheduler policies
GuC supports different scheduling policies for its four internal
queues. Currently these have been set to the same default values
as KMD_NORMAL queue.
Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
maximum submit queue numbers to avoid an out-of-space problem.
This value indicates max number of work items allowed to be queued
for one DPC process. A smaller value will let GuC schedule more
frequently while a larger number may increase chances to optimize
cmds (such as collapse cmds from same lrc) with risks that keeps
CS idle.
Alex Dai [Fri, 18 Dec 2015 20:00:09 +0000 (12:00 -0800)]
drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored during reset etc.
This is the first patch of a series to enable GuC ADS. For now, we
only create the ADS obj whilst keep it disabled.
v1: remove dead code checking return of kmap_atomic (Chris Wilson)
v2: use kmap instead of the atomic version of it.
Dave Gordon [Fri, 18 Dec 2015 20:00:08 +0000 (12:00 -0800)]
drm/i915/guc: Expose (intel)_lr_context_size()
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
Alex Dai [Wed, 16 Dec 2015 19:45:55 +0000 (11:45 -0800)]
drm/i915/guc: Move GuC wq_check_space to alloc_request_extras
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to ring_reserve_space
v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson)
v3: The work queue head pointer is cached by driver now. So we can
quickly return if space is available.
s/reserve/check/g (Dave Gordon)
v4: Update cached wq head after ring doorbell; check wq space before
ring doorbell in case unexpected error happens; call wq space
check only when GuC submission is enabled. (Dave Gordon)
Chris Wilson [Fri, 4 Dec 2015 15:58:54 +0000 (15:58 +0000)]
drm/i915: Disable shrinker for non-swapped backed objects
If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. By doing so, we avoid unbinding objects that cannot be
shrunk and so wasting CPU cycles flushing those objects from the GPU to
the system and then immediately back again (as they will more than
likely be reused shortly after).
Based on a patch by Akash Goel.
v2: frontswap registers extra swap pages available for the system, so it
is already include in the count of available swap pages.
v3: Use get_nr_swap_pages() to query the currently available amount of
swap space. This should also stop us from shrinking the GPU buffers if
we ever run out of swap space. Though at that point, we would expect the
oom-notifier to be running and failing miserably...
Chris Wilson [Fri, 4 Dec 2015 15:58:53 +0000 (15:58 +0000)]
mm: Export nr_swap_pages
Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so, they
want to check using get_nr_swap_pages() to see if any swap space is
available as otherwise they will waste time purging the object from the
device without recovering any memory for the system. This requires the
nr_swap_pages counter to be exported to the modules.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org Link: http://patchwork.freedesktop.org/patch/msgid/1449244734-25733-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Michał Winiarski [Tue, 29 Dec 2015 17:24:52 +0000 (18:24 +0100)]
drm/i915: Avoid writing relocs with addresses in non-canonical form
According to PRM, some parts of HW require the addresses to be in
a canonical form, where bits [63:48] == [47]. Let's convert addresses to
canonical form prior to relocating and return converted offsets to
userspace. We also need to make sure that userspace is using addresses
in canonical form in case of softpin.
v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville)
v3: Rebase on top of softpin, fix a hole in relocate_entry,
s/expect/require (Chris)
v4: Handle softpin in validate_exec_list (Chris)
v5: Convert back to canonical form at copy_to_user time (Chris)
v6: Don't use struct exec_object2 in place of exec_object
v7: Use sign_extend64 for converting to canonical form (Joonas),
reject non-canonical and non-page-aligned offset for softpin (Chris)
v8: Convert back to non-canonical form in a function,
split the test for EXEC_OBJECT_PINNED (Chris)
v9: s/canonial/canonical, drop accidental double newline (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451409892-13708-1-git-send-email-michal.winiarski@intel.com
Testcase: igt/gem_bad_reloc/negative-reloc-blt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92699 Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It looks like 70-80 ms is BSW platform needs in some bad cases of the
monitors at this end (8 times delay at most). Keep less than 100ms for
HDCP pulse HPD low (with at least 100ms) to respond a plug out.
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com> Tested-by: Gary Wang <gary.c.wang@intel.com> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Gary Wang <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450858295-12804-1-git-send-email-gary.c.wang@intel.com Tested-by: Shobhit Kumar <shobhit.kumar@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Calculate visibility in check_plane correctly regardless of dpms.
When the crtc is configured but not active we currently clip to (0,0)x(0,0).
This results in differences in calculations depending on dpms setting.
When the crtc is enabled but not active run check_plane as if it were on,
but afterwards set plane_state->visible = false for the checks.
drm/i915: Keep track of the cdclk as if all crtc's were active.
On skylake when calculating plane visibility with the crtc in
dpms off mode the real cdclk may be different from what it would be
if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
if all crtc's were active.
This is required to get the same calculations done correctly regardless
of dpms mode.
drm/i915: Do not acquire crtc state to check clock during modeset, v4.
Parallel modesets are still not allowed, but this will allow updating
a different crtc during a modeset if the clock is not changed.
Additionally when all pipes are DPMS off the cdclk will be lowered
to the minimum allowed.
Changes since v1:
- Add dev_priv->active_crtcs for tracking which crtcs are active.
- Rename min_cdclk to min_pixclk and move to dev_priv.
- Add a active_crtcs mask which is updated atomically.
- Add intel_atomic_state->modeset which is set on modesets.
- Commit new pixclk/active_crtcs right after state swap.
Changes since v2:
- Make the changes related to max_pixel_rate calculations more readable.
Changes since v3:
- Add cherryview and missing WARN_ON to readout.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com>
drm/i915/skl: Do not allow scaling when crtc is disabled.
This fixes a warning when the crtc is turned off. In that case fb
will be NULL, and crtc_clock will be 0. Because the crtc is no longer
active this is not a bug, and shouldn't trigger the WARN_ON.
Also remove handling a null crtc_state, with all transitional helpers
gone this can no longer happen.
Ville Syrjälä [Thu, 10 Dec 2015 16:22:31 +0000 (18:22 +0200)]
drm/i915: Unbreak check_digital_port_conflicts()
Atomic changes broke check_digital_port_conflicts(). It needs to look
at the global situation instead of just trying to find a conflict
within the current atomic state.
This bug made my HSW explode spectacularly after I had split the DDI
encoders into separate DP and HDMI encoders. With the fix, things
seem much more solid.
I hope holding the connection_mutex is enough protection that we can
actually walk the connectors even if they're not part of the current
atomic state...
v2: Regenerate the patch so that it actually applies (Jani)
Cc: stable@vger.kernel.org Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 5448a00d3f06 ("drm/i915: Don't use staged config in check_digital_port_conflicts()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449764551-12466-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Lukas Wunner [Sat, 19 Dec 2015 14:40:39 +0000 (15:40 +0100)]
drm/i915: Remove obsolete code from intelfb_alloc()
Clean up after 0c82312f3f15 ("drm/i915: Pin the ifbdev for the
info->system_base GGTT mmapping"):
At each of the remaining "goto out" in intelfb_alloc(), fb can only be
either an ERR_PTR or NULL, so the call to drm_framebuffer_unreference()
is now obsolete.
Ville Syrjälä [Fri, 18 Dec 2015 17:24:39 +0000 (19:24 +0200)]
drm/i915: Workaround CHV pipe C cursor fail
Turns out CHV pipe C was glued on somewhat poorly, and there's something
wrong with the cursor. If the cursor straddles the left screen edge,
and is then moved away from the edge or disabled, the pipe will often
underrun. If enough underruns are triggered quickly enough the pipe
will fall over and die (it just scans out a solid color and reports
a constant underrun). We need to turn the disp2d power well off and
on again to recover the pipe.
None of that is very nice for the user, so let's just refuse to place
the cursor in the compromised position. The ddx appears to fall back
to swcursor when the ioctl returns an error, so theoretically there's
no loss of functionality for the user (discounting swcursor bugs).
I suppose most cursors images actually have the hotspot not exactly
at 0,0 so under typical conditions the fallback will in fact kick in
as soon as the cursor touches the left edge of the screen.
Any atomic compositor should anyway be prepared to fall back to
GPU composition when things don't work out, so there should be no
problem with those.
Other things that I tried to solve this include flipping all
display related clock gating knobs I could find, increasing the
minimum gtt alignment all the way up to 512k. I also tried to see
if there are more specific screen coordinates that hit the bug, but
the findings were somewhat inconclusive. Sometimes the failures
happen almost across the whole left edge, sometimes more at the very
top and around the bottom half. I wasn't able to find any real pattern
to these variations, so it seems our only choice is to just refuse
to straddle the left screen edge at all.
Gary Wang [Tue, 15 Dec 2015 04:40:30 +0000 (12:40 +0800)]
drm/i915: Correct max delay for HDMI hotplug live status checking
The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms delay.
v2:
- straight up to loop execution for more clear in code readability
- mdelay will replace with msleep by Daniel's new patch
drm/i915: mdelay(10) considered harmful
- suggest to re-evaluate try times for being compatible to old HDMI monitor
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com> Tested-by: Gary Wang <gary.c.wang@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Gary Wang <gary.c.wang@intel.com>
[danvet: fixup conflict with s/mdelay/msleep/ patch.] Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Serialise updates to GGTT with access through GGTT on Braswell
thankfully caught by the extra WARN safegaurd in 0a878716. Since we now
override the GGTT insert_pages callback when installing the aliasing
ppgtt, we assert that the callback is the original ggtt routine.
However, on Braswell we now use a different insertion routine to
serialise access through the GGTT with updating the PTE and hence the
conflict. To avoid the conflict, move the custom insertion routine for
Braswell down a level.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447859979-20107-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mika Kuoppala [Wed, 16 Dec 2015 17:18:37 +0000 (19:18 +0200)]
drm/i915: Apply broader WaRsDisableCoarsePowerGating for guc also
commit 344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
failed to take into account that the same workaround is used in guc
when forcewake is sampled.
Wrap the condition check inside a macro and use it in both places
to fix the guc side scope.
projects / linux-beck.git / log