- 05 Oct, 2018 21 commits
-
-
Anusha Srivatsa authored
Add missing MODULE_FIRMWARE while loading DMC ICL. v2: Add Fixes tag. (Rodrigo) v3: Rebase by Rodrigo after commit 7fe78985 ("drm/i915/csr: restructure CSR firmware definition macros") v4: Rodrigo fixing his own mess on commit mentioning on v3 comment above. Fixes: 4445930f ("firmware/dmc/icl: load v1.07 on icelake.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v2) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004223613.19938-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
No functional change. But just a minor change to keep up with Spec, since it has changed since commit c3cc39c5 ("drm/i915/icl: program mbus during pipe enable") The instructions previously said to program pipe's B credit = 24 / number of pipes, which is 8 for ICL. Now the spec gives us direct values independent of number of pipes. Let's keep in sync. Also just a reorder on fields to make easier to compare against spec's sequence: A -> BW -> B. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004151814.6054-1-rodrigo.vivi@intel.com
-
Lee, Shawn C authored
Amber Lake used the same gen graphics as Kaby Lake. Kernel driver should configure KBL's DDI buffer setting for AML ULX as well. So far, driver would load DDI translation table that used for KBL H/S platform and apply it on AML devices. But AML is belong to ULX series. This change will lead driver to apply KBL-Y's DDI table for AML devices to avoid unexpected eDP/DP signal quality issue. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Lee, Shawn C <shawn.c.lee@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Lee, Shawn C authored
According to patch "drm/i915/aml: Introducing Amber Lake platform" (e3646724). Add a new marco for AML ULX GT2 devices. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
commit 'b9be7853 ("drm/i915/whl: Introducing Whiskey Lake platform")' introduced WHL by moving some of CFL IDs here and using the Spec information of "U43" for most of IDs what appeared to be GT3. However when propagating the change to Mesa, Lionel noticed that based on number of execution unities the classification here seems at least strange. So, let's move for now with the information we trust more: the number of EUs. So we are able to propagate this change across the stack without getting stuck forever. Reference: https://patchwork.freedesktop.org/patch/246695/ Fixes: b9be7853 ("drm/i915/whl: Introducing Whiskey Lake platform") Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
-
Ville Syrjälä authored
Sprite enable on ILK-IVB may take two frames to complete when the hardware is in big FIFO mode (LP1+). That is not entirely great as it means the sprite enable may actually happen one frame after we've already signalled flip completion. At the very least crc checks may fail due to the sprite not yet being visible when we expect it. We already have code to deal with big FIFO mode when it comes to the sprite scaling on IVB (WaCxSRDisabledForSpriteScaling:ivb). Let's extend that workaround to kick in whenever the sprite is in the process of being enabled. Also ILK/SNB bspec has some notes to indicate that we should most likely also do the sprite scaling w/a on all three platforms, so let's do that as well. Pretty easy to reproduce on SNB/IVB. ILK has proved more elusive, but let's trust the spec and include it as well. v2: Make sure the pipe is active before the vblank wait Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Testcase: igt/kms_plane/pixel-format-pipe-*-planes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107749Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20181004121527.30249-1-ville.syrjala@linux.intel.com
-
Maarten Lankhorst authored
These functions already have a pointer to the correct state, so use it instead of crtc->config. Changes since v1: - Move pll changes to the pll patch. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
Fixing chv_set_phy_signal_level() still requires too many levels of indirection to pass crtc_state along, but chv_data_lane_soft_reset() already has a crtc_state we can use. Signed-off-by:
-
Maarten Lankhorst authored
We're already using crtc_state here and made sure no modeset is occurring by looking at conn_state->commit->hw_done, so there's no need to dereference crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
fbdev init shouldn't race with userspace since it's called from intel_modeset_init, so it's safe to dereference crtc->state and assume nothing changed yet. At least not more harmful than crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Pass the full state to intel_ddi_clk_select, so we can pass it to icl_pll_to_ddi_pll_sel instead of passign the crtc and having to dereference crtc->config Signed-off-by:
-
Maarten Lankhorst authored
Instead of passing crtc and dereferencing crtc->config, pass the correct crtc_state and obtain the crtc pointer from there. Signed-off-by:
-
Maarten Lankhorst authored
Do not rely on crtc->config any more. Remove the assertion from ibx_pch_dpll_disable, because we the dpll state tracking should already handle this case correctly. Changes since v1: - Fixup accidental early return in intel_prepare_shared_dpll, oops! Changes since v2: - Don't use the freed crtc_state in intel_crtc_disable_noatomic() Signed-off-by:
-
Maarten Lankhorst authored
Instead of passing crtc and dereferencing crtc->config, passs the correct crtc_state and obtain the crtc pointer from there. Changes since v1: - Move vlv/chv changes and i9xx_set_pll_dividers changes from crtc_enable/disable patches to here. - Add commit message. Signed-off-by:
-
Maarten Lankhorst authored
Rename intel_crtc to crtc, and pass crtc_state instead of looking at crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Rename intel_crtc to crtc, and pass crtc_state so we don't have to dereference crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Pass the state instead of looking at crtc->config and rename intel_crtc to crtc. Signed-off-by:
-
Maarten Lankhorst authored
If we look at the correct state instead of crtc->config, we can nuke the force parameter, and we cleanup a few more users of crtc->config at the same time. Signed-off-by:
-
Maarten Lankhorst authored
One more user of crtc->config down. :) Changes since v1: - Constify crtc_state - int pipe -> enum pipe pipe - Move i9xx_set_pipeconf declaration to the other pipeconf declarations. Signed-off-by:
-
Chris Wilson authored
Earlier, we reasoned that having idled the gpu under mempressure, that would be a good time to trim our request slabs in order to perform the next request allocation. We have stopped performing the global operation on the device (no idling) and wish to make the allocation failure handling more local, so out with the global barrier that may take a long time. 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/20181005080300.9908-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Before we can reset the seqno, we have to be sure the engines are idle. In debugfs/i915_drop_caches_set, we do wait_for_idle but allow ourselves to be interrupted. We should only proceed to reset the seqno then if we were not interrupted, and so also avoid overwriting the error status. References: https://bugs.freedesktop.org/show_bug.cgi?id=108133 Fixes: 6b048706 ("drm/i915: Forcibly flush unwanted requests in drop-caches") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004082119.24970-1-chris@chris-wilson.co.uk
-
- 04 Oct, 2018 6 commits
-
-
Ville Syrjälä authored
Print the plane hw state readout results in the common format we already use for pipes and encoders. Also print some clearer debug messages when we disable planes during the early phases of state readout/sanitization. v2: Rebase Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to do vblank waits etc. and the other pipe might not even be enabled here. So let's pass the plane's current crtc to intel_plane_disable_noatomic() so that it can its job correctly. To do that semi-cleanly we also have to change the plane readout to record the plane's visibility into the bitmasks of the crtc where the plane is currently enabled rather than to the crtc we want to use for the plane. One caveat here is that our active_planes bitmask will get confused if both planes are enabled on the same pipe. Fortunately we can use plane_mask to reconstruct active_planes sufficiently since plane_mask still has the same meaning (is the plane visible?) during readout. We also have to do the same during the initial plane readout as the second plane could clear the active_planes bit the first plane had already set. v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel) Add Daniel's proposed comment to better document why we do this Drop the redundant intel_set_plane_visible() call Cc: stable@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Cc: Daniel Vetter <daniel@ffwll.ch> Tested-by:Dennis <dennis.nezic@utoronto.ca> Tested-by:
Peter Nowee <peter.nowee@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes: b1e01595 ("drm/i915: Redo plane sanitation during readout") Signed-off-by:
-
Ville Syrjälä authored
Plane sanitation needs vblank interrupts (on account of CxSR disable). So let's restore vblank interrupts earlier. v2: Make it actually build v3: Add comment to explain why we need this (Daniel) Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Tested-by:
-
Ville Syrjälä authored
Always print out the information whether the port and sink can each do MST. And let's include the modparam in the debug output as well. Makes life a little less confusing when you don't have to wonder why MST isn't kicking in. This does cause a slight change in our behaviour towards the sink. Previously we only read the MSTM_CAP register after passing all the other checks. Now we will read that register regardless. Hopefully some crazy sink doesn't get confused by a simple register read. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Daniele Ceraolo Spurio authored
If the HW has not processed the db invalidation request yet, clearing the cookie can generate a db ring. We clear the cookie when we (re-)allocate the doorbell so no need to do it on destroy as well as no one is going to look at it while the doorbell is inactive v2: fix typo in patch title (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
GuC stores some data in there, which might be stale after a reset. We already reset the WQ head and tail, but more things are being moved to the descriptor with the interface updates. Instead of trying to track them one by one, always memset and init the descriptors from scratch after GuC is loaded. The code is also reorganized so that the above operations and the doorbell creation are grouped as "client enabling" v2: add proc_desc_fini for symmetry (Daniele), remove unneeded var init, add guc_is_alive() (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
- 03 Oct, 2018 4 commits
-
-
Chris Wilson authored
Inside the execlists submission tasklet, we often make the mistake of assuming that everything beneath the request is available for use. However, the submission and the request live on two separate timelines, and the request contents may be freed from an early retirement before we have had a chance to run the submission tasklet (think ksoftirqd). To safeguard ourselves against any mistakes, flush the tasklet before we unpin the context if execlists still has a reference to this context. v2: Pull hw_context->active tracking into schedule_in and schedule_out. References: 60367132 ("drm/i915: Avoid use-after-free of ctx in request tracepoints") Signed-off-by:
-
Chris Wilson authored
We do not need to continually clear our dedicated PTE for error capture as it will be updated and invalidated to the next object. Only at the end do we wish to be sure that the PTE doesn't point back to any buffer. Signed-off-by:
-
Chris Wilson authored
The final call to zlib_deflate(Z_FINISH) may require more output space to be allocated and so needs to re-invoked. Failure to do so in the current code leads to incomplete zlib streams (albeit intact due to the use of Z_SYNC_FLUSH) resulting in the occasional short object capture. v2: Check against overrunning our pre-allocated page array v3: Drop Z_SYNC_FLUSH entirely Testcase: igt/i915-error-capture.js Fixes: 0a97015d ("drm/i915: Compress GPU objects in error state") Signed-off-by:
-
Chris Wilson authored
As the kthread may terminate itself, the parent must hold a task_struct reference for it to call kthread_stop(). <4> [498.827675] stack segment: 0000 [#1] PREEMPT SMP PTI <4> [498.827683] CPU: 0 PID: 3872 Comm: drv_selftest Tainted: G U 4.19.0-rc6-CI-CI_DRM_4915+ #1 <4> [498.827686] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018 <4> [498.827695] RIP: 0010:kthread_stop+0x36/0x210 <4> [498.827698] Code: 05 df 3d f6 7e 89 c0 48 0f a3 05 95 f8 29 01 0f 82 56 01 00 00 f0 ff 43 20 f6 43 26 20 0f 84 7f 01 00 00 48 8b ab b0 05 00 00 <f0> 80 4d 00 02 48 89 df e8 5d ff ff ff 48 89 df e8 15 c7 00 00 48 <4> [498.827701] RSP: 0018:ffffc900003937d0 EFLAGS: 00010202 <4> [498.827704] RAX: 0000000000000001 RBX: ffff8802165ece40 RCX: 0000000000000001 <4> [498.827707] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffffff82247460 <4> [498.827709] RBP: 6b6b6b6b6b6b6b6b R08: 00000000581395cb R09: 0000000000000001 <4> [498.827711] R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000393868 <4> [498.827713] R13: ffffc900003937f0 R14: ffff88026c068040 R15: 0000000000001057 <4> [498.827716] FS: 00007fc0c464b980(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 <4> [498.827718] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [498.827720] CR2: 000056178c2feca0 CR3: 000000026983c000 CR4: 0000000000340ef0 <4> [498.827723] Call Trace: <4> [498.827824] smoke_crescendo+0x14c/0x1d0 [i915] <4> [498.827837] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [498.827898] ? __i915_gem_context_pin_hw_id+0x69/0x5f0 [i915] <4> [498.827902] ? ida_alloc_range+0x1f2/0x3d0 <4> [498.827907] ? __mutex_unlock_slowpath+0x46/0x2b0 <4> [498.827914] ? rcu_lockdep_current_cpu_online+0x8f/0xd0 <4> [498.827979] live_preempt_smoke+0x2c2/0x470 [i915] <4> [498.828047] __i915_subtests+0x5e/0xf0 [i915] <4> [498.828113] __run_selftests+0x10b/0x190 [i915] <4> [498.828175] i915_live_selftests+0x2c/0x60 [i915] <4> [498.828232] i915_pci_probe+0x50/0xa0 [i915] <4> [498.828238] pci_device_probe+0xa1/0x130 <4> [498.828244] really_probe+0x25d/0x3c0 <4> [498.828249] driver_probe_device+0x10a/0x120 <4> [498.828253] __driver_attach+0xdb/0x100 <4> [498.828256] ? driver_probe_device+0x120/0x120 <4> [498.828259] bus_for_each_dev+0x74/0xc0 <4> [498.828264] bus_add_driver+0x15f/0x250 <4> [498.828268] ? 0xffffffffa00c3000 <4> [498.828271] driver_register+0x56/0xe0 <4> [498.828274] ? 0xffffffffa00c3000 <4> [498.828278] do_one_initcall+0x58/0x2e0 <4> [498.828281] ? rcu_lockdep_current_cpu_online+0x8f/0xd0 <4> [498.828285] ? do_init_module+0x1d/0x1ea <4> [498.828289] ? rcu_read_lock_sched_held+0x6f/0x80 <4> [498.828293] ? kmem_cache_alloc_trace+0x264/0x290 <4> [498.828297] do_init_module+0x56/0x1ea <4> [498.828302] load_module+0x26f5/0x29d0 <4> [498.828309] ? vfs_read+0x122/0x140 <4> [498.828318] ? __se_sys_finit_module+0xd3/0xf0 <4> [498.828321] __se_sys_finit_module+0xd3/0xf0 <4> [498.828329] do_syscall_64+0x55/0x190 <4> [498.828332] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [498.828335] RIP: 0033:0x7fc0c3f16839 Fixes: 992d2098 ("drm/i915/selftests: Split preemption smoke test into threads") Signed-off-by:
-
- 02 Oct, 2018 6 commits
-
-
Dhinakaran Pandiyan authored
We have new tests and fixes in place since the feature was last disabled. Try again for gen-9+ hardware and enable only PSR1 by default as a first step. v2: Remove typo fix and comment improvements (Rodrigo) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: commit 2ee7dc49 ("drm/i915: disable PSR by default on HSW/BDW") References: commit dcb2e993 ("Revert "drm/i915: Enable PSR by default on Valleyview and Cherryview."") Signed-off-by:
-
Andi Shyti authored
During driver load it's considered that the i915_driver_create() function fails only in case of insufficient memory. Indeed, in case of failure of i915_driver_create(), the load function returns indiscriminately -ENOMEM ignoring the real cause of failure. In i915_driver_create() get the consistent error value from drm_dev_init() and embed it in the pointer return value. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Reviewed-by:
-
Chris Wilson authored
Previously we hesitated in adding the hw probe for the actual GPU frequency for rps_boost as it is quite cumbersome, but given some surprising HW behaviour it would be useful to know both the RPS boost state and the actual HW state in one location. v2: vlv/chv needs more tlc Reported-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
-
Chris Wilson authored
A few callsites were deciding on using WC or WB maps based on HAS_LLC(), so replace them with the equivalent helper function i915_coherent_map_type(). Signed-off-by:
-
Maarten Lankhorst authored
Add plane alpha blending support with the different blend modes. This has been tested on a icl to show the correct results, on earlier platforms small rounding errors cause issues. But this already happens case with fully transparant or fully opaque RGB8888 fb's. The recommended HW workaround is to disable alpha blending when the plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending). This is easy to implement on any platform, so just do that. The tests for userspace are also available, and pass on gen11. Changes since v1: - Change mistaken < 0xff0 to 0xff00. - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend mode. - Rework disabling FBC when per pixel alpha is used. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com>
-
Jyoti Yadav authored
As DMC Package contain DMC FW for multiple steppings including default stepping. This patch will help to load FW for that particular stepping, if FW for that stepping is available, instead of loading default FW. v2 : Fix formatting issue. Signed-off-by:
Jyoti Yadav <jyoti.r.yadav@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 01 Oct, 2018 3 commits
-
-
Chris Wilson authored
Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait completes earlier. v2: Tvrtko recommends to keep the boost-from-user-stall as small as possible and to allow new client flows to be preferred for interactivity over stalls. Testcase: igt/gem_sync/switch-default Signed-off-by:
-
Chris Wilson authored
Currently, the backend scheduling code abuses struct_mutex into order to have a global lock to manipulate a temporary list (without widespread allocation) and to protect against list modifications. This is an extraneous coupling to struct_mutex and further can not extend beyond the local device. Pull all the code that needs to be under the one true lock into i915_scheduler.c, and make it so. Signed-off-by:
-
Chris Wilson authored
Taken from an idea used for FQ_CODEL, we give the first request of a new request flows a small priority boost. These flows are likely to correspond with short, interactive tasks and so be more latency sensitive than the longer free running queues. As soon as the client has more than one request in the queue, further requests are not boosted and it settles down into ordinary steady state behaviour. Such small kicks dramatically help combat the starvation issue, by allowing each client the opportunity to run even when the system is under heavy throughput load (within the constraints of the user selected priority). v2: Mark the preempted request as the start of a new flow, to prevent a single client being continually gazumped by its peers. Testcase: igt/benchmarks/rrul Signed-off-by:
-
