- Feb 14, 2015
-
-
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:Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by:
Jike Song <jike.song@intel.com> Signed-off-by:
Zhiyuan Lv <zhiyuan.lv@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 <damien.lespiau@intel.com> [danvet: Resolve conflict.] 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:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
This may save a few picoseconds on !HAS_FBC platforms. And it also satisfies my OCD. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Paulo Zanoni authored
.. because it would be a waste of time, so move the place where the check is done. Also, with this we won't risk printing "more than one pipe active, disabling compression" or "no output, disabling" when FBC is actually disabled. This patch also represents a small behavior difference when using i915.powersave=0: it is now exactly the same as i915.enable_fbc=0 on this part of the code. V2: Rebase. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by:
-
Nick Hoath authored
Add: WaEnableForceRestoreInCtxtDescForVCS v2: Add stepping check. v3: Fixed stepping check direction. Cleaned up indentation. Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
-
Nick Hoath authored
Fixed the stepping check on WaDisableDgMirrorFixInHalfSliceChicken5 to be for the correct SOC (Skylake) Signed-off-by:
-
Rob Clark authored
In DRM/KMS we are lacking a good way to deal with tiled/compressed formats. Especially in the case of dmabuf/prime buffer sharing, where we cannot always rely on under-the-hood flags passed to driver specific gem-create ioctl to pass around these extra flags. The proposal is to add a per-plane format modifier. This allows to, if necessary, use different tiling patters for sub-sampled planes, etc. The format modifiers are added at the end of the ioctl struct, so for legacy userspace it will be zero padded. v1: original v1.5: increase modifier to 64b v2: Incorporate review comments from the big thread, plus a few more. - Add a getcap so that userspace doesn't have to jump through hoops. - Allow modifiers only when a flag is set. That way drivers know when they're dealing with old userspace and need to fish out e.g. tiling from other information. - After rolling out checks for ->modifier to all drivers I've decided that this is way too fragile and needs an explicit opt-in flag. So do that instead. - Add a define (just for documentation really) for the "NONE" modifier. Imo we don't need to add mask #defines since drivers really should only do exact matches against values defined with fourcc_mod_code. - Drop the Samsung tiling modifier on Rob's request since he's not yet sure whether that one is accurate. v3: - Also add a new ->modifier[] array to struct drm_framebuffer and fill it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin. - Remove TODO in comment and add code comment that modifiers should be properly documented, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5) Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ben Widawsky authored
The current code will both potentially print a WARN, and setup part of the PPGTT structure. Neither of these harm the current code, it is simply for clarity, and to perhaps prevent later bugs, or weird debug messages. Signed-off-by:
-
Ben Widawsky authored
In gen8, 32b PPGTT has always had one "pdp" (it doesn't actually have one, but it resembles having one). The #define was confusing as is, and using "PDPE" is a much better description. sed -i 's/GEN8_LEGACY_PDPS/GEN8_LEGACY_PDPES/' drivers/gpu/drm/i915/*.[ch] It also matches the x86 pagetable terminology: PTE = Page Table Entry - pagetable level 1 page PDE = Page Directory Entry - pagetable level 2 page PDPE = Page Directory Pointer Entry - pagetable level 3 page And in the near future (for 48b addressing): PML4E = Page Map Level 4 Entry v2: Expanded information about Page Directory/Table nomenclature. Cc: Daniel Vetter <daniel@ffwll.ch> CC: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
-
Hoath, Nicholas authored
v2: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for WaForceEnableNonCoherent Signed-off-by:
-
Hoath, Nicholas authored
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds v2: rebase Signed-off-by:
-
Nick Hoath authored
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds v2: Add stepping check. Signed-off-by:
-
Hoath, Nicholas authored
v2: Add stepping check for WaDisableSDEUnitClockGating. Signed-off-by:
-
Nick Hoath authored
This one doesn't have one of these nice cryptic names unfortunately. v2: Added missing register bitmap Signed-off-by:
-
Nick Hoath authored
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds v2: Added stepping check v3: Removed unused register bitmap Signed-off-by:
-
Hoath, Nicholas authored
v2: Dont add WaDisableThreadStallDopClockGating as not SKL WA. (Found by Damien Lespiau) Signed-off-by:
-
Hoath, Nicholas authored
Add Skylake stepping Revision IDs definitions. v1: Use existing revision id. Signed-off-by:
-
Hoath, Nicholas authored
Add framework for gen 9 HW WAs v1: Changed SOC specific WA function to gen 9 common function (Req: Damien Lespiau) Signed-off-by:
-
Damien Lespiau authored
We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Damien Lespiau authored
Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by:
-
