- 13 Feb, 2015 40 commits
-
-
Damien Lespiau authored
This function will host SKL-only W/As. 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
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:
-
Tvrtko Ursulin authored
And skl only works in execlist mode, not in legacy ring submission. Therefore remove dead code. Signed-off-by:
-
Daniel Vetter authored
Just a little demo really. We probably need to introduce skl specific functions for a lot of the format validation stuff, or at least helpers. Specifically I think intel_framebuffer_init and intel_fb_align_height must be adjusted to have an i915_ and a skl_ variant. And only shared code should be converted to fb modifiers, platform code (like the plane config readout can keep on using old tiling_mode defines to avoid some churn). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
With this we can treat the fb format modifier completely independently from the fencing mode in obj->tiling_mode in the initial plane code. Which means new tiling modes without any gtt fence are now fully support in the core i915 driver code. v2: Also add pixel_format while at it, we need this to compute the height for the new tiling formats. Reviewed-by:
-
Daniel Vetter authored
No functional changes yet since intel_framebuffer_init would have fixed this up for us. But this is prep work to be able to handle new tiling layouts in the initial plane config code. Follow-up patches will start to make use of this and switch over to fb modifiers where needed. Reviewed-by:
-
Tvrtko Ursulin authored
Signed-off-by:
-
Daniel Vetter authored
Currently we don't support anything but X tiled. And for an easier transition it makes a lot of sense to just keep requiring that X tiled is properly fenced. Which means we need to do absolutely nothing in old code to support fb modifiers, yay! v2: Fix the Y tiling check, noticed by Tvrtko. v3: Catch Y-tiled fb for legacy addfb again (Tvrtko) and explain why we want X tiling to match in the comment. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
To be used from the new addfb2 extension. v2: - Drop Intel-specific untiled modfier. - Move to drm_fourcc.h. - Document layouts a bit and denote them as platform-specific and not useable for cross-driver sharing. - Add Y-tiling for completeness. - Drop special docstring markers to avoid confusing kerneldoc. v3: Give Y-tiling a unique idea, noticed by Tvrtko. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Damien Lespiau authored
v2: Reorder defines (Ben) v3: More bikesheds, this time re-ordering comments! (Chris) Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Damien Lespiau authored
When enabling new platforms, we may not have any W/A to apply, especially that, now, a bunch of them have to be done from the ring. Signed-off-by:
-
Paulo Zanoni authored
Since the mapping from CRTCs to planes is fixed, looking at the CRTC is essentially the same as looking at the plane. Also, the next patches wil start using the frontbuffer_bits macros, and they take the pipe as the parameter instead of the plane, and this could differ on gens 2 and 3. Another nice thing is that we don't risk accidentally initializing things to PLANE_A if we don't set the value before it is used for the first time. But this shouldn't be a problem with the current code. V2: Rebase. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by:
-
