Make the logic in intel_detect_pch() easier to follow, and make the PCH
id to type mapping reusable. No functional changes.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3bd4ffcd284cdbd4e8dc77ab02d97ded422e0c21.1517851783.git.jani.nikula@intel.com

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=105073Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180213120940.21579-1-chris@chris-wilson.co.uk

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205172131.20255-1-paulo.r.zanoni@intel.com

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-6-paulo.r.zanoni@intel.com

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com

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: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206193346.18272-1-paulo.r.zanoni@intel.com

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: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com

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: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209130755.11893-1-david.weinehall@linux.intel.com

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: 4dd504f7 ("drm/i915: Use memset64() to prefill the GTT page")
Signed-off-by: NChris 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: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212133118.16443-1-chris@chris-wilson.co.uk

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=103337Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174102.10240-1-imre.deak@intel.com

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212102415.24246-1-chris@chris-wilson.co.uk

If the entire device is powered off, we can safely assume that the
engine is also asleep (and idle).
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: a091d4ee ("drm/i915: Hold a wakeref for probing the ring registers")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212093928.6005-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209114056.9957-1-chris@chris-wilson.co.uk

Instead of INTEL_GEN != x use !IS_GENx for more optimisation
opportunities.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-16-tvrtko.ursulin@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209215847.6660-2-chris@chris-wilson.co.uk

Coccinelle patch:

 @@
 identifier p;
 @@
 -INTEL_INFO(p)->gen
 +INTEL_GEN(p)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-12-tvrtko.ursulin@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209215847.6660-1-chris@chris-wilson.co.uk

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207164841.19431-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Check that userspace isn't passing in garbage in the colorkey
ioctl flags.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206204333.4399-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

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: NChris 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=103337Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208112331.12986-1-imre.deak@intel.com

Since commit 4a118ecb ("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: 4a118ecb ("drm/i915: Filter out spurious execlists context-switch interrupts")
Signed-off-by: NChris 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: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208151224.16285-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208163939.27030-1-chris@chris-wilson.co.uk

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: NChris 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: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171209222133.31880-1-chris@chris-wilson.co.uk

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: NChris 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.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

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: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208114224.27271-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

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: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208113917.8439-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208105449.29880-2-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

drivers/gpu/drm/i915/i915_drv.c:891: warning: No description found for parameter 'ent'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208105449.29880-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

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: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111559.32663-1-chris@chris-wilson.co.uk

drivers/gpu/drm/i915/i915_gem_request.c:941: warning: No description found for parameter 'write'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111453.32567-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111328.32422-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111220.32293-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208111105.32149-1-chris@chris-wilson.co.uk

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: NChris 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.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

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: NChris 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.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

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: 36703e79 ("drm/i915: Break modeset deadlocks on reset")
Signed-off-by: NChris 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: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207151350.20883-1-chris@chris-wilson.co.uk

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: NAntonio Argenziano <antonio.argenziano@intel.com>
Fixes: ac14fbd4 ("drm/i915/scheduler: Support user-defined priorities")
Signed-off-by: NChris 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.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

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: 7b92c1bd ("drm/i915: Avoid keeping waitboost active for signaling threads")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206143137.15509-1-chris@chris-wilson.co.uk

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: 95690a02 ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208102403.5587-2-chris@chris-wilson.co.uk

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: 4407eaa9 ("drm/i915/perf: add support for Coffeelake GT3")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208102403.5587-1-chris@chris-wilson.co.uk

Since commit 5896a5c8 (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: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207212440.13438-1-daniele.ceraolospurio@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>