summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-04-16drm/i915: fully convert the IRQ initialization macros to intel_uncorePaulo Zanoni
Make them take the uncore argument from the caller instead of passing the implicit &dev_priv->uncore directly. This will allow us to finally pass something that's not dev_priv->uncore in the future, and gets rid of the implicit variables in register macros. v2: Rebase on top of the newer patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-6-paulo.r.zanoni@intel.com
2019-04-16drm/i915: convert the IRQ initialization functions to intel_uncorePaulo Zanoni
The IRQ initialization helpers are simple and self-contained. Continue the transition started in the recent uncore rework to get us rid of I915_READ/WRITE and the implicit dev_priv variables. While the implicit dev_priv is removed from the IRQ initialization helpers, we didn't get rid of them in the macro callers. Doing that should be very simple now. v2: Rebase on top of the new patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-5-paulo.r.zanoni@intel.com
2019-04-16drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registersPaulo Zanoni
This discussion started because we use token pasting in the GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an empty argument to those macros, making the code a little weird. The original proposal was to just add a comment as the empty argument, but Ville suggested we just add a prefix to the registers, and that indeed sounds like a more elegant solution. Now doing this is kinda against our rules for register naming since we only add gens or platform names as register prefixes when the given gen/platform changes a register that already existed before. On the other hand, we have so many instances of IIR/IMR in comments that adding a prefix would make the users of these register more easily findable, in addition to make our token pasting macros actually readable. So IMHO opening an exception here is worth it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
2019-04-16drm/i915: don't specify the IRQ register in the gen2 macrosPaulo Zanoni
Like the gen3+ macros, the gen2 versions of the IRQ initialization macros take the register name in the 'type' argument. But gen2 only has one set of registers, so there's really no need to specify the type. This commit removes the type argument and uses the registers directly instead of passing them through variables. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-3-paulo.r.zanoni@intel.com
2019-04-16drm/i915: refactor the IRQ init/reset macrosPaulo Zanoni
The whole point of having macros here is for the token pasting necessary to automatically have IMR, IIR and IER selected. We don't really need or want all the inlining that happens as a consequence. The good thing about the current code is that it works regardless of the relative offsets between these registers (they change after gen4, with the usual VLV/CHV exceptions). One thing which we can do is to split the logic of what we do with imr/ier/iir to functions separate from the macros that pick them. That's what we do in this commit. This allows us to get rid of the gen8 duplicates and also all the inlining: add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565) Function old new delta gen3_irq_reset - 233 +233 gen3_irq_init - 151 +151 i8xx_irq_postinstall 459 442 -17 gen11_irq_postinstall 804 744 -60 ironlake_irq_postinstall 450 353 -97 vlv_display_irq_postinstall 348 245 -103 i965_irq_postinstall 378 272 -106 i915_irq_postinstall 333 227 -106 gen8_irq_power_well_post_enable 374 240 -134 ironlake_irq_reset 397 218 -179 vlv_display_irq_reset 616 433 -183 i965_irq_reset 374 180 -194 cherryview_irq_reset 379 185 -194 i915_irq_reset 407 209 -198 ibx_irq_reset 332 133 -199 gen5_gt_irq_postinstall 533 332 -201 gen8_irq_power_well_pre_disable 434 204 -230 gen8_gt_irq_postinstall 469 196 -273 gen8_de_irq_postinstall 1200 836 -364 gen5_gt_irq_reset 471 76 -395 gen8_gt_irq_reset 775 99 -676 gen8_irq_reset 1100 333 -767 gen11_irq_reset 1959 686 -1273 Total: Before=2259222, After=2253657, chg -0.25% v2: - Make checkpatch happy with a temporary which_ (Checkpatch). - Reorder the arguments for the INIT macros (Ville). - Correctly explain when the register offsets change in the commit message (Ville). - Use more line breaks in the macro calls to make the arguments look a little more organized/readable. - Update the bloat-o-meter output (minor change only). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-2-paulo.r.zanoni@intel.com
2019-04-16Merge tag 'gvt-next-2019-04-16' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
drm-intel-next-queued gvt-next-2019-04-16 - Refine range of MCHBAR snapshot (Yakui) - Refine out-of-sync page struct (Yakui) - Remove unused vGPU sreg (Yan) - Refind MMIO reg names (Xiaolin) - Proper handling of sync/async flip (Colin) - Proper handling of PIPE_CONTROL/MI_FLUSH_DW index mode (Xiaolin) - EXCC reg mask fix (Colin) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416084814.GH17995@zhen-hp.sh.intel.com
2019-04-16drm/i915: Mark up ips for RCU protectionChris Wilson
drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in comparison expression (different address spaces) drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in comparison expression (different address spaces) 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/20190412085410.10392-3-chris@chris-wilson.co.uk
2019-04-16drm/i915: Drop bool return from breadcrumbs signalerChris Wilson
Since removal of the "missed interrupt detection" nobody used the result of whether or not we signaled anybody during that invocation, so now remove the return value. References: 789659f4307a ("drm/i915: Drop fake breadcrumb irq") 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/20190416085218.431-1-chris@chris-wilson.co.uk
2019-04-16drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio listColin Xu
According to GFX PRM on 01.org, bit 31:16 of mmio 0x22028 should be masks. Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16drm/i915/gvt: addressed guest GPU hang with HWS index modeXiaolin Zhang
with the introduce of "switch to use HWS indices rather than address", guest GPU hang observed when running workloads which will update the seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang. this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and patch guest GPU HWSP address value to these commands. Fixes: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16Merge tag 'drm-intel-next-2019-04-04' into gvt-nextZhenyu Wang
Merge back drm-intel-next for engine name definition refinement and 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") that would need gvt fixes to depend on. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-15drm/i915: Nuke drm_crtc_state and use intel_atomic_state insteadManasi Navare
This is one of the patches to start replacing drm pointers and use the intel_atomic_state and intel_crtc to derive the necessary intel state variables required for the intel modeset functions. v3: * Remove the unwanted newline (Ville) v2: * Flip the function arguments (Ville) * Remove some remaining instances of drm pointers (Ville) * Use old_crtc_state and new_crtc_state (Ville) Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190415182210.13347-1-manasi.d.navare@intel.com
2019-04-15drm/i915/selftests: Skip live timeline/suspend tests if wedgedChris Wilson
If the driver is wedged, we can not issue the requests to exercise the timelines or the system across suspend, so skip the tests. live_hangcheck is there to fail if we cannot recover. 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/20190413125820.14112-4-chris@chris-wilson.co.uk
2019-04-13drm/i915: Teach intel_workarounds to use uncore mmio accessChris Wilson
Start weaning ourselves off the implicit I915_WRITE macro madness and start using the explicit intel_uncore mmio access. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412202458.10653-1-chris@chris-wilson.co.uk
2019-04-12drm/i915/ehl: Inherit Ice Lake conditional codeBob Paauwe
Most of the conditional code for ICELAKE also applies to ELKHARTLAKE so use IS_GEN(dev_priv, 11) even for PM and Workarounds for now. v2: - Rename commit (Jose) - Include a wm workaround (Jose and Lucas) - Include display core init (Jose and Lucas) v3: Add a missing case of gen greater-than 11 (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412180920.22347-1-rodrigo.vivi@intel.com
2019-04-12drm/i915: Handle catastrophic error on engine resetMika Kuoppala
If cat error is set, we need to clear it by acking it. Further, if it is set, we must not do a normal request for reset. v2: avoid goto (Chris) v3: comment, error format, direct assign (Chris) Bspec: 12567 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190412165353.16432-1-mika.kuoppala@linux.intel.com
2019-04-12drm/i915: Shortcut readiness to reset checkMika Kuoppala
If the engine says it is ready for reset, it is ready so avoid further dancing and proceed. v2: reg (Chris) v3: request, ack, mask from following patch (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190412165335.16347-1-mika.kuoppala@linux.intel.com
2019-04-12drm/i915: Suppress spurious combo PHY B warningVille Syrjälä
On ICL the DMC doesn't reinit combo PHY B so we should not warn about its state being bogus during the display core uninit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411143349.17934-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-04-12drm/i915: Restore correct bxt_ddi_phy_calc_lane_lat_optim_mask() calculationVille Syrjälä
We are no longer calling bxt_ddi_phy_calc_lane_lat_optim_mask() when intel{hdmi,dp}_compute_config() succeeds, and instead only call it when those fail. This is fallout from the bool->int .compute_config() conversion which failed to invert the return value check before calling bxt_ddi_phy_calc_lane_lat_optim_mask(). Let's just replace it with an early bailout so that it's harder to miss. This restores the correct latency optim setting calculation (which could fix some real failures), and avoids the MISSING_CASE() from bxt_ddi_phy_calc_lane_lat_optim_mask() after intel{hdmi,dp}_compute_config() has failed. Cc: Lyude Paul <lyude@redhat.com> Fixes: 204474a6b859 ("drm/i915: Pass down rc in intel_encoder->compute_config()") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109373 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411164925.28491-1-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2019-04-12drm/i915: Flush the CSB pointer resetChris Wilson
The HW resets it CSB tail pointer on resetting the engine. Most of the time. In case it doesn't (and for system resume) we write the expected value anyway. For extra paranoia, flush the write before we invalidate the cacheline. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412110159.10495-1-chris@chris-wilson.co.uk
2019-04-12drm/i915: Fix the inconsistent RMW in WA 827Radhakrishna Sripada
RMW is used only in the disable path. Using it in enable path for consistency. Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190330011921.10397-2-radhakrishna.sripada@intel.com
2019-04-12drm/i915: Rename skl_wa_clkgating to the actual WARadhakrishna Sripada
No functional change. Renaming the function to reflect the specific WA. Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190330011921.10397-1-radhakrishna.sripada@intel.com
2019-04-11drm/i915: Do not enable FEC without DSCVille Syrjälä
Currently we enable FEC even when DSC is no used. While that is theoretically valid supposedly there isn't much of a benefit from this. But more importantly we do not account for the FEC link bandwidth overhead (2.4%) in the non-DSC link bandwidth computations. So the code may think we have enough bandwidth when we in fact do not. Cc: stable@vger.kernel.org Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 240999cf339f ("i915/dp/fec: Add fec_enable to the crtc state.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2019-04-11drm/i915: Avoid reclaim taints from runtime-pm debugChris Wilson
As intel_runtime_pm_get/_put may be called from any blockable context, we need to avoid allowing reclaim from our mallocs, as we need to avoid tainting any mutexes held by the callers (as they may themselves not allow for allocations as they are taken in the shrinker). <4> [435.339331] WARNING: possible circular locking dependency detected <4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U <4> [435.339395] ------------------------------------------------------ <4> [435.339426] gem_caching/1334 is trying to acquire lock: <4> [435.339456] 000000004505c39b (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915] <4> [435.339788] but task is already holding lock: <4> [435.339819] 00000000ee77b4ed (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.24+0x0/0x30 <4> [435.339879] which lock already depends on the new lock. <4> [435.339918] the existing dependency chain (in reverse order) is: <4> [435.339952] -> #1 (fs_reclaim){+.+.}: <4> [435.339998] fs_reclaim_acquire.part.24+0x24/0x30 <4> [435.340035] kmem_cache_alloc_trace+0x2a/0x290 <4> [435.340311] __print_intel_runtime_pm_wakeref+0x24/0x160 [i915] <4> [435.340590] untrack_intel_runtime_pm_wakeref+0x16e/0x1d0 [i915] <4> [435.340869] intel_runtime_pm_put_unchecked+0xd/0x30 [i915] <4> [435.341147] __intel_wakeref_put_once+0x22/0x40 [i915] <4> [435.341508] i915_request_retire+0x477/0xaf0 [i915] <4> [435.341871] ring_retire_requests+0x86/0x160 [i915] <4> [435.342226] i915_retire_requests+0x58/0xc0 [i915] <4> [435.342576] retire_work_handler+0x5b/0x70 [i915] <4> [435.342615] process_one_work+0x245/0x610 <4> [435.342646] worker_thread+0x37/0x380 <4> [435.342679] kthread+0x119/0x130 <4> [435.342714] ret_from_fork+0x3a/0x50 <4> [435.342739] -> #0 (wakeref#3){+.+.}: <4> [435.342788] lock_acquire+0xa6/0x1c0 <4> [435.342822] __mutex_lock+0x8c/0x960 <4> [435.342853] atomic_dec_and_mutex_lock+0x33/0x50 <4> [435.343151] intel_engine_pm_put+0x1b/0x40 [i915] <4> [435.343501] i915_request_retire+0x477/0xaf0 [i915] <4> [435.343851] ring_retire_requests+0x86/0x160 [i915] <4> [435.344202] i915_retire_requests+0x58/0xc0 [i915] <4> [435.344543] i915_gem_shrink+0xd8/0x5b0 [i915] <4> [435.344835] i915_drop_caches_set+0x17b/0x250 [i915] <4> [435.344877] simple_attr_write+0xb0/0xd0 <4> [435.344911] full_proxy_write+0x51/0x80 <4> [435.344943] vfs_write+0xbd/0x1b0 <4> [435.344972] ksys_write+0x55/0xe0 <4> [435.345002] do_syscall_64+0x55/0x190 <4> [435.345040] entry_SYSCALL_64_after_hwframe+0x49/0xbe 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/20190409174108.19396-1-chris@chris-wilson.co.uk
2019-04-11drm/i915/execlists: Always reset the context's RING registersChris Wilson
During reset, we try and stop the active ring. This has the consequence that we often clobber the RING registers within the context image. When we find an active request, we update the context image to rerun that request (if it was guilty, we replace the hanging user payload with NOPs). However, we were ignoring an active context if the request had completed, with the consequence that the next submission on that request would start with RING_HEAD==0 and not the tail of the previous request, causing all requests still in the ring to be rerun. Rare, but occasionally seen within CI where we would spot that the context seqno would reverse and complain that we were retiring an incomplete request. <0> [412.390350] <idle>-0 3d.s2 408373352us : __i915_request_submit: rcs0 fence 1e95b:3640 -> current 3638 <0> [412.390350] <idle>-0 3d.s2 408373353us : __i915_request_submit: rcs0 fence 1e95b:3642 -> current 3638 <0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3644 -> current 3638 <0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3646 -> current 3638 <0> [412.390350] <idle>-0 3d.s2 408373356us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3646 (current 3638), prio=4 <0> [412.390350] i915_sel-4613 0.... 408373374us : __i915_request_commit: rcs0 fence 1e95b:3648 <0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 cs-irq head=2, tail=3 <0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 csb[3]: status=0x00000001:0x00000000, active=0x1 <0> [412.390350] i915_sel-4613 0d..1 408373378us : __i915_request_submit: rcs0 fence 1e95b:3648 -> current 3638 <0> [412.390350] <idle>-0 3..s1 408373378us : execlists_submission_tasklet: rcs0 awake?=1, active=5 <0> [412.390350] i915_sel-4613 0d..1 408373379us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.2, fence 1e95b:3648 (current 3638), prio=4 <0> [412.390350] i915_sel-4613 0.... 408373381us : i915_reset_engine: rcs0 flags=4 <0> [412.390350] i915_sel-4613 0.... 408373382us : execlists_reset_prepare: rcs0: depth<-0 <0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 cs-irq head=3, tail=4 <0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 csb[4]: status=0x00008002:0x00000002, active=0x1 <0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 out[0]: ctx=2.2, fence 1e95b:3648 (current 3640), prio=4 <0> [412.390350] i915_sel-4613 0.... 408373401us : intel_engine_stop_cs: rcs0 <0> [412.390350] i915_sel-4613 0d..1 408373402us : process_csb: rcs0 cs-irq head=4, tail=4 <0> [412.390350] i915_sel-4613 0.... 408373403us : intel_gpu_reset: engine_mask=1 <0> [412.390350] i915_sel-4613 0d..1 408373408us : execlists_cancel_port_requests: rcs0:port0 fence 1e95b:3648, (current 3648) <0> [412.390350] i915_sel-4613 0.... 408373442us : intel_engine_cancel_stop_cs: rcs0 <0> [412.390350] i915_sel-4613 0.... 408373442us : execlists_reset_finish: rcs0: depth->0 <0> [412.390350] ksoftirq-26 3..s. 408373442us : execlists_submission_tasklet: rcs0 awake?=1, active=0 <0> [412.390350] ksoftirq-26 3d.s1 408373443us : process_csb: rcs0 cs-irq head=5, tail=5 <0> [412.390350] i915_sel-4613 0.... 408373475us : i915_request_retire: rcs0 fence 1e95b:3640, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373476us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3640, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373494us : __i915_request_commit: rcs0 fence 1e95b:3650 <0> [412.390350] i915_sel-4613 0d..1 408373496us : process_csb: rcs0 cs-irq head=5, tail=5 <0> [412.390350] i915_sel-4613 0d..1 408373496us : __i915_request_submit: rcs0 fence 1e95b:3650 -> current 3648 <0> [412.390350] i915_sel-4613 0d..1 408373498us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3650 (current 3648), prio=6 <0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire_upto: rcs0 fence 1e95b:3648, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire: rcs0 fence 1e95b:3642, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373501us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3642, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373514us : i915_request_retire: rcs0 fence 1e95b:3644, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373515us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3644, current 3648 <0> [412.390350] i915_sel-4613 0.... 408373527us : i915_request_retire: rcs0 fence 1e95b:3646, current 3640 <0> [412.390350] <idle>-0 3..s1 408373569us : execlists_submission_tasklet: rcs0 awake?=1, active=1 <0> [412.390350] <idle>-0 3d.s2 408373569us : process_csb: rcs0 cs-irq head=5, tail=1 <0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[0]: status=0x00000001:0x00000000, active=0x1 <0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[1]: status=0x00000018:0x00000002, active=0x5 <0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 out[0]: ctx=2.1, fence 1e95b:3650 (current 3650), prio=6 <0> [412.390350] <idle>-0 3d.s2 408373571us : process_csb: rcs0 completed ctx=2 <0> [412.390350] i915_sel-4613 0.... 408373621us : i915_request_retire: i915_request_retire:253 GEM_BUG_ON(!i915_request_completed(request)) v2: Fixup the cancellation path to drain the CSB and reset the pointers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411130515.20716-2-chris@chris-wilson.co.uk
2019-04-11drm/i915/guc: Implement reset locallyChris Wilson
Before causing guc and execlists to diverge further (breaking guc in the process), take a copy of the current reset procedure and make it local to the guc submission backend 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/20190411130515.20716-1-chris@chris-wilson.co.uk
2019-04-11drm/i915: Disable read only ppgtt support for gen11Mika Kuoppala
On gen11 writing to read only ppgtt page causes a gpu hang. This behaviour is different than with previous gen where read only ppgtt access is supported. On those, the write is just dropped without visible side effects. Disable ro ppgtt support on gen11 until a solution can be found to bring it into line with its predecessors. References: HSDES#1807136187 References: https://bugzilla.freedesktop.org/show_bug.cgi?id=108569 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190411083034.28311-1-mika.kuoppala@linux.intel.com
2019-04-11drm/i915: Call i915_sw_fence_fini on request cleanupChris Wilson
As i915_requests are put into an RCU-freelist, they may get reused before debugobjects notice them as being freed. On cleanup, explicitly call i915_sw_fence_fini() so that the debugobject is properly tracked. Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits") 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> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411122445.20060-1-chris@chris-wilson.co.uk
2019-04-11drm/i915: Clean up DSC vs. not bpp handlingVille Syrjälä
No point in duplicating all this code when we can just use a variable to hold the output bpp (the only thing that differs between the two branches). Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.comk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2019-04-11drm/i915: Set DP min_bpp to 8*3 for non-RGB output formatsVille Syrjälä
6bpc is only legal for RGB and RAW pixel encodings. For the rest the minimum is 8bpc. Set our lower limit accordingly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326142556.21176-6-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2019-04-11drm/i915/icl: Switch to using 12 deep CSB status FIFOMika Kuoppala
Now when we can support variable csb fifo sizes, disable legacy mode. By disabling legacy we hope to get better hw testing coverage by assuming everyone else have switched over. v2: rebase References: https://bugs.freedesktop.org/show_bug.cgi?id=110338 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Kelvin Gardiner <kelvin.gardiner@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190405204657.12887-2-chris@chris-wilson.co.uk
2019-04-11drm/i915: Prepare for larger CSB status FIFO sizeMika Kuoppala
Make csb entry count variable in preparation for larger CSB status FIFO size found on gen11+ hardware. v2: adapt to hwsp access only (Chris) non continuous mmio (Daniele) v3: entries (Chris), fix macro for checkpatch v4: num_entries (Chris) v5: consistency on num_entries Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190405204657.12887-1-chris@chris-wilson.co.uk
2019-04-11drm/i915: Use Engine1 instance for gen11 pm interruptsMika Kuoppala
With gen11 the interrupt registers are shared between 2 engines, with Engine1 instance being upper word and Engine0 instance being lower. Annoyingly gen11 selected the pm interrupts to be in the Engine1 instance. Rectify the situation by shifting the access accordingly, based on gen. v2: comments, warn on overzealous rps_events Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059 Testcase: igt/i915_pm_rps@min-max-config-loaded Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190410105923.18546-6-mika.kuoppala@linux.intel.com
2019-04-11drm/i915/icl: Disable video turbo mode for rp controlMika Kuoppala
There is no video turbo mode for gen11, so don't set it. v2: inline (Chris) v3: brackets (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190410132436.23679-1-mika.kuoppala@linux.intel.com
2019-04-11drm/i915/icl: Enable media sampler powergateMika Kuoppala
Enable media sampler powergate as recommended. v2: use REG_BIT (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190410105923.18546-3-mika.kuoppala@linux.intel.com
2019-04-11drm/i915/icl: Apply a recommended rc6 thresholdMika Kuoppala
On gen11 the recommended rc6 threshold differs from previous gens, apply it. Move the write to a correct spot in sequence. v2: do write in 2b, fix bspec ref (Michal) Bspec: 33149 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-2-mika.kuoppala@linux.intel.com
2019-04-11drm/i915: Use dedicated rc6 enabling sequence for gen11Mika Kuoppala
In order not to inflate gen9 rc6 enabling sequence with gen11 specifics, use a separate function for it. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190410105923.18546-1-mika.kuoppala@linux.intel.com
2019-04-11drm/i915: Bump ready tasks ahead of busywaitsChris Wilson
Consider two tasks that are running in parallel on a pair of engines (vcs0, vcs1), but then must complete on a shared engine (rcs0). To maximise throughput, we want to run the first ready task on rcs0 (i.e. the first task that completes on either of vcs0 or vcs1). When using semaphores, however, we will instead queue onto rcs in submission order. To resolve this incorrect ordering, we want to re-evaluate the priority queue when each of the request is ready. Normally this happens because we only insert into the priority queue requests that are ready, but with semaphores we are inserting ahead of their readiness and to compensate we penalize those tasks with reduced priority (so that tasks that do not need to busywait should naturally be run first). However, given a series of tasks that each use semaphores, the queue degrades into submission fifo rather than readiness fifo, and so to counter this we give a small boost to semaphore users as their dependent tasks are completed (and so we no longer require any busywait prior to running the user task as they are then ready themselves). v2: Fixup irqsave for schedule_lock (Tvrtko) Testcase: igt/gem_exec_schedule/semaphore-codependency Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-10drm/i915: Only reset the pinned kernel contexts on resumeChris Wilson
On resume, we know that the only pinned contexts in danger of seeing corruption are the kernel context, and so we do not need to walk the list of all GEM contexts as we tracked them on each engine. 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/20190410190120.830-1-chris@chris-wilson.co.uk
2019-04-10drm/i915/dp: Expose force_dsc_enable through debugfsManasi Navare
Currently we use force_dsc_enable to force DSC from IGT, but we dont expose this value to userspace through debugfs. This patch exposes this through the same dsc_fec_support debugfs node per connector so that we can restore its value back after the tests are completed. Suggested-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405224821.32435-1-manasi.d.navare@intel.com
2019-04-10drm/i915/icl: Don't warn on spurious interruptsMika Kuoppala
There is a chance we can see spurious interrupts in live now. We have more engines enabled and that with more elaborate access patterns with pm and display, increases the chances hardware just makes a social call, without anything to work on. Remove the error as we have tests to actually probe if we really miss interrupt, instead of getting spurious ones. Note that now we do write to intr_dw even with a zero value. This is considered advantegous as the write is an ack that sw is done. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190410132124.21795-2-mika.kuoppala@linux.intel.com
2019-04-10drm/i915/icl: Handle rps interrupts without irq lockMika Kuoppala
Unlike previous gens, we already hold the irq_lock on entering the rps handler so we can't use it as it is. Make a gen11 specific rps interrupt handler without locking. v2: return early (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190410132124.21795-1-mika.kuoppala@linux.intel.com
2019-04-10ALSA: hda: Fix racy display power accessTakashi Iwai
snd_hdac_display_power() doesn't handle the concurrent calls carefully enough, and it may lead to the doubly get_power or put_power calls, when a runtime PM and an async work get called in racy way. This patch addresses it by reusing the bus->lock mutex that has been used for protecting the link state change in ext bus code, so that it can protect against racy display state changes. The initialization of bus->lock was moved from snd_hdac_ext_bus_init() to snd_hdac_bus_init() as well accordingly. Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> 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/s5h8swiunph.wl-tiwai@suse.de
2019-04-10drm/i915/dp: revert back to max link rate and lane count on eDPJani Nikula
Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") started to optize the eDP 1.4+ link config, both per spec and as preparation for display stream compression support. Sadly, we again face panels that flat out fail with parameters they claim to support. Revert, and go back to the drawing board. v2: Actually revert to max params instead of just wide-and-slow. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959 Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.0+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Albert Astals Cid <aacid@kde.org> # v5.0 backport Tested-by: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Tested-by: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com
2019-04-10drm/i915/icl: Fix port disable sequence for mipi-dsiVandita Kulkarni
Re-enable clock gating of DDI clocks. v2: Fix the default ddi clk state for mipi-dsi (Imre) Fixes: 1026bea00381 ("drm/i915/icl: Ungate DSI clocks") Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553513202-13863-2-git-send-email-vandita.kulkarni@intel.com
2019-04-10drm/i915/icl: Ungate ddi clocks before IO enableVandita Kulkarni
IO enable sequencing needs ddi clocks enabled. These clocks will be gated at a later point in the enable sequence. v2: Fix the commit header (Uma) v3: Remove the redundant read (Ville) Fixes: 949fc52af19e ("drm/i915/icl: add pll mapping for DSI") Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553513202-13863-1-git-send-email-vandita.kulkarni@intel.com
2019-04-09drm/i915/guc: Replace preempt_client lookup with engine->preempt_contextChris Wilson
Circumvent the dance we currently perform to find the preempt_client and lookup its HW context for this engine, as we know we have already pinned the preempt_context on the engine. 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/20190408091728.20207-15-chris@chris-wilson.co.uk
2019-04-08drm/i915/selftests: Mark live_forcewake_ops as unreliableChris Wilson
A couple of machines in the farm show quite frequent errors in the powerwells not being released. Either there is an external agent interferring with the powerwells, or the powerwell doesn't quite behave as we anticipate -- either way, the test is not reliable enough to be enabled by default in CI. It has served its immediate purpose in providing coverage as we made tweaks to forcewake, so keep it available for future testing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190407192649.14750-1-chris@chris-wilson.co.uk
2019-04-08drm/i915/psr: Do not enable PSR in interlaced mode for all GENsJosé Roberto de Souza
This interlaced mode restriction applies to all gens, not only to Haswell. Also while at it updating the debug message to. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-4-jose.souza@intel.com
2019-04-08drm/i915/psr: Initialize PSR mutex even when sink is not reliableJosé Roberto de Souza
Even when driver is reloaded and hits this scenario the PSR mutex should be initialized, otherwise reading PSR debugfs status will execute mutex_lock() over a mutex that was not initialized. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-3-jose.souza@intel.com
generated by cgit (git 2.34.1) at 2025-09-08 22:16:02 +0000