- 05 Apr, 2017 5 commits
-
-
Ville Syrjälä authored
VLV/CHV watermarks are now able to handle the radiation, so mark these platforms as ready for atomic. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Suggested-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170303151928.23053-5-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
VLV/CHV don't have double buffered watermarks so they need to consider the cursor visibility as a special case just like ILK-BDW. Let's use the helper we have for that. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
The VLV/CHV watermark calculation is really interested in the hardware plane type rather than the plane type (which is more of a software concept). Let's check plane->id rather plane->type. No functional changes. Signed-off-by:
-
Michal Wajdeczko authored
Almost all other GuC fw definitions are using GUC|guc prefix. While around, in get_core_family() change explicit WARN into MISSING_CASE as it looks more appropriate, since GuC support capability we are controlling by intel_device_info.has_guc flag. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170404133836.125736-1-michal.wajdeczko@intel.comReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
Noticed this while I was looking at some debug output, [drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI I believe the second line should be pipe *bpp* Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491329765-14340-1-git-send-email-dhinakaran.pandiyan@intel.com
-
- 04 Apr, 2017 5 commits
-
-
Ville Syrjälä authored
We're clearing the legacy_cursor_update flag before calling drm_atomic_helper_setup_commit() which means the helper will wait for the flip to complete before cleaning up the framebuffers. That's not what we want for the legacy cursor, so let's clear the flag after setting up the commit. Also toss in a FIXME about solving these problems in a nicer way using the fabled vblank workers. v2: Also unsync with legacy page flips Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Rafael Ristovski <rafael.ristovski@gmail.com> Fixes: a5509abd ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW") Signed-off-by:
-
Michal Wajdeczko authored
On last guc/huc cleanup series we've simplified guc init hw function but missed the one for the huc. While here, change its signature as we don't care about huc loading status. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Chris Wilson authored
If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU, preventing the system from even processing ICMP echo replies. v2: Tvrtko dug into cond_resched() on x86 and found that it only depended upon preempt_count and not tif_need_resched() - which means that we would always call schedule() at that point. Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by:
-
Chris Wilson authored
If the signal to park arrives before we sleep, then we need to check kthread_should_park() before sleeping to avoid missing the signal. Otherwise, if the signal arrives whilst we are processing completed requests, we will reset the current->state back to TASK_INTERRUPTIBLE and so miss the wakeup. Fixes: fe3288b5 ("drm/i915: Park the breadcrumbs signaler across a GPU reset") Signed-off-by:
-
Tvrtko Ursulin authored
Since this can be triggered by simply attempting a huge object, a WARN_ON is not appropriate. Signed-off-by:
-
- 03 Apr, 2017 3 commits
-
-
Chris Wilson authored
Rather than call intel_engine_cleanup() with a partially constructed engine, unwind the error during intel_init_ring_common(). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
Or rather it is used only by intel_ring_pin() to extract the drm_i915_private which we can easily pass in. As this is a relatively rare operation, save the space in the struct, and as such it is even break even in the extra code for passing around the parameter: add/remove: 0/0 grow/shrink: 2/3 up/down: 15/-15 (0) function old new delta intel_init_ring_buffer 906 918 +12 execlists_context_pin 1308 1311 +3 mock_engine 407 403 -4 intel_engine_create_ring 367 363 -4 intel_ring_pin 326 319 -7 Total: Before=1261794, After=1261794, chg +0.00% v2: Reorder intel_init_ring_buffer to keep the ring setup together: add/remove: 0/0 grow/shrink: 2/3 up/down: 9/-15 (-6) function old new delta intel_init_ring_buffer 906 912 +6 execlists_context_pin 1308 1311 +3 mock_engine 407 403 -4 intel_engine_create_ring 367 363 -4 intel_ring_pin 326 319 -7 Total: Before=1261794, After=1261788, chg -0.00% Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 31 Mar, 2017 13 commits
-
-
Chris Wilson authored
commit 8490ae20 ("drm/i915: Suppress busy status for engines if wedged") moved the check for inflight requests to the intel_engines_are_idle() check to protect the idle worker. However, the request selftests were also checking the engine idle status and erroring out if they did not become idle within a short period of time after the final wait. In order to accommodate the new check, call retire requests prior to the engine check so that we flush all the waits. Fixes: 8490ae20 ("drm/i915: Suppress busy status for engines if wedged") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com>
-
Michal Wajdeczko authored
We can rely on compiler to notify us if we miss any case. This approach may also reduce driver size (reported ~4K). Signed-off-by:
-
Paulo Zanoni authored
We don't need to export them since they're not being used outside the file. The next time I try to find the callers for these things I will know I won't need to look outside intel_ddi.c. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Chris Wilson authored
We can merge the pair of loops over the engines and their timelines into a single loop, making it easier to read and more consistent with the commentary. Signed-off-by:
-
Chris Wilson authored
Having added the wait upon each engine to idle into the central i915_gem_wait_for_idle(), we can remove the now redundant wait from reset_all_global_seqno(). This has the advantage of removing the late detection of an error (an engine still busy) which left the seqno reset only partially complete (though it should be safe enough!). Signed-off-by:
-
Chris Wilson authored
Make i915_gem_wait_for_idle() be a little heavier in order to try and guarantee that the GPU is indeed idle (by checking each engine individually is idle, i.e. all writes are complete and the rings stopped) after waiting for in-flight requests to be completed. v2: And return the final error. v3: Break the wait_for() out from under the WARN -- the macro expansion is hideous and unreadable in the warning message v4: If wait_for_engine() fails the result is catastrophic, mark the device as wedged and wait for the repair team. References: https://bugs.freedesktop.org/show_bug.cgi?id=98836Signed-off-by:
-
Chris Wilson authored
As we now distinguish everywhere that can call i915_gem_retire_requests() following a successful wait_for_idle, we can remove the duplication by moving that call into i915_gem_wait_for_idle() itself. Signed-off-by:
-
Michal Wajdeczko authored
There is no reason to separately check for valid fw path before we try to fetch it. Let the fetch function take care of this. Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
This function is no longer used. Its functionality is covered by intel_uc_fini_fw(). Signed-off-by:
-
Michal Wajdeczko authored
Cleanups of uc firmware structs from GuC and Huc are the same for both. Move common code to the helper function to avoid duplication. Signed-off-by:
-
Michal Wajdeczko authored
Some of the DRM_NOTE messages are just using "uC" without specifying which uc they are related to. We can be more user friendly. v2: moved to the header (Joonas) Signed-off-by:
-
Michal Wajdeczko authored
The file fits better. Also use "<invalid>" for invalid case. v2: move directly to .h (Joonas) Signed-off-by:
-
Tamara Diaconita authored
Add description for existing parameter 'pipe' to fix the build warning: ./drivers/gpu/drm/i915/intel_lpe_audio.c:342: warning: No description found for parameter 'pipe'. Signed-off-by:
Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by:
-
- 30 Mar, 2017 14 commits
-
-
Chris Wilson authored
If the driver is wedged, HW state may be very inconsistent and report that it is still busy, even though we have stopped using it. This can lead to a double *ERROR* rather than a graceful cleanup after wedging. Signed-off-by:
-
Chris Wilson authored
As we declare an engine as wedged, we mark all of its active requests as in error. However, we don't want to mark successfully completed requests as in error, which requires us to retire those requests first. Signed-off-by:
-
Chris Wilson authored
We pretty print the name of an engine in several places, mostly for debug, but also in the GPU hang report. Using "ring" in the name is archaic (we call those engines now to differentiate them from the multiple rings of commands we execute on each engine), quite verbose and often tautological. We run out of room in our GPU hang report for instance if we have more than a couple of engines hung simultaneously. Bit the bullet and update the strings to reflect the common internal names. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170330134820.12273-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Michał Winiarski pointed out that the debugging infrastructure (such as trace_dma_fence_release) likes to pretty print the timeline name, long after we have freed the timeline. Our timelines currently live as part of the GTT (due to the strict ordering we currently use through each) which belong to the context. We aim to free the context and release its hardware resources as soon as we able to (i.e. when the last fence/request using it has been signaled and retired). As the .get_timeline_name is purely a debug feature, rather than extending the lifetime of the context, or splitting it into many different release phases just to keep the name around, replace the timeline name with a constant after the fence has been signaled. This avoids the potential use-after-free. Reported-by:
Krzysztof Olinski <krzysztof.e.olinski@intel.com> Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com>
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
gvt-next-2017-03-30 - Add mdev attribute group for per-vgpu info - Time slice based vGPU scheduling QoS support (Gao Ping) - Initial KBL support for E3 server (Han Xu) - other misc. Link: http://patchwork.freedesktop.org/patch/msgid/20170330100516.dkavi3rtlsmnoepi@zhen-hp.sh.intel.comSigned-off-by:
-
Chris Wilson authored
Since commit 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking"), i915_gem_object_put_pages() and specifically the i915_gem_gtt_finish_pages() may be called from outside of the struct_mutex and so we can no longer pass I915_WAIT_LOCKED to i915_gem_wait_for_idle. Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking") Signed-off-by:
-
Oscar Mateo authored
The should happen as soon as possible, but always within the logic that depends on it (and not interrupting the top-level driver control flow). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
Jani Nikula authored
Leave more breadcrumbs for debuggers. Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
-
Jani Nikula authored
Seems more sensible this way, and reduces indent for the more common case. Reviewed-by:
-
Jani Nikula authored
Reduce indent. No functional changes. Reviewed-by:
-
Ping Gao authored
The timeslice usage will determine vGPU whether has chance to schedule or not at every vGPU switch checkpoint. Signed-off-by:
Ping Gao <ping.a.gao@intel.com> Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Ping Gao authored
vGPU resource is allocated by scheduler. To account for non-allocated free cycles, we create an idle vGPU as the placeholder similar to idle task concept, which is useful to handle some corner cases in scheduling policy. Signed-off-by:
-
Ping Gao authored
This method tries to guarantee precision in second level, with the adjustment conducted in every 100ms. At the end of each vGPU switch calculate the sched time and subtract it from the time slice allocated; the allocated time slice for every 100ms together with remaining timeslice, will be used to decide how much timeslice allocated to this vGPU in the next 100ms slice, with the end goal to guarantee weight ratio in second level. Signed-off-by:
-
Ping Gao authored
The weight defines proportional control of physical GPU resource shared between vGPUs. So far the weight is tied to a specific vGPU type, i.e when creating multiple vGPUs with different types, they will inherit different weights. e.g. The weight of type GVTg_V5_2 is 8, the weight of type GVTg_V5_4 is 4, so vGPU of type GVTg_V5_2 has double vGPU resource of vGPU type GVTg_V5_4. TODO: allow user control the weight setting in the future. Signed-off-by:
-
