drm/i915: Add MI_SET_APPID cmd to cmd parser tables

Was missing.

Issue: VIZ-4701
Signed-off-by: Michael H. Nguyen <michael.h.nguyen@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move FBC stuff to intel_fbc.c

No functional changes. This is just the begin of a FBC rework.

v2 (Paulo):
  - Revert intel_fbc_init() changed parameter.
  - Revert set_no_fbc_reason() rename.
  - Rebase.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check mask/bit helper functions

After a bit of irc discussion we've concluded that it would be prudent
to check that callers use the mask/enable paramters correctly. So add
a WARN_ON.

Spurred by Damien's bugfix which added _MASKED_FIELD.

v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
which should always be extended. So this doesn't work really. Dunno
why gcc only started complaining when I've moved the WARN out of the
static inline helper to address a feedback from Jani.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Move golden context init into ->init_context

Similar to a patch from Thomas Daniel for lrc contexts. This keeps
both sides somewhat in sync and should make Dave Gordon happy.

Note that both the wa and the golden context init code suffer a bit
from an inssuficient split into driver load and hw init code. Which
means we have a bunch of tests all over the place to check whether the
one-time initialization has been done already or not.

All that one-tim code should be moved into the one-time ring setup
code, but that's work for later.

Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

gpu: drm: i915: intel_display.c: Remove unused function

Remove the function intel_output_name() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Additional request structure tracing

Added the request structure's 'uniq' identifier to the trace information. Also
renamed the '_complete' trace event to '_notify' as it actually happens in the
IRQ 'notify_ring()' function. The intention is to add a new '_complete' trace
event which occurs when a request structure is actually marked as complete.
However, at the moment the completion status is re-tested every time the query
is made so there isn't a completion event as such.

v2: New patch added to series.

v3: Rebased to remove completion caching as that is apparently contentious.

Change-Id: Ic9bcde67d175c6c03b96217cdcb6e4cc4aa45d67
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add unique id to the request structure for debugging

For debugging purposes, it is useful to be able to uniquely identify a given
request structure as it works its way through the system. This becomes
especially tricky once the seqno value is lazily allocated as then the request
has nothing but its pointer to identify it for much of its life.

Change-Id: Ie76b2268b940467f4cdf5a4ba6f5a54cbb96445d
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Zero fill the request structure

There is a general theory that kzmalloc is better/safer than kmalloc, especially
for interesting data structures. This change updates the request structure
allocation to be zero filled.

This also fixes crashes in the reset code. Quoting Mika's patch:

"Clean the request structure on alloc. Otherwise we might end up
referencing uninitialized fields.  This is apparent when we try to
cleanup the preallocated request on ring reset, before any request has
been submitted to the ring.  The request->ctx is foobar and we end up
freeing the foobarness."

Note that this fixes a regression introduced in

commit 9eba5d4a1d79d5094321469479b4dbe418f60110
Author: John Harrison <John.C.Harrison@Intel.com>
Date:   Mon Nov 24 18:49:23 2014 +0000

    drm/i915: Ensure OLS & PLR are always in sync

References: https://bugs.freedesktop.org/show_bug.cgi?id=86959
References: https://bugs.freedesktop.org/show_bug.cgi?id=86962
References: https://bugs.freedesktop.org/show_bug.cgi?id=86992
Change-Id: I68715ef758025fab8db763941ef63bf60d7031e2
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix up seqno -> request merge issues

The display related patches earlier in this series were edited during merge to
improve the request unreferencing. Specifically, the need for de-referencing at
interrupt time was removed. However, the resulting code did a 'deref(req) ; req
= NULL' sequence rather than using the 'req_assign(req, NULL)' wrapper. The two
are functionally equivalent, but using the wrapper is more consistent with all
the other places where requests are assigned.

Note that the whole point of the wrapper is that using it everywhere that
request pointers are assigned means that the reference counting is done
automatically and can't be accidentally forgotten about. Plus it allows simpler
future maintainance if the reference counting mechanisms ever need to change.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make all plane disables use 'update_plane' (v5)

If we extend the commit_plane handlers for each plane type to be able to
handle fb=0, then we can easily implement plane disable via the
update_plane handler.  The cursor plane already works this way, and this
is the direction we need to go to integrate with the atomic plane
handler.  We can now kill off the type-specific disable functions, as
well as the redundant intel_plane_disable() (not to be confused with
intel_disable_plane()).

Note that prepare_plane_fb() only gets called as part of update_plane
when fb!=NULL (by design, to match the semantics of the atomic plane
helpers); this means that our commit_plane handlers need to handle the
frontbuffer tracking for the disable case, even though they don't handle
it for normal updates.

v2:
 - Change BUG_ON to WARN_ON (Ander/Daniel)

v3:
 - Drop unnecessary plane->crtc check since a previous patch to plane
   update ensures that plane->crtc will always be non-NULL, even for
   disable calls that might pass NULL from userspace.  (Ander)
 - Drop a s/crtc/plane->crtc/ hunk that was unnecessary.  (Ander)

v4:
 - Fix missing whitespace (Ander)

v5:
 - Use state's crtc rather than plane's crtc in
   intel_check_primary_plane().  plane->crtc could be NULL, but we've
   already fixed up state->crtc to ensure it's non-NULL (even if
   userspace passed it as NULL during a disable call).  (Ander)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Ensure state->crtc is non-NULL for plane updates

When disabling a plane, it is legal to pass crtc = NULL.  Since planes
on Intel hardware are tied to a fixed CRTC, go ahead and set state->crtc
to the appropriate crtc in cases where it is passed to us as NULL.

In a future patch, we will start using the update handler for plane
disables, so this will help ensure we always have a non-NULL crtc
pointer to work with.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Consolidate top-level .update_plane() handlers

Our .update_plane() handlers do the same check/prepare/commit/cleanup
steps regardless of plane type.  Consolidate them all into a single
function that calls check/commit through a vtable.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Consolidate plane 'cleanup' operations (v3)

All plane update functions need to unpin the old framebuffer when
flipping to a new one.  Pull this logic into a separate function to ease
the integration with atomic plane helpers.

v2: Don't wait for vblank if we don't have an old fb to cleanup (Ander)

v3: Really don't wait for vblank if we don't have an old fb to cleanup.
    Previous version only handled this for primary planes; we need the
    same change on cursors/sprites too!  (Ander)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Consolidate plane 'prepare' functions (v2)

The 'prepare' step for all types of planes are pretty similar;
consolidate the three 'prepare' functions into a single function.  This
paves the way for future integration with the atomic plane handlers.

Note that we pull the 'wait for pending flips' functionality out of the
primary plane's prepare step and place it directly in the 'setplane'
code.  When we move to the atomic plane handlers, this code will be in
the 'atomic begin' step.

v2: Update GEM fb tracking for physical cursors also (Ander)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make intel_plane_state subclass drm_plane_state

Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Introduce intel_prepare_cursor_plane() (v2)

Primary and sprite planes have already been refactored to include a
'prepare' step which handles all the commit-time operations that could
fail (i.e., pinning buffers and such).  Refactor the cursor commit in a
similar manner.

For simplicity and consistency with other plane types, we also switch to
using intel_pin_and_fence_fb_obj() to perform our pinning for
non-physical cursors.  This will allow us to more easily migrate the
code into the atomic 'begin' handler in a plane-agnostic manner in a
future patchset.

v2:
 - Update GEM fb tracking for physical cursors too. (Ander)
 - Use intel_unpin_fb_obj() rather than
   i915_gem_object_unpin_from_display_plane() and do so while holding
   struct_mutex.  (Ander)
 - Update plane->fb in commit_cursor_plane.  This isn't really necessary
   since the DRM core does this for us in __setplane_internal(), but
   doing it in our driver once we know we're going to succeed helps
   avoid confusion. (Ander)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove intel_pipe_set_base() (v4)

After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().

v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crtc_get_hv_timing()

v3 (by Matt):
 - Rebase to latest di-nightly codebase
 - Use primary->funcs->update_plane() in __intel_set_mode()
 - Use primary->funcs->disable_plane() in intel_crtc_disable()

v4 (by Matt):
 - Drop redundant calls to intel_crtc_wait_for_pending_flips() before
   calling update_plane() (Ville)

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-and-mourned-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove intel_crtc_cursor_set_obj() (v5)

Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.

The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both paths into one.

v5 (by Matt):
 - Rebase onto latest di-nightly codebase
 - Drop extra unreference call when we fail to pin (Ville)

Reviewed-by(v4): Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: add helper to get crtc timings (v5)

We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.

Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were
previously making adjustments for doublescan modes and vscan > 1 modes,
which was incorrect.  Using our new helper fixes this mistake.

v2 (by Matt): Use new stereo doubling function (suggested by Ville)

v3 (by Matt):
 - Add missing kerneldoc (Daniel)
 - Use drm_mode_copy() (Jani)

v4 (by Matt):
 - Drop stereo doubling function again; add 'stereo only' flag
   to drm_mode_set_crtcinfo() instead (Ville)

v5 (by Matt):
 - Note behavioral change in drm_crtc_check_viewport() and
   intel_modeset_pipe_config(). (Ander)
 - Describe new adjustment flags in drm_mode_set_crtcinfo()'s
   kerneldoc. (Ander)

Cc: dri-devel@lists.freedesktop.org
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update DRIVER_DATE to 20141205

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Add WaHdcDisableFetchWhenMasked

We already have it for chv, but was missing for bdw.

Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update the DSI enable path to support dual

We need to program both port registers during dual link enable path.

v2: Address review comments by Jani
    - Used a for loop instead of do-while loop.

v3: Used for_each_dsi_port macro instead of for loop

v4: Renamed mode_hactive variable to mode_hdisplay

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update the DSI disable path to support dual link panel disabling

We need to program both port registers during dual link disable path.

v2: Address review comments by Jani
    - Used a for loop instead of do-while loop.

v3: Used for_each_dsi_port macro instead of for loop

v4: Added comments for the usage of AFE latchout bit

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: MIPI Timings related changes for dual link

hactive, hfp, hbp, hsync needs to be halved for dual link MIPI Panels.
Accordingly timing related mmio regs needs to be programmed for both MIPI Ports.

v2: Address review comments by Jani
    - Used a for loop instead of do-while loop

v3: Used for_each_dsi_port macro instead of for loop

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: cck reg used for checking DSI Pll locked

Instead of pipe configuration reg, cck reg to be used for checking whether
DSI Pll is getting locked or not.

v2: dpio_lock unlocked now in case DSI PLL lock fails

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable DSI PLL for both DSI0 and DSI1 in case of dual link

For Dual link MIPI Panels, dsipll clock for both DSI0 and DSI1 needs to be enabled.

v2: Address review comments by Jani
    - Added wait time for PLL to be locked.

v3: separate patch created for cck read for checking PLL to be locked

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Dual link needs Shutdown and Turn on packet for both ports

For dual link MIPI panels, SHUTDOWN packet needs to send to both Ports
A & C during MIPI encoder disabling sequence. Similarly, TURN ON packet
to be sent to both Ports during MIPI encoder enabling sequence.

v2: Address review comments by Jani
    - Used a for loop instead of do-while loop.

v3: Used for_each_dsi_port macro instead of for loop

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pixel Clock changes for DSI dual link

For dual link MIPI Panels, each port needs half of pixel clock. Pixel overlap
can be enabled if needed by panel, then in that case, pixel clock will be
increased for extra pixels.

v2 : Address review comments by Jani
     - Removed the bit mask used for ->dual_link
     - Used DSI instead of MIPI for #define variables

v3: Added the VLV_DISPLAY_BASE to VLV_CHICKEN_3 register

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add support for port enable/disable for dual link configuration

For Dual Link MIPI Panels, both Port A and Port C should be enabled
during the MIPI encoder enabling sequence. Similarly, during the
disabling sequence, both ports needs to be disabled.

v2: Used for_each_dsi_port macro instead of for loop

v3: Used intel_dsi->ports instead of dual_link var for dual link configuration check

v4: Masking of the required MIPI port bits before writing proper values

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/MI_STORE_DWORD_IMM_GEN8/MI_STORE_DWORD_IMM_GEN4/

MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename
the define to avoid potential confusion if someone tries to use this
on pre-gen8.

Also correct the comment on MI_MEM_VIRTUAL bit. It's present on 945,g33
and 965 only.

Cc: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add USE_GGTT define for g4x+ too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: release struct_mutex on the i915_gem_init_hw fail path

Release struct_mutex if init_rings() fails.

This is a regression introduced in
commit 35a57ffbb10840af219eeaf64718434242bb7c76
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Nov 20 00:33:07 2014 +0100

    drm/i915: Only init engines once

Reported-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Added port as parameter to the functions which does read/write of DSI Controller

This patch is in preparation of DSI dual link panels. For dual link
panels, few packets needs to be sent to Port A or Port C or both. Based
on the portno from MIPI Sequence Block#53, these sequences needs to be
sent accordingly.

v2: Addressed review comments by Jani
    - port variables named properly

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: New functions added for enabling & disabling MIPI Port Ctrl reg

This patch is in preparation for the DSI dual link
port enable and disable related changes.

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't display nonsensical values in i915_ddb_info on gen < 9

When playing around with debugfs and a HSW machine I noticed that we
were displaying some garbled value in i915_ddb_info. This debugfs file
is only meaningful for gen9+, so don't display anything on earlier
platforms.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Stop putting GGTT VMA at the head of the list

Multiple GGTT VMAs per object will be introduced in the near future which will
make it impossible to guarantee normal GGTT view is at the head of the list.

Purpose of this patch is to break this assumption straight away so any
potential hidden assumptions in the code base can be bisected to this
simple patch.

For: VIZ-4544
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Update the DDI translation values for DP/eDP 1.3

Hardware team updated the recommended translation values for DP/eDP 1.3.
This should help with some stability and HBR2 issues.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Satheeshakrishna M<satheeshakrishna.m@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move init_unused_rings to gem_init_hw

We need to do that every time we resume the rings, not just at load.
I've overlooked this in my untangling of the ring init code.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix startup failure in LRC mode after recent init changes

A previous commit introduced engine init changes:

    commit 372ee59699d9 ("drm/i915: Only init engines once")

This broke execlists as intel_lr_context_render_state_init was trying to emit
commands to the RCS for the default context before the ring->init_hw was called.

Made a new gen8_init_rcs_context function and assign in to render ring
init_context.  Moved call to intel_logical_ring_workarounds_emit into
gen8_init_rcs_context to maintain previous functionality.

Moved call to render_state_init from lr_context_deferred_create into
gen8_init_rcs_context, and modified deferred_create to call ring->init_context
for non-default contexts.

Modified i915_gem_context_enable to call ring->init_context for the default
context.

So init_context will now always be called when the hw is ready - in
i915_gem_context_enable for the default context and in lr_context_deferred_create
for other contexts.

Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert pxvid to extvid lookup table to a function

The conversion table can be replaced with simple enough function.

   text    data     bss     dec     hex filename
 839688   10987      24  850699   cfb0b drivers/gpu/drm/i915/i915.ko
 839224   10987      24  850235   cf93b drivers/gpu/drm/i915/i915.ko

Result is 494 saved bytes (.05525%).

v2: - no run on sentences from subject (Chris, Jani)
    - be verbose about the savings (Chris, Daniel)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Flatten engine init control flow

Now that sanity prevails and we have the clean split between software
init and starting the engines we can drop all the "have we allocate
this struct already?" nonsense.

Execlist code could benefit quite a bit more still, but that's for
another patch.

Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Remove unnecessary goto in intel_primary_plane_disable()

The same logic can be implemented without it, and it even saves a line
of code.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only init engines once

We can do this.

And now there's finally the clean split between software setup and
hardware setup I kinda wanted since multi-ring support was merged
aeons ago. It only took almost 5 years.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move intel_init_pipe_control out of engine->init_hw

With this all the ->init_hw hooks really only set up hw state needed
to start the ring, all the software state setup and memory/buffer
allocations happen beforehand.

v2: We need to call intel_init_pipe_control after the ring init since
otherwise engine->dev is NULL and it falls over. Currently that's
now after the hw ring is enabled but a) we'll be fine as long as no
one submits a batch b) this will change soon.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/init()/init_hw()/ in intel_engine_cs

This is (mostly, some exceptions that need fixing) the hw setup
function which starts the ring. And not the function which allocates
all the resources.

Make this clear by giving it a better name.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Consolidate ring freespace calculations

There are numerous places in the code where the driver's idea of
how much space is left in a ring is updated using the driver's
latest notions of the positions of 'head' and 'tail' for the ring.
Among them are some that update one or both of these values before
(re)doing the calculation. In particular, there are four different
places in the code where 'last_retired_head' is copied to 'head'
and then set to -1; and two of these do not have a guard to check
that it has actually been updated since last time it was consumed,
leaving the possibility that the dummy -1 can be transferred from
'last_retired_head' to 'head', causing the space calculation to
produce 'impossible' results (previously seen on Android/VLV).

This code therefore consolidates all the calculation and updating of
these values, such that there is only one place where the ring space
is updated, and it ALWAYS uses (and consumes) 'last_retired_head' if
(and ONLY if) it has been updated since the last call.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make ring freespace calculation more robust

The used space in a ring is given by the cyclic distance from the
consumer (HEAD) to the producer (TAIL), i.e. ((tail-head) MOD size);
conversely, the available space in a ring is the cyclic distance
from the producer to the consumer, MINUS the amount reserved for a
"gap" that is supposed to guarantee that the producer never catches
up with or overruns the consumer. Note that some GEN h/w requires
that TAIL never approach to within one cacheline of HEAD, so the gap
is usually set to twice the cacheline size to ensure this.

While the existing code gives the correct answer for correct inputs,
if the producer HAS overrun into the reserved space, the result can
be a value larger than the maximum valid value (size-reserved). We
can improve this by reorganising the calculation, so that in the
event of overrun the result will be negative rather than over-large.

This means that the commonly-used test (available >= required)
will then reject further writes into the ring after an overrun,
giving some chance that we can recover from or at least diagnose
the original problem; whereas allowing more writes would likely both
confuse the h/w and destroy the evidence of what went wrong.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: add ports to intel_dsi to describe the ports being driven

Later on this can include multiple ports (e.g. (1 << PORT_A) | (1 <<
PORT_C)) to describe dual link DSI.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: clean up MIPI DSI pipe vs. port usage

MIPI DSI works on ports A and C, which map to pipes A and B,
respectively. Things are going to get more complicated with the
introduction of dual link DSI support, so clean up the register defines
and code to match reality.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Deal with video overlay on GPU reset

Clear the video overlay state on GPU reset. Any pending overlay request
in the ring has been nuked, and the display itself gets reset. So we
pretty much lose all state here. Adjust the software state to match so
that the next "putimage" will restore things to working order.

v2: Ass a locking check into intel_overlay_release_old_vid() (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/0/NULL/ to appease sparse, reported by 0-day tester.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert 'trace_irq' to use requests rather than seqnos

Updated the trace_irq code to use requests instead of seqnos. This includes
reference counting the request object to ensure it sticks around when required.
Note that getting access to the reference counting functions means moving the
inline i915_trace_irq_get() function from intel_ringbuffer.h to i915_drv.h.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Resolve conflict due to shuffled merge order.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove redundant flip_work->flip_queued_ring

Similar to the patch from John which removed obj->ring.

Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Remove the now redundant 'obj->ring'

The ring member of the object structure was always updated with the
last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is
now a direct copy of obj->last_read_req->ring. This makes it somewhat redundant
and potentially misleading (especially as there was no comment to explain its
purpose).

This checkin removes the redundant field. Many uses were simply testing for
non-null to see if the object is active on the GPU. Some of these have been
converted to check 'obj->active' instead. Others (where the last_read_req is
about to be used anyway) have been changed to check obj->last_read_req. The rest
simply pull the ring out from the request structure and proceed as before.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed'

Almost everywhere that caled i915_seqno_passed() was really asking 'has the
given seqno popped out of the hardware yet?'. Thus it had to query the current
hardware seqno and then do a signed delta comparison (which copes with wrapping
around zero but not with seqno values more than 2GB apart, although the latter
is unlikely!).

Now that the majority of seqno instances have been replaced with request
structures, it is possible to convert this test to be request based as well.
There is now a 'i915_gem_request_completed()' function which takes a request and
returns true or false as appropriate. Note that this currently just wraps up the
original _passed() test but a later patch in the series will reduce this to
simply returning a cached internal value, i.e.:
  _completed(req) { return req->completed; }'

This checkin converts almost all _seqno_passed() calls. The only one left is in
the semaphore code which still requires seqnos not request structures.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Drop hunk touching the trace_irq code since I've dropped the
patch which converts that, and resolve resulting conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Connect requests to rings at creation not submission

It makes a lot more sense (and makes future seqno -> request conversion patches
simpler) to fill in the 'ring' field of the request structure at the point of
creation rather than submission. Given that the request structure is assigned by
ring specific code and thus is locked to a ring from the start, there really is
no reason to defer this assignment.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert 'ring_idle()' to use requests not seqnos

More seqno value to request structure conversions. Note, this change temporarily
moves the 'get_seqno()' call inside ring_idle() but this will disappear again in
a later patch when i915_seqno_passed() itself is converted.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert trace functions from seqno to request

All the code above is now using requests not seqnos so it is possible to convert
the trace functions across. Note that rather than get into problematic reference
counting issues, the trace code only saves the seqno and ring values from the
request structure not the structure pointer itself.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert 'flip_queued_seqno' into 'flip_queued_request'

Converted the flip_queued_seqno value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Again get rid of the _irq request unref by simply moving that
into the unpin worker. Doesn't matter when we hang onto the request
for a bit longer, and in the unpin worker we already grab the
dev->struct_mutex anyway.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove obsolete seqno parameter from 'i915_add_request'

There is no longer any need to retrieve a seqno value from an i915_add_request()
call. The calling code already knows which request structure is being processed
(it can only be ring->OLR). And as the request itself is now used in preference
to the basic seqno value, the latter is now redundant in this situation.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert __wait_seqno() to __wait_request()

Now that all code above is using request structures instead of seqno values, it
is possible to convert  __wait_seqno() itself. Internally, it is still calling
i915_seqno_passed(), this will be updated later in the series. This step is just
changing the parameter list and function name.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert mmio_flip::seqno to struct request

Converted the mmio_flip 'seqno' value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.

v2: Used the IRQ friendly request dereference call in the notify handler as that
code is called asynchronously without holding any useful mutex locks.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Drop the _irq variant and use the normal reques unref,
wrapped in dev->struct_mutex per the discussion on the m-l.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check locking in i915_gem_request_unreference

With refcounting it looks like you can just drop that refcount, but
that's not really the case. So make sure no one forgets.

Motivated by the unlocked call in the mmio flip code.

Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Convert i915_wait_seqno to i915_wait_request

Updated i915_wait_seqno() to take a request structure instead of a seqno value
and renamed it accordingly. Internally, it just pulls the seqno out of the
request and calls on to __wait_seqno() as before. However, all the code further
up the stack is now simplified as it can just pass the request object straight
through without having to peek inside.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Squash in hunk from an earlier patch which was rebased
wrongly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert 'last_flip_req' to be a request not a seqno

Converted 'last_flip_req' to be an actual request rather than a seqno value as
part of the on going seqno to request changes. This includes reference counting
the request being saved away to ensure it can not be retired and freed while the
overlay code is still waiting on it.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make 'i915_gem_check_olr' actually check by request not seqno

Updated the _check_olr() function to actually take a request object and compare
it to the OLR rather than extracting seqnos and comparing those.

Note that there is one use case where the request object being processed is no
longer available at that point in the call stack. Hence a temporary copy of the
original function is still present (but called _check_ols() instead). This will
be removed in a subsequent patch.

Also, downgraded a BUG_ON to a WARN_ON as apparently the former is frowned upon
for shipping code.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove 'outstanding_lazy_seqno'

The OLS value is now obsolete. Exactly the same value is guarateed to be always
available as PLR->seqno. Thus it is safe to remove the OLS completely. And also
to rename the PLR to OLR to keep the 'outstanding lazy ...' naming convention
valid.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Ensure requests stick around during waits

Added reference counting of the request structure around __wait_seqno() calls.
This is a precursor to updating the wait code itself to take the request rather
than a seqno. At that point, it would be a Bad Idea for a request object to be
retired and freed while the wait code is still using it.

v3:

Note that even though the mutex lock is held during a call to i915_wait_seqno(),
it is still necessary to explicitly bump the reference count. It appears that
the shrinker can asynchronously retire items even though the mutex is locked.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Remove wrongly squashed hunk which breaks the build.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert i915_gem_ring_throttle to use requests

Convert the throttle code to use the request structure rather than extracting a
ring/seqno pair from it and using those. This is in preparation for
__wait_seqno() becoming __wait_request().

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Replace last_[rwf]_seqno with last_[rwf]_req

The object structure contains the last read, write and fenced seqno values for
use in syncrhonisation operations. These have now been replaced with their
request structure counterparts.

Note that to ensure that objects do not end up with dangling pointers, the
assignments of last_*_req include reference count updates. Thus a request cannot
be freed if an object is still hanging on to it for any reason.

v2: Corrected 'last_rendering_' to 'last_read_' in a number of comments that did
not get updated when 'last_rendering_seqno' became 'last_read|write_seqno'
several millenia ago.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add helper functions to aid seqno -> request transition

Added helper functions for retrieving the ring and seqno entries from a request
structure. This allows the internal workings of the request structure to be
hidden from code that is using these. It also allows for useful
workarounds/debug code to be added as or when necessary.

Note that it is intended that the majority (if not all) uses of the seqno
accessor will disappear eventually as code is updated to use the request
structure itself rather than working with seqno values.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add reference count to request structure

The plan is to use request structures everywhere that seqno values were
previously used. This means saving pointers to structures in places that used to
be simple integers. In turn, that means that the target structure now needs much
more stringent lifetime tracking. That is, it must not be freed while some other
random object still holds a pointer to it.

To achieve this tracking, a reference count needs to be added. Whenever a
pointer to the structure is saved away, the count must be incremented and the
free must only occur when all references have been released.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Ensure OLS & PLR are always in sync

The aim is to replace seqno values with request structures. A step along the way
is to switch to using the PLR in preference to the OLS. That requires the PLR to
only be valid when and only when the OLS is also valid. I.e., the two must be
kept in lock step. Then, code which was using the OLS can be safely switched
over to using the PLR instead.

For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix short description of intel_display_power_is_enabled()

That's the version actually taking the dev_priv->power_domains lock.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Assert that we successfully downclock the GPU before suspend

Before suspending, we wait upon the outstanding GPU requests and flush
our pending idle handlers. This should downclock the GPU to its lowest
power state. Add a WARN to check that the delayed tasks were run and did
their job properly.

Suggested-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove user pinning code

Now unused.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Don't read 'HEAD' MMIO register in LRC mode

The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the software. Thus reading the h/w HEAD
could put an unrelated (undefined, effectively random) value into
the s/w 'head' -- A Bad Thing for the free space calculations.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check for matching ringbuffer in logical_ring_wait_request()

The request queue is per-engine, and may therefore contain requests
from several different contexts/ringbuffers. In determining which
request to wait for, this function should only consider requests
from the ringbuffer that it's checking for space, and ignore any
that it finds that belong to other contexts.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable PSR for Baytrail and Braswell.

This patch is the last in series of VLV/CHV PSR,
that finally enable PSR by adding it to HAS_PSR
and calling the proper enable and disable
functions on the right places.

Although it is still disabled by default.

v2: Rebase over intel_psr and merge Durgadoss's fixes.
v3: Fix typo.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV/CHV PSR debugfs.

Add debugfs support for Valleyview and Cherryview considering that
we have PSR per pipe and  we don't have any kind of
performance counter as we have on other platforms that support PSR.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV/CHV PSR Software timer mode

This patch introduces exit/activate functions for PSR
on VLV+. Since on VLV+ HW cannot track frame updates and force PSR
exit let's use fully SW tracking available.

v2: Rebase over intel_psr.c;
    Remove Single Frame update transitioning from state 3 to 5 directly;
    Fake a software invalidation for sprites and cursor so we don't miss
    any screen update;

v3: As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int,
    so let's use 1 instead. Althought the 1/4 of this is needed for the
    transition let's use 1 for simplicity;
    Also fix comments as suggested by Durgadoss

Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions

The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.

v2: Rebase over intel_psr.c;
    Remove docs from static functions;
    Merge vlv_psr_active_on_pipe;
    Timeout for psr transition is 250us;
    Remove SRC_TRASMITTER_STATE;

v3: Rebase after is_psr_enabled function got removed;
    Get SRC_TRANSMITTER_STATE back to be on the safe side since
    default for panels is to require link training on exit when
    main link off;
    As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int,
    so let's use 1 instead. Althought the 1/4 of this is needed for the
    transition let's use 1 for simplicity;

Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add PSR registers for PSR VLV/CHV.

Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different
implementation of PSR that we currently have supported for
Haswell and Broadwell. So let's start by adding registers definitions.

I usually don't like commit that adds just registers without using,
but after I put all in one commit I realized that no one would want
to take the AR to review it so I decided to split in order to make
reviewer's life easier. Only last commit in this series will actually
enable the PSR on intel enable panel path.

But as it happens currently with HSW/BDW the plan is to let it
disabled by default (protected by kernel parameter)
while we are able to fully validate it.

v2: Remove a unused bit definition that isn't used on vlv and
    reserved on chv as pointed out by Durgadoss.

Cc: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove intel_psr_is_enabled function.

This function was in use to check if PSR feature got enabled.
However on HSW and BDW we currently force psr exit by disabling
EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk of false negative.

But anyway this check with DRRS was dangerous, since DRRS could try to get enabled
before PSR gets there. So let's just remove it for now.
A proper synchronization mechanism must be implemented later probably
using pipe config.

Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove PSR BDW single frame update.

Single frame update is a feature available on BDW for PSR that allows
Source to send Sink only one frame and get it updated. Usually useful
when page flipping. However with our frontbuffer tracking where we force
psr exit on flips we don't need this feature.

Also after it got added here many workaround was added to documentation
to mask some bits when using single frame update. So the safest thing
is to just stop using it.

v2: Rebase after removing skip aux one and fixing typo on commit message.

Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: PSR get full link off x standby from VBT

OEMs can specify if full_link might be always enabled, i.e. only_standby
over VBT.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: HSW/BDW PSR Set idle_frames = VBT + 1

Let's use VBT + 1 now we parse it.

v2: fix subject

v3: rebase over intel_psr and without counting on previous fix

Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Parse VBT PSR block.

PSR (aka SRD) block is defined at VBT and currently being used.
Mainly/At-least to configure the amount of idle_frames require to get
back to PSR Entry.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Implement the skl version of MMIO flips

Because the plane registers are different in Skylake we need to adapt
the MMIO code as well.

v2: Don't introduce yet another vfunc when the direction is do
consolidate the plane updates to use the same code path (Daniel)

v3:
  - Use enum pipe instead of int (Ville)
  - Also update PLANE_STRIDE when the tiling has changed (Ville)
  - Put intel_mark_page_flip_active() in the shared code (Damien)

v4:
  - Remove unused variable

v5:
  - Fix whitespace Vs tabs (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Read out crtl1 for eDP/DPLL0

v2: Put the DPLL0 state readout in skylake_get_ddi_pll(), closer to
where the PLL assignement read out is done rather than the frequency
readout function. (Daniel)

v3: Remove stray new line (Damien)
    Add Paulo's r-b tag for v1

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reject modeset when the same digital port is used more than once

On pre-HSW we have two encoders per digital port: one HDMI, one DP.
However they are the same physical port in hardware and we can't enable
both at the same time. Reject the modeset if the user attempts this.

So far we've been saved by the fact that we never see both HDMI and DP
connectors as connected. But if the user decides to force a mode anyway,
all kinds of funny stuff might happen.

Unfortunately we don't seem to have any way to inform userspace that
such configurations are invalid except by returning an error from
setcrtc. possible_clones only covers real cloning situations, and
looking at the connector names doesn't work either since we don't
always register both connectors for the same port. I suppose the
only way to fix that would be to expose only a single encoder per
digital port like we do on HSW+ but that would be a fairly large
undertaking for little gain.

kms_setmode hits this since it forces modes on non-connected VGA and
HDMI connectors. Previosuly it just resulted in weirdness such as
failed link training. With this patch it will now get an error back
from the kernel and will die with an assert since it thinks that the
configuration should be fine.

v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo)

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: mask RPS IRQs properly when disabling RPS

Atm, igt/gem_reset_stats can trigger the recently added WARN on
left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two
reasons for this:
1. we call intel_enable_gt_powersave() without a preceeding
   intel_disable_gt_powersave()
2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR

1. means RPS interrupts will remain enabled and can be serviced during
the HW initialization after a GPU reset. 2. means even if we called
gen6_disable_rps_interrupts() any new RPS interrupt during RPS
initialization would still propagate to PM_IIR too early (though
wouldn't be serviced).

This patch solves the 2. issue by also masking interrupts in PM_IMR, the
following patch fixes 1. getting rid of the WARN. This also makes
intel_enable_gt_powersave() and intel_disable_gt_powersave() more
symmetric.

Since gen6_disable_rps_interrupts() is called during driver loading with
i915 interrupts disabled add a new version of gen6_disable_pm_irq() that
doesn't WARN for this.

Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR
programming sequence and make sure that any queued PM_IIR bit is also
cleared.

The WARN was caught by PRTS after I sent my previous RPS sanitizing
patchset and I could easily reproduce it on HSW. To actually fix it we
also need the next patch.

Reported-by: He, Shuang <shuang.he@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Tune down spurious CRC interrupt warning

We don't really synchronously turn them off from debugfs. We try to
avoid hitting them too badly by waiting one vblank, but apparently the
irq handler can still race through that gap.

Since this isn't really all that important for testcases, only for
debugging CRC issues let's tune it down to a debug message.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602
Cc: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Fix context object leak for legacy contexts

Dynamic context pinning for LRCs introduced a leak in legacy mode.
Reinstate context unreference in i915_gem_free_request for legacy contexts.

Leak reported by i-g-t/drv_module_reload fixed by this patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: John Harrison<John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Update in Gen9 multi-engine forcewake range

Updates in forcewake range for Render/Media/Common
power wells for Gen9.

Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Zhe Wang <zhe1.wang@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/eDP: When enabling panel VDD cancel pending disable worker

Before testing if the panel VDD is enabled on eDP cancel any pending
disable worker. This makes sure the worker will be triggered with a
delay from the last time edp_panel_vdd_schedule_off() is called, not
the first time. This avoids unnecessary overhead.

https://bugs.freedesktop.org/show_bug.cgi?id=86201

v2: use cancel_delayed_work() instead of cancel_delayed_work_sync()
as the pps_mutexes will provide the required serialization with
edp_panel_vdd_work() while the sync variant may deadlock. Suggested
by Ville Syrjälä <ville.syrjala@linux.intel.com>.
Made commit message a bit clearer.

Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Handle runtime pm in the CRC setup code

The crc code doesn't handle anything really that could drop the
register state (by design so that we have less complexity). Which
means userspace may only start crc capture once the pipe is fully set
up.

With an i-g-t patch this will be the case, but there's still the
problem that this results in obscure unclaimed register write
failures. Which is a pain to debug.

So instead make sure we don't have the basic unclaimed register write
failure by grabbing runtime pm references. And reject completely
invalid requests with -EIO. This is still racy of course, but for a
test library we don't really care - if userspace shuts down the pipe
right afterwards the entire setup will be lost anyway.

v2: Put instead of get, spotted by Damien. Also explain the runtime pm
dance.

v3: There's really no need for rpm get/put since power_is_enabled only
checks software state (Damien).

References: https://bugs.freedesktop.org/show_bug.cgi?id=86092
Cc: Damien Lespiau <damien.lespiau@intel.com> (v2)
Tested-by: lu hua <huax.lu@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Disable crtcs gracefully before GPU reset on gen3/4

The GPU reset also resets the display on gen3/4. The g33 docs say we
should disable all planes before flipping the reset switch. Just
disable all the crtcs instead. That seems a nicer thing to do anyway.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Grab modeset locks for GPU rest on pre-ctg

On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip coming
in between these two steps should fail anyway due to reset_in_progress,
so this should be safe.

This fixes a lot of failed asserts in the modeset code when there's a
modeset racing with the reset. Naturally the asserts aren't happy when
the expected state has disappeared.

v2: Drop UMS checks, complete pending flips after the reset (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement GPU reset for g33

g33 seems to sit somewhere between the 915/945/965 style and the
g4x style. The bits look like g4x, but we still need to do a full
reset including display.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement GPU reset for 915/945

915/945 have the same reset registers as 965, so share the code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Restore the display config after a GPU reset on gen4

On pre-ctg GPU reset also resets the display hardware. Force a mode
restore after the GPU reset, and also re-init clock gating.

v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating()
    in case more relevant stuff gets added there at some point
    Restore interrupts after the reset as well

Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>