- 01 May, 2018 1 commit
-
-
Chris Wilson authored
Due to the latency of the tasklet running from ksoftirqd, by the time we process the execlist dequeue may be a long time behind the GPU. If the request was completed when we ran reschedule, we will not have tweaked its priority, but if it is still listed as being in-flight for dequeue we will use it as a reference for the rest of the queue, including requests from its own context which will now be at higher priority. This can cause us to issue a preempt-to-idle request, even though the request we want to preempt is already complete. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180501122131.19435-1-chris@chris-wilson.co.ukReviewed-by:
-
- 30 Apr, 2018 7 commits
-
-
Manasi Navare authored
On clock recovery this function is called to find out the max voltage swing level that we could go. However gen 9 functions use the old buffer translation tables to figure that out. ICL uses different set of tables for eDP and DP for both Combo and MG PHY ports. This patch adds the hook for ICL for getting this information from appropriate buf trans tables. v5 (from Paulo): * New rebase after changes to earlier patches. v4: * Rebase. v3: * Follow the coding conventions here (https://cgit.freedesktop.org/drm-intel/tree/Documentation/process/codin g-style.rst#n191) (Paulo) v2: * Rebase after patch that adds voltage check inside buf trans function (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-9-paulo.r.zanoni@intel.com
-
Manasi Navare authored
This is an important part of the DDI initalization as well as for changing the voltage during DisplayPort link training. The Voltage swing seqeuence is similar to Cannonlake. However it has different register definitions and hence it makes sense to create a separate vswing sequence and program functions for ICL to leave room for more changes in case the Bspec changes later and deviates from CNL sequence. v2: Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula) v3: * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo) v4: * Call it combo_vswing, use switch statement (Paulo) v5 (from Paulo): * Fix a typo. * s/rate < 600000/rate <= 600000/. * Don't remove blank lines that should be there. v6: * Rebased by Rodrigo on top of Cannonlake changes where non vswing sequences are not aligned with iboost anymore. v7: Another rebase after an upstream rework. v8 (from Paulo): * Adjust the code to the upstream output type changes. * Squash the patch that moved some functions up. * Merge both get_combo_buf_trans functions in order to simplify the code. * Change the changelog format. v9 (from Paulo): * Use RTERM_SELECT instead of SCALING_MODE_SEL. * Adjust the output type handling according to how the other platforms do it now. v10 (from Paulo): * Fix comment left out from v9 changes (Rodrigo). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: James Ausmus <james.ausmus@intel.com> Reviewed-by:
-
Chris Wilson authored
We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings. v2: s/live/active/ for consistency with gt.active_requests Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the position of ring->head. As an added bonus, retiring along the ring reduces the penalty of having one execlists client do cleanup for another (old legacy submission shares a ring between all clients). The downside is that slow and irregular (off the critical path) process of cleaning up stale requests after userspace becomes a modicum less efficient. In the long run, it will become apparent that the ordered ring->request_list matches the ring->timeline, a fun challenge for the future will be unifying the two lists to avoid duplication! v2: We need both engine-order and ring-order processing to maintain our knowledge of where individual rings have completed upto as well as knowing what was last executing on any engine. And finally by decoupling retiring the contexts on the engine and the timelines along the rings, we do have to keep a reference to the context on each request (previously it was guaranteed by the context being pinned). v3: Not just a reference to the context, but we need to keep it pinned as we manipulate the rings; i.e. we need a pin for both the manipulation of the engine state during its retirements, and a separate pin for the manipulation of the ring state. Signed-off-by:
-
Chris Wilson authored
Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. v2: Fixup mock_engine to mark the context as pinned on use. Signed-off-by:
-
Chris Wilson authored
In commit 9b6586ae ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to preserve the semantics that no engine wraps in the middle of a submit. (Although this semantic is now only required for gen7 semaphore support, which only supports greater-then comparisons!) v2: Keep a global counter of all requests ever submitted and force the reset when it wraps. References: 9b6586ae ("drm/i915: Keep a global seqno per-engine") Signed-off-by:
-
Chris Wilson authored
Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an inconsistent state by the reset. The presumption was that at worst it would just cause another reset and skip again until it recovered, however it seems just as likely to cause an unrecoverable hang. Instead of risking loading an incomplete context image, restore it back to the default state. v2: Fix up off-by-one from including the ppHSWP in with the register state. v3: Use a ring local to compact a few lines. v4: Beware setting the ring local before checking for a NULL request. References: https://bugs.freedesktop.org/show_bug.cgi?id=105304Signed-off-by:
-
- 28 Apr, 2018 4 commits
-
-
Paulo Zanoni authored
There's a lot of code for the PLL enabling, so let's first only introduce the register definitions in order to make patch reviewing a little easier. v2: Coding style (Jani). v3: Preparation for upstreaming. v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James). Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by:
James Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-3-paulo.r.zanoni@intel.com
-
Mahesh Kumar authored
Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to 11 bits. This patch make changes to use proper mask for ICL+ during hardware ddb value readout. Changes since V1: - Use _MASK & _SHIFT macro (James) Changes since V2: - use kernel type u8 instead of uint8_t Changes since V3: - Rebase Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
-
Mahesh Kumar authored
ICL has two slices of DBuf, each slice of size 1024 blocks. We should not always enable slice-2. It should be enabled only if display total required BW is > 12GBps OR more than 1 pipes are enabled. Changes since V1: - typecast total_data_rate to u64 before multiplication to solve any possible overflow (Rodrigo) - fix where skl_wm_get_hw_state was memsetting ddb, resulting enabled_slices to become zero - Fix the logic of calculating ddb_size Changes since V2: - If no-crtc is part of commit required_slices will have value "0", don't try to disable DBuf slice. Changes since V3: - Create a generic helper to enable/disable slice - don't return early if total_data_rate is 0, it may be cursor only commit, or atomic modeset without any plane. Changes since V4: - Solve checkpatch warnings - use kernel types u8/u64 instead of uint8_t/uint64_t Changes since V5: - Rebase Signed-off-by:
-
Mahesh Kumar authored
This patch adds support to start tracking status of DBUF slices. This is foundation to introduce support for enabling/disabling second DBUF slice dynamically for ICL. Changes Since V1: - use kernel type u8 over uint8_t Signed-off-by:
-
- 27 Apr, 2018 2 commits
-
-
James Ausmus authored
These fields have been deprecated and moved in ICL+. Stop setting the bits. They have moved to GAMMA_MODE and CSC_MODE, respectively. This patch is just to stop incorrectly setting bits in PLANE_COLOR_CTL while we're waiting for the new replacement functionality to be done. v2: Drop useless comment, and change !(GEN >= 11) to (GEN < 11). (Ville) v3: No changes v4 (from Paulo): Rebase. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ian W MORRISON authored
As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 0000:00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2 i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://01.org/linuxgraphics/downloads/firmware and now shows that the firmware has correctly loaded: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) Signed-off-by:Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
-
- 26 Apr, 2018 15 commits
-
-
José Roberto de Souza authored
This was my bad, spec says that the name of this bit is 'Y-coordinate valid' but the values for it is: 0: Include Y-coordinate valid eDP1.4a 1: Do not include Y-coordinate valid eDP 1.4 So not setting it. BSpec: 7713 Cc: 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> Signed-off-by:
-
José Roberto de Souza authored
IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. v3: Reading i915_edp_psr_status was causing PSR to exit but now with 'drm/i915/psr: Prevent PSR exit when a non-pipe related register is written' it is fixed. Reviewed-by:
-
José Roberto de Souza authored
This will be helpful to debug what hardware is actually tracking and causing PSR to exit. BSpec: 7721 v4: - Using _MMIO_TRANS2() in PSR_EVENT - Cleaning events before printing Signed-off-by:
-
osé Roberto de Souza authored
Any write in any display register was causing HW to exit PSR, masking it to allow more power savings. Writes to pipe related registers will still cause HW to exit PSR. This is already masked for PSR2. It also do not break the Display WA #0884, writes to CURSURFLIVE are still causing hardware to exit PSR. This was tested in CNL machine by triggering a write to CURSURFLIVE when a debugfs was read by user. Bspec: 7721 and 8042 v4: Checked that it do not breaks WA #0884 and added this information to the commit message. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Chris Wilson authored
Even though we weren't injecting guilty requests to be reset, we could still fall over the issue of resetting the same request too fast -- where the GPU refuses to start again. (Although it is interesting to note that reloading the driver is sufficient, suggesting that we could recover if we delayed the setup after reset?) Continue to paper over the problem by adding a small delay by waiting for the engine to idle between tests, and ensure that the engines are idle before starting the idle tests. v2: Replace single instance of 50 with a magic macro. References: 02866679 ("drm/i915/selftests: Avoid repeatedly harming the same innocent context") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Abstract compliance test adjustments to a single function. Also make the bpc adjustments affect the limits, actually forcing the bpc. Seems like directly changing the pipe_bpp in the past could not have been effective. Reviewed-by:
-
Jani Nikula authored
For now, there's just the one link config selection, optimizing for slow and wide link. No functional changes. Keep the debug logging in the caller, to avoid duplication later on if alternative link confing selection gets added. v2: Improved commit message Reviewed-by:
-
Jani Nikula authored
Also use same min/max model for bpp, and adjust debug logging while at it. Reviewed-by:
-
Jani Nikula authored
Keep related things together. No functional changes. v2: Fix a typo in patch subject, fix a checkpatch alignment warning. Reviewed-by:
-
Jani Nikula authored
Abstract a new intel_dp_compute_link_config() from intel_dp_compute_config(), with the parts related to link configuration, i.e. bpp, link rate, and lane count selection. No functional changes. v2: Fix a checkpatch warn about spacing. Reviewed-by:
-
Jani Nikula authored
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be able to debug log the link_bw and rate_select parameters; we don't use the parameters here for anything else. We call intel_dp_compute_rate() again during link training where we actually need and use the parameters. Move the debug logging of link_bw and rate_select to intel_dp_link_training_clock_recovery(), and clean up the extra intel_dp_compute_rate() call and extra clutter from the already overcrowded intel_dp_compute_config(). v2: Rewrote commit message (Rodrigo, Manasi) Reviewed-by:
-
Jani Nikula authored
We haven't used the DP bw constants here for a while. No functional changes. Reviewed-by:
-
Jani Nikula authored
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special circumstances. v2: don't change device info dump (Chris) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
The majority of the engine state dumping is too voluminous to be useful outside of a controlled setup, though a few do accompany severe errors. Keep the debug dumps next to the errors, but hide the others behind a CI compile flag. This becomes more useful when adding more dumps to latency sensitive paths. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426103219.22181-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
We can convert engine stats from a spinlock to seqlock to ensure interrupt processing is never even a tiny bit delayed by parallel readers. There is a smidgen bit more cost on the write lock side, and an extremely unlikely chance that readers will have to retry a few times in face of heavy interrupt load. But it should be extremely unlikely given how lightweight read side section is compared to the interrupt processing side, and also compared to the rest of the code paths which can lead into it. Furthermore, writer is the ones doing the real, latency sensitive work, while readers are only informative. Signed-off-by:
-
- 25 Apr, 2018 3 commits
-
-
Oscar Mateo authored
Interrupt handling in Gen11 is quite different from previous platforms. v2: Rebased (Michel) v3: Rebased with wiggle v4: Rebased, remove TODO warning correctly (Daniele) v5: Rebased, made gen11_gtiir const while at it (Michel) v6: Rebased v7: Adapt to the style currently in upstream Suggested-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
A more complete, and more importantly stable, interface for controlling the RPS frequency range is available in sysfs, obsoleting the unstable debugfs. It's presence seems to trick people into using it, forgetting it is not ABI. References: https://bugs.freedesktop.org/show_bug.cgi?id=106237Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180425142334.27113-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
When filling the ring to align the emit pointer to the next cacheline, use memset64() rather than open-coding it. As we know that we always have an even number of dwords, we can replace the dword loop with the qword equivalent. v2: s/0/MI_NOOP<<32 | MI_NOOP/ Signed-off-by:
-
- 24 Apr, 2018 8 commits
-
-
Lyude Paul authored
Does what it says on the label, it's a little confusing debugging atomic check failures otherwise. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Chris Wilson authored
Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting an engine. It also allows us to react better to the user poking around debugfs for testing missed irqs. v2: Tighten the order of del_timer_sync as the fake_irq timer may trigger the hangcheck timer, and so we should cancel it first and then cancel the hangcheck (Mika) Signed-off-by:
-
Gustavo A. R. Silva authored
There is a potential execution path in which variable err is returned without being properly initialized previously. Fix this by initializing variable err to 0. Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable") Fixes: f4ecfbfc ("drm/i915: Check whitelist registers across resets") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
-
José Roberto de Souza authored
If the initial fbdev configuration (intel_fbdev_initial_config()) runs and there still no sink connected it will cause drm_fb_helper_initial_config() to return 0 as no error happened (but internally the return is -EAGAIN). Because no framebuffer was allocated, when a sink is connected intel_fbdev_output_poll_changed() will not execute drm_fb_helper_hotplug_event() that would trigger another try to do the initial fbdev configuration. So here allowing drm_fb_helper_hotplug_event() to be executed when there is no framebuffer allocated and fbdev was not set up yet. This issue also happens when a MST DP sink is connected since boot, as the MST topology is discovered in parallel if intel_fbdev_initial_config() is executed before the first sink MST is discovered it will cause this same issue. This is a follow-up patch of https://patchwork.freedesktop.org/patch/196089/ Changes from v1: - not creating a dump framebuffer anymore, instead just allowing drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v4.15+ Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17 Tested-by:
Ian Pilcher <arequipeno@gmail.com> Acked-by:
-
Chris Wilson authored
Knowing the offset of the per-engine scratch/HWS page during boot is not very informative, so remove the DRM_DEBUG. Signed-off-by:
-
Chris Wilson authored
If we have more than a few, possibly several thousand request in the queue, don't show the central portion, just the first few and the last being executed and/or queued. The first few should be enough to help identify a problem in execution, and most often comparing the first/last in the queue is enough to identify problems in the scheduling. We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common debug scenarios, but for the moment if we can avoiding spending more than a few seconds dumping the GPU state that will avoid a nasty livelock (where hangcheck spends so long dumping the state, it fires again and starts to dump the state again in parallel, ad infinitum). v2: Remember to print last not the stale rq iter after the loop. Signed-off-by:
-
Chris Wilson authored
printk unhelpfully inserts a '\n' between consecutive calls, and since our drm_printf wrapper may be emitting info a seq_file instead, KERN_CONT is not an option. To work with any drm_printf destination, we need to build up the output into a temporary buf on the stack and then feed the complete line in a single call to printk. Fixes: b7268c5e ("drm/i915: Pack params to engine->schedule() into a struct") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424010839.22860-1-chris@chris-wilson.co.uk
-
Mika Kuoppala authored
We need to be careful to not let compiler evaluate the expiration and the operation on it's terms. Document and enforce that COND will be evaluated before checking timeout expiration. Suggested-by:
-
