Tiger Lake supports HDMI on port A. For other platforms we ignore what
the VBT says regarding HDMI to workaround broken VBTs, see
commit 2ba7d7e0 ("drm/i915/bios: ignore HDMI on port A"). Make this
apply gen12+ so they inherit the TGL behavior.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com

This register was being enabled after enable TRANS_DDI_FUNC_CTL and
PIPECONF/TRANS_CONF while BSpec states that it should be set when
enabling TRANS_DDI_FUNC_CTL.

BSpec: 49190
BSpec: 22243
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-3-jose.souza@intel.com

Adding pipe D support to DSI transcoder.
Not adding it for EDP transcoder code paths as only TGL has 4 pipes
and it do not have a EDP transcoder.
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-2-jose.souza@intel.com

TRANS_DDI_MST_TRANSPORT_SELECT is 2 bits wide not 3, it was taking
one bit from EDP/DSI Input Select.

Fixes: b3545e08 ("drm/i915/tgl: add support to one DP-MST stream")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-1-jose.souza@intel.com

When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we vbt->vbt_size makes sense and use that for
the latter checks.

v2: check for vbt_size after checking for vbt signature and give it a
more meaningful error message (from Jani)
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-3-lucas.demarchi@intel.com

oprom is actually a better name to use when using
pci_map_rom(). "bios"  is way too generic and confusing.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-2-lucas.demarchi@intel.com

Still the saga of the hsw live_blt incoherency continues. While it did
seem that the invalidate before the breadcrumb had improved the mtbf,
nevertheless live_blt still failed. Mika's next idea was to pull the
invalidate-stall into the breadcrumb write itself.

References: 860afa08 ("drm/i915/gt: Flush gen7 even harder")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113151956.32242-1-chris@chris-wilson.co.uk

The bspec was just updated with a minor correction to entry 61 (it
shouldn't have had the SCF bit set).

v2:
 - Add a MOCS_ENTRY_UNUSED() and use it to declare the
   explicitly-reserved MOCS entries. (Lucas)
 - Move the warning suppression from the Makefile to a #pragma that only
   affects the TGL table. (Lucas)

v3:
 - Entries 16 and 17 are identical to ICL now, so no need to explicitly
   adjust them (or mess with compiler warning overrides).

Bspec: 45101
Fixes: 2ddf9921 ("drm/i915/tgl: Define MOCS entries for Tigerlake")
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112224757.25116-2-matthew.d.roper@intel.comReviewed-by: NFrancisco Jerez <currojerez@riseup.net>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NTomasz Lis <tomasz.lis@intel.com>

This reverts commit f4071997.

These extra EHL entries won't behave as expected without a bit more work
on the kernel side so let's drop them until that kernel work has had a
chance to land.  Userspace trying to use these new entries won't get the
advantage of the new functionality these entries are meant to provide,
but at least it won't misbehave.

When we do add these back in the future, we'll probably want to
explicitly use separate tables for ICL and EHL so that userspace
software that mistakenly uses these entries (which are undefined on ICL)
sees the same behavior it sees with all the other undefined entries.

Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <stable@vger.kernel.org> # v5.3+
Fixes: f4071997 ("drm/i915/ehl: Update MOCS table for EHL")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112224757.25116-1-matthew.d.roper@intel.comReviewed-by: NFrancisco Jerez <currojerez@riseup.net>

According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
belongs to a CMP-V chipset. Based on the same docs the programming of
the PCH is compatible with that of KBP. Fix up my previous wrong
assumption accordingly using the SPT programming which in turn is the
basis for KBP.

The original bug reporter verified that this is the correct PCH
identification (the only way we'll program valid DDC pin-pair values to
the GMBUS register) and the Windows team uses the same identification
(that is using the KBP programming model for this PCH).

I filed the necessary Bspec update requests (BSpec/33734).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
Fixes: 37c92dc3 ("drm/i915: Add new CNL PCH ID seen on a CML platform")
Reported-and-tested-by: NCyrus <cyrus.lien@canonical.com>
Cc: Cyrus <cyrus.lien@canonical.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112104608.24587-1-imre.deak@intel.com

The warning should be just a warning. Where it is currently is wrong
since we already registered the connector on drm, meaning it dies later
on a NULL pointer deref if the VBT-overriding we have is removed. Move
the warning up.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108214251.79305-1-lucas.demarchi@intel.com

live_blt is still failing on hsw, showing the hallmark of incoherency.
Since we are fairly certain that the interrupt is after the seqno is
visible, the other possibility is that the seqno is before the writes to
memory are flushed. Throw in an TLB invalidate before the breadcrumb as
we are reasonably confident that forces a CS stall.

References: f9228f76 ("drm/i915/gt: Try an extra flush on the Haswell blitter")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112160941.23969-1-chris@chris-wilson.co.uk

drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() error: uninitialized symbol 'file'.

Fixes: 34485832 ("drm/i915/selftests: Exercise parallel blit operations on a single ctx")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112163643.3527-1-chris@chris-wilson.co.uk

Adding all the register definitions needed
for mipi dsi command mode.
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111111029.9126-2-vandita.kulkarni@intel.com

Throw in a flush_work() to specifically flush the context cleanup work
before the module is unloaded.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
Fixes: a4e7ccda ("drm/i915: Move context management under GEM")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112150051.1603-1-chris@chris-wilson.co.uk

Using the array is getting clumsy. Make things a bit more dynamic.

Remove early returns on not having child devices when the end result
after "iterating" the empty list would be the same.

v3:
- use list_add_tail to not reverse the child device list (Ville)

v2:
- stick to previous naming of child devices (Ville)
- use kzalloc, handle failure
- initialize list head earlier to keep intel_bios_driver_remove() safe

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e72da0b412354ed8be6719df55b0e0cc4caa61a.1573227240.git.jani.nikula@intel.com

The pre-initialized magic value is a bit silly, switch to a flag
instead.

v2: Reduce paranoia to a single sanity check (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74fe24ab6d5f0ea2ff2059cdf044d6d3006080fc.1573227240.git.jani.nikula@intel.com

On gen7, including Haswell, the MI_FLUSH_DW command is not synchronous
with the command streamer nor is there an option to make it so. To hide
this we add a large delay on the CS so that the breadcrumb should always
be visible before the interrupt. However, that does not seem to be
enough to ensure the memory is actually coherent with the read of the
breadcrumb. The breadcrumb update is a post-sync op... Throw in a
preliminary MI_FLUSH_DW before the breadcrumb update in the hope that
helps.

References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111120957.17732-1-chris@chris-wilson.co.uk

Since we removed the pm hookup from the GT, the hook in
drm_i915_private.gem is unused. Remove it.

References: 18f3b272 ("drm/i915: Remove pm park/unpark notifications")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112113434.31088-1-chris@chris-wilson.co.uk

As the memory regions are setup early, we can rely on its existence as
we takeover the HW settings from BIOS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111182143.23479-2-chris@chris-wilson.co.uk

Pass around the intended intel_uncore for mmio access during stolen
setup, and avoid relying on the implicit magic I915_READ() macros.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111182143.23479-1-chris@chris-wilson.co.uk

Some basic information that is useful to know, such as how many cycles
is a MI_NOOP.

v2: Keep volatile pages pinned at all times! (Matthew)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Anna Karas <anna.karas@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111172716.23733-1-chris@chris-wilson.co.uk

The gem_ctx_persistence/smoketest was detecting an odd coherency issue
inside the LRC context image; that the address of the ring buffer did
not match our associated struct intel_ring. As we set the address into
the context image when we pin the ring buffer into place before the
context is active, that leaves the question of where did it get
overwritten. Either the HW context save occurred after our pin which
would imply that our idle barriers are broken, or we overwrote the
context image ourselves. It is only in reset_active() where we dabble
inside the context image outside of a serialised path from schedule-out;
but we could equally perform the operation inside schedule-in which is
then fully serialised with the context pin -- and remains serialised by
the engine pulse with kill_context(). (The only downside, aside from
doing more work inside the engine->active.lock, was the plan to merge
all the reset paths into doing their context scrubbing on schedule-out
needs more thought.)

Fixes: d12acee8 ("drm/i915/execlists: Cancel banned contexts on schedule-out")
Testcase: igt/gem_ctx_persistence/smoketest
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk

Enable gup to retry and fault the pages outside of the mmap_sem lock in
our worker. As we are inside our worker, outside of any critical path,
we can allow the mmap_sem lock to be dropped in order to service a page
fault; this in turn allows the mm to populate the page using a slow
fault handler.

References: 5b56d49f ("mm: add locked parameter to get_user_pages_remote()")
Testcase: igt/gem_userptr/userfault
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-2-chris@chris-wilson.co.uk

set_page_dirty says:

	For pages with a mapping this should be done under the page lock
	for the benefit of asynchronous memory errors who prefer a
	consistent dirty state. This rule can be broken in some special
	cases, but should be better not to.

Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).

However, following a try_to_unmap() we may want to remove the userptr and
so call put_pages(). However, try_to_unmap() acquires the page lock and
so we must avoid recursively locking the pages ourselves -- which means
that we cannot safely acquire the lock around set_page_dirty(). Since we
can't be sure of the lock, we have to risk skip dirtying the page, or
else risk calling set_page_dirty() without a lock and so risk fs
corruption.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012
Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
References: cb6d7c7d ("drm/i915/userptr: Acquire the page lock around set_page_dirty()")
References: 505a8ec7 ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"")
References: 6dcc693b ("ext4: warn when page is dirtied without buffers")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk

The setting of MSA is done by the DDI .pre_enable() hook. And when we are
using MST, the MSA is only set to first mst stream by calling of
DDI .pre_eanble() hook. It raies issues to non-first mst streams.
Wrong MSA or missed MSA packets might show scrambled screen or wrong
screen.

This splits a setting of MSA to MST and SST cases. And In the MST case it
will call a setting of MSA after an allocating of Virtual Channel from
MST encoder pre_enable callback.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA")
Fixes: d4a415dc ("drm/i915: Fix MST oops due to MSA changes")
Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
[vsyrjala: nuke spurious newline]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Having been forced to reduce Braswell back to using the aliasing ppgtt,
the coherency issue we previously observed cannot impact us. Reduce the
performance penalty imposed on all platforms from using the mfence to a
mere sfence.

References: cf66b8a0 ("drm/i915/execlists: Apply a full mb before execution for Braswell")
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>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191110185806.17413-10-chris@chris-wilson.co.uk

As the ftrace buffer is single shot, once dumped it will not update. As
such, it only provides information for the first bug and all subsequent
bugs are noise. The goal of CI is to have zero bugs, so taint the kernel
causing CI to reboot the machine; fix the bug and move on.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191110185806.17413-13-chris@chris-wilson.co.uk

To test mmap_offset_exhaustion, we first have to fill the entire vma
manager leaving a single page. Don't assume that the vma manager is not
already fragment, and fill all the holes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111122706.28292-2-chris@chris-wilson.co.uk

Make sure that our code is robust enough to handle multiple threads
trying to clear objects for a single client context. This brings the joy
of a shared GGTT to all!

References: https://bugs.freedesktop.org/show_bug.cgi?id=112176Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111122706.28292-1-chris@chris-wilson.co.uk

We report "frequencies" (actual-frequency, requested-frequency) as the
number of accumulated cycles so that the average frequency over that
period may be determined by the user. This means the units we report to
the user are Mcycles (or just M), not MHz.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191109105356.5273-1-chris@chris-wilson.co.uk

If we detect a hang in a closed context, just flush all of its requests
and cancel any remaining execution along the context. Note that after
closing the context, the last reference to the context may be dropped,
leaving it only valid under RCU.
Signed-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/20191111114323.5833-5-chris@chris-wilson.co.uk

We mention that we are resetting the GPU, and dump the device state for
post mortem debugging. However, while that dump contains the active
processes and the one flagged as causing the error, we do not always
include that information in dmesg. Include the name of the guilty
process in dmesg for reference.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-4-chris@chris-wilson.co.uk

Update the context.name on closing so that the persistent requests are
clear in debug prints.
Signed-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/20191111114323.5833-3-chris@chris-wilson.co.uk

Use a small char buffer inside the i915_gem_context to store the user
friendly name so that ctx->name has the same lifetime as the RCU
protected GEM context. That is, e.g. when using print_request() that
prints the timeline name (ctx->name), the name will not be prematurely
freed upon the context being closed and the last reference dropped.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-2-chris@chris-wilson.co.uk

Inside print_request(), we query the context/timeline name. Nothing
immediately protects the context from being freed if the request is
complete -- we rely on serialisation by the caller to keep the name
valid until they finish using it. Inside intel_engine_dump(), we
generally only print the requests in the execution queue protected by the
engine->active.lock, but we also show the pending execlists ports which
are not protected and so require a rcu_read_lock to keep the pointer
valid.

[ 1695.700883] BUG: KASAN: use-after-free in i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.700981] Read of size 8 at addr ffff8887344f4d50 by task gem_ctx_persist/2968
[ 1695.701068]
[ 1695.701156] CPU: 1 PID: 2968 Comm: gem_ctx_persist Tainted: G     U            5.4.0-rc6+ #331
[ 1695.701246] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 1695.701334] Call Trace:
[ 1695.701424]  dump_stack+0x5b/0x90
[ 1695.701870]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.701964]  print_address_description.constprop.7+0x36/0x50
[ 1695.702408]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.702856]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.702947]  __kasan_report.cold.10+0x1a/0x3a
[ 1695.703390]  ? i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.703836]  i915_fence_get_timeline_name+0x53/0x90 [i915]
[ 1695.704241]  print_request+0x82/0x2e0 [i915]
[ 1695.704638]  ? fwtable_read32+0x133/0x360 [i915]
[ 1695.705042]  ? write_timestamp+0x110/0x110 [i915]
[ 1695.705133]  ? _raw_spin_lock_irqsave+0x79/0xc0
[ 1695.705221]  ? refcount_inc_not_zero_checked+0x91/0x110
[ 1695.705306]  ? refcount_dec_and_mutex_lock+0x50/0x50
[ 1695.705709]  ? intel_engine_find_active_request+0x202/0x230 [i915]
[ 1695.706115]  intel_engine_dump+0x2c9/0x900 [i915]

Fixes: c36eebd9 ("drm/i915/gt: execlists->active is serialised by the tasklet")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-1-chris@chris-wilson.co.uk

After doing some measuring, Icelake behaves on a par with Broadwell, and
without having to compromise for low power cores with long latencies, we
can reduce the powergating hysteresis so that the powersaving is enabled
faster. No impact observed on client side throughput measures (so
negligible increase in extra switching), and inspection from high
frequency polling using igt/gem_exec_nop/sequential, provided an estimate
for the upper bound before we can measure a substantial impact on
latency.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191110185806.17413-9-chris@chris-wilson.co.uk

The ordering of the checks in the existing code can lead to holding
preemption not being considered as privileged op.
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9cd20ef7 ("drm/i915/perf: allow holding preemption on filtered ctx")
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191111095308.2550-1-lionel.g.landwerlin@intel.com

Make sure we have a crtc before probing its primary plane's
max stride. Initially I thought we can't get this far without
crtcs, but looks like we can via the dumb_create ioctl.

Not sure if we shouldn't disable dumb buffer support entirely
when we have no crtcs, but that would require some amount of work
as the only thing currently being checked is dev->driver->dumb_create
which we'd have to convert to some device specific dynamic thing.

Cc: stable@vger.kernel.org
Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: aa5ca8b7 ("drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106172349.11987-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

On gen7, we have to avoid concurrent access to the same mmio cacheline,
and so coordinate all mmio access with the uncore->lock. However, for
pmu, we want to avoid perturbing the system and disabling interrupts
unnecessarily, so restrict the w/a to gen7 where it is requied to
prevent machine hangs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108103511.20951-2-chris@chris-wilson.co.uk