Jani Nikula [Mon, 5 Feb 2018 17:31:38 +0000 (19:31 +0200)]
drm/i915: have virtual PCH detection return a PCH id
Simplify intel_virt_detect_pch() by making it return a PCH id rather
than returning the PCH type and setting PCH id for some PCHs. Map the
PCH id to PCH type using the shared routine. This gives us sanity check
on the supported combinations also in the virtualized setting.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/197cf635261a1c628371ffaaee90e8647493af4d.1517851783.git.jani.nikula@intel.com
Jani Nikula [Mon, 5 Feb 2018 17:31:37 +0000 (19:31 +0200)]
drm/i915: abstract virtual PCH id detection
Make the code slightly more pleasant to look at. No functional changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/38ee1ac06c6724e888679eb287af36c221bd399b.1517851783.git.jani.nikula@intel.com
Jani Nikula [Mon, 5 Feb 2018 17:31:36 +0000 (19:31 +0200)]
drm/i915: abstract PCH type detection from PCH id
Make the logic in intel_detect_pch() easier to follow, and make the PCH
id to type mapping reusable. No functional changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3bd4ffcd284cdbd4e8dc77ab02d97ded422e0c21.1517851783.git.jani.nikula@intel.com
Chris Wilson [Tue, 13 Feb 2018 12:09:40 +0000 (12:09 +0000)]
drm/i915/selftests: Report setup errors for igt_partial_tiling
igt_partial_tiling managed to fail with an -EBUSY. This usually means a
pin leak, but that should be impossible given the test setup. Add a
couple of error messages to help identify the path that failed.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105073
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180213120940.21579-1-chris@chris-wilson.co.uk
Mahesh Kumar [Mon, 5 Feb 2018 17:21:31 +0000 (15:21 -0200)]
drm/i915/icl: program mbus during pipe enable
This patch program default values of MBus credit during pipe enable.
Changes Since V1:
- Add WARN_ON (Paulo)
- Remove TODO comment
- Program 0 during pipe disable
- Rebase
Changes since V2:
- We don't need to do anything when disabling the pipe
Changes since V3 (from Paulo):
- Remove WARN() that we'll never be able to trigger (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205172131.20255-1-paulo.r.zanoni@intel.com
Mahesh Kumar [Mon, 5 Feb 2018 15:40:45 +0000 (13:40 -0200)]
drm/i915/icl: initialize MBus during display init
This patch initializes MBus during display initialization.
Changes since V2 (from Paulo):
- Don't forget to remove the WARN_ON(1) call.
Changes since V1:
- Rebase to use function like Macros
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-6-paulo.r.zanoni@intel.com
Mahesh Kumar [Mon, 5 Feb 2018 15:40:44 +0000 (13:40 -0200)]
drm/i915/icl: Enable both DBuf slices during init
ICL has 2 slices of DBuf, enable both the slices during display init.
Ideally we should only enable the second slice when needed in order to
save power, but while we're not there yet, adopt the simpler solution
to keep us bug-free.
v2 (from Paulo):
- Add the TODO comment.
- Reorganize where things are defined.
- Fix indentation.
- Remove unnecessary POSTING_READ() calls.
- Improve the commit message.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 5 Feb 2018 15:40:43 +0000 (13:40 -0200)]
drm/i915/icl: implement the display init/uninit sequences
This code is similar enough to the CNL code that I considered just
adding ICL support to the CNL function, but I think it's still
different enough, and having a function specific to ICL allows us to
more easily adapt code in case the spec changes more later.
We're still missing the power wells and the mbus code, so leave those
pieces with a FIXME comment while they're not here yet.
v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits.
v3: Use _MMIO_PORT() (Ville).
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v2)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com
Paulo Zanoni [Tue, 6 Feb 2018 19:33:46 +0000 (17:33 -0200)]
drm/i915/icl: add the main CDCLK functions
This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.
v2:
- Implement the voltage levels.
- Rebase.
v3:
- Adjust to the new "bypass" clock (Imre).
- Call intel_dump_cdclk_state() too.
- Rename a variable to avoid confusion.
- Simplify the DVFS part.
v4:
- Remove wrong bit definition (James).
- Also drive-by fix the coding style for the register definition we
touched.
v5:
- Comment style (checkpatch).
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206193346.18272-1-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 5 Feb 2018 15:40:41 +0000 (13:40 -0200)]
drm/i915/icl: add ICL support to cnl_set_procmon_ref_values
On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.
Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing port A. This way, we'll be able to easily reuse
the function on ICL when we add icl_display_core_init().
v2: Don't use _PICK() when you can use a ternary operator.
v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
Add an extra comment about why we're passing PORT_A (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com
David Weinehall [Fri, 9 Feb 2018 13:07:55 +0000 (15:07 +0200)]
drm/i915: Fix incorrect comment
While the comment singles out Port A or B, the code says Port A or *D*.
Looking at the history it seems that the comment was added after the code,
so it seems likely that the code is correct, not the comment.
CC: Jani Nikula <jani.nikula@intel.com>
CC: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209130755.11893-1-david.weinehall@linux.intel.com
Chris Wilson [Mon, 12 Feb 2018 13:31:18 +0000 (13:31 +0000)]
drm/i915: Replace open-coded memset_p()
When initialising the page directories, we set the GTT entries and the
tree to the scratch page. We have already replaced the DMA fill with
memset64(), but we can similarly use memset_p() to set the pointer array.
References:
4dd504f7d98a ("drm/i915: Use memset64() to prefill the GTT page")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212133118.16443-1-chris@chris-wilson.co.uk
Imre Deak [Thu, 8 Feb 2018 17:41:02 +0000 (19:41 +0200)]
drm/i915: Don't query PCODE RC6VIDS on platforms not supporting it
On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
platforms. Do it only on SNB, IVB and HSW, where we use this command
anyway for RC6 enabling.
Based on my tests the command also succeeds on all LLC platforms, but
it's not clear if it's really supported on those (it returns 0 aka 245mv
for all RC6 states everywhere except on SNB). BSpec lists the command as
supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
incorrect, since on SKL/KBL the same command ID is used for
SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
command list is also incorrect for those platforms (see
P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
I filed a request to update that info in Bspec, but for now let's
assume a minimal set of platforms where the command is supported.
References: https://bugs.freedesktop.org/show_bug.cgi?id=103337
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174102.10240-1-imre.deak@intel.com
Chris Wilson [Mon, 12 Feb 2018 10:24:15 +0000 (10:24 +0000)]
drm/i915: Hold rpm wakeref for printing the engine's register state
When dumping the engine, we print out the current register values. This
requires the rpm wakeref. If the device is alseep, we can assume the
engine is asleep (and the register state is uninteresting) so skip and
only acquire the rpm wakeref if the device is already awake.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212102415.24246-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 12 Feb 2018 09:39:28 +0000 (09:39 +0000)]
drm/i915: Don't wake the device up to check if the engine is asleep
If the entire device is powered off, we can safely assume that the
engine is also asleep (and idle).
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: a091d4ee931b ("drm/i915: Hold a wakeref for probing the ring registers")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212093928.6005-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 9 Feb 2018 11:40:56 +0000 (11:40 +0000)]
drm/i915: Move the final intel_gpu_reset() to after declaring wedged
If we fail to reset the GPU (i915_reset()), we do one final
intel_gpu_reset() attempt as we mark the device wedged. The idea here is
even though the GPU has proven unreliable (and so we want to stop using
it for the time being), we don't want it spinning away in the background
whilst the driver idles so we try to reset it one more time. However, we
want to dump the i915_gem_set_wedged() debugging info before we do, so
that we can see the accurate state of the GPU when it failed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209114056.9957-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 9 Feb 2018 21:58:47 +0000 (21:58 +0000)]
drm/i915: Replace some negative Gen checks
Instead of INTEL_GEN != x use !IS_GENx for more optimisation
opportunities.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-16-tvrtko.ursulin@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/20180209215847.6660-2-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 9 Feb 2018 21:58:46 +0000 (21:58 +0000)]
drm/i915: Use INTEL_GEN everywhere
Coccinelle patch:
@@
identifier p;
@@
-INTEL_INFO(p)->gen
+INTEL_GEN(p)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-12-tvrtko.ursulin@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/20180209215847.6660-1-chris@chris-wilson.co.uk
Ville Syrjälä [Wed, 7 Feb 2018 16:48:41 +0000 (18:48 +0200)]
drm/i915: Give all ioctl functions an _ioctl suffix
Most of our ioctl functions have an _ioctl suffix in the name. I like
that idea since it makes it easy to figure out how the function is
going to get called. Rename the handful of exceptions to follow the
same pattern.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207164841.19431-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ville Syrjälä [Tue, 6 Feb 2018 20:43:33 +0000 (22:43 +0200)]
drm/i915: Reject undefined colorkey flags
Check that userspace isn't passing in garbage in the colorkey
ioctl flags.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206204333.4399-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Thu, 8 Feb 2018 11:23:31 +0000 (13:23 +0200)]
drm/i915/snb+: Remove incorrect forcewake check in debugfs/i915_drpc_info
FORCEWAKE_ACK is depricated by BSpec at least starting from BDW,
referring to the multi-threaded version of it instead. Accessing
FORCEWAKE_ACK triggers an unclaimed register access error - at
least on GLK - see the Reference: below.
The correct registers to use would be FORCEWAKE_MT_ACK on IVB+ and
FORCEWAKE_ACK_RENDER_GEN9 on SKL+ like it's done elsewhere in the
driver.
The forcewake check itself is inconsistent and redundant, since there
could be other forcewake requesters besides the kernel (being the
multithreaded version of the register) and the kernel's per-domain
forcewake counters are shown anyway at the end of the file. So let's
just remove the check.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103337
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208112331.12986-1-imre.deak@intel.com
Chris Wilson [Thu, 8 Feb 2018 15:12:24 +0000 (15:12 +0000)]
drm/i915: Remove redundant check on execlists interrupt
Since commit
4a118ecbe99c ("drm/i915: Filter out spurious execlists
context-switch interrupts") we probe execlists->active, and no longer
have to peek at the execlist interrupt to determine if the tasklet still
needs to be run to drain the ELSP.
References:
4a118ecbe99c ("drm/i915: Filter out spurious execlists context-switch interrupts")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208151224.16285-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 16:39:39 +0000 (16:39 +0000)]
drm/i915/crt: Silence compiler warning for uninitialised status
clang is confused by our if-else-chain that abruptly exits before a
final else:
drivers/gpu/drm/i915/intel_crt.c:821:11: warning: variable 'status' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
else if (ret < 0)
^~~~~~~
drivers/gpu/drm/i915/intel_crt.c:826:9: note: uninitialized use occurs here
return status;
^~~~~~
drivers/gpu/drm/i915/intel_crt.c:821:7: note: remove the 'if' if its condition is always true
else if (ret < 0)
^~~~~~~~~~~~
drivers/gpu/drm/i915/intel_crt.c:761:12: note: initialize the variable 'status' to silence this warning
int status, ret;
In this case, we can reduce the final else-if clause to an unconditional
else.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20180208163939.27030-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 9 Dec 2017 22:21:33 +0000 (22:21 +0000)]
drm/i915: Avoid leaking lpe audio platdev.data
The struct platform_device memdups the provided data pointer requiring
us to free the template we construct during lpe_audio_platdev_create():
unreferenced object 0xffff88026eafe400 (size 512):
comm "insmod", pid 6850, jiffies
4295060179 (age 22.300s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
000000008e4a834c>] intel_audio_init+0x9/0x30 [i915]
[<
000000001360e195>] i915_driver_load+0x802/0x14e0 [i915]
[<
00000000ab3f0e99>] i915_pci_probe+0x29/0x70 [i915]
[<
0000000016330ee5>] pci_device_probe+0x9c/0x120
[<
000000000257d054>] driver_probe_device+0x307/0x470
[<
000000009f0a6cb6>] __driver_attach+0x98/0xe0
[<
0000000031b46e58>] bus_for_each_dev+0x57/0x80
[<
000000000e28239d>] bus_add_driver+0x1bd/0x260
[<
00000000abbe5161>] driver_register+0x52/0xc0
[<
000000005c6e23d4>] do_one_initcall+0x36/0x150
[<
00000000a55002f4>] do_init_module+0x56/0x1d7
[<
00000000e48f2217>] load_module+0x23c8/0x2910
[<
000000002b60bf61>] SyS_finit_module+0xb8/0xd0
[<
0000000041cbad96>] entry_SYSCALL_64_fastpath+0x17/0x70
[<
000000009f1d37ab>] 0xffffffffffffffff
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171209222133.31880-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 16:16:39 +0000 (16:16 +0000)]
drm/i915: Disable unused-but-set compiler warning
The unused-but-set warning enabled by W=1 catches out a lot of the
atomic helper iterator macros and drown us in their noise (or trip over
Werror and die). Path of least resistance is to ignore the warning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208161639.27511-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Chris Wilson [Thu, 8 Feb 2018 11:42:24 +0000 (11:42 +0000)]
drm/i915: Fix kerneldoc warnings for i915_gem_internal
drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found for parameter 'i915'
drivers/gpu/drm/i915/i915_gem_internal.c:183: warning: No description found for parameter 'size'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208114224.27271-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 8 Feb 2018 11:39:17 +0000 (11:39 +0000)]
drm/i915: Fix kerneldoc warnings in i915_gem_execbuffer
drivers/gpu/drm/i915/i915_gem_execbuffer.c:1983: warning: No description found for parameter 'dev_priv'
drivers/gpu/drm/i915/i915_gem_execbuffer.c:1983: warning: No description found for parameter 'file'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208113917.8439-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 10:54:49 +0000 (10:54 +0000)]
drm/i915: Fix kerneldoc parameter markup
drivers/gpu/drm/i915/i915_syncmap.c:92: warning: No description found for parameter 'root'
drivers/gpu/drm/i915/i915_syncmap.c:155: warning: No description found for parameter 'root'
drivers/gpu/drm/i915/i915_syncmap.c:155: warning: No description found for parameter 'id'
drivers/gpu/drm/i915/i915_syncmap.c:155: warning: No description found for parameter 'seqno'
drivers/gpu/drm/i915/i915_syncmap.c:354: warning: No description found for parameter 'root'
drivers/gpu/drm/i915/i915_syncmap.c:354: warning: No description found for parameter 'id'
drivers/gpu/drm/i915/i915_syncmap.c:354: warning: No description found for parameter 'seqno'
drivers/gpu/drm/i915/i915_syncmap.c:396: warning: No description found for parameter 'root'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208105449.29880-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 8 Feb 2018 10:54:48 +0000 (10:54 +0000)]
drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
drivers/gpu/drm/i915/i915_drv.c:891: warning: No description found for parameter 'ent'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208105449.29880-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 8 Feb 2018 11:15:59 +0000 (11:15 +0000)]
drm/i915: Remove lost comment from i915_gem_context
The comment is very old and quite misleading now.
drivers/gpu/drm/i915/i915_gem_context.c:349: warning: No description found for parameter 'dev_priv'
drivers/gpu/drm/i915/i915_gem_context.c:349: warning: No description found for parameter 'file_priv'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111559.32663-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 11:14:53 +0000 (11:14 +0000)]
drm/i915: Fix kerneldoc warnings for i915_gem_request
drivers/gpu/drm/i915/i915_gem_request.c:941: warning: No description found for parameter 'write'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111453.32567-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 11:13:28 +0000 (11:13 +0000)]
drm/i915: Fix kerneldoc warnings for i915_gem_userptr
drivers/gpu/drm/i915/i915_gem_userptr.c:761: warning: No description found for parameter 'dev'
drivers/gpu/drm/i915/i915_gem_userptr.c:761: warning: No description found for parameter 'data'
drivers/gpu/drm/i915/i915_gem_userptr.c:761: warning: No description found for parameter 'file'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111328.32422-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 11:12:20 +0000 (11:12 +0000)]
drm/i915: Fix kerneldoc warnings for intel_ringbuffer
drivers/gpu/drm/i915/intel_ringbuffer.c:179: warning: No description found for parameter 'req'
drivers/gpu/drm/i915/intel_ringbuffer.c:741: warning: No description found for parameter 'req'
drivers/gpu/drm/i915/intel_ringbuffer.c:741: warning: No description found for parameter 'cs'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111220.32293-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 11:11:05 +0000 (11:11 +0000)]
drm/i915: Fix kerneldoc warnings for i915_gpu_error
drivers/gpu/drm/i915/i915_gpu_error.c:1815: warning: No description found for parameter 'dev_priv'
drivers/gpu/drm/i915/i915_gpu_error.c:1815: warning: No description found for parameter 'engine_mask'
drivers/gpu/drm/i915/i915_gpu_error.c:1815: warning: No description found for parameter 'error_msg'
drivers/gpu/drm/i915/i915_gpu_error.c:1815: warning: Excess function parameter 'dev' description in 'i915_capture_error_state'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111105.32149-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 7 Feb 2018 22:28:24 +0000 (22:28 +0000)]
drm/i915: Wait for gen3 reset status to be asserted
After we assert the reset request (and wait for 20us), when the device
has been fully reset it asserts the reset-status bit. Before we stop
requesting the reset and allow the device to return to normal, we should
wait for the reset to be completed. (Similar to how we wait for the
device to return to normal after deasserting the reset request.)
v2: Rename i915_reset_completed() probe to not cause as much confusion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207222824.29864-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Thu, 8 Feb 2018 07:28:00 +0000 (07:28 +0000)]
drm/i915: Be paranoid and post the writes to stop the rings
Although the mmio are uncached and so should be flushed on every write,
be paranoid and do a mmio read after setting the ring head/tail to be
sure they have taken effect before moving on.
v2: post tail to be pleasing to the eye
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208072800.595-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Wed, 7 Feb 2018 15:13:50 +0000 (15:13 +0000)]
drm/i915: Mark the device as wedged from the beginning of set-wedged
Reduce the window of opportunity for set-wedged being called
concurrently with reset (after i915_reset() has performed the
i915_gem_unset_wedged()) by moving the set_bit(I915_WEDGED) to before we
complete the inflight requests. When i915_reset() is being blocked on a
request, such completion may allow it to start and beginning resetting
the GPU before i915_gem_set_wedged() has finished (and so before
set-wedge will have marked the device as wedged). As such,
i915_gem_init_hw() may see a wedged device even from inside
i915_reset().
References:
36703e79a982 ("drm/i915: Break modeset deadlocks on reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207151350.20883-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 08:51:51 +0000 (08:51 +0000)]
drm/i915: Avoid truncation before clamping userspace's priority value
Userspace provides a 64b value for the priority, we need to be careful
to preserve the full range before validation to prevent truncation (and
letting an illegal value pass).
Reported-by: Antonio Argenziano <antonio.argenziano@intel.com>
Fixes: ac14fbd460d0 ("drm/i915/scheduler: Support user-defined priorities")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208085151.11480-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 6 Feb 2018 14:31:37 +0000 (14:31 +0000)]
drm/i915: Remove superfluous worker wakeups when RPS is already boosted
We only need to wake up the RPS worker once when initially enabling the
client boost, it remains in effect then until the last client no longer
requires the boost.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102250
References:
7b92c1bd0540 ("drm/i915: Avoid keeping waitboost active for signaling threads")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206143137.15509-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 10:24:03 +0000 (10:24 +0000)]
drm/i915/perf: Fix compiler warning for string truncation
drivers/gpu/drm/i915/i915_oa_cnl.c: In function ‘i915_perf_load_test_config_cnl’:
drivers/gpu/drm/i915/i915_oa_cnl.c:99:2: error: ‘strncpy’ output truncated before terminating nul copying 36 bytes from a string of the same length [-Werror=stringop-truncation]
v2: strlcpy
Fixes: 95690a02fb5d ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208102403.5587-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 8 Feb 2018 10:24:02 +0000 (10:24 +0000)]
drm/i915/perf: Fix compiler warning for string truncation
drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function ‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated before terminating nul copying 36 bytes from a string of the same length [-Werror=stringop-truncation]
v2: strlcpy
Fixes: 4407eaa9b0cc ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208102403.5587-1-chris@chris-wilson.co.uk
Daniele Ceraolo Spurio [Wed, 7 Feb 2018 21:24:40 +0000 (13:24 -0800)]
drm/i915: do not stop engines on sanitize if i915.reset=0
Since commit
5896a5c8c9c0 (drm/i915: Always stop the rings before a
missing GPU reset) we attempt to stop the engines during gem_sanitize
even if reset=0 and nothing bad happened on the gpu.
The specs says that the STOP_RINGS bit needs to be cleared to resume
normal operation, but for some reason the value of the bit seems to be
changing without us writing to it (maybe rc6 entry/exit?), so normal
operation resumes correctly. However, it still feels incorrect to stop
the engines if there hasn't been any issue so skip the whole reset
call in gem_sanitize if i915.reset=0
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207212440.13438-1-daniele.ceraolospurio@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Wed, 7 Feb 2018 21:05:44 +0000 (21:05 +0000)]
drm/i915: Only allocate preempt context when required
If we remove some hardcoded assumptions about the preempt context having
a fixed id, reserved from use by normal user contexts, we may only
allocate the i915_gem_context when required. Then the subsequent
decisions on using preemption reduce to having the preempt context
available.
v2: Include an assert that we don't allocate the preempt context twice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-3-chris@chris-wilson.co.uk
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Chris Wilson [Wed, 7 Feb 2018 21:05:43 +0000 (21:05 +0000)]
drm/i915: Move the scheduler feature bits into the purview of the engines
Rather than having the high level ioctl interface guess the underlying
implementation details, having the implementation declare what
capabilities it exports. We define an intel_driver_caps, similar to the
intel_device_info, which instead of trying to describe the HW gives
details on what the driver itself supports. This is then populated by
the engine backend for the new scheduler capability field for use
elsewhere.
v2: Use caps.scheduler for validating CONTEXT_PARAM_SET_PRIORITY (Mika)
One less assumption of engine[RCS] \o/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-2-chris@chris-wilson.co.uk
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Chris Wilson [Wed, 7 Feb 2018 21:05:42 +0000 (21:05 +0000)]
drm/i915/guc: Allow preempt-client to be NULL
In the next patch, we may only conditionally allocate the preempt-client
if there is a global preempt context and so we need to be prepared in
case the preempt-client itself is NULL.
v2: Grep for more preempt_client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207210544.26351-1-chris@chris-wilson.co.uk
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Chris Wilson [Wed, 7 Feb 2018 16:04:28 +0000 (16:04 +0000)]
drm/i915/pmu: Fix building without CONFIG_PM
As we peek inside struct device to query members guarded by CONFIG_PM,
so must be the code.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
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/20180207160428.17015-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Tue, 6 Feb 2018 18:33:11 +0000 (18:33 +0000)]
drm/i915/pmu: Fix sleep under atomic in RC6 readout
We are not allowed to call intel_runtime_pm_get from the PMU counter read
callback since the former can sleep, and the latter is running under IRQ
context.
To workaround this, we record the last known RC6 and while runtime
suspended estimate its increase by querying the runtime PM core
timestamps.
Downside of this approach is that we can temporarily lose a chunk of RC6
time, from the last PMU read-out to runtime suspend entry, but that will
eventually catch up, once device comes back online and in the presence of
PMU queries.
Also, we have to be careful not to overshoot the RC6 estimate, so once
resumed after a period of approximation, we only update the counter once
it catches up. With the observation that RC6 is increasing while the
device is suspended, this should not pose a problem and can only cause
slight inaccuracies due clock base differences.
v2: Simplify by estimating on top of PM core counters. (Imre)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
Testcase: igt/perf_pmu/rc6-runtime-pm
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@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: David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206183311.17924-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Wed, 7 Feb 2018 11:15:45 +0000 (11:15 +0000)]
drm/i915: Tidy up some error messages around reset failure
On blb and pnv, we are seeing sporadic
i915 0000:00:02.0: Resetting chip after gpu hang
[drm:intel_gpu_reset [i915]] rcs0: timed out on STOP_RING
[drm:i915_reset [i915]] *ERROR* Failed hw init on reset -5
which notably lack the actual root cause of the error. Ostensibly it
should be the init_ring_common() that failed, but it's error paths are
covered by DRM_ERROR.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207111545.17078-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 7 Feb 2018 08:43:49 +0000 (08:43 +0000)]
drm/i915: Trim the retired request queue after submitting
If we submit a request and see that the previous request on this
timeline was already signaled, we first do not need to add the
dependency tracker for that completed request and secondly we know that
we there is then a large backlog in retiring requests affecting this
timeline. Given that we just submitted more work to the HW, now would be
a good time to catch up on those retirements.
v2: Try to sum up the compromises involved in flushing the retirement
queue after submission.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207084350.3929-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 7 Feb 2018 08:43:50 +0000 (08:43 +0000)]
drm/i915: Skip request serialisation if the timeline is already complete
If the last request on the timeline is already complete, we do not need
to emit the serialisation barriers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207084350.3929-2-chris@chris-wilson.co.uk
Maarten Lankhorst [Mon, 5 Feb 2018 10:58:41 +0000 (11:58 +0100)]
drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2.
According to bspec, result_lines > 31 is only a maximum for latency
level 1 through 7.
For level 0 the number of lines is ignored, so always write 0 there
to prevent overflowing the 5 bits value.
This is required to make NV12 work.
Changes since v1:
- Rebase on top of GEN11 wm changes. It seems to use res_lines for
level 0 limit calculations, but still doesn't appear to program it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20180205105841.31634-1-maarten.lankhorst@linux.intel.com
Chris Wilson [Tue, 6 Feb 2018 09:46:33 +0000 (09:46 +0000)]
drm/i915/breadcrumbs: Ignore unsubmitted signalers
When a request is preempted, it is unsubmitted from the HW queue and
removed from the active list of breadcrumbs. In the process, this
however triggers the signaler and it may see the clear rbtree with the
old, and still valid, seqno, or it may match the cleared seqno with the
now zero rq->global_seqno. This confuses the signaler into action and
signaling the fence.
Fixes: d6a2289d9d6b ("drm/i915: Remove the preempted request from the execution queue")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.12+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206094633.30181-1-chris@chris-wilson.co.uk
Joonas Lahtinen [Wed, 7 Feb 2018 07:26:04 +0000 (09:26 +0200)]
drm/i915: Update DRIVER_DATE to
20180207
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Tvrtko Ursulin [Mon, 5 Feb 2018 09:34:48 +0000 (09:34 +0000)]
drm/i915/pmu: Fix PMU enable vs execlists tasklet race
Commit
99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
inside for busy-stats") added a tasklet_disable call in busy stats
enabling, but we failed to understand that the PMU enable callback runs
as an hard IRQ (IPI).
Consequence of this is that the PMU enable callback can interrupt the
execlists tasklet, and will then deadlock when it calls
intel_engine_stats_enable->tasklet_disable.
To fix this, I realized it is possible to move the engine stats enablement
and disablement to PMU event init and destroy hooks. This allows for much
simpler implementation since those hooks run in normal context (can
sleep).
v2: Extract engine_event_destroy. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking inside for busy-stats")
Testcase: igt/perf_pmu/enable-race-*
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@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: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205093448.13877-1-tvrtko.ursulin@linux.intel.com
Rafael Antognolli [Mon, 5 Feb 2018 23:33:30 +0000 (15:33 -0800)]
drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern
This workaround should prevent a bug that can be hit on a context
restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall
(0x7a000004 0x00100000 0x00000000 0x00000000) followed by 12DW's of
NOOP(0x0) in the indirect context batch buffer, to ensure the engine is
idle prior to programming 3DSTATE_SAMPLE_PATTERN.
It's also not clear whether we should add those extra dwords because of
the workaround itself, or if that's just padding for the WA BB (and next
commands could come right after the PIPE_CONTROL). We keep them for now.
References: HSD#
1939868
v2: More descriptive changelog and comments.
v3: Explain that PIPE_CONTROL is actually 6 dwords, and that we advance
10 more dwords because of that.
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-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/20180205233330.14973-1-rafael.antognolli@intel.com
Michal Srb [Mon, 5 Feb 2018 16:04:38 +0000 (16:04 +0000)]
drm/i915/cmdparser: Do not check past the cmd length.
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.
If the offset ends up outside of the command length, reject the command.
Fixes: 351e3db2b363 ("drm/i915: Implement command buffer parsing logic")
Signed-off-by: Michal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.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/20180205160438.3267-2-chris@chris-wilson.co.uk
Michal Srb [Mon, 5 Feb 2018 16:04:37 +0000 (16:04 +0000)]
drm/i915/cmdparser: Check reg_table_count before derefencing.
The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.
In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as MI_STORE_REGISTER_MEM. When trying to check
such command, the find_reg would dereference NULL pointer.
Now it will just return NULL meaning that the register was not found and the
command will be rejected.
Fixes: 76ff480ec963 ("drm/i915/cmdparser: Use binary search for faster register lookup")
Signed-off-by: Michal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@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/20180205160438.3267-1-chris@chris-wilson.co.uk
register lookup")
Ville Syrjälä [Fri, 2 Feb 2018 20:42:31 +0000 (22:42 +0200)]
drm/i915: Deprecate I915_SET_COLORKEY_NONE
Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
way to disable colorkey is to just set flags to 0, which is
exactly what the intel ddx has been doing all along.
Currently when userspace sets the flags to 0, we end up in a
funny state where colorkey is disabled, but various colorkey
vs. scaling checks still consider colorkey to be enabled, and
thus we don't allow plane scaling to kick in.
In case there is some other userspace out there that actually
uses this flag (unlikely as this is an i915 specific uapi)
we'll keep on accepting it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202204231.27905-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Mon, 5 Feb 2018 15:24:31 +0000 (15:24 +0000)]
drm/i915: Skip post-reset request emission if the engine is not idle
Since commit
7b6da818d86f ("drm/i915: Restore the kernel context after a
GPU reset on an idle engine") we submit a request following the engine
reset. The intent is that we don't submit a request if the engine is
busy (as it will restart active by itself) but we only checked to see if
there were remaining requests in flight on the hardware and skipped
checking to see if there were any ready requests that would be
immediately submitted on restart (the same time as our new request would
be). Having convinced the engine to appear idle in the previous patch,
we can use intel_engine_is_idle() as a better test to only submit a new
request if there are no pending requests.
As it happens, this is tripping up igt/drv_selftest/live_hangcheck in CI
as we overfill the kernel_context ringbuffer trigger an infinite
recursion from within the reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104786
References:
7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-4-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 15:24:30 +0000 (15:24 +0000)]
drm/i915/execlists: Move the reset bits to a more natural home
In preparation for the next patch, we want the engine to appear idle
after a reset (if there are no requests in flight). For execlists, this
entails clearing the active status on reset, it will be regenerated on
restarting the engine after the reset. In the process, note that a
couple of other status flags and checks could be moved into the
describing function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 15:24:29 +0000 (15:24 +0000)]
drm/i915/selftests: Use a sacrificial context for hang testing
Avoid injecting hangs in to the i915->kernel_context in case the GPU
reset leaves corruption in the context image in its wake (leading to
continual failures and system hangs after the selftests are ostensibly
complete). Use a sacrificial kernel_context instead.
v2: Closing a context is tricky; export a function (for selftests) from
i915_gem_context.c to get it right.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 15:24:28 +0000 (15:24 +0000)]
drm/i915/selftests: Flush old resets between engines
When injecting rapid resets, we must be careful to at least wait for the
previous reset to have taken effect and the engine restarted. If we
perform a second reset before that has happened, we will notice that the
engine hasn't recovered and declare it lost, wedging the device and
failing. In practice, since we wait for each hanging batch to start
before injecting the reset, this too-fast-reset condition can only be
triggered when moving onto the next engine in the test, so we need only
wait for the existing reset to complete before switching engines.
v2: Wrap up the wait inside a safety net to bail out in case of angry hw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205152431.12163-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 3 Feb 2018 10:19:14 +0000 (10:19 +0000)]
drm/i915/breadcrumbs: Drop request reference for the signaler thread
If we remember to cancel the signaler on a request when retiring it
(after we know that the request has been signaled), we do not need to
carry an additional request in the signaler itself. This prevents an
issue whereby the signaler threads may be delayed and hold on to
thousands of request references, causing severe memory fragmentation and
premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
and frequent use of inter-engine fences).
v2: Rename first_signal(), document reads outside of locks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203101914.24880-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Mon, 5 Feb 2018 09:22:01 +0000 (09:22 +0000)]
drm/i915: Remove unbannable context spam from reset
During testing, we trigger a lot of resets on an unbannable context
leading to massive amounts of irrelevant debug spam. Remove the
ban_score accounting and message for the unbannable context so that we
improve the signal:noise in the log messages for when the unexpected
occurs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-7-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 09:22:00 +0000 (09:22 +0000)]
drm/i915/execlists: Remove the startup spam
Execlists is now enabled by default and included in the list of
capabilities printed out to dmesg and beyond. We do not need to mention
it again, every time we restart the engine, so kill the spam.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-6-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 09:21:59 +0000 (09:21 +0000)]
drm/i915: Show the GPU state when declaring wedged
Dump each engine state when i915_gem_set_wedged() is called to give us
some more clues as to why we had to terminate the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-5-chris@chris-wilson.co.uk
Chris Wilson [Thu, 25 Jan 2018 22:41:22 +0000 (22:41 +0000)]
drm/i915: Always update the no_fbc_reason when disabling
Provide the reason why we call intel_fbc_deactivate() so that debugging
issues with FBC being delayed is clearer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125224122.27480-1-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 5 Feb 2018 10:06:18 +0000 (10:06 +0000)]
drm/i915: Add some newlines to intel_engine_dump() headers
The headers should be on a separate line for consistency, so add the
missing trailing newline in a few intel_engine_dump() callers.
Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205100618.11001-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 5 Feb 2018 09:41:39 +0000 (09:41 +0000)]
drm/i915: Report if an unbannable context is involved in a GPU hang
Since unbannable contexts are special and supposed not to be causing GPU
hangs in the first place, make it clear when they are implicated in said
hang. In practice, most unbannable contexts are those created by igt
for the express purpose of throwing untold thousands of hangs at the GPU
and wish to keep doing so to finish the test. Normally they are cleaned
up, but it's when they or the other unbannable kernel contexts stay
stuck in an erroneous state that we need to worry and so need
highlighting.
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205094139.10671-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Fri, 2 Feb 2018 15:34:48 +0000 (15:34 +0000)]
drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
As we ourselves cancel interrupts during reset by clearing the GTIIR, it
is possible for the master IIR to indicate a pending IRQ for which we
have already cleared from the GTIIR. In this case, the DRM_ERROR are
intended and should not be flagged as an error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202153448.23908-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 2 Feb 2018 14:54:55 +0000 (14:54 +0000)]
drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
Be paranoid and flush the GTIIR after clearing the CS interrupt to be
sure it has taken before we re-enable the interrupt handler. We still
see early interrupts following reset, the tasklet handling the mmio read
before it has been written by the CS. This hopefully reduces the
frequency to 0...
References: https://bugs.freedesktop.org/show_bug.cgi?id=104262
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202145455.29876-1-chris@chris-wilson.co.uk
Jani Nikula [Fri, 2 Feb 2018 13:04:16 +0000 (15:04 +0200)]
drm/i915: reduce indent in pch detection
Save some horizontal space.
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202130416.18233-1-jani.nikula@intel.com
Michal Wajdeczko [Thu, 1 Feb 2018 17:32:48 +0000 (17:32 +0000)]
drm/i915: Enable inject_load_failure only in DEBUG config
We're using i915_inject_load_failure() to inject dummy
faults during driver load, but since this is debug utility
we shouldn't expose it in default config as it consumes
both code and data.
add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302)
Function old new delta
__i915_inject_load_failure 61 - -61
i915_gem_init 1331 1268 -63
i915_driver_load 5923 5745 -178
Total: Before=
1177454, After=
1177152, chg -0.03%
add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-4 (-4)
Data old new delta
i915_load_fail_count 4 - -4
Total: Before=56762, After=56758, chg -0.01%
add/remove: 4/8 grow/shrink: 0/1 up/down: 245/-591 (-346)
RO Data old new delta
__param_str_inject_load_failure 20 - -20
__UNIQUE_ID_inject_load_failuretype200 34 - -34
__param_inject_load_failure 40 - -40
__func__ 4998 4896 -102
__UNIQUE_ID_inject_load_failure201 150 - -150
Total: Before=119095, After=118749, chg -0.29%
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180201173248.3912-1-michal.wajdeczko@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Jani Nikula [Thu, 1 Feb 2018 11:03:43 +0000 (13:03 +0200)]
drm/i915/dp: limit DP link rate based on VBT on CNL+
We have the max DP link rate info available in VBT since BDB version
216, included in child device config since commit
c4fb60b9aba9
("drm/i915/bios: add DP max link rate to VBT child device
struct"). Parse it and use it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a8b1364d1f2394fba3062b6ad11b474744ea4366.1517482774.git.jani.nikula@intel.com
Jani Nikula [Thu, 1 Feb 2018 11:03:42 +0000 (13:03 +0200)]
drm/i915/dp: clean up source rate limiting for cnl
Make the limiting rate based instead of messing with the array size.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cb03b9419191a7d6359bf371aacb2d3725c746de.1517482774.git.jani.nikula@intel.com
Jani Nikula [Thu, 1 Feb 2018 11:03:41 +0000 (13:03 +0200)]
drm/i915/dp: abstract rate array length limiting
This will be useful later on. Also move the functions around to not need
forward declarations in subsequent patches. No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/40f37f08cad33234cd86337d39e823ac6e55805f.1517482774.git.jani.nikula@intel.com
Imre Deak [Tue, 30 Jan 2018 14:29:39 +0000 (16:29 +0200)]
drm/i915/bxt, glk: Avoid long atomic poll during CDCLK change
There is no requirement for doing the PCODE request polling atomically,
so do that only for a short time switching to sleeping poll afterwards.
The specification requires a 150usec timeout for the change notification,
so let's use that for the atomic poll. Do the extra 2ms poll - needed as
a workaround on BXT/GLK - in sleeping mode.
v2:
- rebase on v2 of patchset dropping the sandybridge_pcode_read/write
refactoring (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-2-imre.deak@intel.com
Imre Deak [Tue, 30 Jan 2018 14:29:38 +0000 (16:29 +0200)]
drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.
Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)
This issue is similar to
commit
2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.
v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.4+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
Michal Wajdeczko [Wed, 31 Jan 2018 17:32:39 +0000 (17:32 +0000)]
drm/i915/guc: Don't try to create log runtime if there is no log
In case of GuC initialization failure we may continue with driver
load, but we wrongly assume that GuC is fully functional. This
leads to the BUG as we attempt to access non-existing log vma.
[26386.121085] BUG: unable to handle kernel NULL pointer dereference at
00000000000000a0
[26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915]
[26386.121763] Call Trace:
[26386.121870] guc_log_late_setup+0xfd/0x140 [i915]
[26386.121969] i915_driver_load+0x7ab/0x1730 [i915]
[26386.122069] i915_pci_probe+0x2d/0x90 [i915]
[26386.122089] pci_device_probe+0x9c/0x120
[26386.122107] driver_probe_device+0x2a9/0x490
[26386.122126] __driver_attach+0xd9/0xe0
[26386.122143] ? driver_probe_device+0x490/0x490
[26386.122158] bus_for_each_dev+0x57/0x90
[26386.122175] bus_add_driver+0x1eb/0x260
[26386.122190] ? 0xffffffffa069a000
[26386.122206] driver_register+0x52/0xc0
[26386.122220] ? 0xffffffffa069a000
[26386.122234] do_one_initcall+0x39/0x170
[26386.122252] ? kmem_cache_alloc_trace+0x1fd/0x2e0
[26386.122273] do_init_module+0x56/0x1ec
[26386.122289] load_module+0x219e/0x2550
[26386.122309] ? vfs_read+0x121/0x140
[26386.122331] ? SyS_finit_module+0xa5/0xe0
[26386.122346] SyS_finit_module+0xa5/0xe0
[26386.122371] entry_SYSCALL_64_fastpath+0x22/0x8f
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-4-michal.wajdeczko@intel.com
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Michal Wajdeczko [Wed, 31 Jan 2018 17:32:37 +0000 (17:32 +0000)]
drm/i915/guc: Don't forget to free GuC error log
We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called.
If we free this log object as part of the late uC cleanup, where
we also release other firmware objects, we can avoid this BUG:
[70841.001413] BUG drm_i915_gem_object (Tainted: G U W ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown()
[70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100
[70841.001466] Call Trace:
[70841.001471] dump_stack+0x5e/0x8e
[70841.001476] slab_err+0x99/0xb0
[70841.001483] ? __slab_alloc.isra.24.constprop.29+0x62/0x70
[70841.001491] ? __kmalloc+0x1f5/0x320
[70841.001497] __kmem_cache_shutdown+0x18b/0x400
[70841.001505] shutdown_cache+0x13/0x1c0
[70841.001511] kmem_cache_destroy+0x1c2/0x240
[70841.001517] ? __mutex_unlock_slowpath+0x38/0x270
[70841.001559] i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.001595] i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.001630] i915_driver_load+0x708/0x1720 [i915]
[70841.001638] ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.001673] i915_pci_probe+0x2d/0x90 [i915]
[70841.001680] pci_device_probe+0x9c/0x120
[70841.001687] driver_probe_device+0x2a9/0x490
[70841.001694] __driver_attach+0xd9/0xe0
[70841.001700] ? driver_probe_device+0x490/0x490
[70841.001705] bus_for_each_dev+0x57/0x90
[70841.001712] bus_add_driver+0x1eb/0x260
[70841.001717] ? 0xffffffffa0685000
[70841.001723] driver_register+0x52/0xc0
[70841.001728] ? 0xffffffffa0685000
[70841.001733] do_one_initcall+0x39/0x170
[70841.001739] ? rcu_read_lock_sched_held+0x6f/0x80
[70841.001746] ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.001753] do_init_module+0x56/0x1ec
[70841.001759] load_module+0x219e/0x2550
[70841.001766] ? vfs_read+0x121/0x140
[70841.001774] ? SyS_finit_module+0xa5/0xe0
[70841.001779] SyS_finit_module+0xa5/0xe0
[70841.001788] entry_SYSCALL_64_fastpath+0x22/0x8f
[70841.001806] INFO: Object 0x00000000eab7ed96 @offset=6208
[70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708
[70841.001861] kmem_cache_alloc+0x23d/0x2d0
[70841.001897] i915_gem_object_create.part.32+0x1f/0x260 [i915]
[70841.001937] intel_guc_allocate_vma+0x15/0x100 [i915]
[70841.001977] intel_guc_log_create+0x34/0x1c0 [i915]
[70841.002014] intel_guc_init+0x5a/0x100 [i915]
[70841.002051] intel_uc_init+0x3e/0xb0 [i915]
[70841.002089] i915_gem_init+0x18e/0x540 [i915]
[70841.002123] i915_driver_load+0xa7a/0x1720 [i915]
[70841.002159] i915_pci_probe+0x2d/0x90 [i915]
[70841.002165] pci_device_probe+0x9c/0x120
[70841.002171] driver_probe_device+0x2a9/0x490
[70841.002177] __driver_attach+0xd9/0xe0
[70841.002182] bus_for_each_dev+0x57/0x90
[70841.002188] bus_add_driver+0x1eb/0x260
[70841.002193] driver_register+0x52/0xc0
[70841.002198] do_one_initcall+0x39/0x170
[70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects
[70841.002491] Call Trace:
[70841.002497] dump_stack+0x5e/0x8e
[70841.002503] kmem_cache_destroy+0x1e0/0x240
[70841.002509] ? __mutex_unlock_slowpath+0x38/0x270
[70841.002551] i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.002586] i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.002621] i915_driver_load+0x708/0x1720 [i915]
[70841.002629] ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.002664] i915_pci_probe+0x2d/0x90 [i915]
[70841.002671] pci_device_probe+0x9c/0x120
[70841.002678] driver_probe_device+0x2a9/0x490
[70841.002684] __driver_attach+0xd9/0xe0
[70841.002690] ? driver_probe_device+0x490/0x490
[70841.002696] bus_for_each_dev+0x57/0x90
[70841.002702] bus_add_driver+0x1eb/0x260
[70841.002708] ? 0xffffffffa0685000
[70841.002713] driver_register+0x52/0xc0
[70841.002719] ? 0xffffffffa0685000
[70841.002724] do_one_initcall+0x39/0x170
[70841.002731] ? rcu_read_lock_sched_held+0x6f/0x80
[70841.002737] ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.002745] do_init_module+0x56/0x1ec
[70841.002751] load_module+0x219e/0x2550
[70841.002758] ? vfs_read+0x121/0x140
[70841.002766] ? SyS_finit_module+0xa5/0xe0
[70841.002772] SyS_finit_module+0xa5/0xe0
[70841.002781] entry_SYSCALL_64_fastpath+0x22/0x8f
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-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>
Matthew Auld [Wed, 31 Jan 2018 21:44:40 +0000 (21:44 +0000)]
drm/i915/selftests: add missing gtt shrinker test
Try to catch a bug we've seen in the wild where the shrinker purges the
pd/pdp from under us while allocating our paging structures.
References: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.auld@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/20180131214440.7141-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 31 Jan 2018 21:44:39 +0000 (21:44 +0000)]
drm/i915/ppgtt: Pin page directories before allocation
Commit
e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
believed that because it did not insert its freshly allocated page
directory into the pd tree, it was safe from the shrinker. I failed to
heed the lesson learnt from commit
dd19674bacba ("drm/i915: Remove bitmap
tracking for used-ptes") that we need to pin all the levels in the tree
before hitting the shrinker or else the shrinker may free an upper layer
as we proceed to allocate the tree. Thus leaving dangling pointers
everywhere and a GPF should we hit direct reclaim at just the wrong
moment.
CPU: 0 PID: 7374 Comm: chromium Tainted: P O 4.14.13-1-ARCH #1
Hardware name: Apple Inc. MacBookPro12,1/Mac-
E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.
1706181928 06/18/2017
task:
ffff994f696c2c40 task.stack:
ffffb1a789d4c000
RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
RSP: 0018:
ffffb1a789d4f940 EFLAGS:
00010206
RAX:
81c1788cc4f68138 RBX:
ffff994f54db8000 RCX:
ffff994f696c2c40
RDX:
000000023bc73003 RSI:
ffff994d598b6b80 RDI:
ffff994f54db8000
RBP:
ffff994d598b6b80 R08:
0000000000000000 R09:
0000000000000000
R10:
ffffb1a789d4f550 R11:
ffff994eaf3c3208 R12:
0000000000000027
R13:
0000000000005000 R14:
0000000004e8f000 R15:
ffff994f54dba000
FS:
00007f585886aa00(0000) GS:
ffff994faec00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000004ac8e8 CR3:
00000002552c8004 CR4:
00000000003606f0
Call Trace:
gen8_ppgtt_alloc_pdp+0x178/0x320 [i915]
gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915]
ppgtt_bind_vma+0x30/0x70 [i915]
i915_vma_bind+0x68/0xd0 [i915]
__i915_vma_do_pin+0x2d6/0x3a0 [i915]
eb_lookup_vmas+0x7a2/0xb50 [i915]
i915_gem_do_execbuffer+0x4d7/0x10e0 [i915]
? sock_wfree+0x34/0x60
? unix_stream_read_generic+0x1f9/0x7e0
? import_iovec+0x37/0xd0
? i915_gem_execbuffer2+0x5d/0x390 [i915]
i915_gem_execbuffer2+0x1b7/0x390 [i915]
? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
drm_ioctl_kernel+0x59/0xb0 [drm]
drm_ioctl+0x2d5/0x370 [drm]
? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
? __seccomp_filter+0x3b/0x260
do_vfs_ioctl+0xa1/0x610
? syscall_trace_enter+0xdb/0x2b0
SyS_ioctl+0x74/0x80
do_syscall_64+0x55/0x110
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f584fa82d27
RSP: 002b:
00007ffee14a7828 EFLAGS:
00000246 ORIG_RAX:
0000000000000010
RAX:
ffffffffffffffda RBX:
000003b0126a1030 RCX:
00007f584fa82d27
RDX:
00007ffee14a7870 RSI:
0000000040406469 RDI:
0000000000000080
RBP:
00007ffee14a7870 R08:
0000000000000002 R09:
0000000000000077
R10:
00007f5839f2b780 R11:
0000000000000246 R12:
0000000040406469
R13:
0000000000000080 R14:
00007f5842b00040 R15:
0000000000000000
Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3
RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP:
ffffb1a789d4f940
Reported-by: Eric Blau <eblau@eblau.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
References:
dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes")
Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Paulo Zanoni [Tue, 30 Jan 2018 13:49:18 +0000 (11:49 -0200)]
drm/i915/icl: allow the reg_read ioctl to read the RCS TIMESTAMP register
This enables the Mesa driver to advertise support for ARB_timer_query,
and thus an OpenGL version higher than 3.2.
Based on the CNL patch by Nanley Chery.
v2: Rebase.
Cc: Anuj Phogat <anuj.phogat@intel.com>
Cc: Nanley Chery <nanley.g.chery@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Requested-by: Anuj Phogat <anuj.phogat@intel.com>
Tested-by: Anuj Phogat <anuj.phogat@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-10-paulo.r.zanoni@intel.com
Kelvin Gardiner [Tue, 30 Jan 2018 13:49:17 +0000 (11:49 -0200)]
drm/i915/icl: Set graphics mode register for gen11
This patch clears a single bit. The bit is 0 by default but expected
not to be set. Explicitly clearing the bit in this patch is intended
to indicate some thinking has occurred, and that we want this bit
cleared and we are not just excepting the default value.
We also stop setting GFX_RUN_LIST_ENABLE, which is correct since that
bit is gone.
v2 (from Paulo): fix indentation.
v3: Changed GEN check to >= 11. Corrected author name.
v4 (from Paulo): improve commit message (Daniele).
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Kelvin Gardiner <kelvin.gardiner@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-9-paulo.r.zanoni@intel.com
James Ausmus [Tue, 30 Jan 2018 13:49:16 +0000 (11:49 -0200)]
drm/i915/icl: Handle expanded PLANE_CTL_FORMAT field
ICL+ adds changes the PLANE_CTL_FORMAT field from [27:24] to [27:23],
however, all existing PLANE_CTL_FORMAT_* definitions still map to the
correct values. Add an ICL_PLANE_CTL_FORMAT_MASK definition, and use
that for masking for the conversion to fourcc.
v2: No changes
v3: Change new definition name, drop comment (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-8-paulo.r.zanoni@intel.com
Paulo Zanoni [Tue, 30 Jan 2018 13:49:15 +0000 (11:49 -0200)]
drm/i915/gen11: fix the SAGV block time for gen11
It's 10us for gen 11.
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-7-paulo.r.zanoni@intel.com
Mahesh Kumar [Tue, 30 Jan 2018 13:49:14 +0000 (11:49 -0200)]
drm/i915/icl: Introduce MBus related registers
This patch introduce MBus control registers and their bit-fields
MBUS_ABOX_CTL
MBUS_BBOX_CTL
MBUS_DBOX_CTL
MBUS_UBOX_CTL
Changes Since V1:
- Use function like macros (Paulo)
- fix copy-paste error (Paulo)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-6-paulo.r.zanoni@intel.com
Mahesh Kumar [Tue, 30 Jan 2018 13:49:13 +0000 (11:49 -0200)]
drm/i915/icl: NV12 y-plane ddb is not in same plane
We don't have planar pixel format support implemented for ICL yet.
ICL require 2 display planes to be allocated for Planar formats unlike
previous GEN. So ICL/GEN11 doesn't require to write Y-plane ddb data in
NV12_BUF_CFG register and PLANE_NV12_BUF_CFG register is removed in ICL.
This patch removes the PLANE_NV12_BUF_CFG write for ICL.
Changes Since V1:
- Improve commit message as per Paulo's comment
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-5-paulo.r.zanoni@intel.com
Mahesh Kumar [Tue, 30 Jan 2018 13:49:12 +0000 (11:49 -0200)]
drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed
ICL require DDB allocation of plane to be more than "minimum display
buffer needed" for each level in order to enable WM level.
This patch implements and consider the same while allocating DDB
and enabling WM.
Changes Since V1:
- rebase
Changes Since V2:
- Remove extra parentheses
- Use FP16.16 only when absolutely necessary (Paulo)
Changes Since V3:
- Rebase
Changes since v4 (from Paulo):
- Coding style issue.
Changes since v5 (from Paulo):
- Do the final checks according to BSpec.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-4-paulo.r.zanoni@intel.com
Mahesh Kumar [Tue, 30 Jan 2018 13:49:11 +0000 (11:49 -0200)]
drm/i915/icl: Do not fix dbuf block size to 512
GEN9/10 had fixed DBuf block size of 512. Dbuf block size is not a
fixed number anymore in GEN11, it varies according to bits per pixel
and tiling. If 8bpp & Yf-tile surface, block size = 256 else block
size = 512
This patch addresses the same.
v2 (from Paulo):
- Make it compile.
- Fix a few coding style issues.
v3:
- Rebase on top of upstream patches
v4 (from Paulo):
- Bikeshed if statements (James).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-3-paulo.r.zanoni@intel.com
Mahesh Kumar [Tue, 30 Jan 2018 13:49:10 +0000 (11:49 -0200)]
drm/i915/icl: Don't allocate fixed bypass path blocks for ICL
GEN9 onwards bypass path allocation of 4 blocks was needed, as per
hardware design. ICL doesn't require bypass path allocation of 4 DDB
blocks, handling the same in this patch.
v2 (from Paulo):
- No need for a comment that says what the code already says.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-2-paulo.r.zanoni@intel.com
Chris Wilson [Tue, 30 Jan 2018 16:44:57 +0000 (16:44 +0000)]
drm/i915: Flush ggtt writes through the old fenced vma before changing fences
This is a precautionary measure as I have no evidence to suggest we've
hit a bug here (I was hoping this might explain gdg's odd behaviour, but
alas), but given that we have a function to flush the ggtt writes it
seems prudent to use it prior to changing the fence register. Due to the
intrinsic nature of the GTT often operating as an independent mmio path,
we should not just rely on the write to the fence acting as a full flush
for GTT writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130164457.14037-1-chris@chris-wilson.co.uk
Sagar Arun Kamble [Wed, 31 Jan 2018 06:14:37 +0000 (11:44 +0530)]
drm/i915/guc: Fix return from guc_log_relay_file_create
guc_log_relay_file_create will return -EEXIST if we invoke
relay_late_setup_files multiple times as part of i915_guc_log_control.
However this is to be not cosidered as fail and need to return 0.
This was mistakenly introduced in the below commit. Fix it.
Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex"
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1517379279-12967-1-git-send-email-sagar.a.kamble@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Mon, 29 Jan 2018 14:41:04 +0000 (14:41 +0000)]
drm/i915: Always run hangcheck while the GPU is busy
Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit
4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.
If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. We just have to remember to be careful that
we do not declare a GPU hang when idly waiting for the next request to
be come ready, as we will run hangcheck continuously even when the
engines are stalled waiting for external events. This should be true
already as we should only be tracking requests submitted to hardware for
execution as an indicator that the engine is busy.
Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104840
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129144104.3921-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:23 +0000 (15:22 -0800)]
drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
On CNL SKUs that uses port F, max DP rate is 8.1G for all
ports when we have the elevated voltage (higher than 0.85V).
v2: Make commit message more generic.
v3: Move conditions to a helper to get easier to read. (Ville).
v4: Add a mention to the numerical voltage on commit
message per Manasi request.
v5: Thanks CI! "error: control reaches end of non-void function"
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-10-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:22 +0000 (15:22 -0800)]
drm/i915/cnl: Enable DDI-F on Cannonlake.
Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.
v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)
v9: Squash in the PORT_F case for enabling DP MST encoder. (DK)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:21 +0000 (15:22 -0800)]
drm/i915/cnl: Add HPD support for Port F.
On CNP boards that are using DDI F,
bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
the Digital Port F hotplug line when the Digital
Port F hotplug detect input is enabled.
v2: Reuse all existent structure instead of adding a
new HPD_PORT_F pointing to pin of port E.
v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
this right now. If that SKU ever get a proper name
we come back and update it.
v4: Rebase on top of digital connected port using encoder
instead of port.
v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-8-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:20 +0000 (15:22 -0800)]
drm/i915: For HPD connected port use hpd_pin instead of port.
Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.
But for now this is only a re-org with no functional change
expected.
v2: Add missing lines and nuke @port reference from code
documentation. (Ville)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-7-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:19 +0000 (15:22 -0800)]
drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
On CNP Pin 3 is for misc of Port F usage depending on the
configuration. For CNL that uses Port F, pin 3 is the one.
v2: Make it more generic and update commit message.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-6-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:18 +0000 (15:22 -0800)]
drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
Since when it got introduced with commit '
555e38d27317
("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
was wrong, because Port F bits are far from bits used
for A to E.
Since Port F is not used so far we don't need to propagate
Fixes back there.
v2: Reuse _SHIFT definition to avoid complicated duplication (DK).
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-5-rodrigo.vivi@intel.com
projects / openwrt / staging / blogic.git / log