Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We'll gather cross-gen9 W/A in a separate function later.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Squash in fixup from Wu Fengguang.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There have been quite a bit of development lately, leaving behing lonely
protypes. Time to bid them farewell.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>k
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhiyuan Lv <zhiyuan.lv@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhiyuan Lv <zhiyuan.lv@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NEddie Dong <eddie.dong@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NEddie Dong <eddie.dong@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NEddie Dong <eddie.dong@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch introduces 2 bit definitions of context save/restore
control register.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Suggested-by: NDave Gordon <david.s.gordon@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let the DRM core know we can handle it.

v2: Change to boolean true. (Daniel Vetter)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And at the same time replace BUG() with a warning and handle it gracefuly.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
[danvet: Drop the hunk in check_sprite, it's impossible.]
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And skl only works in execlist mode, not in legacy ring submission.

Therefore remove dead code.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Reorder defines (Ben)
v3: More bikesheds, this time re-ordering comments! (Chris)
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Resolve conflict.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This may save a few picoseconds on !HAS_FBC platforms. And it also
satisfies my OCD.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>