- 08 Jun, 2017 1 commit
-
-
Changbin Du authored
The gvt:gvt_command trace involve unnecessary overhead even this trace is not enabled. We need improve it. The kernel trace infrastructure provide a full api to define a trace event. We should leverage them if possible. And one important thing is that a trace point should store raw data but not format string. This patch include two part work: 1) Refactor the gvt_command trace definition, including: o only store raw trace data. o use __dynamic_array() to declare a variable size buffer. o use __print_array() to format raw cmd data. o rename vm_id as vgpu_id. 2) Improve the trace invoking, including: o remove the cycles calculation for handler. We can get this data by any perf tool. o do not make a backup for raw cmd data which just doesn't make sense. With this patch, this trace has no overhead if it is not enabled. And we are trace style now. The final output example: gvt workload 0-211 [000] ...1 120.555964: gvt_command: vgpu1 ring 0: buf_type 0, ip_gma e161e880, raw cmd {0x4000000} gvt workload 0-211 [000] ...1 120.556014: gvt_command: vgpu1 ring 0: buf_type 0, ip_gma e161e884, raw cmd {0x7a000004,0x1004000,0xe1511018,0x0,0x7d,0x0} gvt workload 0-211 [000] ...1 120.556062: gvt_command: vgpu1 ring 0: buf_type 0, ip_gma e161e89c, raw cmd {0x7a000004,0x140000,0x0,0x0,0x0,0x0} gvt workload 0-211 [000] ...1 120.556110: gvt_command: vgpu1 ring 0: buf_type 0, ip_gma e161e8b4, raw cmd {0x10400002,0xe1511018,0x0,0x7d} Signed-off-by:Changbin Du <changbin.du@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 29 May, 2017 1 commit
-
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 May, 2017 6 commits
-
-
Chris Wilson authored
Currently the timer is armed for 1ms after the first use and is killed immediately, dropping the forcewake as early as possible. However, for very frequent operations the forcewake dance has a large impact on latency and keeping the timer alive until we are idle is preferred. To achieve this, if we call intel_uncore_forcewake_get whilst the timer is alive (repeated use), then set a flag to restart the timer on expiry rather than drop the forcewake usage count. The timer is racy, the consequence of the race is to expire the timer earlier than is now desired but does not impact on correct behaviour. The offset the race slightly, we set the active flag again on intel_uncore_forcewake_put. The effect should be to reduce the jitter of reacquiring the fw every 1ms on a busy system. However, the cost is to keep the timer alive for an extra 1ms on a nearly idle system. We chose to incur the jitter previously to keep the timer off for as much as possible. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170526132209.14640-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around instead of using kernel memory (chris) don't store the logs in the gpu_error struct (Chris) add a check on guc_log_level to avoid snapshotting empty logs v3: use separate debugfs for error log (Chris) v4: rebased v5: clean up obj selection, move err_load inside guc_log, move err_load cleanup, rename functions (Michal) v6: move obj back to intel_guc, move functions to intel_uc.c, don't clear obj on new GuC load, free object only if enable_guc_loading is set (Michal) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1495475428-19295-1-git-send-email-daniele.ceraolospurio@intel.comReviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Tested-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Buffer based command transport can replace MMIO based mechanism. It may be used to perform host-2-guc and guc-to-host communication. Portions of this patch are based on work by: Michel Thierry <michel.thierry@intel.com> Robert Beckett <robert.beckett@intel.com> Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> v2: use gem_object_pin_map (Chris) don't use DEBUG_RATELIMITED (Chris) don't track action stats (Chris) simplify next fence (Chris) use READ_ONCE (Chris) move blob allocation to new function (Chris) v3: use static owner id (Daniele) v4: but keep channel initialization generic (Daniele) and introduce owner_sub_id (Daniele) Signed-off-by: -
Michal Wajdeczko authored
In earlier patch 789a6251 we were enabling send function only after successful init. For completeness, we should make sure that we disable it on fini. v2: don't group steps by submission flag (Chris) Signed-off-by:
-
Puthikorn Voravootivat authored
This patch adds the following definition - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap register which only use bit 0:4 - Base frequency (27 MHz) for backlight PWM frequency generator. Signed-off-by:
Puthikorn Voravootivat <puthik@chromium.org> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170523223805.46372-5-puthik@chromium.org
-
Puthikorn Voravootivat authored
There are some panel that (1) does not support display backlight enable via AUX (2) support display backlight adjustment via AUX (3) support display backlight enable via eDP BL_ENABLE pin The current driver required that (1) must be support to enable (2). This patch drops that requirement. Signed-off-by:
-
- 25 May, 2017 3 commits
-
-
Chris Wilson authored
We depend on intel_iommu_gfx_mapped for various workarounds, but that is only available under an #ifdef CONFIG_INTEL_IOMMU. Refactor all the cut-and-paste ifdefs to a common routine. Signed-off-by:
-
Chris Wilson authored
As only GGTT vma may be permanently pinned and are always at the head of the object's vma list, as soon as we seen a ppGTT vma we can stop searching for any_vma_pinned(). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Jon Bloomfield authored
BXT has a H/W issue with IOMMU which can lead to system hangs when Aperture accesses are queued within the GAM behind GTT Accesses. This patch avoids the condition by wrapping all GTT updates in stop_machine and using a flushing read prior to restarting the machine. The stop_machine guarantees no new Aperture accesses can begin while the PTE writes are being emmitted. The flushing read ensures that any following Aperture accesses cannot begin until the PTE writes have been cleared out of the GAM's fifo. Only FOLLOWING Aperture accesses need to be separated from in flight PTE updates. PTE Writes may follow tightly behind already in flight Aperture accesses, so no flushing read is required at the start of a PTE update sequence. This issue was reproduced by running igt/gem_readwrite and igt/gem_render_copy simultaneously from different processes, each in a tight loop, with INTEL_IOMMU enabled. This patch was originally published as: drm/i915: Serialize GTT Updates on BXT v2: Move bxt/iommu detection into static function Remove #ifdef CONFIG_INTEL_IOMMU protection Make function names more reflective of purpose Move flushing read into static function v3: Tidy up for checkpatch.pl Testcase: igt/gem_concurrent_blit Signed-off-by:Jon Bloomfield <jon.bloomfield@intel.com> Cc: John Harrison <john.C.Harrison@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1495641251-30022-1-git-send-email-jon.bloomfield@intel.comReviewed-by:
-
- 24 May, 2017 2 commits
-
-
Chris Wilson authored
Having just watched someone add a new value, 0x3, without realising that the flags were bit values, I have come to appreciate the value in using BIT. Signed-off-by:
-
Chris Wilson authored
The compiler doesn't always spot the guard that object is allocated on the first pass, leading to: drivers/gpu/drm/i915/selftests/i915_gem_context.c: warning: 'obj' may be used uninitialized in this function [-Wuninitialized]: => 370:8 v2: Make it more obvious by setting obj to NULL on the first pass and any later pass where we need to reallocate. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: 791ff39a ("drm/i915: Live testing for context execution") Signed-off-by:
-
- 23 May, 2017 2 commits
-
-
Michał Winiarski authored
If port[0] is occupied and we're trying to dequeue request from different context, we will inevitably hit BUG_ON in port_assign. Let's skip it - similar to what we're doing in execlists counterpart. Fixes: 77f0d0e9 ("drm/i915/execlists: Pack the count into the low bits of the port.request") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
Passing NULL ctx to request_alloc would lead to null-ptr-deref. v2: Let's not replace the comment with a BUG_ON Signed-off-by:
-
- 22 May, 2017 3 commits
-
-
Mika Kuoppala authored
We improved the reset reliablity on gen4 with stopping all engines before commencing reset, in commit 2c80353f ("drm/i915/g4x: Improve gpu reset reliability") Evidence indicates that this same trick works with g33. v2: proper gen naming, comment readability (Chris) Testcase: igt/gem_busy/*-hang #blb-e6850 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Acked-by:
-
Daniel Vetter authored
This reverts commit bc5ca47c. Gabriel put this back into generic code with commit 75f6dfe3 Author: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Date: Wed Dec 28 12:32:11 2016 -0200 drm: Deduplicate driver initialization message but somehow he missed Chris' patch to add the message meanwhile. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101025 Fixes: 75f6dfe3 ("drm: Deduplicate driver initialization message") Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.11+ Reviewed-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517131557.7836-1-daniel.vetter@ffwll.ch
-
Anusha Srivatsa authored
Update version of HuC from 01.07.1748 to the version 02.00.1748 Cc: Ander Conselvan <ander.conselvan.de.oliveira@intel.com> Cc: John Spotswood <john.a.spotswood@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1495129631-2930-1-git-send-email-anusha.srivatsa@intel.com
-
- 19 May, 2017 6 commits
-
-
Colin Ian King authored
The memory allocation for C is not being null checked and hence we could end up with a null pointer dereference. Fix this with a null pointer check. (I really should have noticed this when I was fixing an earlier issue.) Detected by CoverityScan, CID#1436406 ("Dereference null return") Fixes: 47624cc3 ("drm/i915: Import the kfence selftests for i915_sw_fence") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170519175617.7036-1-colin.king@canonical.comReviewed-by:
-
Michal Wajdeczko authored
Usefulness of these stats was over-advertised. v2: remove duplicated engine stats (Chris) Suggested-by:
-
Mika Kuoppala authored
ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings before resetting. It is unclear what cleanup exactly means but evidence shows that stopping the ring does have an effect on reset reliability. This patch makes reset successful on hangs induced by chained batches (the igt ones). Note that if the hang is inside a shader, it is possible that our attempts to stop the ring achieves anything. v2: zero ctl,head,tail also. bug ref. use driver debugs (Chris) v3: specify platform on testcases, comment tidyup (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Testcase: igt/gem_busy/*-hang #elk Testcase: igt/gem_ringfill/hang-* #elk Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Debugfs does not seems to be a right place to display transient data. If we want to capture errors, we should log them. Signed-off-by:
-
Michal Wajdeczko authored
This stat is almost always zero unless fatal error occurs, which should be reported by other means anyway. Suggested-by:
-
Michal Wajdeczko authored
This member was dropped long time ago. Fixes: 774439e1 ("drm/i915/guc: re-optimise i915_guc_client layout") Signed-off-by:
-
- 18 May, 2017 5 commits
-
-
Chris Wilson authored
Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942Suggested-by:
-
Chris Wilson authored
Repeat the reset a couple of times if at first we do not succeed. v2: differentiate which path/engine failed with a debug message Signed-off-by:
-
Chris Wilson authored
Set the class on our mock pci device to GFX. This should be useful for utilities like intel-iommu that special case gfx devices. References: https://bugs.freedesktop.org/show_bug.cgi?id=101080Signed-off-by:
-
Colin Ian King authored
There are two occasions where pointer B is being check for a NULL when it should be pointer C instead. Fix these. Detected by CoverityScan, CID#1436348,1436349 ("Logically Dead Code") Fixes: 47624cc3 ("drm/i915: Import the kfence selftests for i915_sw_fence") Signed-off-by: -
Hans de Goede authored
This commit fixes the following compiler warning: drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’: drivers/gpu/drm/i915/intel_dsi.c:1487:23: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] PORT_A ? PORT_C : PORT_A), Fixes: f4c3a88e ("drm/i915: Tighten mmio arrays for MIPI_PORT") Signed-off-by:Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 17 May, 2017 11 commits
-
-
Kumar, Mahesh authored
This patch make changes to use linetime latency if allocated DDB size during plane watermark calculation is not available. linetime is the time, display engine takes to fetch one line worth of pixels with given pixel clock rate. This is required to implement new DDB allocation algorithm. In New Algorithm DDB is allocated based on WM values, because of which number of DDB blocks will not be available during WM calculation, So this "linetime latency" is suggested by SV/HW team to be used during switch-case for WM blocks selection. linetime latency us = pipe horizontal total pixels/adjusted pixel rate MHz Changes since v1: - Rebase on top of Paulo's patch series Changes since v2: - Fix if-else condition (pointed by Maarten) Changes since v3: - Use common function for timetime_us calculation (Paulo) - rebase on drm-tip Changes since v4: - Use consistent name for fixed_point operation Changes since v5: - Improve commit message - rename skl_get_linetime_us to intel_get_linetime_us - fix watermark result selection (Matt) Signed-off-by:
"Mahesh Kumar" <mahesh1.kumar@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Kumar, Mahesh authored
Instead of iterating over planes & wm levels in a single function use skl_compute_wm_level function to interate over WM levels. Change name of function to skl_compute_wm_levels (Matt). These changes are to clean-up WM code & will help in making only new ddb algorithm related changes in later patch in series. Signed-off-by:
-
Kumar, Mahesh authored
This patch cleanup/reorganises the watermark calculation functions. This patch make use of already available macro "drm_atomic_crtc_state_for_each_plane_state" to walk through plane_state list instead of calculating plane_state in function itself. This restructuring will help later patch for new DDB allocation algorithm to do only algo related changes. Changes from V1: - split the patch in two parts as per Matt's comment Signed-off-by:
-
Kumar, Mahesh authored
DDB minimum requirement of crtc configuration (cumulative of all the enabled planes in crtc) may exceed the allocated DDB for crtc/pipe. This patch make changes to fail the flip/ioctl if minimum requirement for pipe exceeds the total ddb allocated to the pipe. Previously it succeeded but making alloc_size a negative value. Which will make subsequent calculations for plane ddb allocation bogus & may lead to screen corruption or system hang. Changes from V1: - Improve commit message as per Ander's comment - Remove extra parentheses (Ander) Signed-off-by:
-
Kumar, Mahesh authored
We are already doing memset of ddb structure at the begining of skl_allocate_pipe_ddb function, No need to again do a memset. Signed-off-by:
-
Kumar, Mahesh authored
Fail the flip if no FB is present but plane_state is set as visible. Above is not a valid combination so instead of continue fail the flip. Signed-off-by:
-
Kumar, Mahesh authored
This patch make changes to calculate adjusted plane pixel rate & plane downscale amount using fixed_point functions available. This patch will give uniformity in code, & will help to avoid mixing of 32bit uint32_t variable for fixed-16.16 with fixed_16_16_t variables in later patch in the series. Changes from V1: - Rebase based on wrapper name change - Remove unnecessary comment Signed-off-by:
-
Kumar, Mahesh authored
Don't use fixed_16_16 structure members directly, instead use wrapper to perform fixed_16_16 division operation. Signed-off-by:
-
Kumar, Mahesh authored
This patch adds few wrapper to perform fixed_point_16_16 operations mul_round_up_u32_fixed16 : Multiplies u32 and fixed_16_16_t variables & returns u32 result with rounding-up. mul_fixed16 : Multiplies two fixed_16_16_t variable & returns fixed_16_16 div_round_up_fixed16 : Perform division operation on fixed_16_16_t variables & return u32 result with round-off div_round_up_u32_fixed16 : devide uint32_t variable by fixed_16_16 variable and round_up the result to uint32_t. These wrappers will be used by later patches in the series. Changes from V1: - Rename wrapper as per Matt's comment Changes from V2: - Fix indentation Signed-off-by:
-
Kumar, Mahesh authored
fixed_16_16_div_round_up(_u64), wrapper for fixed_16_16 division operation don't really round_up the result. Wrapper round_up only the fraction part of the result to make it 16-bit. This patch eliminates round_up keyword from the wrapper. Later patch will introduce the new wrapper to do rounding-off the result and give unt32_t output to cleanup mix use of fixed_16_16_t & uint32_t variables. Signed-off-by:
-
Chris Wilson authored
Since we coordinate with the execlists tasklet using a locked schedule operation that ensures that after we set the engine->irq_posted we always have an invocation of the tasklet, we do not need to use a locked operation to set the engine->irq_posted itself. Signed-off-by:
-
