aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-12-18Merge tag 'gvt-fixes-2019-12-18' of https://github.com/intel/gvt-linux into drm-intel-fixesJoonas Lahtinen6-6/+118
gvt-fixes-2019-12-18 - vGPU state setting locking fix (Zhenyu) - Fix vGPU display dmabuf as read-only (Zhenyu) - Properly handle vGPU display dmabuf page pin when rendering (Tina) - Fix one guest boot warning to handle guc reset state (Fred) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218051657.GA21662@zhen-hp.sh.intel.com
2019-12-18drm/i915: Fix pid leak with banned clientsTvrtko Ursulin1-2/+1
Get_pid_task() needs to be paired with a put_pid or we leak a pid reference every time a banned client tries to create a context. v2: * task_pid_nr helper exists! (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191217170933.8108-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit ba16a48af797db124ac100417f9229b1650ce1fb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-18drm/i915/gem: Keep request alive while attaching fencesChris Wilson1-0/+2
Since commit e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex"), the request retirement can happen outside of the struct_mutex serialised only by the timeline->mutex. We drop the timeline->mutex on submitting the request (i915_request_add) so after that point, it is liable to be freed. Make sure our local reference is kept alive until we have finished attaching it to the signalers. (Note that this erodes the argument that i915_request_add should consume the reference, but that is a slightly larger patch!) Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217134729.3297818-1-chris@chris-wilson.co.uk (cherry picked from commit e14177f19739d74839eb496a27f5f5d958beaa5b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-17drm/i915: Fix WARN_ON condition for cursor plane ddb allocationVandita Kulkarni1-2/+2
In some cases like latency[level]==0, wm[level].res_lines>31, min_ddb_alloc can be U16_MAX, exclude it from the WARN_ON. v2: Specify the cases in which we hit U16_MAX, indentation (Ville) Fixes: 10a7e07b68b9 ("drm/i915: Make sure cursor has enough ddb for the selected wm level") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216080619.10945-1-vandita.kulkarni@intel.com (cherry picked from commit 4ba487019d1a196051feefab57f4a393815733b4) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-17drm/i915/gvt: Fix guest boot warningGao Fred1-0/+16
Simulate MIA core in reset status once GUC engine is reset. v2: 1. use vgpu_vreg_t() function, 2. clear MIA_IN_RESET after reading. (Zhenyu) v3: add comments. (Zhenyu) Signed-off-by: Gao Fred <fred.gao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191216160255.29499-1-fred.gao@intel.com
2019-12-16drm/i915/tgl: Drop Wa#1178Matt Roper2-6/+4
The TGL workaround database no longer shows Wa #1178 (or anything similar under different workaround names/numbers) so we should be able to drop it. In fact Swati just discovered that applying this workaround is the root cause of some power well enable failures we've been seeing in CI (gitlab issue 498). Once we stop applying this WA, TGL no longer utilizes any of the special handling provided by icl_combo_phy_aux_power_well_ops so we can just drop back to using the standard hsw-style power well ops instead. v3: Drop now-unused _TGL_AUX_ANAOVRD1_C definition too. (Lucas) Closes: https://gitlab.freedesktop.org/drm/intel/issues/498 Fixes: deea06b47574 ("drm/i915/tgl: apply Display WA #1178 to fix type C dongles") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213001511.678070-3-matthew.d.roper@intel.com (cherry picked from commit ab3402581d0fa58e63e36875995f43ab02b4d0a0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915/ehl: Define EHL powerwells independently of ICLMatt Roper1-0/+147
Outputs C and D on EHL are combo PHY outputs and thus should not be using the same TC AUX power well handlers as ICL. And even though icl_combo_phy_aux_power_well_ops works okay for EHL/JSL combo PHYs none of its special handling is actually necessary for this platform: * EHL/JSL don't actually need to program PORT_CL_DW12 * Display WA #1178 does not apply to EHL/JSL Thus we can simply drop back to using our standard "hsw-style" power well ops for EHL AUX power wells. Bspec: 4301 Fixes: f722b8c1e2a2 ("drm/i915/ehl: All EHL ports are combo phys") Cc: Jose Souza <jose.souza@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213001511.678070-2-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit e8ab8d669d046a8e9b07707d2f00b9ba3e25d0ae) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915: Set fence_work.ops before dma_fence_initChris Wilson1-2/+1
Since dma_fence_init may call ops (because of a meaningless trace_dma_fence), we need to set the worker ops prior to that call. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Fixes: 8e458fe2ee05 ("drm/i915: Generalise the clflush dma-worker") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191212154224.1631531-1-chris@chris-wilson.co.uk (cherry picked from commit 1bc9865d8df3e1c6857a27c4b2b8a9ce8f027349) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915: Copy across scheduler behaviour flags across submit fencesChris Wilson2-26/+89
We want the bonded request to have the same scheduler properties as its master so that it is placed at the same depth in the queue. For example, consider we have requests A, B and B', where B & B' are a bonded pair to run in parallel on two engines. A -> B \- B' B will run after A and so may be scheduled on an idle engine and wait on A using a semaphore. B' sees B being executed and so enters the queue on the same engine as A. As B' did not inherit the semaphore-chain from B, it may have higher precedence than A and so preempts execution. However, B' then sits on a semaphore waiting for B, who is waiting for A, who is blocked by B. Ergo B' needs to inherit the scheduler properties from B (i.e. the semaphore chain) so that it is scheduled with the same priority as B and will not be executed ahead of Bs dependencies. Furthermore, to prevent the priorities changing via the expose fence on B', we need to couple in the dependencies for PI. This requires us to relax our sanity-checks that dependencies are strictly in order. v2: Synchronise (B, B') execution on all platforms, regardless of using a scheduler, any no-op syncs should be elided. Fixes: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding") Closes: https://gitlab.freedesktop.org/drm/intel/issues/464 Testcase: igt/gem_exec_balancer/bonded-chain Testcase: igt/gem_exec_balancer/bonded-semaphore 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/20191210151332.3902215-1-chris@chris-wilson.co.uk (cherry picked from commit c81471f5e95c79c55687282ff6800f112b5d560b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915/dsb: Fix in mmio offset calculation of DSB instanceAnimesh Manna1-1/+1
As the current usage is restricted to first DSB instance per pipe, so existing code could not catch the issue to calculate the mmio offset of different DSB instance per pipe. Corrected the offset calculation. Fixes: a6e58d9a2e04 ("drm/i915/dsb: Check DSB engine status.") Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205123513.22603-1-animesh.manna@intel.com (cherry picked from commit d04a661a2c7169b48782aa5e9d85d4b4383d562e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-13drm/i915/gvt: Pin vgpu dma address before usingTina Zhang4-4/+99
Dma-buf display uses the vgpu dma address saved in the guest part GGTT table which is updated by vCPU thread. In host side, when the dma address is used by qemu ui thread, gvt-g must make sure the dma address is validated before letting it go to the HW. Invalid guest dma address will easily cause DMA fault and make GPU hang. v2: Rebase Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191212141342.3417-1-tina.zhang@intel.com
2019-12-13drm/i915/gvt: set guest display buffer as readonlyZhenyu Wang1-0/+1
We shouldn't allow write for exposed guest display buffer which doesn't make sense. So explicitly set read only flag for display dmabuf allocated object. Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Cc: Tina Zhang <tina.zhang@intel.com> Acked-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191212084614.1100-1-zhenyuw@linux.intel.com
2019-12-11drm/i915: Serialise with remote retirementChris Wilson1-3/+23
Since retirement may be running in a worker on another CPU, it may be skipped in the local intel_gt_wait_for_idle(). To ensure the state is consistent for our sanity checks upon load, serialise with the remote retirer by waiting on the timeline->mutex. Outside of this use case, e.g. on suspend or module unload, we expect the slack to be picked up by intel_gt_pm_wait_for_idle() and so prefer to put the special case serialisation with retirement in its single user, for now at least. 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/20191121071044.97798-2-chris@chris-wilson.co.uk (cherry picked from commit 2d0fb251360ab7eccbffd99f6933a2a4de678d52) Fixes: 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree") Closes: https://gitlab.freedesktop.org/drm/intel/issues/754 Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-11drm/i915/gvt: use vgpu lock for active state settingZhenyu Wang1-2/+2
Need to align with deactivate, should only use vgpu's lock for active state setting instead of gvt lock. Fixes: f25a49ab8ab9 ("drm/i915/gvt: Use vgpu_lock to protect per vgpu access") Cc: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191202070109.73924-2-zhenyuw@linux.intel.com
2019-12-10drm/i915/gt: Detect if we miss WaIdleLiteRestoreChris Wilson1-25/+21
In order to avoid confusing the HW, we must never submit an empty ring during lite-restore, that is we should always advance the RING_TAIL before submitting to stay ahead of the RING_HEAD. Normally this is prevented by keeping a couple of spare NOPs in the request->wa_tail so that on resubmission we can advance the tail. This relies on the request only being resubmitted once, which is the normal condition as it is seen once for ELSP[1] and then later in ELSP[0]. On preemption, the requests are unwound and the tail reset back to the normal end point (as we know the request is incomplete and therefore its RING_HEAD is even earlier). However, if this w/a should fail we would try and resubmit the request with the RING_TAIL already set to the location of this request's wa_tail potentially causing a GPU hang. We can spot when we do try and incorrectly resubmit without advancing the RING_TAIL and spare any embarrassment by forcing the context restore. In the case of preempt-to-busy, we leave the requests running on the HW while we unwind. As the ring is still live, we cannot rewind our rq->tail without forcing a reload so leave it set to rq->wa_tail and only force a reload if we resubmit after a lite-restore. (Normally, the forced reload will be a part of the preemption event.) Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Closes: https://gitlab.freedesktop.org/drm/intel/issues/673 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@kernel.vger.org Link: https://patchwork.freedesktop.org/patch/msgid/20191209023215.3519970-1-chris@chris-wilson.co.uk (cherry picked from commit 82c69bf58650e644c61aa2bf5100b63a1070fd2f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-10drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()Ville Syrjälä5-28/+14
intel_hdcp_transcoder_config() is clobbering some globally visible state in .compute_config(). That is a big no no as .compute_config() is supposed to have no visible side effects when either the commit fails or it's just a TEST_ONLY commit. Inline this stuff into intel_hdcp_enable() so that the state only gets modified when we actually commit the state to the hardware. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Fixes: 39e2df090c3c ("drm/i915/hdcp: update current transcoder into intel_hdcp") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com> (cherry picked from commit 67e1d5ed85a83e232a9e0b995f5778a86722b96e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-10drm/i915/fbc: Disable fbc by default on all glk+Ville Syrjälä1-1/+1
We're missing a workaround in the fbc code for all glk+ platforms which can cause corruption around the top of the screen. So enabling fbc by default is a bad idea. I'm not keen to backport the w/a so let's start by disabling fbc by default on all glk+. We'll lift the restriction once the w/a is in place. Cc: stable@vger.kernel.org Cc: Daniel Drake <drake@endlessm.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jian-Hong Pan <jian-hong@endlessm.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit cd8c021b36a66833cefe2c90a79a9e312a2a5690) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-10drm/i915/perf: Configure OAR for specific contextUmesh Nerlige Ramappa1-87/+112
Gen12 supports saving/restoring render counters per context. Apply OAR configuration only for the context that is passed in to perf. v2: - Fix OACTXCONTROL value to only stop/resume counters. - Remove gen12_update_reg_state_unlocked as power state is already applied by the caller. v3: (Lionel) - Move register initialization into the array - Assume a valid oa_config in enable_metric_set Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-2-umesh.nerlige.ramappa@intel.com (cherry picked from commit ccdeed497042676e13fc1625e2a341880eff5da5) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-10drm/i915/perf: Allow non-privileged access when OA buffer is not sampledUmesh Nerlige Ramappa1-2/+3
SAMPLE_OA_REPORT enables sampling of OA reports from the OA buffer. Since reports from OA buffer had system wide visibility, collecting samples from the OA buffer was a privileged operation on previous platforms. Prior to TGL, it was also necessary to sample the OA buffer to normalize reports from MI REPORT PERF COUNT. TGL has a dedicated OAR unit to sample perf reports for a specific render context. This removes the necessity to sample OA buffer. - If not sampling the OA buffer, allow non-privileged access. An earlier patch allows the non-privilege access: https://patchwork.freedesktop.org/patch/337716/?series=68582&rev=1 - Clear up the path for non-privileged access in this patch Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 322d56aa3145a28445907ecc638a2c3aa3295c6b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-09drm/i915/gt: Save irqstate around virtual_context_destroyChris Wilson1-2/+3
As virtual_context_destroy() may be called from a request signal, it may be called from inside an irq-off section, and so we need to do a full save/restore of the irq state rather than blindly re-enable irqs upon unlocking. <4> [110.024262] WARNING: inconsistent lock state <4> [110.024277] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G U <4> [110.024292] -------------------------------- <4> [110.024305] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. <4> [110.024323] kworker/0:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes: <4> [110.024338] ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915] <4> [110.024592] {IN-HARDIRQ-W} state was registered at: <4> [110.024612] lock_acquire+0xa7/0x1c0 <4> [110.024627] _raw_spin_lock_irqsave+0x33/0x50 <4> [110.024788] intel_engine_breadcrumbs_irq+0x38c/0x600 [i915] <4> [110.024808] irq_work_run_list+0x49/0x70 <4> [110.024824] irq_work_run+0x26/0x50 <4> [110.024839] smp_irq_work_interrupt+0x44/0x1e0 <4> [110.024855] irq_work_interrupt+0xf/0x20 <4> [110.024871] __do_softirq+0xb7/0x47f <4> [110.024885] irq_exit+0xba/0xc0 <4> [110.024898] do_IRQ+0x83/0x160 <4> [110.024910] ret_from_intr+0x0/0x1d <4> [110.024922] irq event stamp: 172864 <4> [110.024938] hardirqs last enabled at (172863): [<ffffffff819ea214>] _raw_spin_unlock_irq+0x24/0x50 <4> [110.024963] hardirqs last disabled at (172864): [<ffffffff819e9fba>] _raw_spin_lock_irq+0xa/0x40 <4> [110.024988] softirqs last enabled at (172812): [<ffffffff81c00385>] __do_softirq+0x385/0x47f <4> [110.025012] softirqs last disabled at (172797): [<ffffffff810b829a>] irq_exit+0xba/0xc0 <4> [110.025031] other info that might help us debug this: <4> [110.025049] Possible unsafe locking scenario: <4> [110.025065] CPU0 <4> [110.025075] ---- <4> [110.025084] lock(&(&rq->lock)->rlock); <4> [110.025099] <Interrupt> <4> [110.025109] lock(&(&rq->lock)->rlock); <4> [110.025124] *** DEADLOCK *** <4> [110.025144] 4 locks held by kworker/0:0/5: <4> [110.025156] #0: ffff88827588f528 ((wq_completion)events){+.+.}, at: process_one_work+0x1de/0x620 <4> [110.025187] #1: ffffc9000006fe78 ((work_completion)(&engine->retire_work)){+.+.}, at: process_one_work+0x1de/0x620 <4> [110.025219] #2: ffff88825605e270 (&kernel#2){+.+.}, at: engine_retire+0x57/0xe0 [i915] <4> [110.025405] #3: ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915] <4> [110.025634] stack backtrace: <4> [110.025653] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G U 5.4.0-rc8-CI-CI_DRM_7489+ #1 <4> [110.025675] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017 <4> [110.025856] Workqueue: events engine_retire [i915] <4> [110.025872] Call Trace: <4> [110.025891] dump_stack+0x71/0x9b <4> [110.025907] mark_lock+0x49a/0x500 <4> [110.025926] ? print_shortest_lock_dependencies+0x200/0x200 <4> [110.025946] mark_held_locks+0x49/0x70 <4> [110.025962] ? _raw_spin_unlock_irq+0x24/0x50 <4> [110.025978] lockdep_hardirqs_on+0xa2/0x1c0 <4> [110.025995] _raw_spin_unlock_irq+0x24/0x50 <4> [110.026171] virtual_context_destroy+0xc5/0x2e0 [i915] <4> [110.026376] __active_retire+0xb4/0x290 [i915] <4> [110.026396] dma_fence_signal_locked+0x9e/0x1b0 <4> [110.026613] i915_request_retire+0x451/0x930 [i915] <4> [110.026766] retire_requests+0x4d/0x60 [i915] <4> [110.026919] engine_retire+0x63/0xe0 [i915] Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") 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/20191205145934.663183-1-chris@chris-wilson.co.uk (cherry picked from commit 6f7ac8285371fb0df58aba861eaab387f79ed04d) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-06Merge tag 'drm-next-2019-12-06' of git://anongit.freedesktop.org/drm/drmLinus Torvalds28-107/+367
Pull more drm updates from Dave Airlie: "Rob pointed out I missed his pull request for msm-next, it's been in next for a while outside of my tree so shouldn't cause any unexpected issues, it has some OCMEM support in drivers/soc that is acked by other maintainers as it's outside my tree. Otherwise it's a usual fixes pull, i915, amdgpu, the main ones, with some tegra, omap, mgag200 and one core fix. Summary: msm-next: - OCMEM support for a3xx and a4xx GPUs. - a510 support + display support core: - mst payload deletion fix i915: - uapi alignment fix - fix for power usage regression due to security fixes - change default preemption timeout to 640ms from 100ms - EHL voltage level display fixes - TGL DGL PHY fix - gvt - MI_ATOMIC cmd parser fix, CFL non-priv warning - CI spotted deadlock fix - EHL port D programming fix amdgpu: - VRAM lost fixes on BACO for CI/VI - navi14 DC fixes - misc SR-IOV, gfx10 fixes - XGMI fixes for arcturus - SRIOV fixes amdkfd: - KFD on ppc64le enabled - page table optimisations radeon: - fix for r1xx/2xx register checker. tegra: - displayport regression fixes - DMA API regression fixes mgag200: - fix devices that can't scanout except at 0 addr omap: - fix dma_addr refcounting" * tag 'drm-next-2019-12-06' of git://anongit.freedesktop.org/drm/drm: (100 commits) drm/dp_mst: Correct the bug in drm_dp_update_payload_part1() drm/omap: fix dma_addr refcounting drm/tegra: Run hub cleanup on ->remove() drm/tegra: sor: Make the +5V HDMI supply optional drm/tegra: Silence expected errors on IOMMU attach drm/tegra: vic: Export module device table drm/tegra: sor: Implement system suspend/resume drm/tegra: Use proper IOVA address for cursor image drm/tegra: gem: Remove premature import restrictions drm/tegra: gem: Properly pin imported buffers drm/tegra: hub: Remove bogus connection mutex check ia64: agp: Replace empty define with do while agp: Add bridge parameter documentation agp: remove unused variable num_segments agp: move AGPGART_MINOR to include/linux/miscdevice.h agp: remove unused variable size in agp_generic_create_gatt_table drm/dp_mst: Fix build on systems with STACKTRACE_SUPPORT=n drm/radeon: fix r1xx/r2xx register checker for POT textures drm/amdgpu: fix GFX10 missing CSIB set(v3) drm/amdgpu: should stop GFX ring in hw_fini ...
2019-12-03drm/i915/ehl: Make icp_digital_port_connected() use phy instead of portMatt Roper1-7/+5
When looking at SDEISR to determine the connection status of combo outputs, we should use the phy index rather than the port index. Although they're usually the same thing, EHL's DDI-D (port D) is attached to PHY-A and SDEISR doesn't even have bits for a "D" output. It's also possible that future platforms may map DDIs (the internal display engine programming units) to PHYs (the output handling on the IO side) in ways where port!=phy, so let's look at the PHY index by default. v2: Rename to intel_combo_phy_connected. (Lucas) Fixes: 719d24002602 ("drm/i915/ehl: Enable DDI-D") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127221314.575575-2-matthew.d.roper@intel.com (cherry picked from commit 3d1e388d4072dd240e558709d2f73605a742a723) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-02Merge tag 'kbuild-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds1-1/+0
Pull Kbuild updates from Masahiro Yamada: - remove unneeded asm headers from hexagon, ia64 - add 'dir-pkg' target, which works like 'tar-pkg' but skips archiving - add 'helpnewconfig' target, which shows help for new CONFIG options - support 'make nsdeps' for external modules - make rebuilds faster by deleting $(wildcard $^) checks - remove compile tests for kernel-space headers - refactor modpost to simplify modversion handling - make single target builds faster - optimize and clean up scripts/kallsyms.c - refactor various Makefiles and scripts * tag 'kbuild-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (59 commits) MAINTAINERS: update Kbuild/Kconfig maintainer's email address scripts/kallsyms: remove redundant initializers scripts/kallsyms: put check_symbol_range() calls close together scripts/kallsyms: make check_symbol_range() void function scripts/kallsyms: move ignored symbol types to is_ignored_symbol() scripts/kallsyms: move more patterns to the ignored_prefixes array scripts/kallsyms: skip ignored symbols very early scripts/kallsyms: add const qualifiers where possible scripts/kallsyms: make find_token() return (unsigned char *) scripts/kallsyms: replace prefix_underscores_count() with strspn() scripts/kallsyms: add sym_name() to mitigate cast ugliness scripts/kallsyms: remove unneeded length check for prefix matching scripts/kallsyms: remove redundant is_arm_mapping_symbol() scripts/kallsyms: set relative_base more effectively scripts/kallsyms: shrink table before sorting it scripts/kallsyms: fix definitely-lost memory leak scripts/kallsyms: remove unneeded #ifndef ARRAY_SIZE kbuild: make single target builds even faster modpost: respect the previous export when 'exported twice' is warned modpost: do not set ->preloaded for symbols from Module.symvers ...
2019-12-02Merge tag 'gvt-next-fixes-2019-12-02' of https://github.com/intel/gvt-linux into drm-intel-next-fixesJoonas Lahtinen2-5/+6
gvt-next-fixes-2019-12-02 - Fix cmd parser for MI_ATOMIC (Zhenyu) - Fix non-priv register access warning on CFL (Fred) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202051711.GZ4196@zhen-hp.sh.intel.com
2019-12-02drm/i915/gem: Take timeline->mutex to walk list-of-requestsChris Wilson1-2/+2
Though the context is closed and so no more requests can be added to the timeline, retirement can still be removing requests. It can even be removing the very request we are inspecting and so cause us to wander into dead links. Serialise with the retirement by taking the timeline->mutex used for guarding the timeline->requests list. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112404 Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()") 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> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191129151845.1092933-1-chris@chris-wilson.co.uk (cherry picked from commit 7ce596a8036cf3a4cb9ffa0c4edd8a76a7a43cc3) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-02drm/i915/gvt: Fix cmd length check for MI_ATOMICZhenyu Wang1-3/+3
Correct valid command length check for MI_ATOMIC, need to check inline data available field instead of operand data length for whole command. Fixes: 00a33be40634 ("drm/i915/gvt: Add valid length check for MI variable commands") Reported-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Gao Fred <fred.gao@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-11-27Merge tag 'drm-next-2019-11-27' of git://anongit.freedesktop.org/drm/drmLinus Torvalds273-15309/+26935
Pull drm updates from Dave Airlie: "Lots of stuff in here, though it hasn't been too insane this merge apart from dealing with the security fun. uapi: - export different colorspace properties on DP vs HDMI - new fourcc for ARM 16x16 block format - syncobj: allow querying last submitted timeline value - DRM_FORMAT_BIG_ENDIAN defined as unsigned core: - allow using gem vma manager in ttm - connector/encoder/bridge doc fixes - allow more than 3 encoders for a connector - displayport mst suspend/resume reprobing support - vram lazy unmapping, uniform vram mm and gem vram - edid cleanups + AVI informframe bar info - displayport helpers - dpcd parser added dp_cec: - Allow a connector to be associated with a cec device ttm: - pipelining with no_gpu_wait fix - always keep BOs on the LRU sched: - allow free_job routine to sleep i915: - Block userptr from mappable GTT - i915 perf uapi versioning - OA stream dynamic reconfiguration - make context persistence optional - introduce DRM_I915_UNSTABLE Kconfig - add fake lmem testing under unstable - BT.2020 support for DP MSA - struct mutex elimination - Tigerlake display/PLL/power management improvements - Jasper Lake PCH support - refactor PMU for multiple GPUs - Icelake firmware update - Split out vga + switcheroo code amdgpu: - implement dma-buf import/export without helpers - vega20 RAS enablement - DC i2c over aux fixes - renoir GPU reset - DC HDCP support - BACO support for CI/VI asics - MSI-X support - Arcturus EEPROM support - Arcturus VCN encode support - VCN dynamic powergating on RV/RV2 amdkfd: - add navi12/14/renoir support to kfd radeon: - SI dpm fix ported from amdgpu - fix bad DMA on ppc platforms gma500: - memory leak fixes qxl: - convert to new gem mmap exynos: - build warning fix komeda: - add aclk sysfs attribute v3d: - userspace cleanup uapi change i810: - fix for underflow in dispatch ioctls ast: - refactor show_cursor mgag200: - refactor show_cursor arcgpu: - encoder finding improvements mediatek: - mipi_tx, dsi and partial crtc support for MT8183 SoC - rotation support meson: - add suspend/resume support omap: - misc refactors tegra: - DisplayPort support for Tegra 210, 186 and 194. - IOMMU-backed DMA API fixes panfrost: - fix lockdep issue - simplify devfreq integration rcar-du: - R8A774B1 SoC support - fixes for H2 ES2.0 sun4i: - vcc-dsi regulator support virtio-gpu: - vmexit vs spinlock fix - move to gem shmem helpers - handle large command buffers with cma" * tag 'drm-next-2019-11-27' of git://anongit.freedesktop.org/drm/drm: (1855 commits) drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10 drm/amdgpu: initialize vm_inv_eng0_sem for gfxhub and mmhub drm/amd/amdgpu/sriov skip RLCG s/r list for arcturus VF. drm/amd/amdgpu/sriov temporarily skip ras,dtm,hdcp for arcturus VF drm/amdgpu/gfx10: re-init clear state buffer after gpu reset merge fix for "ftrace: Rework event_create_dir()" drm/amdgpu: Update Arcturus golden registers drm/amdgpu/gfx10: fix out-of-bound mqd_backup array access drm/amdgpu/gfx10: explicitly wait for cp idle after halt/unhalt Revert "drm/amd/display: enable S/G for RAVEN chip" drm/amdgpu: disable gfxoff on original raven drm/amdgpu: remove experimental flag for Navi14 drm/amdgpu: disable gfxoff when using register read interface drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK (v2) drm/amdgpu: fix bad DMA from INTERRUPT_CNTL2 drm/radeon: fix bad DMA from INTERRUPT_CNTL2 drm/amd/display: Fix debugfs on MST connectors drm/amdgpu/nv: add asic func for fetching vbios from rom directly drm/amdgpu: put flush_delayed_work at first drm/amdgpu/vcn2.5: fix the enc loop with hw fini ...
2019-11-27drm/i915: Reduce nested prepare_remote_context() to a trylockChris Wilson1-4/+17
On context retiring, we may invoke the kernel_context to unpin this context. Elsewhere, we may use the kernel_context to modify this context. This currently leads to an AB-BA lock inversion, so we need to back-off from the contended lock, and repeat. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111732 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126065521.2331017-1-chris@chris-wilson.co.uk (cherry picked from commit 58b4c1a07ada7fb91ea757bdb9bd47df02207357) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-27drm/i915: Default to a more lenient forced preemption timeoutChris Wilson1-1/+1
Based on a sampling of a number of benchmarks across platforms, by default opt for a much more lenient timeout so that we should not adversely affect existing "good" clients. 640ms ought to be enough for anyone. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191125162737.2161069-1-chris@chris-wilson.co.uk (cherry picked from commit 5766a5ffc6a69595903865518c43636bde0e4ac4) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-27drm/i915/gvt: Update force-to-nonpriv register whitelistGao, Fred1-0/+1
Host print below warning message when creating guest: "gvt: vgpu(1) Invalid FORCE_NONPRIV write 10002349". Add register 0x2348 in force-to-nonpriv whitelist as required by guest. Signed-off-by: Gao, Fred <fred.gao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-11-27drm/i915/gvt: Refine non privilege register address calucationGao, Fred1-2/+2
The BitField of non privilege register address is only from bit 2 to 25. v2: use REG_GENMASK instead. (Zhenyu) Signed-off-by: Gao, Fred <fred.gao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-11-26Merge branch 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds4-6/+5
Pull locking updates from Ingo Molnar: "The main changes in this cycle were: - A comprehensive rewrite of the robust/PI futex code's exit handling to fix various exit races. (Thomas Gleixner et al) - Rework the generic REFCOUNT_FULL implementation using atomic_fetch_* operations so that the performance impact of the cmpxchg() loops is mitigated for common refcount operations. With these performance improvements the generic implementation of refcount_t should be good enough for everybody - and this got confirmed by performance testing, so remove ARCH_HAS_REFCOUNT and REFCOUNT_FULL entirely, leaving the generic implementation enabled unconditionally. (Will Deacon) - Other misc changes, fixes, cleanups" * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (27 commits) lkdtm: Remove references to CONFIG_REFCOUNT_FULL locking/refcount: Remove unused 'refcount_error_report()' function locking/refcount: Consolidate implementations of refcount_t locking/refcount: Consolidate REFCOUNT_{MAX,SATURATED} definitions locking/refcount: Move saturation warnings out of line locking/refcount: Improve performance of generic REFCOUNT_FULL code locking/refcount: Move the bulk of the REFCOUNT_FULL implementation into the <linux/refcount.h> header locking/refcount: Remove unused refcount_*_checked() variants locking/refcount: Ensure integer operands are treated as signed locking/refcount: Define constants for saturation and max refcount values futex: Prevent exit livelock futex: Provide distinct return value when owner is exiting futex: Add mutex around futex exit futex: Provide state handling for exec() as well futex: Sanitize exit state handling futex: Mark the begin of futex exit explicitly futex: Set task::futex_state to DEAD right after handling futex exit futex: Split futex_mm_release() for exit/exec exit/exec: Seperate mm_release() futex: Replace PF_EXITPIDONE with a state ...
2019-11-26Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-1/+1
Pull RCU updates from Ingo Molnar: "The main changes in this cycle were: - Dynamic tick (nohz) updates, perhaps most notably changes to force the tick on when needed due to lengthy in-kernel execution on CPUs on which RCU is waiting. - Linux-kernel memory consistency model updates. - Replace rcu_swap_protected() with rcu_prepace_pointer(). - Torture-test updates. - Documentation updates. - Miscellaneous fixes" * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (51 commits) security/safesetid: Replace rcu_swap_protected() with rcu_replace_pointer() net/sched: Replace rcu_swap_protected() with rcu_replace_pointer() net/netfilter: Replace rcu_swap_protected() with rcu_replace_pointer() net/core: Replace rcu_swap_protected() with rcu_replace_pointer() bpf/cgroup: Replace rcu_swap_protected() with rcu_replace_pointer() fs/afs: Replace rcu_swap_protected() with rcu_replace_pointer() drivers/scsi: Replace rcu_swap_protected() with rcu_replace_pointer() drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer() x86/kvm/pmu: Replace rcu_swap_protected() with rcu_replace_pointer() rcu: Upgrade rcu_swap_protected() to rcu_replace_pointer() rcu: Suppress levelspread uninitialized messages rcu: Fix uninitialized variable in nocb_gp_wait() rcu: Update descriptions for rcu_future_grace_period tracepoint rcu: Update descriptions for rcu_nocb_wake tracepoint rcu: Remove obsolete descriptions for rcu_barrier tracepoint rcu: Ensure that ->rcu_urgent_qs is set before resched IPI workqueue: Convert for_each_wq to use built-in list check rcu: Several rcu_segcblist functions can be static rcu: Remove unused function hlist_bl_del_init_rcu() Documentation: Rename rcu_node_context_switch() to rcu_note_context_switch() ...
2019-11-26drm/i915/gt: Make intel_ring_unpin() safe for concurrent pintChris Wilson1-9/+4
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") allowed the intel_ring unpinning to be run concurrently with the next context pinning it. Thus each step in intel_ring_unpin() needed to be atomic and ordered in a nice onion with intel_ring_pin() so that the lifetimes overlapped and were always safe. Sadly, a few steps in intel_ring_unpin() were overlooked, such as closing the read/write pointers of the ring and discarding the intel_ring.vaddr, as these steps were not serialised with intel_ring_pin() and so could leave the ring in disarray. Fixes: 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-6-chris@chris-wilson.co.uk (cherry picked from commit a266bf42006004306dd48a9082c35dfbff153307) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Schedule request retirement when timeline idlesChris Wilson7-3/+108
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA") is that it disables RC6 while Skylake (and friends) is active, and we do not consider the GPU idle until all outstanding requests have been retired and the engine switched over to the kernel context. If userspace is idle, this task falls onto our background idle worker, which only runs roughly once a second, meaning that userspace has to have been idle for a couple of seconds before we enable RC6 again. Naturally, this causes us to consume considerably more energy than before as powersaving is effectively disabled while a display server (here's looking at you Xorg) is running. As execlists will get a completion event as each context is completed, we can use this interrupt to queue a retire worker bound to this engine to cleanup idle timelines. We will then immediately notice the idle engine (without userspace intervention or the aid of the background retire worker) and start parking the GPU. Thus during light workloads, we will do much more work to idle the GPU faster... Hopefully with commensurate power saving! v2: Watch context completions and only look at those local to the engine when retiring to reduce the amount of excess work we perform. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112315 References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA") References: 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") 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/20191125105858.1718307-3-chris@chris-wilson.co.uk (cherry picked from commit 4f88f8747fa43c97c3b3712d8d87295ea757cc51) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Adapt engine_park synchronisation rules for engine_retireChris Wilson1-6/+21
In the next patch, we will introduce a new asynchronous retirement worker, fed by execlists CS events. Here we may queue a retirement as soon as a request is submitted to HW (and completes instantly), and we also want to process that retirement as early as possible and cannot afford to postpone (as there may not be another opportunity to retire it for a few seconds). To allow the new async retirer to run in parallel with our submission, pull the __i915_request_queue (that passes the request to HW) inside the timelines spinlock so that the retirement cannot release the timeline before we have completed the submission. v2: Actually to play nicely with engine_retire, we have to raise the timeline.active_lock before releasing the HW. intel_gt_retire_requsts() is still serialised by the outer lock so they cannot see this intermediate state, and engine_retire is serialised by HW submission. 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/20191125105858.1718307-2-chris@chris-wilson.co.uk (cherry picked from commit 88a4655e75ac8f55eea5e3f38b176cba9cf653b5) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/execlists: Fixup cancel_port_requests()Chris Wilson1-9/+7
I rushed a last minute correction to cancel_port_requests() to prevent the snooping of *execlists->active as the inflight array was being updated, without noticing we iterated the inflight array starting from active! Oops. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112387 Fixes: 97f9af78f38d ("drm/i915/gt: Mark the execlists->active as the primary volatile access") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191125112520.1760492-1-chris@chris-wilson.co.uk (cherry picked from commit da0ef77e1e0ccff703efee82406c629d5c4f4bbb) [Joonas: Fixed Fixes: tag to match drm-intel-next-fixes] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Mark the execlists->active as the primary volatile accessChris Wilson2-13/+18
Since we want to do a lockless read of the current active request, and that request is written to by process_csb also without serialisation, we need to instruct gcc to take care in reading the pointer itself. Otherwise, we have observed execlists_active() to report 0x40. [ 2400.760381] igt/para-4098 1..s. 2376479300us : process_csb: rcs0 cs-irq head=3, tail=4 [ 2400.760826] igt/para-4098 1..s. 2376479303us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 [ 2400.761271] igt/para-4098 1..s. 2376479306us : trace_ports: rcs0: promote { b9c59:2622, b9c55:2624 } [ 2400.761726] igt/para-4097 0d... 2376479311us : __i915_schedule: rcs0: -2147483648->3, inflight:0000000000000040, rq:ffff888208c1e940 which is impossible! The answer is that as we keep the existing execlists->active pointing into the array as we copy over that array, the unserialised read may see a partial pointer value. Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") 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/20191125094318.1630806-1-chris@chris-wilson.co.uk (cherry picked from commit 331bf90591573dfe6c8e892239713ef9702f1396) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Unlock engine-pm after queuing the kernel context switchChris Wilson1-7/+40
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend"), I erroneously concluded that we last modify the engine inside __i915_request_commit() meaning that we could enable concurrent submission for userspace as we enqueued this request. However, this falls into a trap with other users of the engine->kernel_context waking up and submitting their request before the idle-switch is queued, with the result that the kernel_context is executed out-of-sequence most likely upsetting the GPU and certainly ourselves when we try to retire the out-of-sequence requests. As such we need to hold onto the effective engine->kernel_context mutex lock (via the engine pm mutex proxy) until we have finish queuing the request to the engine. v2: Serialise against concurrent intel_gt_retire_requests() v3: Describe the hairy locking scheme with intel_gt_retire_requests() for future reference. v4: Combine timeline->lock and engine pm release; it's hairy. Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-2-chris@chris-wilson.co.uk (cherry picked from commit 5cba288466e9b229feb68295675246e7522fb5eb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Close race between engine_park and intel_gt_retire_requestsChris Wilson3-12/+32
The general concept was that intel_timeline.active_count was locked by the intel_timeline.mutex. The exception was for power management, where the engine->kernel_context->timeline could be manipulated under the global wakeref.mutex. This was quite solid, as we always manipulated the timeline only while we held an engine wakeref. And then we started retiring requests outside of struct_mutex, only using the timelines.active_list and the timeline->mutex. There we started manipulating intel_timeline.active_count outside of an engine wakeref, and so introduced a race between __engine_park() and intel_gt_retire_requests(), a race that could result in the engine->kernel_context not being added to the active timelines and so losing requests, which caused us to keep the system permanently powered up [and unloadable]. The race would be easy to close if we could take the engine wakeref for the timeline before we retire -- except timelines are not bound to any engine and so we would need to keep all active engines awake. The alternative is to guard intel_timeline_enter/intel_timeline_exit for use outside of the timeline->mutex. Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191120165514.3955081-1-chris@chris-wilson.co.uk (cherry picked from commit a6edbca74b305adc165e67065d7ee766006e6a48) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915: Mark up the calling context for intel_wakeref_put()Chris Wilson11-25/+54
Previously, we assumed we could use mutex_trylock() within an atomic context, falling back to a worker if contended. However, such trickery is illegal inside interrupt context, and so we need to always use a worker under such circumstances. As we normally are in process context, we can typically use a plain mutex, and only defer to a work when we know we are being called from an interrupt path. Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref") References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") References: https://bugs.freedesktop.org/show_bug.cgi?id=111626 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/20191120125433.3767149-1-chris@chris-wilson.co.uk (cherry picked from commit 07779a76ee1f93f930cf697b22be73d16e14f50c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915: Wait until the intel_wakeref idle callback is completeChris Wilson2-2/+26
When waiting for idle, serialise with any ongoing callback so that it will have completed before completing the wait. 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/20191118230254.2615942-12-chris@chris-wilson.co.uk (cherry picked from commit f4ba0707c825d60f1d0f5ce7bd3d875e68f3e204) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_stateChris Wilson1-1/+1
pm_suspend_target_state is declared under CONFIG_PM_SLEEP but only defined under CONFIG_SUSPEND. Play safe and only use the symbol if it is both declared and defined. Reported-by: kbuild-all@lists.01.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: a70a9e998e8e ("drm/i915: Defer rc6 shutdown to suspend_late") Cc: Andi Shyti <andi.shyti@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191120182209.3967833-1-chris@chris-wilson.co.uk Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/query: Align flavour of engine data lookupTvrtko Ursulin1-2/+5
Commit 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") changed the engine query to iterate over uabi engines but left the buffer size calculation look at the physical engine count. Difference has no practical consequence but it is nicer to align both queries. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191122104115.29610-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 9acc99d8f278e3da398e927774431bd3e947ab2e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/tgl: Add DKL PHY vswing table for HDMIMatt Roper1-5/+24
The bspec initially provided a single DKL PHY vswing table for both HDMI and DP, but was recently updated to include an independent table for HDMI. Bspec: 49292 Fixes: 978c3e539be2 ("drm/i915/tgl: Add dkl phy programming sequences") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118180219.9309-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 362bfb995b78394aefe61f7cc0511ef7c50bb11e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25drm/i915/ehl: Update voltage level checksMatt Roper1-1/+3
The bspec was recently updated with new cdclk -> voltage level tables to accommodate the new 324/326.4 cdclk values. Bspec: 21809 Fixes: 63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit d147483884ed08ee6bb618ef610ee0329a27fda7) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-25locking/refcount: Consolidate implementations of refcount_tWill Deacon1-1/+0
The generic implementation of refcount_t should be good enough for everybody, so remove ARCH_HAS_REFCOUNT and REFCOUNT_FULL entirely, leaving the generic implementation enabled unconditionally. Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Tested-by: Hanjun Guo <guohanjun@huawei.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20191121115902.2551-9-will@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-11-22Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()"Chris Wilson1-2/+7
From inside an active timeline in the execbuf ioctl, we may try to reclaim some space in the GGTT. We need GGTT space for all objects on !full-ppgtt platforms, and for context images everywhere. However, to free up space in the GGTT we may need to remove some pinned objects (e.g. context images) that require flushing the idle barriers to remove. For this we use the big hammer of intel_gt_wait_for_idle() However, commit 7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()") will continue spinning on the wait if a timeline is active but lacks requests, as is the case during execbuf reservation. Spinning forever is quite time consuming, so revert that commit and start again. In practice, the effect commit 7936a22dd466 was trying to achieve is accomplished by commit 1683d24c1470 ("drm/i915/gt: Move new timelines to the end of active_list"), so there is no immediate rush to replace the looping. Testcase: igt/gem_exec_reloc/basic-range Fixes: a46bfdc83fee ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()") References: 1683d24c1470 ("drm/i915/gt: Move new timelines to the end of active_list") 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> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-1-chris@chris-wilson.co.uk (cherry picked from commit 689122dcc36e08f53732adf7ae0246f62eff3eb6) [Joonas: Corrected Fixes: tag ref to match drm-intel-next-fixes] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-11-21drm/i915/fbdev: Restore physical addresses for fb_mmap()Chris Wilson1-4/+5
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: Neil MacLeod <freedesktop@nmacleod.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Neil MacLeod <freedesktop@nmacleod.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk (cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-11-20Merge tag 'gvt-next-fixes-2019-11-12' of https://github.com/intel/gvt-linux into drm-intel-next-fixesJoonas Lahtinen1-0/+4
gvt-next-fixes-2019-11-12 - Remove PVINFO read for initial state (Tina) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112062032.GO4196@zhen-hp.sh.intel.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.