- 13 Feb, 2015 40 commits
-
-
Damien Lespiau authored
It's always a good idea to keep static analysis happy (also because it prompts doing the check like I proposed :), this time smatch complains: drivers/gpu/drm/i915/intel_ringbuffer.c:891 gen9_init_workarounds() warn: always true condition '((->dev->pdev->revision) >= (0)) => (0-255 >= 0)' That's because revision is a u8. Tweak a bit the condition then. Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
This W/A is put in a gen9 specific function because it may well be needed on other gen9 platforms. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Mika Kuoppala authored
We use the pid of the process which opened our device when we track which was the culprit of the gpu hang. But as that file descriptor might get inherited, we might blame the wrong process when we record the error state. Track process identifiers in requests to always find the correct offender. v2: Track only user processes (Chris) Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> [danvet: drop NULL check before put_pid as suggested by Chris.] Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
This function will host SKL-only W/As. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Let's also take the opportunity the remove the comment telling it's a pre-prod W/A, it should be obvious from the stepping test. Signed-off-by:
-
Damien Lespiau authored
We'll gather cross-gen9 W/A in a separate function later. Signed-off-by:
-
Damien Lespiau authored
WaDisableAsyncFlipPerfMode isn't listed for SKL and INSTPM_FORCE_ORDERING is MBZ so let's make a gen9 specific render init function. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Damien Lespiau authored
At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe eDRAM capabilities). To be more future proof, only look at bit 0 to detect eDRAM presence. Signed-off-by:
-
Damien Lespiau authored
The last (only?) user of this was removed in: commit 2208d655 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 14 09:25:29 2014 +0100 drm/i915: drop WaSetupGtModeTdRowDispatch:snb Signed-off-by:
-
Damien Lespiau authored
This function is not used outside of intel_display.c since; commit cf4c7c12 Author: Matt Roper <matthew.d.roper@intel.com> Date: Thu Dec 4 10:27:42 2014 -0800 drm/i915: Make all plane disables use 'update_plane' (v5) Signed-off-by:
-
Damien Lespiau authored
This was introduced in: commit 0bc12bcb Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Fri Nov 14 08:52:28 2014 -0800 drm/i915: Introduce intel_psr.c But the unpack function is unused at this date. Signed-off-by:
-
Damien Lespiau authored
This function is only used in intel_dp.c since: commit 0e32b39c Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) Signed-off-by:
-
Damien Lespiau authored
This function is only used in intel_lrc.c, so restrict it to that file. The function was moved around to avoid a forward declaration and group it with its user. Signed-off-by:
-
Damien Lespiau authored
This function is only used in intel_lrc.c, so restrict it to that file. The function was moved around to avoid a forward declaration and group it with its user. Signed-off-by:
-
Damien Lespiau authored
This header has been unusued since: commit 063c86f6 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Jan 16 14:27:27 2015 +0200 drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein Signed-off-by:
-
Damien Lespiau authored
This function is only used in intel_ringbuffer.c, so restrict it to that file. The function was moved around to avoid a forward declaration and group it with its user. Signed-off-by:
-
Damien Lespiau authored
There have been quite a bit of development lately, leaving behing lonely protypes. Time to bid them farewell. Signed-off-by:
-
Yu Zhang authored
The current Intel GVT-g only supports alias ppgtt. And the emulation is done in the host by first trapping PP_DIR_BASE mmio accesses. Updating PP_DIR_BASE by using instructions such as MI_LOAD_REGISTER_IMM are hard to detect and are not supported in current code. Therefore this patch also adds a new callback routine - vgpu_mm_switch() to set the PP_DIR_BASE by mmio writes. v2: take Chris' comments: - move the code into sanitize_enable_ppgtt() v4: take Tvrtko's comments: - fix the parenthesis alignment warning Signed-off-by:Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by:
Jike Song <jike.song@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Yu Zhang authored
In the virtualized environment, forcewake operations are not necessary for the driver, because mmio accesses will be trapped and emulated by the host side, and real forcewake operations are also done in the host. New mmio access handlers are added to directly call the __raw_i915_read/write, therefore will reduce many traps and increase the overall performance for drivers running in the VM with Intel GVT-g enhancement. v2: take Chris' comments: - register the mmio hooks in intel_uncore_init() v3: take Daniel's comments: - use macros to assign mmio write functions for vGPU v4: take Tvrtko's comments: - also use mmio hooks for read operations Signed-off-by: -
Yu Zhang authored
With Intel GVT-g, GPU power management is controlled by host driver, so there is no need to provide virtualized GPU PM support. In the future it might be useful to gather VM input for freq boost, but now let's disable it simply. v2: take Chris' comments: - do not special case this to gen6+ Signed-off-by: -
Yu Zhang authored
Display switch logic is added to notify the host side that current vGPU have a valid surface to show. It does so by writing the display_ready field in PV INFO page, and then will be handled in the host side. This is useful to avoid trickiness when the VM's framebuffer is being accessed in the middle of VM modesetting, e.g. compositing the framebuffer in the host side. v2: - move the notification code outside the 'else' in load sequence - remove the notification code in intel_crtc_set_config() v4: - code rebase, no need to define another dev_priv - use #define instead of enum for display readiness Signed-off-by:Zhiyuan Lv <zhiyuan.lv@intel.com> Reviewed-by:
-
Yu Zhang authored
Framebuffer compression is disabled when driver detects it's running in a Intel GVT-g enlightened VM, because FBC is not emulated and there is no stolen memory for a vGPU. v2: take Chris' comments: - move the code into intel_update_fbc() v4: take Tvrtko's comments: - rebase the code into intel_fbc_update() Signed-off-by: -
Yu Zhang authored
With Intel GVT-g, the fence registers are partitioned by multiple vGPU instances in different VMs. Routine i915_gem_load() is modified to reset the num_fence_regs, when the driver detects it's running in a VM. Accesses to the fence registers from vGPU will be trapped and remapped by the host side. And the allocated fence number is provided in PV INFO page structure. By now, the value of fence number is fixed, but in the future we can relax this limitation, to allocate the fence registers dynamically from host side. Signed-off-by:
Eddie Dong <eddie.dong@intel.com> Reviewed-by:
-
Yu Zhang authored
With Intel GVT-g, the global graphic memory space is partitioned by multiple vGPU instances in different VMs. The ballooning code is called in i915_gem_setup_global_gtt(), utilizing the drm mm allocator APIs to mark the graphic address space which are partitioned out to other vGPUs as reserved. With ballooning, host side does not need to translate a grahpic address from guest view to host view. By now, current implementation only support the static ballooning, but in the future, with more cooperation from guest driver, the same interfaces can be extended to grow/shrink the guest graphic memory dynamically. v2: take Chris and Daniel's comments: - no guard page between different VMs - use drm_mm_reserve_node() to do the reservation for ballooning, instead of the previous drm_mm_insert_node_in_range_generic() v3: take Daniel's comments: - move ballooning functions into i915_vgpu.c - add kerneldoc to ballooning functions v4: take Tvrtko's comments: - more accurate comments and commit message Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Yu Zhang authored
Introduce a PV INFO structure, to facilitate the Intel GVT-g technology, which is a GPU virtualization solution with mediated pass-through. This page contains the shared information between i915 driver and the host emulator. For now, this structure utilizes an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware will have the reserved window architecturally defined, and layout of the page will be added in future BSpec. The i915 driver load routine detects if it is running in a VM by reading the contents of this PV INFO page. Thereafter a flag, vgpu.active is set, and intel_vgpu_active() is used by checking this flag to conclude if GPU is virtualized with Intel GVT-g. By now, intel_vgpu_active() will return true, only when the driver is running as a guest in the Intel GVT-g enhanced environment on HSW platform. v2: take Chris' comments: - call the i915_check_vgpu() in intel_uncore_init() - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info take Daniel's comments: - put the definition of PV INFO into a new header - i915_vgt_if.h other changes: - access mmio regs by readq/readw in i915_check_vgpu() v3: take Daniel's comments: - move the i915/vgt interfaces into a new i915_vgpu.c - update makefile - add kerneldoc to functions which are non-static - add a DOC: section describing some of the high-level design - update drm docbook other changes: - rename i915_vgt_if.h to i915_vgpu.h v4: take Tvrtko's comments: - fix a typo in commit message - add debug message when vgt version mismatches - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO structure Signed-off-by: -
Zhi Wang authored
This patch introduces 2 bit definitions of context save/restore control register. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Let the DRM core know we can handle it. v2: Change to boolean true. (Daniel Vetter) Signed-off-by:
-
Tvrtko Ursulin authored
And at the same time replace BUG() with a warning and handle it gracefuly. Signed-off-by:
-
Tvrtko Ursulin authored
Also drop the mutex since with universal planes there is always a proper framebuffer around which wraps the underlying bo. Which means tiling is locked down. This was different in the old code which directly took gem handles. The looking though was always cargo-cult since races where not prevented in any way. v2: Unconditionally enforce untiled, because cursors are always untiled. The check for physical or gtt cursor is irrelevant. Also clarify the commit message a bit Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by: -
Tvrtko Ursulin authored
While at it just outright remove the tiling check in intel_check_sprite_plane because it's impossible: We only allow untiled and X-tiled. This essentially reverts commit 94c6419e Author: Damien Lespiau <damien.lespiau@intel.com> Date: Mon Oct 29 15:14:51 2012 +0000 drm/i915: Error out when trying to set a y-tiled as a sprite Signed-off-by:
-
