drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.
v1-v2: old changelog
1: Add comment about need to synchronize flush work and log runtime
destroy
2: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)
v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@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/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
Ville Syrjälä [Mon, 22 Jan 2018 17:41:31 +0000 (19:41 +0200)]
drm/i915: Implement display w/a #1143
Apparently SKL/KBL/CFL need some manual help to get the
programmed HDMI vswing to stick. Implement the relevant
workaround (display w/a #1143).
Note that the relevant chicken bits live in a transcoder register
even though the bits affect a specific DDI port rather than a
specific transcoder. Hence we must pick the correct transcoder
register instance based on the port rather than based on the
cpu_transcoder.
Also note that for completeness I included support for DDI A/E
in the code even though we never have HDMI on those ports.
Chris Wilson [Wed, 24 Jan 2018 11:36:07 +0000 (11:36 +0000)]
drm/i915: Track the number of times we have woken the GPU up
By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.
v2: No reason to specify precise number of bits here.
v3: Take Tvrtko's advice and reserve 0 as an invalid epoch.
Chris Wilson [Tue, 23 Jan 2018 21:04:12 +0000 (21:04 +0000)]
drm/i915/execlists: Inhibit context save/restore for the fake preempt context
We only use the preempt context to inject an idle point into execlists.
We never need to reference its logical state, so tell the GPU never to
load it or save it.
v2: BIT(2) for save-inhibit.
N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the
submission process rather than the context image.
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123210412.17653-1-chris@chris-wilson.co.uk
Michel Thierry [Wed, 24 Jan 2018 00:43:49 +0000 (16:43 -0800)]
drm/i915: Move LRC register offsets to a header file
Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.
v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)
v3: License notice shenanigans.
v4: Documentation/process/coding-style.rst is always right (Chris)
v5: Rebase.
Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-2-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tvrtko Ursulin [Tue, 23 Jan 2018 13:45:58 +0000 (13:45 +0000)]
drm/i915/pmu: Fix sysfs exported counter config
We need to generate the event config value using the uAPI class and not
the driver internal one.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180123134558.3222-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Mon, 22 Jan 2018 13:55:41 +0000 (13:55 +0000)]
drm/i915: Increase render/media power gating hysteresis for gen9+
On gen9+, after an idle period the HW will disable the entire power well
to conserve power (by preventing current leakage). It takes around a 100
microseconds to bring the power well back online afterwards. With the
current hysteresis value of 25us (really 25 * 1280ns), we do not have
sufficient time to respond to an interrupt and schedule the next execution
before the HW powers itself down. (At present, we prevent this by
grabbing the forcewake for prolonged periods of time, but that overkill
fixed in the next patch.) The minimum we want to set the power gating
hysteresis to is the length of time it takes us to service the GPU, which
across a broad spectrum of machines is about 250us.
(Note this also brings guc latency into the same ballpark as execlists.)
v2: Include some notes on where I plucked the numbers from.
Testcase: igt/gem_exec_nop/sequential Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122135541.32222-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 19 Jan 2018 10:00:04 +0000 (10:00 +0000)]
drm/i915: Per-engine scratch VMA is mandatory
We fail engine initialization if the scratch VMA cannot be created so
there is no point in error handle it later. If the initialization ordering
gets messed up, we can explode during development just as well.
Tvrtko Ursulin [Fri, 19 Jan 2018 10:00:03 +0000 (10:00 +0000)]
drm/i915: Downgrade incorrect engine constructor usage warnings to development
Render engine constructor helpers must only be called from the render
engine constructors, but there is no need to burden the production
binaries with warnings which can only be triggered during development.
Manasi Navare [Thu, 12 Oct 2017 19:13:38 +0000 (12:13 -0700)]
drm/i915/edp: Do not do link training fallback or prune modes on EDP
In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.
In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.
v2:
* Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507835618-23051-1-git-send-email-manasi.d.navare@intel.com
Chris Wilson [Sun, 21 Jan 2018 17:31:43 +0000 (17:31 +0000)]
drm/i915: Protect WC stash allocation against direct reclaim
As we attempt to allocate pages for use in a new WC stash, direct
reclaim may run underneath us and fill up the WC stash. We have to be
careful then not to overflow the pvec.
Fixes: 66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103109 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180121173143.17090-1-chris@chris-wilson.co.uk
Michal Wajdeczko [Fri, 19 Jan 2018 12:49:26 +0000 (12:49 +0000)]
drm/i915/guc: Keep GuC log disabled by default
It looks that GuC log functionality is not fully functional yet and
causes issues when enabled by auto(-1) modparam on debug builds.
For example, but not limited to:
[ 30.062893] ======================================================
[ 30.062894] WARNING: possible circular locking dependency detected
[ 30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U
[ 30.062896] ------------------------------------------------------
[ 30.062897] debugfs_test/1268 is trying to acquire lock:
[ 30.062898] (&dev->struct_mutex){+.+.}, at: [<00000000e4213449>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
[ 30.062921]
but task is already holding lock:
[ 30.062921] (&mm->mmap_sem){++++}, at: [<00000000dd7adc93>] __do_page_fault+0x106/0x560
[ 30.062924]
which lock already depends on the new lock.
References: 0ed87953532652 ("drm/i915/guc: Redefine guc_log_level modparam values")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104694
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119124926.29844-1-michal.wajdeczko@intel.com Reviewed-by: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tvrtko Ursulin [Thu, 11 Jan 2018 22:55:07 +0000 (14:55 -0800)]
drm/i915/icl: Gen11 render context size
Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12544 DWORDs (13 pages), plus
one page for PPHWSP.
Please notice that, when looking at the BSpec context image table,
the right filter has to be applied as some rows are excluded for
specific GENs. Also, some rows apply per-subslice (for the
calculation above, we have supposed I915_MAX_SUBSLICES = 8).
v2: Rebase.
v3: Use the right size as per the BSpec.
v4:
- Rebased on top of the default context size (Rodrigo)
- Clarify in the commit message where the subslice calculation
comes from.
v5: s/12538/12544/ (Daniele)
BSpec: 18907
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ben Widawsky <benjamin.widawsky@intel.com> (older version) Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515711307-28979-2-git-send-email-oscar.mateo@intel.com
Oscar Mateo [Thu, 11 Jan 2018 22:55:06 +0000 (14:55 -0800)]
drm/i915: Return a default RCS context size
Instead of returning whatever size the latest GEN used. This is because
context sizes for new GENs can go up or down, but the only safe thing to
do for missing cases is to use the largest known one, whatever that is.
Anusha Srivatsa [Fri, 19 Jan 2018 18:48:12 +0000 (16:48 -0200)]
drm/i915/icp: Add backlight Support for ICP
ICP has two backlight controllers - similar to previous platforms like
BXT -, but we only use one controller for now, so we can just reuse
the CNP code.
v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
Reuse CNP code since it is very similar.(Ville)
v3 (from Paulo): Rebase.
v4 (from Paulo): adjust commit message (James) and comment (Rodrigo).
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: James Ausmus <james.ausmus@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119184812.2888-1-paulo.r.zanoni@intel.com Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Anusha Srivatsa [Thu, 11 Jan 2018 18:00:07 +0000 (16:00 -0200)]
drm/i915/icp: Add Panel Power Sequencing Support
ICP, like BXT, has has two panel power sequencers.
v2: Simplify the code. Remove unwanted register definitions.
Make code as close to BXT style as possible. (Ville)
Also, remove the use of ICP_SECOND_PPS_BACKLIGHT for now.
Moving forward, if we are sure we need to set this register,
we can access it.
v3: Use INTEL_GEN(dev_priv), make code more readeable. (Ville)
v5: Use per platform checks rather than INTEL_GEN().
v4 of this patch breaks on CoffeeLake, since CFL uses
CNP and per platform check makes sense in that case.
v6 (from Paulo):
- v5 was a patch on top of v4, not a new version. Now v6 is correctly
a new version of the original patch.
Rodrigo Vivi [Thu, 11 Jan 2018 18:00:04 +0000 (16:00 -0200)]
drm/i915/icl: Add initial Icelake definitions.
Icelake is an Intel® Processor containing an Intel® Graphics
Controller.
This is just an initial Icelake definition. PCI IDs, Icelake support
and new features coming in following patches.
v2: Add .ddb_size and .has_guc (Michal Wajdeczko).
v3: Add the ICL_FEATURES macro (Kelvin Gardiner).
v4 (from Paulo): Add missing __initconst (Paulo) and say "graphics
controller" instead of something that looks like an official marketing
name but isn't (Chris).
Rodrigo Vivi [Thu, 11 Jan 2018 18:00:03 +0000 (16:00 -0200)]
drm/i915/cnl: Add Port F definition.
Some Cannonlake SKUs will come with a full split between
port A and port E. This will be called port F although it
is not a 6th port, but only a split.
Note this patch alone is not sufficient for port F enabling,
it's just the first step.
v2: Fix size of dvo_ports found by Ander.
v3: Adding missing cases from intel_bios.c for Port_F
v4: Adding other missing cases and fix the commit message.
v5: Rebase on top of display headers rework.
v6 (from Paulo): improve commit message, bikeshed bit definitions.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111180010.24357-2-paulo.r.zanoni@intel.com
Mika Kahola [Mon, 18 Dec 2017 08:04:03 +0000 (10:04 +0200)]
drm/i915: Check for fused or unused pipes
We may have fused or unused pipes in our system. Let's check that the pipe
in question is within limits of accessible pipes. In case, that we are not
able to access the pipe, we return early with a warning.
v2: Rephrasing of the commit message (Jani)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206 Reported-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Jaswinder Singh Rajput <jaswinder@perfectintelligent.com> Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513584243-12607-1-git-send-email-mika.kahola@intel.com
Ville Syrjälä [Fri, 22 Dec 2017 19:22:28 +0000 (21:22 +0200)]
drm/i915: Add CCS capability for sprites
Allow sprites to scan out compressed framebuffers.
Since different platforms have a different set of planes that
support CCS let's add a small helper to determine whether a
specific plane supports CCS or not. Currently that information
is spread around in many places, and not all the pieces of
code even agree with each other.
In addition to allowing sprites to scan out compressed fbs,
the other fix here is that we stop rejecting them on pipe C
on CNL.
Ville Syrjälä [Fri, 22 Dec 2017 19:22:27 +0000 (21:22 +0200)]
drm/i915: Clean up the sprite modifier checks
Split the g4x and snb cases into separate functions to match how we deal
with all other platforms. Also sort the switch cases to match the format
lists we've declared earlier, to ease comparisons.
Ville Syrjälä [Fri, 22 Dec 2017 19:22:26 +0000 (21:22 +0200)]
drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
Y/Yf were dropped out from the SKL+ sprite modifier list on account
of some watermark issues Daniel Stone was having. My subsequent testing
seemed to indicate that things work better now, so add the modifiers
back in.
v2: Update the commit message with a better explanation
Abdiel Janulgue [Fri, 15 Dec 2017 10:20:55 +0000 (12:20 +0200)]
drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set
4K modes testing by using dummy EDID data has never been working
properly on boxes with DP++ (dual-mode) adaptors. The reason for
this is that those modes got pruned during hdmi mode validation.
intel_hdmi_mode_valid returns CLOCK_HIGH because the pixel clock
reported by the 4k mode is higher than dual port TMDS clock limit.
However 4k injection does work properly on machines that don't have
DP++ adapters because the mode is never validated against the DP++
TMDS clock limit.
v2: Don't detect the DP++ limits when we're testing using overridden
EDIDs. Make sure to check for the override condition after
respecting the value of drm_dp_dual_mode_detect (Jani Nikula).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101649 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171215102055.11729-1-abdiel.janulgue@linux.intel.com
Jani Nikula [Fri, 29 Dec 2017 12:55:47 +0000 (14:55 +0200)]
drm/i915: remove redundant ELD connector type update
drm_edid_to_eld() sets ELD connector type since commit 1d1c36650752
("drm/edid: set ELD connector type in drm_edid_to_eld()"). Remove the
redundant update.
(Commit c945b8c14bb7 ("drm/edid: build ELD in drm_add_edid_modes()") and
commit d471ed04b487 ("drm/drivers: drop redundant drm_edid_to_eld()
calls") are also related.)
v2: Rebase, update commit message with commit references.
Lucas De Marchi [Tue, 28 Nov 2017 22:05:53 +0000 (14:05 -0800)]
drm/i915/cnl: apply Display WA #1178 to fix type C dongles
Display WA #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. Although it is for type C, HW engineers reported
that it can be applied to all external ports even if they are not going
to type C.
For CNL we apply the workaround every time Aux B, C and D are powering
up since they will lose the configuration when powered down.
v2: Use common tag for WA
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128220553.22435-1-lucas.demarchi@intel.com
Michal Wajdeczko [Thu, 11 Jan 2018 15:24:41 +0000 (15:24 +0000)]
drm/i915/guc: Change values for i915_guc_log_control
Today we have format mismatch between read/write operations
of i915_guc_log_control entry. For read we return (0, 1..4)
that represents disable/verbosity levels, but for write we
force user to follow internal structure format (0,1,9,11,13).
Let's hide internals from the user and accept same values
as we support for read and related guc_log_level modparam.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180111152441.21676-2-michal.wajdeczko@intel.com Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We used value -1 to indicate "disabled" and values 0..3 to
indicate "enabled", but most of our other modparams are using
-1 for "auto" mode and 0 for "disable". For consistency let's
change our log level values to:
Chris Wilson [Thu, 18 Jan 2018 13:16:09 +0000 (13:16 +0000)]
drm/i915: Avoid waitboosting on the active request
Watching a light workload on Baytrail (running glxgears and a 1080p
decode), instead of the system remaining at low frequency, the glxgears
would regularly trigger waitboosting after which it would have to spend
a few seconds throttling back down. In this case, the waitboosting is
counter productive as the minimal wait for glxgears doesn't prevent it
from functioning correctly and delivering frames on time. In this case,
glxgears happens to almost always be waiting on the current request,
which we already expect to complete quickly (see i915_spin_request) and
so avoiding the waitboost on the active request and spinning instead
provides the best latency without overcommitting to upclocking.
However, if the system falls behind we still force the waitboost.
Similarly, we will also trigger upclocking if we detect the system is
not delivering frames on time - again using a mechanism that tries to
detect a miss and not preemptively upclock.
v2: Also skip boosting for after missed vblank if the desired request is
already active.
Imre Deak [Wed, 17 Jan 2018 17:25:08 +0000 (19:25 +0200)]
drm/i915: Add tracking for CDCLK bypass frequency
The CDCLK bypass frequency can vary on upcoming platforms, so prepare
for that now by tracking its value in the CDCLK state.
Currently on BDW+ the bypass frequency is always the reference clock and
I didn't bother with earlier platforms since it's not all that clear
what's the bypass clock on those.
I also didn't bother adding support for changing this frequency, since
atm I don't see any need for it.
Chris Wilson [Mon, 15 Jan 2018 21:24:46 +0000 (21:24 +0000)]
drm/i915: Only attempt to scan the requested number of shrinker slabs
Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"),
we track the number of objects we scan and do not wish to exceed that as
it will overly penalise our own slabs under mempressure. Given that we
now know the target number of objects to scan, use that as our guide for
deciding to shrink as opposed to the number of objects we manage to
shrink (which doesn't correspond to the numbers we report to shrinkctl).
Arnd Bergmann [Wed, 17 Jan 2018 15:48:53 +0000 (16:48 +0100)]
drm: i915: remove timeval users
struct timeval is deprecated because it cannot represent times
past 2038. In this driver, the only use of this structure is
to capture debug information. This is easily changed to ktime_t,
which we then format as needed when printing it later.
Chris Wilson [Wed, 17 Jan 2018 13:57:13 +0000 (13:57 +0000)]
drm/i915/selftests: Wait for the dma-fence timeout
When testing that the timeout fired, we need to be sure we have waited
just long enough for the timeout to have occurred and for the softirq
(on another cpu) to have completed. Sleeping for an arbitrary amount is
prone to error, so wait for the timeout instead and complain if it was
too late.
v2: Use wait_event_timeout to provide an upper bound
v3: Fix inverted check for wait_event_timeout timing out
v4: Restore the check that the fences aren't signalled too early, by
inspecting them before the expected timeout.
It's perfectly legal to create a fb with stride < 512, and one of
the kms_plane_scaling subtests creates a very small fb.
Downgrade the WARN_ON to a simple check check, and because this
function is potentially called on every atomic update/pageflip,
downgrade the other WARN_ON to a WARN_ON_ONCE, and do the right
thing here.
drm/i915: Always call to intel_display_set_init_power() in resume_early.
intel_power_domains_init_hw() calls set_init_power, but when using
runtime power management this call is skipped. This prevents hw readout
from taking place.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104172 Link: https://patchwork.freedesktop.org/patch/msgid/20180116155324.75120-1-maarten.lankhorst@linux.intel.com Fixes: bc87229f323e ("drm/i915/skl: enable PC9/10 power states during suspend-to-idle") Cc: Nivedita Swaminathan <nivedita.swaminathan@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Reviewed-by: Imre Deak <imre.deak@intel.com>
Chris Wilson [Mon, 15 Jan 2018 20:57:59 +0000 (20:57 +0000)]
drm/i915: Rewrite some comments around RCU-deferred object free
Tvrtko noticed that the comments describing the interaction of RCU and
the deferred worker for freeing drm_i915_gem_object were a little
confusing, so attempt to bring some sense to them.
Chris Wilson [Mon, 15 Jan 2018 12:28:45 +0000 (12:28 +0000)]
drm/i915: Use our singlethreaded wq for freeing objects
As freeing the objects require serialisation on struct_mutex, we should
prefer to use our singlethreaded driver wq that is dedicated to work
requiring struct_mutex (hence serialised).The benefit should be less
clutter on the system wq, allowing it to make progress even when the
driver/struct_mutex is heavily contended.
Chris Wilson [Mon, 15 Jan 2018 09:20:41 +0000 (09:20 +0000)]
drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
In order to prevent a race condition where we may end up overaccounting
the active state and leaving the busy-stats believing the GPU is 100%
busy, lock out the tasklet while we reconstruct the busy state. There is
no direct spinlock guard for the execlists->port[], so we need to
utilise tasklet_disable() as a synchronous barrier to prevent it, the
only writer to execlists->port[], from running at the same time as the
enable.
Chris Wilson [Mon, 15 Jan 2018 09:06:43 +0000 (09:06 +0000)]
drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences
As the timeout mechanism has grown more and more complicated, using
multiple deferred tasks and more than doubling the size of our struct,
split the two implementations to streamline the simpler no-timeout
callback variant.
Chris Wilson [Mon, 15 Jan 2018 09:06:42 +0000 (09:06 +0000)]
drm/i915: Only defer freeing of fence callback when also using the timer
Without an accompanying timer (for internal fences), we can free the
fence callback immediately as we do not need to employ the RCU barrier
to serialise with the timer. By avoiding the RCU delay, we can avoid the
extra mempressure under heavy inter-engine request utilisation.
drm/i915/psr: Avoid initializing PSR if there is no sink support.
DPCD read for the eDP is complete by the time intel_psr_init() is
called, which means we can avoid initializing PSR structures and state
if there is no sink support.
drm/i915/psr: CAN_PSR() macro to check for PSR source and sink support.
The global variable dev_priv->psr.sink_support is set if an eDP sink
supports PSR. Use this instead of redoing the check with is_edp_psr().
Combine source and sink support checks into a macro that can be used to
return early from psr_{invalidate, single_frame_update, flush}.
This flag has become redundant since
commit 4d90f2d507ab ("drm/i915: Start tracking PSR state in crtc state")
It is set at the same place as psr.enabled, which is also exposed via
debugfs.
Chris Wilson [Thu, 11 Jan 2018 07:30:31 +0000 (07:30 +0000)]
drm/i915/pmu: Reconstruct active state on starting busy-stats
We have a hole in our busy-stat accounting if the pmu is enabled during
a long running batch, the pmu will not start accumulating busy-time
until the next context switch. This then fails tests that are only
sampling a single batch.
v2: Count each active port just once (context in/out events are only on
the first and last assignment to a port).
v3: Avoid hardcoding knowledge of 2 submission ports
Fixes: 30e17b7847f5 ("drm/i915: Engine busy time tracking")
Testcase: igt/perf_pmu/busy-start
Testcase: igt/perf_pmu/busy-double-start Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111073031.14614-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Thu, 11 Jan 2018 08:35:25 +0000 (08:35 +0000)]
drm/i915/pmu: Only enumerate available counters in sysfs
Switch over to dynamically creating device attributes, which are in turn
used by the perf core to expose available counters in sysfs.
This way we do not expose counters which are not avaiable on the current
platform, and are so more consistent between what we reply to open
attempts via the perf_event_open(2), and what is discoverable in sysfs.
v2:
* Simplify attribute pointer freeing loop.
* Changed attr init from macro to function.
* More common error unwind. (Chris Wilson)
* Rename some locals. (Chris Wilson)
Tvrtko Ursulin [Thu, 11 Jan 2018 08:24:17 +0000 (08:24 +0000)]
drm/i915: Apply headless DMC workaround for CNL
With firmware 1.07 having fixed the state corruption issue, we can enable
the headless GT performance workaround for CNL as well. (Equivalent to b68763741aa2 ("drm/i915: Restore GT performance in headless mode with DMC
loaded") on other affected platforms.)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Testcase: igt/gem_exec_nop/headless Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111082417.795-1-tvrtko.ursulin@linux.intel.com
Oscar Mateo [Fri, 22 Dec 2017 22:38:49 +0000 (14:38 -0800)]
drm/i915: Stop getting the fault address from RING_FAULT_REG
This register does not contain it. Instead, we have to look into FAULT_TLB_DATA0 & 1
(where, by the way, we can also get the address space).
v2: Right formatting
v3:
- Use 12 (as per the register format) instead of PAGE_SIZE (Chris)
- s/BITS_44_TO_47/HIGHBITS (Chris)
- Right formatting, this time for real
Fixes: b03ec3d67ab8 ("drm/i915: There is only one fault register from GEN8 onwards") Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1513982329-32191-1-git-send-email-oscar.mateo@intel.com Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drm/i915/guc: Add uc_fini_wq in gem_init unwind path
While moving code around for solving lockdep issue for GuC log relay,
spotted that uc_fini_wq is not being called in failure path in gem_init.
Missed in the below commit. Add it.
v2: Removed GEM_BUG_ON(!HAS_GUC()) from intel_uc_fini_wq as init happens
only based on enable_guc module parameter and does not consider has_guc
capability. (Michal)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Fixes: 3176ff49bc3e ("drm/i915/guc: Move GuC workqueue allocations outside of the mutex") Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515588857-10283-1-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Tue, 9 Jan 2018 12:20:40 +0000 (14:20 +0200)]
drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masks
The power domain masks are 64 bit wide, so we need BIT_ULL() when
setting bits in them, these ones were missed during converting from 32
to 64 bit masks. All 3 enums are <32 atm, so this didn't cause a real
problem.
Fixes: d8fc70b7367b ("drm/i915: Make power domain masks 64 bit long") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180109122040.19425-1-imre.deak@intel.com
Stefan Brüns [Sun, 31 Dec 2017 22:34:54 +0000 (23:34 +0100)]
drm/i915: Try EDID bitbanging on HDMI after failed read
The ACK/NACK implementation as found in e.g. the G965 has the falling
clock edge and the release of the data line after the ACK for the received
byte happen at the same time.
This is conformant with the I2C specification, which allows a zero hold
time, see footnote [3]: "A device must internally provide a hold time of
at least 300 ns for the SDA signal (with respect to the V IH(min) of the
SCL signal) to bridge the undefined region of the falling edge of SCL."
Some HDMI-to-VGA converters apparently fail to adhere to this requirement
and latch SDA at the falling clock edge, so instead of an ACK
sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
transfer.
The bitbanging releases the data line for the ACK only 1/4 bit time after
the falling clock edge, so a slave will see the correct value no matter
if it samples at the rising or the falling clock edge or in the center.
Fallback to bitbanging is already done for the CRT connector.
Chris Wilson [Sat, 6 Jan 2018 10:56:18 +0000 (10:56 +0000)]
drm/i915: Don't adjust priority on an already signaled fence
When we retire a signaled fence, we free the dependency tree. However,
we skip clearing the list so that if we then try to adjust the priority
of the signaled fence, we may walk the list of freed dependencies.
[ 3083.156757] ==================================================================
[ 3083.156806] BUG: KASAN: use-after-free in execlists_schedule+0x199/0x660 [i915]
[ 3083.156810] Read of size 8 at addr ffff8806bf20f400 by task Xorg/831
[ 3083.158187] Memory state around the buggy address:
[ 3083.158190] ffff8806bf20f300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158192] ffff8806bf20f380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158195] >ffff8806bf20f400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158196] ^
[ 3083.158199] ffff8806bf20f480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158201] ffff8806bf20f500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 3083.158203] ==================================================================
Reported-by: Alexandru Chirvasitu <achirvasub@gmail.com> Reported-by: Mike Keehan <mike@keehan.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104436 Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its lifetime") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alexandru Chirvasitu <achirvasub@gmail.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Tested-by: Alexandru Chirvasitu <achirvasub@gmail.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180106105618.13532-1-chris@chris-wilson.co.uk
Kenneth Graunke [Fri, 5 Jan 2018 08:59:05 +0000 (00:59 -0800)]
drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
Geminilake requires the 3D driver to select whether barriers are
intended for compute shaders, or tessellation control shaders, by
whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
switching pipelines. Failure to do this properly can result in GPU
hangs.
Unfortunately, this means it needs to switch mid-batch, so only
userspace can properly set it. To facilitate this, the kernel needs
to whitelist the register.
The workarounds page currently tags this as applying to Broxton only,
but that doesn't make sense. The documentation for the register it
references says the bit userspace is supposed to toggle only exists on
Geminilake. Empirically, the Mesa patch to toggle this bit appears to
fix intermittent GPU hangs in tessellation control shader barrier tests
on Geminilake; we haven't seen those hangs on Broxton.
v2: Mention WA #0862 in the comment (it doesn't have a name).
Chris Wilson [Thu, 4 Jan 2018 16:38:42 +0000 (16:38 +0000)]
drm/i915: Pass DMA_ATTR_NO_WARN to dma_map_sg()
In some iommu, e.g. swiotlb, the available space can be quite limited.
So we employ a trial-and-error approach to seeing if our large
contiguous chunks can fit, and if that fails we try again with smaller
chunks after trying to free our own lazily allocated blobs. As we use a
trial-and-error approach, we do not want dma_map_sg() to emit a WARN of
its own accord, we want to gracefully report the error back to the caller
instead.
Note that our noisy culprit, swiotlb, doesn't honour the flag, yet.
drm/i915/guc : Decoupling ADS and logs from submission
The Additional Data Struct (ADS) contains objects that are required by
GuC post FW load and are not necessarily submission-only. Even with
submission disabled we may require something inside the ADS, so it
makes more sense for them to be always created.
Similarly, we need to access GuC logs and even if GuC submission
is disabled, to debug issues with GuC loading or with whatever we're using
GuC for.
v2: re-wording commit message (Sagar)
Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1514928025-29659-1-git-send-email-sujaritha.sundaresan@intel.com
After staring at the list_for_each_safe macros for a bit, our current
invocation of list_safe_reset_next in execlists_schedule() simply
reduces to list_for_each.
Chris Wilson [Tue, 2 Jan 2018 15:12:26 +0000 (15:12 +0000)]
drm/i915/execlists: Assert there are no simple cycles in the dependencies
The dependency chain must be an acyclic graph. This is checked by the
swfence, but for sanity, also do a simple check that we do not corrupt
our list iteration in execlists_schedule() by a shallow dependency
cycle.
Chris Wilson [Tue, 2 Jan 2018 15:12:31 +0000 (15:12 +0000)]
drm/i915: Hold rpm wakeref for modifying the global seqno
To modify the global seqno may require rewriting a few registers, which
requires us to hold the rpm wakeref. We must therefore take it around
the call to i915_gem_set_global_seqno() in debugfs, on behalf of the
user.
Chris Wilson [Tue, 2 Jan 2018 15:12:32 +0000 (15:12 +0000)]
drm/i915/execlists: Clear context-switch interrupt earlier in the reset
Move the clearing of the CS-interrupt into the engine reset phase,
before the current init-hw phase. This helps clarify that we clear the
pending interrupts prior to any restarting of the execlists.
i915_gem_request_assign() is not used since commit 77f0d0e925e8
("drm/i915/execlists: Pack the count into the low bits of the
port.request"), so remove the defunct code
References: 77f0d0e925e8 ("drm/i915/execlists: Pack the count into the low bits of the port.request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180102151235.3949-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 23 Dec 2017 11:04:07 +0000 (11:04 +0000)]
drm/i915/selftests: Allow random array allocation to fail
In the selftests, we don't want to force an oom and would rather
ENOMEM be reported. In this case, we would rather the allocation for the
random array to fail.
Chris Wilson [Sat, 23 Dec 2017 11:04:06 +0000 (11:04 +0000)]
drm/i915/selftests: Tweak igt_ggtt_page to speed it up
Reduce the number of GGTT PTE operations to speed the test up, but we
reduce the likelihood of spotting a coherency error in those operations.
However, Broxton is sporadically timing on this test, presumably because
its GGTT operations are all uncached.
C, Ramalingam [Tue, 7 Nov 2017 18:38:23 +0000 (00:08 +0530)]
drm/i915: Runtime disable for eDP DRRS
Debugfs called i915_drrs_ctl is added to enable and disable the
eDP DRRS. Writing 0 will disable the feature, whereas non-zero
will enable the feature.
Possibility of disabling the DRRS, enables the testing of the
frontbuffer tracking based features (FBC, DRRS and PSR) as
standalone or any combination of the set.
[v2]: ctl interface is moved from module parameter to debugfs [Rodrigo]
Hans de Goede [Wed, 20 Dec 2017 10:50:17 +0000 (11:50 +0100)]
drm/i915/vlv: Add cdclk workaround for DSI
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.
After looking at drm.debug output I noticed that initially we inherit the
cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 333333 KHz makes the problem go away.
I've tested this on various Bay Trail devices, to make sure this not does
cause regressions on other devices and the higher cdclk does not cause
any problems on the following devices:
-GP-electronic T701 1024x600 333333 KHz cdclk after this patch
-PEAQ C1010 1920x1200 333333 KHz cdclk after this patch
-PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch
-Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch
Also interesting wrt this is the comment in vlv_calc_cdclk about the
existing workaround to avoid 200 Mhz as clock because that causes issues
in some cases.
This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI
panel is active.
Changes in v2:
-Change the commit message and the code comment to not treat the GOP as
a reference, the GOP should not be treated as a reference
Lucas De Marchi [Mon, 4 Dec 2017 23:22:10 +0000 (15:22 -0800)]
drm/i915: Apply Display WA #1183 on skl, kbl, and cfl
Display WA #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
Chris Wilson [Fri, 22 Dec 2017 18:25:21 +0000 (18:25 +0000)]
drm/i915: Show HWSP in intel_engine_dump()
Looking at a CI failure with an ominous line of
[ 362.550715] hangcheck current seqno ffffff6b, last ffffff8c, hangcheck ffffff6b [6016 ms], inflight 118
with no apparent cause for the seqno to be negative, left me wondering
if someone had scribbled over the HWSP. So include the HWSP in the
engine dump to see if there are more signs of random scribbling.
v2: Fix row pointer, i is now incremented by 8 so doesn't need scaling
by 8, and we don't need to keep volatile here as the status_page isn't
marked up as volatile itself.
v3: Use hexdump, with suppression of identical lines. (Tvrtko)
Which results in
Chris Wilson [Fri, 22 Dec 2017 14:19:59 +0000 (14:19 +0000)]
drm/i915: Assert that the request is on the execution queue before being removed
We should only attempt to remove requests from the execution queue that
are on the execution queue. These are the requests that have been
assigned a global_seqno, so we can assert that we only attempt to remove
requests with a nonzero global_seqno. Afterwards we assert that we
remove them in order, i.e. the global_seqno matches the engine's seqno,
but that leaves a small loophole for an unattached request on an unused
engine.
We can then make the same assertion on queuing the request to the
execution engine, it must have a zero global_seqno or else we are queuing
the same request twice.
Chris Wilson [Fri, 22 Dec 2017 13:27:42 +0000 (13:27 +0000)]
drm/i915/execlists: Show preemption progress in GEM_TRACE
We already emit a GEM_TRACE for when we start preemption, but we lack
one to show when the preemption is completed and we return to the regular
queue. This is to continue the investigation into the mysterious
Ville Syrjälä [Mon, 13 Nov 2017 13:36:22 +0000 (15:36 +0200)]
drm/i915: Put all non-blocking modesets onto an ordered wq
We have plenty of global registers and whatnot programmed without
any further locking by the modeset code. Currently non-bocking
modesets are allowed to execute in parallel which could corrupt
said registers.
To avoid the problem let's run all non-blocking modesets on an
ordered workqueue. We still put page flips etc. to system_unbound_wq
allowing page flips on one pipe to execute in parallel with page flips
or a modeset on a another pipe (assuming no known state is shared
between them, at which point they would have been added to the same
atomic commit and serialized that way).
Blocking modesets are already serialized with each other by
connection_mutex, and thus are safe. To serialize them with
non-blocking modesets we just flush the workqueue before executing
blocking modesets.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 94f050246b42 ("drm/i915: nonblocking commit") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113133622.8593-1-ville.syrjala@linux.intel.com Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
projects / mirror_ubuntu-jammy-kernel.git / log