summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-01-14drm/i915/gt: Rearrange ivb workaroundsChris Wilson
Some rcs0 workarounds were being incorrectly applied to the GT, and so we failed to restore the expected register settings after a reset. 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/20210113225144.30810-2-chris@chris-wilson.co.uk
2021-01-14drm/i915/gt: Rearrange vlv workaroundsChris Wilson
Some rcs0 workarounds were being incorrectly applied to the GT, and so we failed to restore the expected register settings after a reset. 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/20210113225144.30810-1-chris@chris-wilson.co.uk
2021-01-13drm/i915/gt: Replace open-coded intel_engine_stop_cs()Chris Wilson
In the legacy ringbuffer submission, we still had an open-coded version of intel_engine_stop_cs() with one additional verification step. Transfer that verification to intel_engine_stop_cs() itself, and call it. 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/20210113204709.15020-1-chris@chris-wilson.co.uk
2021-01-13drm/i915/selftests: Bump the scheduling error threshold for fast heartbeatsChris Wilson
Since we are system_highpri_wq, we expected the heartbeat to be scheduled promptly. However, we see delays of over 10ms upsetting our assertions. Accept this as inevitable and bump the minimum error threshold to 20ms (from 6 jiffies). <6> [616.784749] rcs0: Heartbeat delay: 3570us [2802, 9188] <6> [616.807790] bcs0: Heartbeat delay: 2111us [745, 4372] <6> [616.853776] vcs0: Heartbeat delay: 6485us [2424, 11637] <3> [616.859296] vcs0: Heartbeat delay was 6485us, expected less than 6000us <3> [616.860901] i915/intel_heartbeat_live_selftests: live_heartbeat_fast failed with error -22 v2: More context from CI. 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/20210113163115.5740-2-chris@chris-wilson.co.uk
2021-01-13drm/i915/selftests: Force a failed engine resetChris Wilson
Inject a fault into the engine reset and check that the outstanding requests are completed despite the failed reset. 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/20210113205049.22565-1-chris@chris-wilson.co.uk
2021-01-13drm/i915/guc: stop calling execlists_set_default_submissionDaniele Ceraolo Spurio
Initialize all required entries from guc_set_default_submission, instead of calling the execlists function. The previously inherited setup has been copied over from the execlist code and simplified by removing the execlists submission-specific parts. v2: move setting of relative_mmio flag to engine_setup_common (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-5-daniele.ceraolospurio@intel.com
2021-01-13drm/i915/guc: init engine directly in GuC submission modeDaniele Ceraolo Spurio
Instead of starting the engine in execlists submission mode and then switching to GuC, start directly in GuC submission mode. The initial setup functions have been copied over from the execlists code and simplified by removing the execlists submission-specific parts. v2: remove unneeded unexpected starting state check (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@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/20210113021236.8164-4-daniele.ceraolospurio@intel.com
2021-01-13drm/i915/guc: do not dump execlists state with GuC submissionDaniele Ceraolo Spurio
GuC owns the execlists state and the context IDs used for submission, so the status of the ports and the CSB entries are not something we control or can decode from the i915 side, therefore we can avoid dumping it. A follow-up patch will also stop setting the csb pointers when using GuC submission. GuC dumps all the required events in the GuC logs when verbosity is set high enough. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@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/20210113021236.8164-3-daniele.ceraolospurio@intel.com
2021-01-13drm/i915/guc: Delete GuC code unused in future patchesMatthew Brost
Delete GuC code unused in future patches that rewrite the GuC interface to work with the new firmware. Most of the code deleted relates to workqueues or execlist port. The code is safe to remove because we still don't allow GuC submission to be enabled, even when overriding the modparam, so it currently can't be reached. The defines + structs for the process descriptor and workqueue remain. Although the new GuC interface does not require either of these for the normal submission path multi-lrc submission does. The usage of the process descriptor and workqueue for multi-lrc will be quite different from the code that is deleted in this patch. A future patch will implement multi-lrc submission. v2: add a code in the commit message about the code being safe to remove (Chris) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <john.c.harrison@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/20210113021236.8164-2-daniele.ceraolospurio@intel.com
2021-01-12drm/i915: move region_lmem under gtMatthew Auld
Device local-memory should be thought of as part the GT, which means it should also sit under gt/. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matthew Auld <matthew.auld@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/20210112164300.356524-1-matthew.auld@intel.com
2021-01-12drm/i915/lmem: make intel_region_lmem_ops staticJani Nikula
There are no users outside of intel_region_lmem.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210112172246.11933-1-jani.nikula@intel.com
2021-01-12drm/i915/region: make intel_region_map staticJani Nikula
There are no users outside of intel_memory_region.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210112170429.27619-1-jani.nikula@intel.com
2021-01-12drm/i915/gt: Perform an arbitration check before busywaitingChris Wilson
During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset preparations) on the first request afterwards. There was no explicit MI_ARB_CHECK in this sequence as the presumption was that the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point. It did not in this circumstance, so force it. This patch is based on the assumption that the MI_SEMAPHORE_WAIT failure to arbitrate is a rare Tigerlake bug, similar to the lite-restore vs semaphore issues previously seen in the CS. The explicit MI_ARB_CHECK should always ensure that there is at least one arbitration point in the request before the MI_SEMAPHORE_WAIT to trigger the IDLE->ACTIVE event. Upon processing that event, we will clear the stop-ring flag and release the semaphore from its busywait. 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/20210112100759.32698-2-chris@chris-wilson.co.uk
2021-01-12drm/i915/gt: Check for arbitration after writing start seqnoChris Wilson
On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make the decisions as to how to process that CS event. v2: More commentary about the users of i915_request_started() as a reminder about why we are marking the initial breadcrumb. 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/20210112100759.32698-1-chris@chris-wilson.co.uk
2021-01-12drm/i915/selftests: Allow huge_gem_object to kick the shrinkerChris Wilson
A new fi-cml-dallium CI machine has 8G and apparently plenty free, yet fails some selftests with ENOMEM. The failures all seem to be from huge_gem_object which does not try very hard to allocate memory, skipping reclaim entirely. Let's try a bit harder and direct reclaim before failing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210112020013.19464-1-chris@chris-wilson.co.uk
2021-01-12drm/i915/gem: Remove stolen node before releasing the regionChris Wilson
If this stolen object holds the last reference to the region, we need to remove our drm_mm_node before freeing the region's drm_mm. <4> [431.679591] Memory manager not clean during takedown. <4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x51/0x100 <4> [431.679655] Modules linked in: i915 vgem btusb snd_hda_codec_hdmi btrtl btbcm btintel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio bluetooth coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ecdh_generic ecc r8169 realtek lpc_ich snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers [last unloaded: i915] <4> [431.679883] CPU: 0 PID: 110 Comm: kworker/u4:3 Tainted: G U 5.11.0-rc3-CI-CI_DRM_9583+ #1 <4> [431.679895] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 <4> [431.679905] Workqueue: i915 __i915_gem_free_work [i915] <4> [431.680831] RIP: 0010:drm_mm_takedown+0x51/0x100 <4> [431.680850] Code: 44 24 08 65 48 33 04 25 28 00 00 00 0f 85 b6 00 00 00 48 83 c4 10 5b 5d 41 5c c3 48 89 fb 48 c7 c7 c8 b7 38 82 e8 00 d6 37 00 <0f> 0b 48 8b 3d 96 d5 d1 00 ba 00 10 00 00 be c0 0c 00 00 e8 d7 64 <4> [431.680862] RSP: 0018:ffffc90000ad7dc0 EFLAGS: 00010282 <4> [431.680879] RAX: 0000000000000000 RBX: ffff8881109aa140 RCX: 0000000000000001 <4> [431.680888] RDX: 0000000080000001 RSI: ffffffff8235a70f RDI: 00000000ffffffff <4> [431.680897] RBP: ffff8881109aa178 R08: 0000000000000001 R09: 0000000000000001 <4> [431.680906] R10: 0000000025eaec48 R11: 00000000f5b271a7 R12: ffff88810a38ddc0 <4> [431.680916] R13: 00000000ffffffff R14: ffffffff82861b70 R15: ffff88810b715538 <4> [431.680925] FS: 0000000000000000(0000) GS:ffff88817b800000(0000) knlGS:0000000000000000 <4> [431.680935] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [431.680945] CR2: 000056377cfd7c48 CR3: 00000001045de000 CR4: 00000000001006f0 <4> [431.680954] Call Trace: <4> [431.680977] __intel_memory_region_destroy+0x24/0x50 [i915] <4> [431.681340] i915_gem_object_release_stolen+0x26/0x40 [i915] <4> [431.681637] __i915_gem_free_objects.isra.21+0x1ef/0x3b0 [i915] <4> [431.681935] process_one_work+0x270/0x5c0 <4> [431.682022] worker_thread+0x37/0x380 <4> [431.682047] ? process_one_work+0x5c0/0x5c0 <4> [431.682062] kthread+0x146/0x170 <4> [431.682077] ? kthread_park+0x80/0x80 <4> [431.682098] ret_from_fork+0x22/0x30 <4> [431.682153] irq event stamp: 1872905 <4> [431.682162] hardirqs last enabled at (1872911): [<ffffffff8112bd9a>] console_unlock+0x49a/0x580 <4> [431.682176] hardirqs last disabled at (1872916): [<ffffffff8112bd06>] console_unlock+0x406/0x580 <4> [431.682187] softirqs last enabled at (1872850): [<ffffffff81e00342>] __do_softirq+0x342/0x48e <4> [431.682201] softirqs last disabled at (1872845): [<ffffffff81c00f52>] asm_call_irq_on_stack+0x12/0x20 <4> [431.682214] ---[ end trace 5d3bcd818e2e3816 ]--- <3> [431.686188] [drm:drm_mm_takedown] *ERROR* node [0002d000 + 00004000]: inserted at drm_mm_insert_node_in_range+0x34a/0x5b0 i915_gem_stolen_insert_node_in_range+0x7b/0xa0 [i915] _i915_gem_object_create_stolen+0x83/0xd0 [i915] i915_gem_object_create_region+0x61/0x140 [i915] intel_engine_create_ring+0x176/0x230 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2927 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210112015000.16108-1-chris@chris-wilson.co.uk
2021-01-12drm/i915: Allow the sysadmin to override security mitigationsChris Wilson
The clear-residuals mitigation is a relatively heavy hammer and under some circumstances the user may wish to forgo the context isolation in order to meet some performance requirement. Introduce a generic module parameter to allow selectively enabling/disabling different mitigations. To disable just the clear-residuals mitigation (on Ivybridge, Baytrail, or Haswell) use the module parameter: i915.mitigations=auto,!residuals Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858 Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v5.7 Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-3-chris@chris-wilson.co.uk
2021-01-12drm/i915/gt: Restore clear-residual mitigations for Ivybridge, BaytrailChris Wilson
The mitigation is required for all gen7 platforms, now that it does not cause GPU hangs, restore it for Ivybridge and Baytrail. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Reviewed-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk
2021-01-12drm/i915/gt: Limit VFE threads based on GTChris Wilson
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the range [0, n-1] where n is #EU * (#threads/EU) with the number of threads based on plaform and the number of EU based on the number of slices and subslices. This is a fixed number per platform/gt, so appropriately limit the number of threads we spawn to match the device. v2: Oversaturate the system with tasks to force execution on every HW thread; if the thread idles it is returned to the pool and may be reused again before an unused thread. v3: Fix more state commands, which was causing Baytrail to barf. v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024 Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Randy Wright <rwright@hpe.com> Cc: stable@vger.kernel.org # v5.7+ Reviewed-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-1-chris@chris-wilson.co.uk
2021-01-11drm/i915/dg1: Update voltage swing tables for DPMatt Roper
DG1's vswing tables are the same for eDP and HDMI but have slight differences from ICL/TGL for DP. v2: - Use a "_hbr2_hbr3" suffix on the table name to make it more clear that the same table is used for both HBR2 and HBR3 link rates. (Swathi) Bspec: 49291 Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108222528.1954514-1-matthew.d.roper@intel.com Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
2021-01-11drm/i915/selftests: Include engine name after reset failureChris Wilson
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the next time this happens, mention which engine that was. 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/20210111105735.21515-4-chris@chris-wilson.co.uk
2021-01-11drm/i915/gt: Disable arbitration around Braswell's pdp updatesChris Wilson
Braswell's pdp workaround is full of dragons, that may be being angered when they are interrupted. Let's not take that risk and disable arbitration during the update. 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/20210111105735.21515-1-chris@chris-wilson.co.uk
2021-01-11drm/i915: Try to use fast+narrow link on eDP again and fall back to the old ↵Ville Syrjälä
max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-11drm/i915: Fix checkpatch warns in cursor codeVille Syrjälä
Eliminate checkpatch warnings from intel_cursor.c: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Possible repeated word: 'by' Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110175624.3524-2-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2021-01-11drm/i915: Fix HTI port checkingJosé Roberto de Souza
There was some misinterpretation of specification, when DDIX_USED is set, the next bit means 0 for DP and 1 for HDMI. Anyways this misinterpretation is not causing any issues, this change is just to comply with specification. Also as for us it do not matters if it is HDMI or DP, not checking the port type that HTI is using. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108134802.21280-1-jose.souza@intel.com
2021-01-11drm/i915/selftests: Fix some error codesDan Carpenter
These error paths return success instead of negative error codes as intended. Fixes: c92724de6db1 ("drm/i915/selftests: Try to detect rollback during batchbuffer preemption") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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/X/xMdcewtft7+QFM@mwanda
2021-01-11drm/i915/backlight: fix CPU mode backlight takeover on LPTJani Nikula
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight() functions operate directly on the hardware registers. If inverting the value is needed, using intel_panel_compute_brightness(), it should only be done in the interface between hardware registers and panel->backlight.level. The CPU mode takeover code added in commit 5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the hardware register and converts to panel->backlight.level correctly, however the value written back should remain in the hardware register "domain". This hasn't been an issue, because GM45 machines are the only known users of i915.invert_brightness and the brightness invert quirk, and without one of them no conversion is made. It's likely nobody's ever hit the problem. Fixes: 5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v5.1+ Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
2021-01-09drm/i915: Refactor marking a request as EIOChris Wilson
When wedging the device, we cancel all outstanding requests and mark them as EIO. Rather than duplicate the small function to do so between each submission backend, export one. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-3-chris@chris-wilson.co.uk
2021-01-09drm/i915/gt: Mark up a debug-only functionChris Wilson
drivers/gpu/drm/i915//gt/intel_workarounds.c:1394:20: error: function 'is_nonpriv_flags_valid' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] static inline bool is_nonpriv_flags_valid(u32 flags) This is only used by debug build, so mark it as maybe-unused to keep the compiler from complaining. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-2-chris@chris-wilson.co.uk
2021-01-09drm/i915/gt: Remove unused function 'dword_in_page'Chris Wilson
>> drivers/gpu/drm/i915/gt/intel_lrc.c:17:28: error: unused function 'dword_in_page' [-Werror,-Wunused-function] static inline unsigned int dword_in_page(void *addr) Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-1-chris@chris-wilson.co.uk
2021-01-09drm/i915/gt: Exercise lrc_wa_ctx initialisation failureChris Wilson
Inject a fault into lrc_init_wa_ctx() to ensure that we can tolerate a failure to construct the workarounds. v2: Avoid mentioning an error for fault-injection, other CI will complain about the dmesg spam. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210109114453.27798-1-chris@chris-wilson.co.uk
2021-01-08drm/i915/gt: Disable arbitration on no-preempt requestsChris Wilson
If a request is submitted and known to require no preemption, disable arbitration around the batch which prevents the HW from handling a preemption request during the payload. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-7-chris@chris-wilson.co.uk
2021-01-08drm/i915/gt: Only disable preemption on gen8 render enginesChris Wilson
The reason why we did not enable preemption on Broadwater was due to missing GPGPU workarounds. Since this only applies to rcs0, only restrict rcs0 (and our global capabilities). While this does not affect exposing a preemption capability to userspace, it does affect our internal decisions on whether to use timeslicing and semaphores between individual engines. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-6-chris@chris-wilson.co.uk
2021-01-08drm/i915/gt: Only retire on the last breadcrumb if the last requestChris Wilson
We use the completion of the last active breadcrumb to retire the requests along a timeline. This is purely opportunistic as nothing guarantees that any particular timeline is terminated by a breadcrumb; except for parking the engine where we explicitly add a breadcrumb so that we park quickly and do an explicit retire upon signaling to reduce the latency dramatically (avoiding a retire worker roundtrip). With scheduling, we anticipate retiring completed timelines as a matter of course. Performing the same action from inside the breadcrumbs is intended to provide similar functionality for legacy ringbuffer submission. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-5-chris@chris-wilson.co.uk
2021-01-08drm/i915/gt: Restore ce->signal flush before releasing virtual engineChris Wilson
Before we mark the virtual engine as no longer inflight, flush any ongoing signaling that may be using the ce->signal_link along the previous breadcrumbs. On switch to a new physical engine, that link will be inserted into the new set of breadcrumbs, causing confusion to an ongoing iterator. This patch undoes a last minute mistake introduced into commit bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer"), whereby instead of unconditionally applying the flush, it was only applied if the request itself was going to be reused. v2: Generalise and cancel all remaining ce->signals Fixes: bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-4-chris@chris-wilson.co.uk
2021-01-08drm/i915/selftests: Rearrange ktime_get to reduce latency against CSChris Wilson
In our tests where we measure the elapsed time on both the CPU and CS using a udelay, our CS results match the udelay much more accurately than the ktime (even when using ktime_get_fast_ns). With preemption disabled, we can go one step lower than ktime and use local_clock. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2919 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-3-chris@chris-wilson.co.uk
2021-01-08drm/i915/selftests: Skip unstable timing measurementsChris Wilson
If any of the perf tests run into 0 time, not only are we liable to divide by zero, but the result would be highly questionable. Nevertheless, let's not have a div-by-zero error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-2-chris@chris-wilson.co.uk
2021-01-08drm/i915/gt: Prevent use of engine->wa_ctx after errorChris Wilson
On error we unpin and free the wa_ctx.vma, but do not clear any of the derived flags. During lrc_init, we look at the flags and attempt to dereference the wa_ctx.vma if they are set. To protect the error path where we try to limp along without the wa_ctx, make sure we clear those flags! Reported-by: Matt Roper <matthew.d.roper@intel.com> Fixes: 604a8f6f1e33 ("drm/i915/lrc: Only enable per-context and per-bb buffers if set") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.15+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-1-chris@chris-wilson.co.uk
2021-01-08drm/i915: Disable RPM wakeref assertions during driver shutdownChris Wilson
As with the regular suspend paths, also disable the wakeref assertions as we disable the driver during shutdown. Reported-by: Hans de Goede <hdegoede@redhat.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2899 Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210104203905.19248-1-chris@chris-wilson.co.uk
2021-01-08drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921)Alexandre Demers
This fix bug 210921 where DRM_INFO floods log when hitting an unsupported ASIC in amdgpu_device_asic_has_dc_support(). This info should be only called once. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210921 Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-01-08drm/amdgpu/display: fix build with CONFIG_DRM_AMD_DC_DCN disabledAlex Deucher
dc_allow_idle_optimizations() needs to be protected by CONFIG_DRM_AMD_DC_DCN. Fixes: 71338cb4a7c2 ("drm/amd/display: enable idle optimizations for linux (MALL stutter)") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amd/pm: modify the fine grain tuning function for RenoirXiaojian Du
This patch is to improve the fine grain tuning function for Renoir. The fine grain tuning function uses the sysfs node -- pp_od_clk_voltage to config gfxclk. Meanwhile, another sysfs node -- power_dpm_force_perfomance_level also affects the gfx clk. It will cause confusion when these two sysfs nodes works together. And the flag "od_enabled" is used to control the overdrive function for dGPU, like navi10, navi14 and navi21. APU like Renior or Vangogh uses this "od_enabled" to configure the frequency range of gfx clock, but the max value of frequency range will not be higher than the safe limit, it is not "overdrive". So this patch adds two new flags -- "fine_grain_enabled" and "fine_grain_started" to avoid this confusion, the flag will make these two sysfs nodes work separately. The flag "fine_grain_enabled" is set as "enabled" by default, so the fine grain tuning function will be enabled by default. But the flag "fine_grain_started" is set as "false" by default, so the fine grain function will not take effect until it is set as "true". Only when power_dpm_force_perfomance_level is changed to "manual" mode, the flag "fine_grain_started" will be set as "true", and the fine grain tuning function will be started. In other profile modes, including "auto", "high", "low", "profile_peak", "profile_standard", "profile_min_sclk", "profile_min_mclk", the flag "fine_grain_started" will be set as "false", and the od range of fine grain tuning function will be restored default value. Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amd/pm: add the parameters of power profiles for vangoghXiaojian Du
This pacth is to add the parameters of power profiles for vangogh, includeing "profile_peak", "profile_standard", "profile_min_sclk", "profile_min_mclk". Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amdgpu/psp: fix psp gfx ctrl cmdsVictor Zhao
psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao <Victor.Zhao@amd.com> Reviewed-by: Emily.Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amdkfd: check more client ids in interrupt handlerTao Zhou
Add check for SExSH clients in kfd interrupt handler. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amdgpu: Correct the read sclk for navi10Emily.Deng
According to hw, after navi10,it runs in dfll mode, and should read sclk from AverageGfxclkFrequency. Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/amdgpu: Add new mode 2560x1440Emily.Deng
Add one more 2k resolution which appears frequently in market. Signed-off-by: Emily.Deng <Emily.Deng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-08drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}Anshuman Gupta
We need a power_domain wakeref in pps_{lock,unlock} to prevent a race while resetting pps state in intel_power_sequencer_reset(). intel_power_sequencer_reset() need a pps_mutex to access pps_pipe but it can't grab pps_mutex due to deadlock with power_well functions are called while holding pps_mutex. intel_power_sequencer_reset() is called by power_well function associated with legacy platforms like vlv and chv therefore re-use the POWER_DOMAIN_DISPLAY_CORE power domain, which only used by vlv and chv display power domain. This will avoids the unnecessary noise of unrelated power wells in pps_{lock,unlock}. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107112500.16216-1-anshuman.gupta@intel.com
2021-01-08Merge drm/drm-next into drm-intel-nextRodrigo Vivi
sync-up to not fall too much behind. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-01-07drm/i915/gt: Remove timeslice suppressionChris Wilson
In the next^W future patch, we remove the strict priority system and continuously re-evaluate the relative priority of tasks. As such we need to enable the timeslice whenever there is more than one context in the pipeline. This simplifies the decision and removes some of the tweaks to suppress timeslicing, allowing us to lift the timeslice enabling to a common spot at the end of running the submission tasklet. One consequence of the suppression is that it was reducing fairness between virtual engines on an over saturated system; undermining the principle for timeslicing. v2: Commentary v3: Commentary for the right cancel_timer() v4: Add tracing for why we need a timeslice Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802 Testcase: igt/gem_exec_balancer/fairslice Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107132322.28373-1-chris@chris-wilson.co.uk
generated by cgit (git 2.34.1) at 2025-10-01 22:11:10 +0000