summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-11-09drm/i915: Clean up DP code local variables and calling conventionsVille Syrjälä
Eliminate a ton of pointless 'dev' variables in the DP code, and pass around 'dev_priv' instead of 'dev'. v2: Rebase Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109152758.32257-1-ville.syrjala@linux.intel.com
2017-11-09drm/i915: Clean up PPS code calling conventionsVille Syrjälä
No need to pass 'dev' or 'dev_priv' when the function already takes 'intel_dp'. Also let's prefer passing 'dev_priv' instead of 'dev' when we have to pass one or the other. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-10-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Nuke intel_digital_port->portVille Syrjälä
Remove intel_digital_port->port and replace its users with intel_encoder->port. intel_encoder->port is a superset of intel_digital_port->port, and it works correctly even for MST encoders. v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK) Performed with cocci: @@ @@ struct intel_digital_port { ... - enum port port; ... } @@ struct intel_digital_port *D; expression E; @@ - D->port = E; @@ struct intel_digital_port *D; @@ - D->port + D->base.port @ expression E; @@ ( - dp_to_dig_port(E)->port + dp_to_dig_port(E)->base.port | - enc_to_dig_port(E)->port + to_intel_encoder(E)->port ) @@ expression E; @@ - to_intel_encoder(&E->base) + E @@ struct intel_digital_port *D; identifier I, M; @@ I = &D->base <... ( - D->base.M + I->M | - &D->base + I ) ...> @@ identifier D; expression E; identifier M; @@ D = enc_to_dig_port(&E->base) <... ( - D->base.M + E->M | - &D->base + E ) ...> @@ identifier D, DP; expression E; identifier M; @@ DP = enc_to_intel_dp(&E->base) <... ( - dp_to_dig_port(DP)->base.M + E->M | - &dp_to_dig_port(DP)->base + E ) ...> @@ expression E; identifier M; @@ ( - enc_to_dig_port(&E->base)->base.M + E->M | - enc_to_dig_port(&E->base)->base + E | - enc_to_mst(&E->base)->primary->base.port + E->port ) @@ expression E; identifier D; @@ - struct intel_digital_port *D = E; ... when != D Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
2017-11-09drm/i915: Replace dig_port->port with encoder port for BXT DPLL selectionVille Syrjälä
Replace dig_port->port with encoder->port in the BXT DPLL selection. We can do this because both the master encoder and the fake MST encoders have the same encoder->port value, whereas using dig_port->port only worked for the master encoder since the fake encoders were't derived from intel_digital_port. This eliminates the DP MST special case. Do this by hand because spatch is having problems with the control flow due to the dig_port assignment happening in two different branches. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-8-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Eliminate crtc->config usage from CRT codeVille Syrjälä
Replace crtc->config usage with the passed down crtc state. Also take the opportunity for some s/pipe_config/crtc_state/ while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Pass crtc state to DPIO PHY functionsVille Syrjälä
Rather than digging through encoder->crtc and crtc->config in the DPIO PHY functions, pass down the correct crtc state from the caller. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Eliminate some encoder->crtc usage from TV codeVille Syrjälä
Extract the current crtc from the crtc state rather than via the legacy encoder->crtc pointer whenever possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-5-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Eliminate some encoder->crtc usage from SDVO codeVille Syrjälä
Extract the current crtc from the crtc state rather than via the legacy encoder->crtc pointer whenever possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-4-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Eliminate some encoder->crtc usage from DSI codeVille Syrjälä
Extract the current crtc from the crtc state rather than via the legacy encoder->crtc pointer whenever possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Eliminate some encoder->crtc usage from DP codeVille Syrjälä
Extract the current crtc from the crtc state rather than via the legacy encoder->crtc pointer whenever possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-11-09drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCUChris Wilson
When we close the VMA, we unbind it from the ppgtt and tear down the page directory pointing at it. That may trigger us to return WC pages back to the system, requiring conversion back to WB which itself may sleep. That makes i915_vma_close() unsuitable for use inside the RCU read lock, which we need to hold to iterate the radixtree. The fix is quite simple, we can close all the VMA as we close the ppgtt, we only need to do that instead of closing them during destruction of the LUT. v2: Order between closing the LUT and the ppgtt is important; we use the vma inside the LUT as a means of retrieving the object, and so we must clear the LUT before freeing the VMA when closing the ppgtt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638 Fixes: 547da76b5777 ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)") Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109085540.32264-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 94dec87159af6f3dcc0b78d3f909aefa9e29c01a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Move init_clock_gating() back to where it wasVille Syrjälä
Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reported-by: Mark Janes <mark.a.janes@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.com Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit f72b84c677d61f201b869223a8d6e389c7bb7d3d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Prune the reservation shared fence arrayChris Wilson
The shared fence array is not autopruning and may continue to grow as an object is shared between new timelines. Take the opportunity when we think the object is idle (we have to confirm that any external fence is also signaled) to decouple all the fences. We apply a similar trick after waiting on an object, see commit e54ca9774777 ("drm/i915: Remove completed fences after a wait") v2: No longer need to handle the batch pool as a special case. v3: Need to trylock from within i915_vma_retire as this may be called form the shrinker - and we may later try to allocate underneath the reservation lock, so a deadlock is possible. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct reservation_object") Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 1ab22356b37ab08a391d6f007fda4c822bef9fb5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Idle the GPU before shinking everythingChris Wilson
The handling of contexts are peculiar. Instead of tieing their vma to activity, we pin the context. This means that we cannot simply unbind the context object itself at will (which would normally cause us to wait for the vma to be idle), but must manually idle the GPU and retire requests first. A consequence of this peculiarity is when doing a last desperate attempt to recover memory. If the memory is tied up inside active context objects, we will fail to recover any memory simply by trying to unbind the objects without first doing a wait-for-idle. A side-effect of removing the call to shrinker_lock_uninterruptible() from i915_gem_shrinker_oom() was that we removed an unlocked wait-for-idle, and so lost the "natural" shrinkage of context objects. By replacing that with a locked wait from inside i915_gem_shrink(), we not only replace it with the ability to recover all context objects, but do so for all i915_gem_shrink_all() callers. v2: Switching requires request allocation, which is not permitted from inside the shrinker as it only uses ordinary allocations. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: f2123818ffad ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 2f6a3783833dde63f1c08982943a8b2229b97afb) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Lock llist_del_first() vs llist_del_all()Chris Wilson
An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest stale object before a fresh allocation") was that not only do we have to serialise concurrent users of llist_del_first(), but we also have to lock llist_del_first() vs llist_del_all(). From llist.h, * This can be summarized as follows: * * | add | del_first | del_all * add | - | - | - * del_first | | L | L * del_all | | | - * * Where, a particular row's operation can happen concurrently with a column's * operation, with "-" being no lock needed, while "L" being lock is needed. This should hopefully explain: <4>[ 89.287106] general protection fault: 0000 [#1] PREEMPT SMP <4>[ 89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid pinctrl_geminilake pinctrl_intel <4>[ 89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U 4.14.0-rc8-CI-CI_DRM_3315+ #1 <4>[ 89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4>[ 89.287270] task: ffff88017ab34ec0 task.stack: ffffc90000128000 <4>[ 89.287290] RIP: 0010:llist_add_batch+0x4/0x20 <4>[ 89.287301] RSP: 0018:ffffc9000012bdb8 EFLAGS: 00010296 <4>[ 89.287314] RAX: ffffffff811017ad RBX: 6e468801a1560000 RCX: ef3e53fceecdeb81 <4>[ 89.287330] RDX: 6e468801a1566130 RSI: ffff880103d73d98 RDI: ffff880103d73d98 <4>[ 89.287346] RBP: ffffc9000012bdb8 R08: ffff88017ab35780 R09: 0000000000000000 <4>[ 89.287361] R10: ffffc9000012bd68 R11: 00000000abb18c3d R12: ffffffffa01369e0 <4>[ 89.287377] R13: ffff88017fd1b8f8 R14: ffff88017ab34ec0 R15: 000000000000000a <4>[ 89.287393] FS: 0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000 <4>[ 89.287411] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 89.287424] CR2: 00007ff0c0755018 CR3: 000000016df9b000 CR4: 00000000003406e0 <4>[ 89.287440] Call Trace: <4>[ 89.287511] __i915_gem_free_object_rcu+0x20/0x40 [i915] <4>[ 89.287527] rcu_process_callbacks+0x27a/0x730 <4>[ 89.287544] __do_softirq+0xc0/0x4ae <4>[ 89.287559] ? smpboot_thread_fn+0x2d/0x280 <4>[ 89.287571] run_ksoftirqd+0x1f/0x70 <4>[ 89.287582] smpboot_thread_fn+0x18a/0x280 <4>[ 89.287595] kthread+0x114/0x150 <4>[ 89.287605] ? sort_range+0x30/0x30 <4>[ 89.287615] ? kthread_create_on_node+0x40/0x40 <4>[ 89.287628] ret_from_fork+0x27/0x40 <4>[ 89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85 <1>[ 89.287774] RIP: llist_add_batch+0x4/0x20 RSP: ffffc9000012bdb8 <4>[ 89.287826] ---[ end trace e775d15174d8ae02 ]--- (Lockless lists are only easy (and lockless) when only using llist_add/llist_del_all!) Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before a fresh allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171106111508.11941-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit f991c492aa55fb1c6834882c5d786d5bb3b25f07) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Calculate ironlake intermediate watermarks correctly, v2.Maarten Lankhorst
The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the intermediate watermarks don't need to be programmed separately, and could be directly assigned to the optimal watermarks. Changes since v1: - Use intel_atomic_get_old_crtc_state. (ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten.lankhorst@linux.intel.com [mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself] Cc: stable@vger.kernel.org #v4.8+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 (cherry picked from commit b6b178a77210055b153dbc175e4468bd3c7122df) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Disable lazy PPGTT page table optimization for vGPUJoonas Lahtinen
When running under virtualization (vGPU active), we must disable the lazy PPGTT page table initialization optimization introduced by commit 14826673247e ("drm/i915: Only initialize partially filled pagetables"). We must do this because GVT-g makes unduly assumptions about guest behaviour, which this optimization breaks. This results in following looking errors in the host: ERROR gvt: guest page write error -22, gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1 The real fix is to not to depend on i915 driver behaviour, but instead either rely on only the contracts that i915 has with the hardware, or add some paravirtualization. While the real fix is en route, it won't be finished in time for 4.15, so the best option is to disable the optimization for now when vGPU is active to avoid breaking 4.15 guests in existing VM environments. Fixes: 14826673247e ("drm/i915: Only initialize partially filled pagetables") Suggested-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> [Joonas: Rewrote the commit message and added tags.] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023153209.10527-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 22a8a4fc93b14b5a8cfc785edbdc6f7bd98bffb6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915/execlists: Remove the priority "optimisation"Chris Wilson
Originally we set the priority to max upon inserting the request into the execlists queue (and removing it from the scheduler lists). We could then use the prio==INT_MAX as a shortcut within execlists_schedule() to detect the end of the dependency chain. Since commit 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its lifetime") this is no longer true as we use the request completion as an indicator the schedule dependency chain is complete instead. (This allows us to then reschedule requests even when its context is in flight.) However, this makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change the rq->prio at the same time. As the assertion is useful, let's keep the assertion and remove the micro-optimisation. Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its lifetime") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171024115501.21033-1-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 64b80085dd3603d401fc05879f700b86a3a5c8e8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Filter out spurious execlists context-switch interruptsChris Wilson
Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists context-switch when idle") we noticed the presence of late context-switch interrupts. We were able to filter those out by looking at whether the ELSP remained active, but in commit beecec901790 ("drm/i915/execlists: Preemption!") that became problematic as we now anticipate receiving a context-switch event for preemption while ELSP may be empty. To restore the spurious interrupt suppression, add a counter for the expected number of pending context-switches and skip if we do not need to handle this interrupt to make forward progress. v2: Don't forget to switch on for preempt. v3: Reduce the counter to a on/off boolean tracker. Declare the HW as active when we first submit, and idle after the final completion event (with which we confirm the HW says it is idle), and track each source of activity separately. With a finite number of sources, it should aide us in debugging which gets stuck. Fixes: beecec901790 ("drm/i915/execlists: Preemption!") 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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit 4a118ecbe99c93cf9f9582e83a88d03f18d6cb84) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-11-09drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCUChris Wilson
When we close the VMA, we unbind it from the ppgtt and tear down the page directory pointing at it. That may trigger us to return WC pages back to the system, requiring conversion back to WB which itself may sleep. That makes i915_vma_close() unsuitable for use inside the RCU read lock, which we need to hold to iterate the radixtree. The fix is quite simple, we can close all the VMA as we close the ppgtt, we only need to do that instead of closing them during destruction of the LUT. v2: Order between closing the LUT and the ppgtt is important; we use the vma inside the LUT as a means of retrieving the object, and so we must clear the LUT before freeing the VMA when closing the ppgtt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638 Fixes: 547da76b5777 ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)") Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109085540.32264-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-11-09Merge tag 'drm-misc-next-fixes-2017-11-08' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next 4.15 merge window fixes, round 2: randconfig fix from Arnd, plus the vblank WARN_ON fix from Ville. * tag 'drm-misc-next-fixes-2017-11-08' of git://anongit.freedesktop.org/drm/drm-misc: drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug drm/rockchip: add CONFIG_OF dependency for lvds
2017-11-09Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next A few more fixes for 4.15. * 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: use irq-safe lock for kiq->ring_lock drm/amdgpu: bypass lru touch for KIQ ring submission drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories() drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs() drm/amd/powerplay: initialize a variable before using it drm/amd/powerplay: suppress KASAN out of bounds warning in vega10_populate_all_memory_levels drm/amd/amdgpu: fix evicted VRAM bo adjudgement condition
2017-11-08drm/amdgpu: use irq-safe lock for kiq->ring_lockpding
This lock is used during register accessing in SRIOV guest. The register accessing could happen both in irq enabled and irq disabled cases. Always use irq-safe lock. Signed-off-by: Pixel Ding <Pixel.Ding@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-11-08drm/amdgpu: bypass lru touch for KIQ ring submissionPixel Ding
KIQ ring submission is used for register accessing on SRIOV VF that could happen both in irq enabled and irq disabled cases. Inversion lock could happen on adev->ring_lru_list_lock, while this operation is useless and just adds overhead in this use case. Signed-off-by: Pixel Ding <Pixel.Ding@amd.com> Reviewed-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-11-08drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()Dan Carpenter
After commit ea09729c9302 ("drm/amdgpu: rework page directory filling v2") then it becomes a lot harder to verify that "r" is initialized. My static checker complains and so I've reviewed the code. It does look like it might be buggy... Anyway, it doesn't hurt to set "r" to zero at the start. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2017-11-08drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()Dan Carpenter
We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping") and now my static checker complains that "r" might not be initialized at the end of the function. I've reviewed the code, and that seems possible, but it's also possible I may have missed something. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2017-11-08drm/i915/guc: Simplify programming of GUC_SHIM_CONTROLMichal Wajdeczko
We can program GUC_SHIM_CONTROL register with all expected bits without use of extra macro defined in fwif.h v2: rebased without pre-prod code v3: fixed typo Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-4-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-11-08drm/i915/guc: Drop legacy workarounds from guc_prepare_xferMichal Wajdeczko
We don't keep the workarounds for pre-production hardware (see intel_detect_preproduction_hw) thus we can drop some extra steps during firmware upload needed only for unsupported platforms. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-3-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-11-08drm/i915/guc: Wait for ucode DMA transfer completionMichal Wajdeczko
We silently assumed that DMA transfer will be completed within assumed timeout and thus we were waiting only at last step for GuC to become ready. Add intermediate wait to catch unexpected delays in DMA transfer. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-2-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-11-08drm/i915/guc: Split GuC firmware xfer function into clear stepsMichal Wajdeczko
Transfer of GuC firmware requires few steps that currently are implemented in two large functions. Split this code into smaller functions to make these steps small and clear. Also be prepared for potential DMA xfer step failure. v2: rename function steps (Sagar) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-1-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-11-08drm/i915: Implement ReadHitWriteOnlyDisable.Rafael Antognolli
The workaround for this is described as: "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1" Further documentation in the internal bug referenced by the bspec suggest that any of the above suggestions should suffice to fix the issue. We are going with disabling RCC clock gating. Unfortunately, what we are doing doesn't match the name of the workaround, but at least it matches its description. This change improves CNL stability by avoiding some of the hangs seen in the platform. v2: Only disable RCC clock gating. Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171103183027.5051-1-rafael.antognolli@intel.com
2017-11-08drm/i915: Move init_clock_gating() back to where it wasVille Syrjälä
Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reported-by: Mark Janes <mark.a.janes@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.com Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-11-08drm/i915: Prune the reservation shared fence arrayChris Wilson
The shared fence array is not autopruning and may continue to grow as an object is shared between new timelines. Take the opportunity when we think the object is idle (we have to confirm that any external fence is also signaled) to decouple all the fences. We apply a similar trick after waiting on an object, see commit e54ca9774777 ("drm/i915: Remove completed fences after a wait") v2: No longer need to handle the batch pool as a special case. v3: Need to trylock from within i915_vma_retire as this may be called form the shrinker - and we may later try to allocate underneath the reservation lock, so a deadlock is possible. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct reservation_object") Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-11-08drm/i915: Idle the GPU before shinking everythingChris Wilson
The handling of contexts are peculiar. Instead of tieing their vma to activity, we pin the context. This means that we cannot simply unbind the context object itself at will (which would normally cause us to wait for the vma to be idle), but must manually idle the GPU and retire requests first. A consequence of this peculiarity is when doing a last desperate attempt to recover memory. If the memory is tied up inside active context objects, we will fail to recover any memory simply by trying to unbind the objects without first doing a wait-for-idle. A side-effect of removing the call to shrinker_lock_uninterruptible() from i915_gem_shrinker_oom() was that we removed an unlocked wait-for-idle, and so lost the "natural" shrinkage of context objects. By replacing that with a locked wait from inside i915_gem_shrink(), we not only replace it with the ability to recover all context objects, but do so for all i915_gem_shrink_all() callers. v2: Switching requires request allocation, which is not permitted from inside the shrinker as it only uses ordinary allocations. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: f2123818ffad ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-11-08drm/i915: Include intel_engine_is_idle() status in engine pretty-printerChris Wilson
Upon parking, if we discover an active engine we dump its state. Follow that state with an indication of whether the engine was idle. References: https://bugs.freedesktop.org/show_bug.cgi?id=103479 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107152211.19930-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-11-08drm/i915: Read ilk FDI PLL frequency once during initialisationChris Wilson
During intel_atomic_check(), we do not take the intel_runtime_pm_get() wakeref and so should do the atomic modeset precalculations without referring to the HW. However, on Ironlake we see <7>[ 23.487557] [drm:intel_atomic_check [i915]] [CONNECTOR:47:VGA-1] checking for sink bpp constrains <7>[ 23.487615] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to default limit of 24 <4>[ 23.487621] RPM wakelock ref not held during HW access <4>[ 23.487652] ------------[ cut here ]------------ <4>[ 23.487697] WARNING: CPU: 0 PID: 1343 at drivers/gpu/drm/i915/intel_drv.h:1813 gen5_read32+0x183/0x200 [i915] <4>[ 23.487701] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me ptp mei pps_core prime_numbers <4>[ 23.487784] CPU: 0 PID: 1343 Comm: debugfs_test Tainted: G W 4.14.0-rc7-CI-Trybot_1378+ #1 <4>[ 23.487788] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 <4>[ 23.487793] task: ffff8801f90aa6c0 task.stack: ffffc900013ec000 <4>[ 23.487838] RIP: 0010:gen5_read32+0x183/0x200 [i915] <4>[ 23.487842] RSP: 0018:ffffc900013efb58 EFLAGS: 00010292 <4>[ 23.487849] RAX: 000000000000002a RBX: ffff880205c00000 RCX: 0000000000000006 <4>[ 23.487854] RDX: 000000000000140a RSI: ffffffff81d0eb14 RDI: ffffffff81cc26f6 <4>[ 23.487857] RBP: ffffc900013efb80 R08: ffff8801f90aaff8 R09: 0000000000000000 <4>[ 23.487861] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 23.487865] R13: 0000000000046000 R14: ffff88020ffaba78 R15: ffff88020b109bf8 <4>[ 23.487870] FS: 00007f53b5e40a40(0000) GS:ffff88021bc00000(0000) knlGS:0000000000000000 <4>[ 23.487874] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 23.487878] CR2: 000055e41900c0e8 CR3: 00000001fa0d6005 CR4: 00000000000206f0 <4>[ 23.487882] Call Trace: <4>[ 23.487931] intel_atomic_check+0x745/0x1290 [i915] <4>[ 23.487948] drm_atomic_check_only+0x459/0x560 <4>[ 23.487956] ? drm_atomic_set_crtc_for_connector+0xc9/0x100 <4>[ 23.488025] drm_atomic_commit+0x18/0x50 <4>[ 23.488035] restore_fbdev_mode_atomic+0x190/0x1f0 <4>[ 23.488059] restore_fbdev_mode+0x32/0x120 <4>[ 23.488072] drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0xa0 <4>[ 23.488139] intel_fbdev_restore_mode+0x34/0x90 [i915] <4>[ 23.488194] i915_driver_lastclose+0xe/0x10 [i915] <4>[ 23.488208] drm_lastclose+0x39/0xf0 <4>[ 23.488219] drm_release+0x30c/0x3c0 <4>[ 23.488236] __fput+0xb9/0x200 <4>[ 23.488252] ____fput+0xe/0x10 <4>[ 23.488264] task_work_run+0x89/0xc0 <4>[ 23.488278] exit_to_usermode_loop+0x83/0x90 <4>[ 23.488290] syscall_return_slowpath+0xd0/0x110 <4>[ 23.488304] entry_SYSCALL_64_fastpath+0xaf/0xb1 <4>[ 23.488312] RIP: 0033:0x7f53b4317560 <4>[ 23.488320] RSP: 002b:00007ffca7e70748 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 <4>[ 23.488333] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00007f53b4317560 <4>[ 23.488340] RDX: 0000000000000005 RSI: 00007ffca7e70640 RDI: 0000000000000004 <4>[ 23.488347] RBP: 000055e417783900 R08: 000055e418f9e290 R09: 0000000000000000 <4>[ 23.488356] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 <4>[ 23.488363] R13: 00007f53b4302c40 R14: 0000000000000000 R15: 0000000000000000 <4>[ 23.488384] Code: b5 f2 f2 e0 0f ff e9 c5 fe ff ff 80 3d 0e 4b 10 00 00 0f 85 c6 fe ff ff 48 c7 c7 30 73 29 a0 c6 05 fa 4a 10 00 01 e8 8e f2 f2 e0 <0f> ff e9 ac fe ff ff e8 51 9d f3 e0 85 c0 0f 85 01 ff ff ff 48 <4>[ 23.488780] ---[ end trace 6bc72ce7f1596190 ]--- <7>[ 23.488844] [drm:intel_atomic_check [i915]] checking fdi config on pipe A, lanes 1 <7>[ 23.488911] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24, dithering: 0 due to intel_fdi_link_freq() poking at FDI_PLL_BIOS_0. Avoid this by recording the fdi pll frequency during device initiailisation. v2: Also extract the static FDI PLL frequencies for Sandybridge and Ivybridge. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107214713.18704-1-chris@chris-wilson.co.uk Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-11-07drm/amd/powerplay: initialize a variable before using itNicolas Iooss
Function vega10_apply_state_adjust_rules() only initializes stable_pstate_sclk_dpm_percentage when data->registry_data.stable_pstate_sclk_dpm_percentage is not between 1 and 100. The variable is then used to compute stable_pstate_sclk, which therefore uses an uninitialized value. Fix this by initializing stable_pstate_sclk_dpm_percentage to data->registry_data.stable_pstate_sclk_dpm_percentage. This issue has been found while building the kernel with clang. The compiler reported a -Wsometimes-uninitialized warning. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-11-07drm/amd/powerplay: suppress KASAN out of bounds warning in ↵Evan Quan
vega10_populate_all_memory_levels Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-and-Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-11-07drm/amd/amdgpu: fix evicted VRAM bo adjudgement conditionRoger He
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Roger He <Hongbo.He@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2017-11-08Merge tag 'drm-misc-next-fixes-2017-11-07' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next Fixes for 4.15 merge window: Just the cherry-picked vc4 fix plus a GFP_NOFAIL annotation (there's apparently some new options in-flight to change/audit too-small-to-fail kmalloc semantics or something like that). * tag 'drm-misc-next-fixes-2017-11-07' of git://anongit.freedesktop.org/drm/drm-misc: drm/vc4: Fix wrong printk format in vc4_bo_stats_debugfs() drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
2017-11-07drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debugVille Syrjälä
Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count") even drivers that don't implement accurate vblank timestamps will end up using drm_crtc_accurate_vblank_count(). That leads to a WARN every time drm_crtc_arm_vblank_event() gets called. The could be as often as every frame for each active crtc. Considering drm_crtc_accurate_vblank_count() is never any worse than the drm_vblank_count() we used previously, let's just skip the WARN unless DRM_UT_VBL is enabled. That way people won't be bothered by this unless they're debugging vblank code. And let's also change it to WARN_ONCE() so that even when you're debugging vblank code you won't get drowned by constant WARNs. Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Cc: "Szyprowski, Marek" <m.szyprowski@samsung.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Reported-by: Andrzej Hajda <a.hajda@samsung.com> Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023152540.15364-1-ville.syrjala@linux.intel.com Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-11-07drm/i915/selftests: Take rpm wakeref around partial tiling testsChris Wilson
Since the partial tiling tests are poking into the GGTT to watch the fence registers in operation, it itself needs the device rpm wakeref in order for the GGTT to remain accessible. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107115653.10716-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-11-07drm/i915/selftests: Take rpm wakeref around GGTT lowlevel testsChris Wilson
The vma routines are responsible for acquiring the device rpm wakeref before they poke the HW. However, some of the selftests bypass the higher level vma routines in order to poke directly at the lowlevel GGTT functions; these are then responsible for managing rpm themselves. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107114051.10583-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.auld@intel.com>
2017-11-07drm/i915/selftests: Skip mixed page exhaustion if only small pages availableChris Wilson
If we only have 4k pages, we can't mix together different combinations of hugepages to see if the world burns. However, as the loops did nothing, we never set err to 0 and reported ENODEV aborting the test. Teach the test to skip instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107110559.6098-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
2017-11-07drm/i915: Prevent unbounded wm results in g4x_compute_wm()Chris Wilson
Smatch warns of drivers/gpu/drm/i915/intel_pm.c:1161 g4x_compute_wm() warn: signedness bug returning '(-33554430)' which is a result of it believing that wm may be INT_MAX following g4x_tlb_miss_wa(). Just declaring g4x_tlb_miss_wa() as returning an unsigned integer is not sufficient, we need to tell smatch that wm itself is unsigned for it to not worry. So mark up the locals we expect to be non-negative, and so silence smatch. v2: Mark up vlv_compute_wm_level() as unsigned similarly. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20171107140338.13748-1-chris@chris-wilson.co.uk
2017-11-07drm/i915: Simplify onion for bxt_ddi_phy_init()Chris Wilson
Older compilers (gcc-4.9) are not as able to track uninitialised variables as well as more recent compilers. In particular, drivers/gpu/drm/i915/intel_dpio_phy.c: In function ‘bxt_ddi_phy_init’: drivers/gpu/drm/i915/intel_dpio_phy.c:482:25: warning: ‘was_enabled’ may be used uninitialized in this function [-Wmaybe-uninitialized] In this case, we can rearrange code slightly to make the control flow clearer to the reader, as well as the compiler. That is we only call uninit using the same predicate as calling init Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107135324.28300-1-chris@chris-wilson.co.uk Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
2017-11-07drm/i915: Silence compiler for csr_load_work_fn()Chris Wilson
gcc-4.7 is not very smart and can not tell that "si" is guarded by size being 0. So it complains, drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’: drivers/gpu/drm/i915/intel_csr.c:204:3: warning: ‘si’ may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/i915/intel_csr.c:190:30: note: ‘si’ was declared in Give in and mark si as NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107145334.27154-1-chris@chris-wilson.co.uk Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
2017-11-07drm/i915: Silence smatch for cmdparserChris Wilson
drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:808:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:811:23: error: not an lvalue drivers/gpu/drm/i915/i915_cmd_parser.c:814:23: error: not an lvalue If we move the shift into each case not only do we kill the warning from smatch, but we shrink the code slightly: text data bss dec hex filename 1267906 20587 3168 1291661 13b58d before 1267890 20587 3168 1291645 13b57d after Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171107154055.19460-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
2017-11-07drm/i915: Deconstruct struct sgt_dma initialiserChris Wilson
gcc-4.4 complains about: struct sgt_dma iter = { .sg = vma->pages->sgl, .dma = sg_dma_address(iter.sg), .max = iter.dma + iter.sg->length, }; drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen8_ppgtt_insert_4lvl’: drivers/gpu/drm/i915/i915_gem_gtt.c:938: error: ‘iter.sg’ is used uninitialized in this function drivers/gpu/drm/i915/i915_gem_gtt.c:939: error: ‘iter.dma’ is used uninitialized in this function and worse generates invalid code that triggers a GPF: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915] PGD 0 Oops: 0000 [#1] SMP Modules linked in: snd_aloop nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 ip6table_filter ip6_tables ctr ccm xt_state nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_recent xt_owner xt_addrtype iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c ip_tables dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm irqbypass uas usb_storage hid_multitouch btusb btrtl uvcvideo videobuf2_v4l2 videobuf2_core videodev media videobuf2_vmalloc videobuf2_memops sg ppdev dell_wmi sparse_keymap mei_wdt sd_mod iTCO_wdt iTCO_vendor_support rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core dell_smm_hwmon hwmon dell_laptop dell_smbios dcdbas joydev input_leds hci_uart btintel btqca btbcm bluetooth parport_pc parport i2c_hid intel_lpss_acpi intel_lpss pcspkr wmi int3400_thermal acpi_thermal_rel dell_rbtn mei_me mei snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ahci libahci acpi_pad xhci_pci xhci_hcd snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore int3403_thermal arc4 e1000e ptp pps_core i2c_i801 iwlmvm mac80211 rtsx_pci iwlwifi cfg80211 rfkill intel_pch_thermal processor_thermal_device int340x_thermal_zone intel_soc_dts_iosf i915 video fjes CPU: 2 PID: 2408 Comm: X Not tainted 4.10.0-rc5+ #1 Hardware name: Dell Inc. Latitude E7470/0T6HHJ, BIOS 1.11.3 11/09/2016 task: ffff880219fe4740 task.stack: ffffc90005f98000 RIP: 0010:gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915] RSP: 0018:ffffc90005f9b8c8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8802167d8000 RCX: 0000000000000001 RDX: 00000000ffff7000 RSI: ffff880219f94140 RDI: ffff880228444000 RBP: ffffc90005f9b948 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000080 R13: 0000000000000001 R14: ffffc90005f9bcd7 R15: ffff88020c9a83c0 FS: 00007fb53e1ee920(0000) GS:ffff88024dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000022ef95000 CR4: 00000000003406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ppgtt_bind_vma+0x40/0x50 [i915] i915_vma_bind+0xcb/0x1c0 [i915] __i915_vma_do_pin+0x6e/0xd0 [i915] i915_gem_execbuffer_reserve_vma+0x162/0x1d0 [i915] i915_gem_execbuffer_reserve+0x4fc/0x510 [i915] ? __kmalloc+0x134/0x250 ? i915_gem_wait_for_error+0x25/0x100 [i915] ? i915_gem_wait_for_error+0x25/0x100 [i915] i915_gem_do_execbuffer+0x2df/0xa00 [i915] ? drm_malloc_gfp.clone.0+0x42/0x80 [i915] ? path_put+0x22/0x30 ? __check_object_size+0x62/0x1f0 ? terminate_walk+0x44/0x90 i915_gem_execbuffer2+0x95/0x1e0 [i915] drm_ioctl+0x243/0x490 ? handle_pte_fault+0x1d7/0x220 ? i915_gem_do_execbuffer+0xa00/0xa00 [i915] ? handle_mm_fault+0x10d/0x2a0 vfs_ioctl+0x18/0x30 do_vfs_ioctl+0x14b/0x3f0 SyS_ioctl+0x92/0xa0 entry_SYSCALL_64_fastpath+0x1a/0xa9 RIP: 0033:0x7fb53b4fcb77 RSP: 002b:00007ffe0c572898 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fb53e17c038 RCX: 00007fb53b4fcb77 RDX: 00007ffe0c572900 RSI: 0000000040406469 RDI: 000000000000000b RBP: 00007fb5376d67e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000028 R11: 0000000000003246 R12: 0000000000000000 R13: 0000000000000000 R14: 000055eecb314d00 R15: 000055eecb315460 Code: 0f 84 5d ff ff ff eb a2 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 58 0f 1f 44 00 00 31 c0 89 4d b0 <4c> 8b 60 10 44 8b 70 0c 48 89 d0 4c 8b 2e 48 c1 e8 27 25 ff 01 RIP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915] RSP: ffffc90005f9b8c8 CR2: 0000000000000010 Recent gccs, such as 4.9, 6.3 or 7.2, do not generate the warning nor do they explode on use. If we manually create the struct using locals from the stack, this should eliminate this issue, and does not alter code generation with gcc-7.2. Fixes: 894ccebee2b0 ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()") Reported-by: Kelly French <kfrench@federalhill.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kelly French <kfrench@federalhill.net> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171106211128.12538-1-chris@chris-wilson.co.uk Tested-by: Kelly French <kfrench@federalhill.net> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-11-06drm/rockchip: add CONFIG_OF dependency for lvdsArnd Bergmann
Build-testing on randconfig kernels revealed a dependency in the newly added lvds sub-driver: drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 'rockchip_lvds_bind': drivers/gpu/drm/rockchip/rockchip_lvds.c:380:24: error: 'struct drm_bridge' has no member named 'of_node' remote = lvds->bridge->of_node; We could work around that in the code, adding a Kconfig dependency seems easier. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171106135852.1355487-1-arnd@arndb.de
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 16:37:17 +0000