- 16 Feb, 2017 3 commits
-
-
Jani Nikula authored
No need to cater for old A revisions. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487172099-24873-4-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
No need to cater for old A revisions. Reviewed-by:
-
Jani Nikula authored
No need to cater for old A revisions. Reviewed-by:
-
- 15 Feb, 2017 28 commits
-
-
Uma Shankar authored
MIPI Video Mode for high res panels (requiring dual link), need a 8X/3 divider to be programmed as 0x2. Modifying the same in this patch. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by:
-
Uma Shankar authored
Panel GPIO control should be done based on platform. Add a check to restrict VLV and CHT specific GPIO confirguration, so that they dont apply to other platforms. The VBT spec fails to mention the PMIC backlight control option is valid only for VLV/CHT, and the field may be set to "PMIC" for BXT even if PMIC is not desired or possible. Signed-off-by:
-
Manasi Navare authored
The max link parameters should be set/reset only on HPD or connected boot case or on system resume. Add a flag reset_link_params to intel_dp to decide when to reset the max link parameters. This prevents the parameters from getting reset/overwritten through all other connector->funcs->detect() calls. This is important when link training fails and the max link params are modified to the lower fallback values. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Chris Wilson authored
Make checkpatch happy and make the use of u32/u64 consistent throughout i915_gem_gtt.[ch] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170215084357.19977-23-chris@chris-wilson.co.uk
-
Chris Wilson authored
Use an invalid filp so that the aliasing_ppgtt can be clearly identified. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170215084357.19977-22-chris@chris-wilson.co.uk
-
Chris Wilson authored
As the aliasing GTT is only accessed via the global GTT, we will never use more of it than we expose via the Global GTT and so we only need to preallocate sufficient space within the ppgtt for the full GTT. Equally, if the aliasing GTT is smaller than the global GTT, we have a serious issue and must bail. Signed-off-by:
-
Chris Wilson authored
Once upon a time, back in the UMS days, we supported userspace initialising the GTT and sharing portions of the GTT with other users. Now, we own the GTT (both global and per-process) and the tables always start at 0 - so we can remove i915_address_space.start and forget about this old complication. Signed-off-by:
-
Chris Wilson authored
We never assign or use the ppgtt->enable() callback, so remove it. Signed-off-by:
-
Chris Wilson authored
The tracepoints are now entirely synonymous with binding and unbinding the VMA (and the tracepoints there). Signed-off-by:
-
Chris Wilson authored
We want to reload the PDP (and flush the TLB) when the addresses are changed. Signed-off-by:
-
Chris Wilson authored
The barrier here is not required - we apply the barrier before the range is ever reused by the GPU instead. Signed-off-by:
-
Chris Wilson authored
We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by:
-
Chris Wilson authored
We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by:
-
Chris Wilson authored
We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by:
-
Chris Wilson authored
We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170215084357.19977-12-chris@chris-wilson.co.uk
-
Chris Wilson authored
Stop passing around unused parameters makes the code more compact. Signed-off-by:
-
Chris Wilson authored
Upon creation of the va range, it is initialised to point at scratch. Signed-off-by:
-
Chris Wilson authored
The hardware does not cope very well with us changing the PD within an active context (the context must be idle for it to re-read the PD). As we only check whether the page is idle before changing the entry (and on through the PD tree), we cannot reliably replace PD entries on gen6/gen7. To fully avoid changing the tree at runtime, preallocate it on init. Signed-off-by:
-
Chris Wilson authored
In the future, we need to call allocate_va_range on the aliasing-ppgtt which means moving the call down from the vma into the vm (which is more appropriate for calling the vm function). Signed-off-by:
-
Chris Wilson authored
As these are now both plain and simple kmap_atomic/kunmap_atomic pairs, we can remove the wrappers for a small gain of clarity (in particular, not hiding the atomic critical sections!). Signed-off-by:
-
Chris Wilson authored
We flush the entire page every time we update a few bytes, making the update of a page table many, many times slower than is required. If we create a WC map of the page for our updates, we can avoid the clflush but incur additional cost for creating the pagetable. We amoritize that cost by reusing page vmappings, and only changing the page protection in batches. Signed-off-by:
-
Chris Wilson authored
Similar to how we already split the bind_vma for ggtt/aliasing_gtt, also split up the unbind for symmetry. Signed-off-by:
-
Chris Wilson authored
The aliasing_ppgtt is a regular ppgtt, and we can use the regular i915_ppgtt_put() to properly tear it down. Signed-off-by:
-
Chris Wilson authored
Improve the sg iteration and in hte process eliminate a bug in miscomputing the pml4 length as orig_nents<<PAGE_SHIFT is no longer the full length of the sg table. v2: Check for the end of the fourth level page table (the final pdpe) and move onto the next. v3: Assert that 3lvl insert_pte_entries doesn't overflow its smaller set of PDP. Signed-off-by:
-
Chris Wilson authored
Inline the address computation to avoid the vfunc call for every page. We still have to pay the high overhead of sg_page_iter_next(), but now at least GCC can optimise the inner most loop, giving a significant boost to some thrashing Unreal Engine workloads. Signed-off-by:
-
Chris Wilson authored
The predominant VMA class is normal GTT, so allow gcc to emphasize that path and avoid unnecessary stack movement. Signed-off-by:
-
Hans de Goede authored
If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail tablet and on a ACER SW5_017 machine. Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Tvrtko Ursulin authored
intel_ring_workarounds_emit is exactly the same code. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
- 14 Feb, 2017 9 commits
-
-
Chris Wilson authored
Currently we apply the jump to rpe if we are below it and the GPU needs more power. For some GPUs, the rpe is 75% of the maximum range causing us to dramatically overshoot low power applications *and* unable to reach the low frequency that can most efficiently deliver their workload. Signed-off-by:
Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
-
Chris Wilson authored
If we receive a DOWN_TIMEOUT rps interrupt, we respond by reducing the GPU clocks significantly. Before we do, double check that the frequency we pick is actually a decrease. Signed-off-by:
-
Chris Wilson authored
When the RPS tuning was applied to Baytrail, in commit 8fb55197 ("drm/i915: Agressive downclocking on Baytrail"), concern was given that it might cause Cherryview excess wakeups of the common power well. However, the static thresholds perform poorly for Kodi, and the GPU is unable to deliver the video frames on time. Enabling the dynamic, finer thresholds used on all other platforms (including Skylake and Broxton that also have the same multiple powerwell concerns) allows the GPU to pick a more appropriate frequency and not drop frames. Signed-off-by:
-
Chris Wilson authored
Once upon a time before we had automated GPU state capture upon hangs, we had intel_gpu_dump. Now we come almost full circle and reinstate that view of the current GPU queues and registers by using the error capture facility to snapshot the GPU state when debugfs/.../i915_gpu_info is opened - which should provided useful debugging to both the error capture routines (without having to cause a hang and avoid the error state being eaten by igt) and generally. v2: Rename drm_i915_error_state to i915_gpu_state to alleviate some name collisions between the error state dump and inspecting the gpu state. Signed-off-by:
-
Chris Wilson authored
We no longer need to take the struct_mutex for freeing objects, and on the finalisation paths here the mutex is not been used for serialisation of the pointer access, so remove the BKL wart. Signed-off-by:
-
Chris Wilson authored
In general, the compiler should not be able to detect if we do any passes through the test loops: In file included from drivers/gpu/drm/i915/i915_gem.c:5029: drivers/gpu/drm/i915/selftests/i915_gem_coherency.c: In function 'igt_gem_coherency': drivers/gpu/drm/i915/selftests/i915_gem_coherency.c:274: error: 'err' may be used uninitialized in this function Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Chris Wilson authored
gcc-4.7 spotted that In file included from drivers/gpu/drm/i915/i915_gem_gtt.c:3791:0: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c: In function ‘pot_hole’: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:594:6: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized] So set it to 0 should we ever skip over a hole smaller than a few pages. Signed-off-by:
-
Chris Wilson authored
When using the mock_ppgtt selftest, the GTT is large enough to cause an overflow in pot_hole() when adding 2 pages to the address. Avoid the overflow by computing the final valid address and iterating up to that address. Signed-off-by:
-
Deepak S authored
With latest Punit FW, vgg input voltag drop falling to minimum is fixed. So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0] This is not a 1:1 revert of the commit 5b7c91b7. You can refer to commit 5b5929cb ("drm/i915/chv: remove pre-production hardware workarounds") as the reason for the discrepancy commit 5b7c91b7 Author: Deepak S <deepak.s@linux.intel.com> Date: Sat May 9 18:15:46 2015 +0530 drm/i915/chv: Set min freq to efficient frequency on chv v2: Fix inconsistent return type. (Chris) v3: drop pre-production hw case (Ville) Acked-by:
Deepak S <deepak.s@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471007801-86075-1-git-send-email-deepak.s@linux.intel.comReviewed-by:
-
