Chris Wilson [Sat, 4 May 2019 07:07:07 +0000 (08:07 +0100)]
drm/i915: Disable semaphore busywaits on saturated systems
Asking the GPU to busywait on a memory address, perhaps not unexpectedly
in hindsight for a shared system, leads to bus contention that affects
CPU programs trying to concurrently access memory. This can manifest as
a drop in transcode throughput on highly over-saturated workloads.
The only clue offered by perf, is that the bus-cycles (perf stat -e
bus-cycles) jumped by 50% when enabling semaphores. This corresponds
with extra CPU active cycles being attributed to intel_idle's mwait.
This patch introduces a heuristic to try and detect when more than one
client is submitting to the GPU pushing it into an oversaturated state.
As we already keep track of when the semaphores are signaled, we can
inspect their state on submitting the busywait batch and if we planned
to use a semaphore but were too late, conclude that the GPU is
overloaded and not try to use semaphores in future requests. In
practice, this means we optimistically try to use semaphores for the
first frame of a transcode job split over multiple engines, and fail if
there are multiple clients active and continue not to use semaphores for
the subsequent frames in the sequence. Periodically, we try to
optimistically switch semaphores back on whenever the client waits to
catch up with the transcode results.
With 1 client, on Broxton J3455, with the relative fps normalized by %cpu:
x no semaphores
+ drm-tip
* patched
+------------------------------------------------------------------------+
| * |
| *+ |
| **+ |
| **+ x |
| x * +**+ x |
| x x * * +***x xx |
| x x * * *+***x *x |
| x x* + * * *****x *x x |
| + x xx+x* + *** * ********* x * |
| + x xx+x* * *** +** ********* xx * |
| * + ++++* + x*x****+*+* ***+*************+x* * |
|*+ +** *+ + +* + *++****** *xxx**********x***+*****************+*++ *|
| |__________A_____M_____| |
| |_______________A____M_________| |
| |____________A___M________| |
+------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 120 2.60475 3.50941 3.31123 3.2143953 0.21117399
+ 120 2.3826 3.57077 3.25101 3.1414161 0.28146407
Difference at 95.0% confidence
-0.0729792 +/- 0.0629585
-2.27039% +/- 1.95864%
(Student's t, pooled s = 0.248814)
* 120 2.35536 3.66713 3.2849 3.2059917 0.24618565
No difference proven at 95.0% confidence
Indicating that we've recovered the regression from enabling semaphores
on this saturated setup, with a hint towards an overall improvement.
Very similar, but of smaller magnitude, results are observed on both
Skylake(gt2) and Kabylake(gt4). This may be due to the reduced impact of
bus-cycles, where we see a 50% hit on Broxton, it is only 10% on the big
core, in this particular test.
One observation to make here is that for a greedy client trying to
maximise its own throughput, using semaphores is the right choice. It is
only the holistic system-wide view that semaphores of one client
impacts another and reduces the overall throughput where we would choose
to disable semaphores.
The most noticeable negactive impact this has is on the no-op
microbenchmarks, which are also very notable for having no cpu bus load.
In particular, this increases the runtime and energy consumption of
gem_exec_whisper.
Ville Syrjälä [Thu, 2 May 2019 20:06:07 +0000 (23:06 +0300)]
drm/i915: Allow ICL pipe "HDR mode" when the cursor is visible
Turns out the cursor is compatible with the pipe "HDR mode". It's
only the actual SDR planes that get entirely bypassed during
blending. So let's ignore the cursor when checking if we have
any planes active that aren't HDR compatible. This fixes the
regressions in the kms_cursor_crc and kms_plane_cursor tests.
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110579 Fixes: 86154fe3da3f ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502200607.14504-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Thu, 2 May 2019 20:06:06 +0000 (23:06 +0300)]
drm/i915: Move the PIPEMISC write the correct place
I fumbled the PIPEMISC write into the wrong place. It only gets
called for fastsets, but since value needs to be updated based on
the set of active planes it needs to be done for all plane updates.
Move it to the correct spot.
The symptoms include SDR planes never showing up if a previous
modeset/fastset left the pipe in HDR mode. This was immediately
obvious when running the kms_plane pixel format tests. Unfortunately
the test didn't realize it was scanning out pure black all the time
and declared success anyway.
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Fixes: 86154fe3da3f ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502200607.14504-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Chris Wilson [Wed, 1 May 2019 11:45:36 +0000 (12:45 +0100)]
drm/i915: Delay semaphore submission until the start of the signaler
Currently we submit the semaphore busywait as soon as the signaler is
submitted to HW. However, we may submit the signaler as the tail of a
batch of requests, and even not as the first context in the HW list,
i.e. the busywait may start spinning far in advance of the signaler even
starting.
If we wait until the request before the signaler is completed before
submitting the busywait, we prevent the busywait from starting too
early, if the signaler is not first in submission port.
To handle the case where the signaler is at the start of the second (or
later) submission port, we will need to delay the execution callback
until we know the context is promoted to port0. A challenge for later.
Chris Wilson [Wed, 1 May 2019 11:45:28 +0000 (12:45 +0100)]
drm/i915/hangcheck: Track context changes
Given sufficient preemption, we may see a busy system that doesn't
advance seqno while performing work across multiple contexts, and given
sufficient pathology not even notice a change in ACTHD. What does change
between the preempting contexts is their RING, so take note of that and
treat a change in the ring address as being an indication of forward
progress.
Chris Wilson [Thu, 2 May 2019 15:00:24 +0000 (16:00 +0100)]
drm/i915: Leave engine parking to the engines
Drop the check in GEM parking that the engines were already parked. The
intention here was that before we dropped the GT wakeref, we were sure
that no more interrupts could be raised -- however, we have already
dropped the wakeref by this point and the warning is no longer valid.
Chris Wilson [Fri, 3 May 2019 08:09:42 +0000 (09:09 +0100)]
drm/i915/execlists: Flush the tasklet on parking
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
v2: Do the full check for idleness before parking, to be sure we flush
any residual interrupt.
Chris Wilson [Thu, 2 May 2019 20:30:09 +0000 (21:30 +0100)]
drm/i915/guc: Fix runtime suspend
We are not allowed to rpm_get() inside the runtime-suspend callback, so
split the intel_uc_suspend() into the core that assumes the caller holds
the wakeref (intel_uc_runtime_suspend), and one that acquires the wakeref
as necessary (intel_uc_suspend).
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Fixes: 14ab88e3a048 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502203009.15727-1-chris@chris-wilson.co.uk
Jani Nikula [Thu, 2 May 2019 15:02:47 +0000 (18:02 +0300)]
drm/i915: extract intel_gmbus.h from i915_drv.h and rename intel_i2c.c
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
While at it, rename intel_i2c.c to intel_gmbus.c and the functions to
intel_gmbus_*.
Jani Nikula [Thu, 2 May 2019 15:02:43 +0000 (18:02 +0300)]
drm/i915: extract i915_debugfs.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Thu, 2 May 2019 15:02:42 +0000 (18:02 +0300)]
drm/i915: extract intel_acpi.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Thu, 2 May 2019 15:02:41 +0000 (18:02 +0300)]
drm/i915: extract intel_lpe_audio.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Thu, 2 May 2019 15:02:40 +0000 (18:02 +0300)]
drm/i915: extract intel_dpio_phy.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Imre Deak [Thu, 2 May 2019 10:17:54 +0000 (13:17 +0300)]
drm/i915: Tune down WARN about incorrect VBT TC legacy flag
Looks like VBT contains again the wrong information about a port's TypeC
legacy vs. DP-alt/TBT-alt type. There is no further issues after we
notice this and fix it up, so tune down the WARN to be a a DRM_ERROR.
This also avoids CI tainting the kernel and stopping the test run.
Imre Deak [Thu, 25 Apr 2019 18:52:52 +0000 (21:52 +0300)]
drm/i915/icl: Factor out combo PHY lane power setup helper
Factor out the combo PHY lane power configuration code to a separate
helper; it will be also needed by the next patch adding the same
configuration for DDI ports.
Add support for DDI ports and lane reversal as preparation for the next
patch.
The PWR_DOWN_LN_1 value is unspecified in the BSpec register description
so remove it.
v2:
- Fix up the wrong assumption that the encodings are the same for DDI
and DSI ports. (Jani)
v3:
- Use intel_ instead of icl_ prefix. (Jani)
- Add required headers to intel_combo_phy.h after the upstream header
refactoring.
Ville Syrjälä [Tue, 30 Apr 2019 14:29:01 +0000 (17:29 +0300)]
drm/i915: hsw+ audio regs are per-transocder
s/pipe/transcoder/ when dealing with hsw+ audio registers. This
won't actually make any real difference since there is no audio
on the EDP transcoder. But this should avoid a bit of confusion
when cross checking against the spec.
Ville Syrjälä [Tue, 30 Apr 2019 14:29:00 +0000 (17:29 +0300)]
drm/i915: Don't skip audio enable if ELD is bogus
We've already committed to enabling audio when intel_audio_codec_enable()
is called. We can't back out even if the ELD has turned sour in the
meantime. So just spew some debug log and plow ahead. Otherwise the
state checker gets unhappy when audio isn't enabled when it is
expected to be.
I suppose we really ought to precompute the ELD as well, but
let's just toss in a FIXME for the future.
Currently due to regression CI machine displays show corrupt picture.
Problem is when CDCLK is as low as 79200, picture gets unstable, while
DSI and DE pll values were confirmed to be correct. Limiting to 158400
as agreed with Ville.
We could not come up with any better solution yet, as PLL divider values
both for MIPI(DSI PLL) and CDCLK(DE PLL) are correct, however seems that
due to some boundary conditions, when clocking is too low we get wrong
timings for DSI display. Similar workaround exists for VLV though, so
just took similar condition into use. At least that way GLK platform
will start to be usable again, with current drm-tip.
v2: Fixed commit subject as suggested.
v3: Added generic bugs(crc failures, screen not init
for GLK DSI which might be affected).
v4: Added references tag for bugs affected.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=109267
References: https://bugs.freedesktop.org/show_bug.cgi?id=103184 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430125119.7478-1-stanislav.lisovskiy@intel.com
Chris Wilson [Wed, 1 May 2019 13:57:51 +0000 (14:57 +0100)]
drm/i915: Complete both freed-object passes before draining the workqueue
The workqueue code complains viciously if we try to queue more work onto
the queue while attampting to drain it. As we asynchronously free
objects and defer their enqueuing with RCU, it is quite tricky to
quiesce the system before attempting to drain the workqueue. Yet drain
we must to ensure that the worker is idle before unloading the module.
Give the freed object drain 3 whole passes with multiple rcu_barrier()
to give the defer freeing of several levels each protected by RCU and
needing a grace period before its parent can be freed, ultimately
resulting in a GEM object being freed after another RCU period.
A consequence is that it will make module unload even slower.
Chris Wilson [Wed, 1 May 2019 10:32:04 +0000 (11:32 +0100)]
drm/i915: Move the engine->destroy() vfunc onto the engine
Make the engine responsible for cleaning itself up!
This removes the i915->gt.cleanup vfunc that has been annoying the
casual reader and myself for the last several years, and helps keep a
future patch to add more cleanup tidy.
v2: Assert that engine->destroy is set after the backend starts
allocating its own state.
Ville Syrjälä [Fri, 12 Apr 2019 18:30:09 +0000 (21:30 +0300)]
drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used
The pipe has a special HDR mode with higher precision when only
HDR planes are active. Let's use it.
Curiously this fixes the kms_color gamma/degamma tests when
using a HDR plane, which is always the case unless one hacks
the test to use an SDR plane. If one does hack the test to use
an SDR plane it does pass already.
I have no actual explanation how the output after the gamma
LUT can be different between the two modes. The way the tests
are written should mean that the output should be identical
between the solid color vs. the gradient. But clearly that
somehow doesn't hold true for the HDR planes in non-HDR pipe
mode. Anyways, as long as we stick to one type of plane the
test should produce sensible results now.
Jani Nikula [Mon, 29 Apr 2019 12:29:38 +0000 (15:29 +0300)]
drm/i915: extract intel_combo_phy.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:36 +0000 (15:29 +0300)]
drm/i915: extract intel_runtime_pm.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:53:31 +0000 (15:53 +0300)]
drm/i915: extract intel_atomic.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: fix sparse warnings on undeclared global functions
Jani Nikula [Mon, 29 Apr 2019 12:29:34 +0000 (15:29 +0300)]
drm/i915: extract intel_dsi_dcs_backlight.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:33 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_mst.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:32 +0000 (15:29 +0300)]
drm/i915: extract intel_vdsc.h from intel_drv.h and i915_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:31 +0000 (15:29 +0300)]
drm/i915: extract intel_overlay.h from intel_drv.h and i915_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:30 +0000 (15:29 +0300)]
drm/i915: extract intel_quirks.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:29 +0000 (15:29 +0300)]
drm/i915: extract intel_bios.h functions from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the header remains self-contained, and do so with minimal further
includes, using forward declarations as needed.
Jani Nikula [Mon, 29 Apr 2019 12:50:11 +0000 (15:50 +0300)]
drm/i915: extract intel_hotplug.h from intel_drv.h and i915_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: fix sparse warnings on undeclared global functions
Jani Nikula [Mon, 29 Apr 2019 12:29:27 +0000 (15:29 +0300)]
drm/i915: extract i915_irq.h from intel_drv.h and i915_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:26 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_aux_backlight.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:25 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_link_training.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Mon, 29 Apr 2019 12:29:24 +0000 (15:29 +0300)]
drm/i915: extract intel_fifo_underrun.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Lucas De Marchi [Thu, 4 Apr 2019 23:04:26 +0000 (16:04 -0700)]
drm/i915: do not mix workaround with normal flow
Separate the two comments: one is a workaround and the other is a sanity
check. We could just compare != 1, but let's treat them differently due
to having different meaning.
Chris Wilson [Fri, 26 Apr 2019 16:33:36 +0000 (17:33 +0100)]
drm/i915: Move i915_request_alloc into selftests/
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/ where the remaining users are confined.
Chris Wilson [Fri, 26 Apr 2019 16:33:35 +0000 (17:33 +0100)]
drm/i915: Remove intel_context.active_link
We no longer need to track the active intel_contexts within each engine,
allowing us to drop a tricky mutex_lock from inside unpin (which may
occur inside fs_reclaim).
Chris Wilson [Fri, 26 Apr 2019 16:33:34 +0000 (17:33 +0100)]
drm/i915: Switch back to an array of logical per-engine HW contexts
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine instance and always use an index into the
ctx->engines[]. Later on, this ctx->engines[] may be replaced by a user
specified map.
v2: Add for_each_gem_engine() helper to iterator within the engines lock
v3: intel_context_create_request() helper
v4: s/unsigned long/unsigned int/ 4 billion engines is quite enough.
v5: Push iterator locking to caller
Chris Wilson [Fri, 26 Apr 2019 16:33:33 +0000 (17:33 +0100)]
drm/i915: Split engine setup/init into two phases
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
v2: s/setup_xcs/setup_common/ for intel_ring_submission_setup()
Chris Wilson [Fri, 26 Apr 2019 16:33:28 +0000 (17:33 +0100)]
drm/i915/gvt: Pin the per-engine GVT shadow contexts
Our eventual goal is to rid request construction of struct_mutex, with
the short term step of lifting the struct_mutex requirements into the
higher levels (i.e. the caller must ensure that the context is already
pinned into the GTT). In this patch, we pin GVT's shadow context upon
allocation and so keep them pinned into the GGTT for as long as the
virtual machine is alive, and so we can use the simpler request
construction path safe in the knowledge that the hard work is already
done.
Ville Syrjälä [Mon, 8 Apr 2019 12:18:15 +0000 (15:18 +0300)]
drm/i915: Clean up cherryview_load_luts()
I like my functions simple, so split up the low level bits from
cherryview_load_luts() into separate functions. Also rename the
whole thing to chv_load_luts() to match the new world order.
Ville Syrjälä [Thu, 25 Apr 2019 19:24:19 +0000 (22:24 +0300)]
drm/i915: Fix ICL output CSC programming
When I refactored the code into its own function I accidentally
misplaced the <<16 shifts for some of the registers causing us
to lose the blue channel entirely.
Chris Wilson [Fri, 19 Apr 2019 17:27:20 +0000 (18:27 +0100)]
drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimising the amount of state it needs to reload and manually save
across batches.
v2: CONSTANT_BUFFER woes
Running through piglit turned up an interesting issue, a GPU hang inside
the context load. The context image includes the CONSTANT_BUFFER command
that loads an address into a on-gpu buffer, and the context load was
executing that immediately. However, since it was reading from the GTT
there is no guarantee that the GTT retains the same configuration as
when the context was saved, resulting in stray reads and a GPU hang.
Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
ring before saving the context to no avail, we resort to patching out
the instruction inside the context image before loading.
This does impose that gen4 always reissues CONSTANT_BUFFER commands on
each batch, but due to the use of a shared GTT that was and will remain
a requirement.
v3: ECOSKPD to the rescue
Ville found the magic bit in the ECOSKPD to disable saving and restoring
the CONSTANT_BUFFER from the context image, thereby completely avoiding
the GPU hangs from chasing invalid pointers. This appears to be the
default behaviour for gen5, and so we just need to tweak gen4 to match.
v4: Fix spelling of ECOSKPD and discover it already exists
Chris Wilson [Fri, 19 Apr 2019 11:17:48 +0000 (12:17 +0100)]
drm/i915: Enable render context support for Ironlake (gen5)
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of state it needs to reload, or manually save and restore.
v2: Fix off-by-one in reading CXT_SIZE, and add a comment that the
CXT_SIZE and context-layout do not match in bspec, but the difference is
irrelevant as we overallocate the full page anyway (Ville).
Despite what I think the prm recommends, commit 42ed124d327e
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
simple rendercopies with igt, do not suffer).
Ville found the following clue,
"[DevCTG+]: For the invalidate operation of the pipe control, the
following pointers are affected. The
invalidate operation affects the restore of these packets. If the pipe
control invalidate operation is completed
before the context save, the indirect pointers will not be restored from
memory.
1. Pipeline State Pointer
2. Media State Pointer
3. Constant Buffer Packet"
which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT,
we prevent the context-restore from chasing the dangling pointers within
the image, and explains why this likely prevents the GPU hang.
Chris Wilson [Fri, 26 Apr 2019 08:17:24 +0000 (09:17 +0100)]
drm/i915: Merge sandybridge_pcode_(read|write)
These routines are identical except in the nature of the value parameter.
For writes it is a pure in-param, but for a read, we need an out-param.
Since they differ in a single line, merge the two routines into one.
Chris Wilson [Fri, 26 Apr 2019 08:17:23 +0000 (09:17 +0100)]
drm/i915: Merge sbi read/write into a single accessor
Since intel_sideband_read and intel_sideband_write differ by only a
couple of lines (depending on whether we feed the value in or out),
merge the two into a single common accessor.
v2: Restore vlv_flisdsi_read() lost during rebasing.
Chris Wilson [Fri, 26 Apr 2019 08:17:21 +0000 (09:17 +0100)]
drm/i915: Replace pcu_lock with sb_lock
We now have two locks for sideband access. The general one covering
sideband access across all generation, sb_lock, and a specific one
covering sideband access via the punit on vlv/chv. After lifting the
sb_lock around the punit into the callers, the pcu_lock is now redudant
and can be separated from its other use to regulate RPS (essentially
giving RPS a lock all of its own).
Chris Wilson [Fri, 26 Apr 2019 08:17:20 +0000 (09:17 +0100)]
drm/i915: Lift sideband locking for vlv_punit_(read|write)
Lift the sideband acquisition for vlv_punit_read and vlv_punit_write
into their callers, so that we can lock the sideband once for a sequence
of operations, rather than perform the heavyweight acquisition on each
request.
Chris Wilson [Fri, 26 Apr 2019 08:17:19 +0000 (09:17 +0100)]
drm/i915: Lift acquiring the vlv punit magic to a common sb-get
As we now employ a very heavy pm_qos around the punit access, we want to
minimise the number of synchronous requests by performing one for the
whole punit sequence rather than around individual accesses. The
sideband lock is used for this, so push the pm_qos into the sideband
lock acquisition and release, moving it from the lowlevel punit rw
routine to the callers. In the first step, we move the punit magic into
the common sideband lock so that we can acquire a bunch of ports
simultaneously, and if need be extend the workaround protection later.
Chris Wilson [Fri, 26 Apr 2019 08:17:18 +0000 (09:17 +0100)]
drm/i915: Disable preemption and sleeping while using the punit sideband
While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.
Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.
v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
is insufficient evidence to implicate a wider problem atm. Similarly,
restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
of users.
The working theory, courtesy of Ville and Hans, is the issue lies within
the power delivery and so is likely to be unit and board specific and
occurs when both the unit/fw require extra power at the same time as the
cpu package is changing its own power state.
References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 26 Apr 2019 01:35:40 +0000 (11:35 +1000)]
Merge tag 'drm-misc-next-fixes-2019-04-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
- fb_helper: Fix NULL deref in legacy drivers (Noralf)
- leases: Ensure lessees can't connect to objects outside their perview (Daniel)
- leases: Enforce that lessees hold the lease for implicitly set planes (Daniel)
- leases: A few non-functional cleanups (Daniel)
Chris Wilson [Thu, 25 Apr 2019 05:43:33 +0000 (06:43 +0100)]
drm/i915: Allow multiple user handles to the same VM
It was noted that we made the same mistake for VM_ID as for object
handles, whereby we ensured that we only allocated a single handle for
one ppgtt. This has the unfortunate consequence for userspace that they
need to reference count the handles to avoid destroying an active ID. If
we allow multiple handles to the same ppgtt, userspace can freely
unreference any handle they own without fear of destroying the same
handle in use elsewhere.
Chris Wilson [Thu, 25 Apr 2019 05:01:43 +0000 (06:01 +0100)]
drm/i915: Explicitly pin the logical context for execbuf
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
Chris Wilson [Wed, 24 Apr 2019 20:07:17 +0000 (21:07 +0100)]
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Chris Wilson [Wed, 24 Apr 2019 20:07:16 +0000 (21:07 +0100)]
drm/i915: Pass intel_context to i915_request_create()
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a foundation for
breaking up the complex request allocation to handle different scenarios
inside execbuf.
For the purpose of emitting a request from inside retirement (see the
next patch for engine power management), we also need to lift control
over the timeline mutex to the caller.
v2: Note that the request carries the active reference upon construction.
Chris Wilson [Wed, 24 Apr 2019 20:07:15 +0000 (21:07 +0100)]
drm/i915: Introduce context->enter() and context->exit()
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global GEM operation). In this patch,
we introduce the context callbacks that in future patches will be
redirected to per-engine interfaces leading to global operations as
required.
The intent is that this will be guarded by the timeline->mutex, except
that retiring has not quite finished transitioning over from being
guarded by struct_mutex. So at the moment it is protected by
struct_mutex with a reminded to switch.
v2: Rename default handlers to intel_context_enter_engine.
Chris Wilson [Wed, 24 Apr 2019 20:07:13 +0000 (21:07 +0100)]
drm/i915: Introduce struct intel_wakeref
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular intel_wakeref_t tracker.
Chris Wilson [Wed, 24 Apr 2019 17:48:39 +0000 (18:48 +0100)]
drm/i915: Move GraphicsTechnology files under gt/
Start partitioning off the code that talks to the hardware (GT) from the
uapi layers and move the device facing code under gt/
One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
subdivide that header and body further (and split out the submission
code from the ringbuffer and logical context handling). This patch aims
to be simple motion so git can fixup inflight patches with little mess.
Chris Wilson [Wed, 24 Apr 2019 11:09:41 +0000 (12:09 +0100)]
drm/i915/selftests: Verify whitelist of context registers
The RING_NONPRIV allows us to add registers to a whitelist that allows
userspace to modify them. Ideally such registers should be safe and
saved within the context such that they do not impact system behaviour
for other users. This selftest verifies that those registers we do add
are (a) then writable by userspace and (b) only affect a single client.
Opens:
- Is GEN9_SLICE_COMMON_ECO_CHICKEN1 really write-only?
v2: Remove the blatant copy-paste.
v3: Emulate userspace register writes via the batch again.
Chris Wilson [Wed, 24 Apr 2019 09:51:34 +0000 (10:51 +0100)]
drm/i915: Store the default sseu setup on the engine
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is to dig it out from i915->runtime_info.
v2: Use intel_sseu_from_device_info() to describe the converter
Daniel Vetter [Thu, 28 Feb 2019 14:49:10 +0000 (15:49 +0100)]
drm/atomic: -EACCESS for lease-denied crtc lookup
With the previous patch drm_crtc_find will return NULL when the crtc
isn't in our lease, which will then disable the plane/connector. No
longer an issue since the lessor can't escape their lease terms
anymore, but not quite great semantics yet either.
Catch this and return -EACCES, so that at least evil test cases have a
better chance of making sure the kernel works correctly.
projects / kernel.git / log