The i915_flip* tracepoints are no longer in use since the removal of CS
flip in commit 8b5d27b9 ("drm/i915: Remove intel_flip_work
infrastructure")

References: 8b5d27b9 ("drm/i915: Remove intel_flip_work infrastructure")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508151552.31024-1-chris@chris-wilson.co.uk

During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.

v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-2-chris@chris-wilson.co.ukReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.

v2: Keep rcu_read_lock() around for PREEMPT_RCU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-1-chris@chris-wilson.co.ukReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

As we flush each test and wait for idle before the next, also switch
back to the kernel context. This helps limit the amount of collateral
damage a test may cause by resetting to the default state each time (and
also helps clean up temporaries used by the test).
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/20180508115312.12628-1-chris@chris-wilson.co.uk

Add some onion to populate_lr_context.

v2: prefer err_unpin_ctx
    drop the fixes tag, worst case we just spew a warn before everything
    is cleaned up and balance is restored
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301114639.510-1-matthew.auld@intel.com

igt_ctx_exec() expects that we retire all active requests/objects before
completing, so that when we clean up the files afterwards they are ready
to be freed. Before we do so, it is then prudent to ensure that we have
indeed retired the GPU activity, raising an error if it fails. If we do
not, we run the risk of triggering an assertion when freeing the object:

  __i915_gem_free_objects:4793 GEM_BUG_ON(i915_gem_object_is_active(obj))
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/20180505091014.26126-2-chris@chris-wilson.co.uk

Pull igt_flush_test() out into its own library before copying and
pasting the code for a third time.
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/20180505091014.26126-1-chris@chris-wilson.co.uk

Operating on a zero sized GEM userptr object will lead to explosions.

Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Testcase: igt/gem_userptr_blits/input-checking
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/20180502195021.30900-1-matthew.auld@intel.com

When rescheduling a change of dependencies, they all need to be added to
the same priolist (at least the ones on the same engine!). Since we
likely want to move a batch of requests, keep the priolist around.

v2: Throw in an assert to catch trivial errors quickly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-2-chris@chris-wilson.co.uk

lookup_priolist() no longer attaches the request into the priolist, it
just returns the priolist for the given priority instead. Drop the
unused parameter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-1-chris@chris-wilson.co.uk

Unsafe module parameters are just that, unsafe. If the user is foolish
enough to try them and the kernel breaks, they get to keep both pieces.
Don't ask them to file a bug report if they broke it themselves.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106423
Fixes: d15d7538 ("drm/i915: Tune down init error message due to failure injection")
Signed-off-by: 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>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506183147.2690-1-chris@chris-wilson.co.uk

This implements the "MG PLL Programming" sequence from our spec. The
biggest problem was that the spec assumes real numbers, so we had to
adjust some numbers and calculations due to the fact that the Kernel
prefers to deal with integers.

I recommend grabbing some coffee, a pen and paper before reviewing
this patch.

v2:
 - Correctly identify DP encoders after upstream change.
 - Small checkpatch issues.
 - Rebase.
v3:
 - Try to impove the comment on the tdc_targetcnt calculation based on
   Manasi's feedback (Manasi).
 - Rebase.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-7-paulo.r.zanoni@intel.com

Just use the hardcoded tables provided by our spec.

v2: Rebase.
v3: Clarify that 38.4 uses the 19.2 table (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/20180328215803.13835-6-paulo.r.zanoni@intel.com

HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
the CNL code.

v2:
 - Properly detect HDMI crtcs.
 - Rebase after changes to the cnl function (clock * 1000).
v3:
 - Add a comment to clarify why we treat 38.4 as 19.2 (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/20180328215803.13835-5-paulo.r.zanoni@intel.com

This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.

Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.

v2:
 - Rebase around dpll_lock changes.
v3:
 - The spec now says what the timeouts should be.
 - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
   the machine.
 - Checkpatch found a white space problem.
 - Small adjustments before upstreaming.
v4:
 - Move the ICL checks out of the *map_plls_to_ports() functions
  (James)
 - Add extra encoder check (James)
 - Call icl_unmap_plls_to_ports() later (James)
v5:
 - Rebase after the pll struct changes.
v6:
 - Properly make the unmap function based on encoders_post_disable()
   with regarding to checks and iterators.
 - Address checkpatch comment on "min = max = x()".

Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com

Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com

Ignore the tests looking at the innards of execlists and its submission
tasklets on machines that don't support execlists!
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/20180504124202.24894-1-chris@chris-wilson.co.uk

Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.

Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.

This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.

This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.

[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
 code and properly cover the max hw timeout of ~4 seconds, and
 drop the comment about the specific machine since this is not
 a particulary surprising issue, nor specific to that one machine]
Signed-off-by: Florent Flament <contact@florentflament.com>
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic <ppetrovic@acm.org>
Cc: Sérgio M. Basto <sergio@serjux.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>

It is useful to see the priority as requests are coming in and completed
status as requests are coming out of the GPU.

To achieve this in a more readable way we need to abandon the common
request_hw tracepoint class.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504115643.22437-1-tvrtko.ursulin@linux.intel.com

"An outstanding request must still be on an active ring somewhere" is
only true if we haven't just been interrupted by the shrinker in the
middle of allocating the request itself. (At the start of
i915_request_alloc() we pin the context and prepare the GT for activity,
marking it as active, and then try to allocate the request. If this
allocation invokes the shrinker, we try to reclaim some space by calling
i915_retire_requests() which may then be confused by the pre-reservation
of active_requests.)

<3>[  125.472695] i915_retire_requests:1429 GEM_BUG_ON(list_empty(&i915->gt.active_rings))
<2>[  125.472792] kernel BUG at drivers/gpu/drm/i915/i915_request.c:1429!
<4>[  125.472822] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
<4>[  125.498764] Modules linked in: snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel btusb btrtl btbcm btintel cdc_ether snd_hda_codec_realtek bluetooth i915 snd_hda_codec_generic usbnet r8152 mii ecdh_generic lpc_ich mei_me snd_hda_intel snd_hda_codec mei snd_hwdep snd_hda_core snd_pcm prime_numbers
<4>[  125.498923] CPU: 0 PID: 1115 Comm: gem_exec_create Tainted: G     U            4.17.0-rc3-gc49cbe0d1eb8-kasan_32+ #1
<4>[  125.498955] Hardware name: GOOGLE Peppy/Peppy, BIOS MrChromebox 02/04/2018
<4>[  125.499074] RIP: 0010:i915_retire_requests+0x3f2/0x590 [i915]
<4>[  125.499095] RSP: 0018:ffff88004e5dec40 EFLAGS: 00010282
<4>[  125.499117] RAX: 0000000000000010 RBX: ffff8800458f0000 RCX: 0000000000000000
<4>[  125.499140] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff880060c2f6f0
<4>[  125.499164] RBP: ffff88004e5dee30 R08: ffffed000c185ee6 R09: ffffed000c185ee6
<4>[  125.499187] R10: 0000000000000001 R11: ffffed000c185ee5 R12: ffff8800553da160
<4>[  125.499210] R13: dffffc0000000000 R14: 0000000000000000 R15: ffff8800458faed0
<4>[  125.499235] FS:  00007fe18f052980(0000) GS:ffff880065400000(0000) knlGS:0000000000000000
<4>[  125.499262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  125.499282] CR2: 00007f01df11efb8 CR3: 00000000518d4001 CR4: 00000000000606f0
<4>[  125.499304] Call Trace:
<4>[  125.499417]  i915_gem_shrink+0x576/0xb50 [i915]
<4>[  125.499532]  ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915]
<4>[  125.499561]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  125.499671]  ? i915_gem_shrinker_count+0x1d6/0x2f0 [i915]
<4>[  125.499782]  ? i915_gem_shrinker_scan+0xc4/0x320 [i915]
<4>[  125.499889]  i915_gem_shrinker_scan+0xc4/0x320 [i915]
<4>[  125.499997]  ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915]
<4>[  125.500021]  ? do_raw_spin_unlock+0x4f/0x240
<4>[  125.500042]  ? _raw_spin_unlock+0x29/0x40
<4>[  125.500149]  ? i915_gem_shrinker_count+0x1d6/0x2f0 [i915]
<4>[  125.500177]  shrink_slab.part.18+0x23e/0x8f0
<4>[  125.500202]  ? unregister_shrinker+0x1f0/0x1f0
<4>[  125.500226]  ? mem_cgroup_iter+0x379/0xcc0
<4>[  125.500249]  shrink_node+0xa7e/0x1180
<4>[  125.500276]  ? shrink_node_memcg+0x11f0/0x11f0
<4>[  125.500297]  ? __delayacct_freepages_start+0x38/0x80
<4>[  125.500319]  ? __is_insn_slot_addr+0xe3/0x1a0
<4>[  125.500342]  ? recalibrate_cpu_khz+0x10/0x10
<4>[  125.500361]  ? ktime_get+0xb2/0x140
<4>[  125.500382]  do_try_to_free_pages+0x2d3/0xe40
<4>[  125.500407]  ? allow_direct_reclaim.part.23+0x1e0/0x1e0
<4>[  125.500429]  ? shrink_node+0x1180/0x1180
<4>[  125.500450]  ? __read_once_size_nocheck.constprop.4+0x10/0x10
<4>[  125.500476]  try_to_free_pages+0x1af/0x560
<4>[  125.500497]  ? do_try_to_free_pages+0xe40/0xe40
<4>[  125.500525]  __alloc_pages_nodemask+0xadc/0x2130
<4>[  125.500553]  ? gfp_pfmemalloc_allowed+0x150/0x150
<4>[  125.500654]  ? i915_gem_do_execbuffer+0x219d/0x32e0 [i915]
<4>[  125.500678]  ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[  125.500701]  ? __debug_object_init+0x322/0xd90
<4>[  125.500722]  ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[  125.500827]  ? i915_gem_do_execbuffer+0xdc2/0x32e0 [i915]
<4>[  125.500942]  ? i915_request_alloc+0x5b5/0x13f0 [i915]
<4>[  125.500964]  ? page_frag_free+0x170/0x170
<4>[  125.500984]  ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[  125.501008]  new_slab+0x21d/0x5c0
<4>[  125.501029]  ___slab_alloc.constprop.35+0x322/0x3e0
<4>[  125.501052]  ? reservation_object_reserve_shared+0x10b/0x250
<4>[  125.501074]  ? __ww_mutex_lock.constprop.3+0x1104/0x2cf0
<4>[  125.501097]  ? _raw_spin_unlock_irqrestore+0x39/0x60
<4>[  125.501120]  ? fs_reclaim_acquire+0x10/0x10
<4>[  125.501138]  ? lock_acquire+0x138/0x3c0
<4>[  125.501156]  ? lock_acquire+0x3c0/0x3c0
<4>[  125.501176]  ? reservation_object_reserve_shared+0x10b/0x250
<4>[  125.501198]  ? __slab_alloc.isra.27.constprop.34+0x3d/0x70
<4>[  125.501219]  __slab_alloc.isra.27.constprop.34+0x3d/0x70
<4>[  125.501243]  ? reservation_object_reserve_shared+0x10b/0x250
<4>[  125.501265]  __kmalloc_track_caller+0x313/0x350
<4>[  125.501287]  krealloc+0x62/0xb0
<4>[  125.501305]  reservation_object_reserve_shared+0x10b/0x250
<4>[  125.501411]  i915_gem_do_execbuffer+0x2040/0x32e0 [i915]
<4>[  125.501522]  ? eb_relocate_slow+0xad0/0xad0 [i915]
<4>[  125.501544]  ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[  125.501646]  ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[  125.501755]  ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[  125.501779]  ? drm_dev_get+0x20/0x20
<4>[  125.501803]  ? __might_fault+0xea/0x1a0
<4>[  125.501902]  ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[  125.502012]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502116]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502218]  i915_gem_execbuffer2_ioctl+0x3c5/0x770 [i915]
<4>[  125.502243]  ? drm_dev_enter+0xe0/0xe0
<4>[  125.502260]  ? lock_acquire+0x138/0x3c0
<4>[  125.502362]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502470]  ? i915_gem_object_create.part.28+0x570/0x570 [i915]
<4>[  125.502575]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502680]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502702]  drm_ioctl_kernel+0x151/0x200
<4>[  125.502721]  ? drm_ioctl_permit+0x2a0/0x2a0
<4>[  125.502746]  drm_ioctl+0x63a/0x920
<4>[  125.502844]  ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[  125.502868]  ? drm_getstats+0x20/0x20
<4>[  125.502886]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  125.502919]  do_vfs_ioctl+0x173/0xe90
<4>[  125.502936]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  125.502957]  ? ioctl_preallocate+0x170/0x170
<4>[  125.502978]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  125.503002]  ? retint_kernel+0x2d/0x2d
<4>[  125.503024]  ksys_ioctl+0x35/0x60
<4>[  125.503043]  __x64_sys_ioctl+0x6a/0xb0
<4>[  125.503061]  do_syscall_64+0x97/0x400
<4>[  125.503081]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  125.503101] RIP: 0033:0x7fe18e4f65d7
<4>[  125.503116] RSP: 002b:00007ffe2ffc06a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
<4>[  125.503145] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe18e4f65d7
<4>[  125.503168] RDX: 00007ffe2ffc07f0 RSI: 0000000040406469 RDI: 0000000000000003
<4>[  125.503191] RBP: 00007ffe2ffc07f0 R08: 0000000000000004 R09: 00007ffe2ffcf080
<4>[  125.503215] R10: 000000000002c7de R11: 0000000000000246 R12: 0000000040406469
<4>[  125.503238] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
<4>[  125.503268] Code: e8 18 a0 c9 da 48 8b 35 25 3a 47 00 49 c7 c0 a0 3b 88 c0 b9 95 05 00 00 48 c7 c2 e0 49 88 c0 48 c7 c7 8d 3b 5d c0 e8 ee 7e db da <0f> 0b 48 89 ef e8 a4 26 f5 da e9 51 fe ff ff e8 8a 26 f5 da e9
<1>[  125.503548] RIP: i915_retire_requests+0x3f2/0x590 [i915] RSP: ffff88004e5dec40

Fixes: 643b450a ("drm/i915: Only track live rings for retiring")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504101147.26286-1-chris@chris-wilson.co.uk

Following commit f773568b ("drm/i915: nuke the duplicated stolen
discovery"), the if-else-chain for determining the GTT size is redundant
with the !chv branches all being the same.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: f773568b ("drm/i915: nuke the duplicated stolen discovery")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503212956.3948-1-chris@chris-wilson.co.uk

The new helper returns index of the matching string in an array.
We are going to use it here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503181706.22120-1-andriy.shevchenko@linux.intel.com

Limit the arbitration (where preemption may occur) to inside the batch,
and prevent it from happening on the pipecontrols/flushes we use to
write the breadcrumb seqno. Once the user batch is complete, we have
nothing left to do but serialise and emit the breadcrumb; switching
contexts at this point is futile so don't.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503195416.22498-1-chris@chris-wilson.co.uk

Don't pre-emptively retire the oldest request in our ring's list if it
is the only request. We keep various bits of state alive using the
active reference from the request and would rather transfer that state
over to a new request rather than the more involved process of retiring
and reacquiring it.
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/20180503195115.22309-2-chris@chris-wilson.co.uk

When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.

However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.

If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.

In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.

v2: s/__i915_vma_final_close/i915_vma_destroy/ etc.
v3: Leave a hint as to why we deferred the unbind on close.
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/20180503195115.22309-1-chris@chris-wilson.co.uk

Trivial fix to spelling mistake in pr_err error message
Signed-off-by: Colin Ian King <colin.king@canonical.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/20180503154510.708-1-colin.king@canonical.com

In Icelake, there are more engines on which Memory Object Control
States need to be configured. Besides adding Icelake under Skylake
config, the patch makes sure MOCS register addresses for the new
engines are properly defined.

Additional patch might be need later, in case the specification will
propose different MOCS config values for Icelake than in previous
gens.

v2: Restricted comments to gen11, updated description, renamed
defines.

v3: Used proper engine indexes for gen11.

v4: Ensure patch is Icelake only.

v5: Style fixes (proposed by mwajdeczko)

v6 (from Paulo): fix checkpatch's COMMIT_LOG_LONG_LINE (Checkpatch).

BSpec: 19405
BSpec: 21140
Cc: Oscar Mateo Lozano <oscar.mateo@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502223142.3891-1-paulo.r.zanoni@intel.com

During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
scale the pipe contents. Let's preserve the pipe src size based
information in the user mode to make things consistent again.

This fixes a problem introduced by commit a2936e3d ("drm/i915:
Use drm_mode_get_hv_timing() to populate plane clip rectangle")
where the inconsistent state is now leading the plane clipping code
to report a failure on account the plane dst coordinates not matching
the user mode size. Previously we did the plane clipping based on
the pipe src size instead and thus never noticed the inconsistency.

The failure manifests as a WARN:
[    0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
[    0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
...
[    0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143
...
[    0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC
[    0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
[    0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
[    0.764713] ------------[ cut here ]------------
[    0.764714] Could not determine valid watermarks for inherited state
[    0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915]
...

Cc: FadeMind <fademind@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: FadeMind <fademind@gmail.com>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Tested-by: Dave Jones <davej@codemonkey.org.uk>
References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
Fixes: a2936e3d ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: FadeMind <fademind@gmail.com>

No functional changes, just a minor knit. Stumbled across the kernel doc for
schedule_timeout() which quotes "In all cases the return value is guaranteed
to be non-negative". Also, the return code of schedule_timeout() already checks
for negative values "return timeout < 0 ? 0 : timeout;" and returns 0
in such cases. Furthermore, the msec_to_jiffies returns an ungined long
value. So, let's do away with the redundant check for an atomic
pipe update.

v2: Commit message changes (Manasi).
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Tarun Vyas <tarun.vyas@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502233300.81220-1-tarun.vyas@intel.com

On intel_dp_compute_config() we were calculating the needed vco
for eDP on gen9 and we stashing it in
intel_atomic_state.cdclk.logical.vco

However few moments later on intel_modeset_checks() we fully
replace entire intel_atomic_state.cdclk.logical with
dev_priv->cdclk.logical fully overwriting the logical desired
vco for eDP on gen9.

So, with wrong VCO value we end up with wrong desired cdclk, but
also it will raise a lot of WARNs: On gen9, when we read
CDCLK_CTL to verify if we configured properly the desired
frequency the CD Frequency Select bits [27:26] == 10b can mean
337.5 or 308.57 MHz depending on the VCO. So if we have wrong
VCO value stashed we will believe the frequency selection didn't
stick and start to raise WARNs of cdclk mismatch.

[   42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[   42.897269] cdclk state doesn't match!
[   42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[   42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
[   43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[   43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[   43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0

v2: Move the entire eDP's vco logical adjustment to inside
    the skl_modeset_calc_cdclk as suggested by Ville.

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>
Fixes: bb0f4aab ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com

As we unpark the engines and are about to begin a new cycle of activity,
mark the current status of the hangceck as idle so that we avoid
carrying over a stale timestamp/action into the next cycle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502220313.6459-2-chris@chris-wilson.co.uk

In the unusual circumstance where we reuse a seqno (for example, in
igt), make sure that we reset the hangcheck timestamp before it sees the
same seqno again.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106215Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502220313.6459-1-chris@chris-wilson.co.uk

If we try to suspend a wedged device following a GPU reset failure, we
will also fail to turn off the rc6 powerwells (on vlv), leading to a
*ERROR*. This is quite expected in this case, so the best we can do is
shake our heads and reduce the *ERROR* to a debug so CI stops
complaining.

Testcase: igt/gem_eio/in-flight-suspend #vlv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105583Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409094905.4516-1-chris@chris-wilson.co.uk

Move the tracepoint into the common execlists_context_schedule_out() and
call it from preemption completion as well. A small bit of refactoring
code should help with when tracing, or else we end up with requests
mysteriously disappearing and some being emitted to HW multiple times.
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502230202.6848-1-chris@chris-wilson.co.uk

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.

v2: Tweak wait_for_idle to stop the compiling thinking that ret may be
uninitialised.
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/20180502163839.3248-2-chris@chris-wilson.co.uk

In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.

The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.

v2: Reinforce that one isn't allowed to mix the engine execution
timeline with the client timeline from userspace (on the ring).
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/20180502163839.3248-1-chris@chris-wilson.co.uk

Replace 01.org URL with upstream linux-firmware repo URL.
We no longer release firmware to 01.org.
linux-firmware.git is the ultimate place to find
the i915 firmwares.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525129168-529-1-git-send-email-anusha.srivatsa@intel.com

As our early doorbell is split between early allocation and a late setup
after we have a channel to the GuC, it may happen due to a lapse of
programmer judgement that we try to setup an invalid doorbell. Make use
of our has_doorbell() function to check the doorbell does exist for the
client before we try and tell the guc about it. In doing so, we prevent
the compiler from warning about the otherwise unused function in some
configurations.
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180501075203.12458-1-chris@chris-wilson.co.uk

Commit 39bf4de8 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enabled some additional clang-only warnings, as a
result building i915 with clang currently is extremely noisy. For now
also disable the clang warnings sign-compare, sometimes-uninitialized,
unneeded-internal-declaration and initializer-overrides. If desired
they can be re-enabled after the code has been fixed.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
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/20180501182440.70121-1-mka@chromium.org

Since the advent of execlists, the HW no longer executes from a single
statically assigned ring, but instead switches to a different ring for
each context (logical ringbuffer contexts as it is called). So a good way
to tally the executing context against what we have queued is by
comparing the RING_START register against our requests. Make it so.
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/20180502104150.29874-1-chris@chris-wilson.co.uk