When we transitioned to the atomic plane helpers in commit:

        commit ea2c67bb
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Tue Dec 23 10:41:52 2014 -0800

            drm/i915: Move to atomic plane helpers (v9)

one of the changes was to call intel_plane_destroy_state() while tearing
down a plane to prevent leaks when unloading the driver.  That made
sense when the patches were first written, but before they were merged,

        commit 3009c037
        Author:     Thierry Reding <treding@nvidia.com>
        Date:       Tue Nov 25 12:09:49 2014 +0100

            drm: Free atomic state during cleanup

had already landed, which made this the responsibility of the DRM core.
The result was that we were kfree()'ing the state twice, and also
possibly double-unref'ing a framebuffer, leading to memory corruption
when the driver was unloaded.

The fix is to simply not try to cleanup the state in the i915 teardown
code now that the core handles this for us.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88433
Testcase: igt/drv_module_reload
Root-cause-analysis-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we determine that a specific port is eDP, don't register the HDMI
connector/encoder for it. The reason being that we want to disable
HPD interrupts for eDP ports when the display is off, but the presence
of the extra HDMI connector would demand the HPD interrupt to remain
enabled all the time.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The userspace-requested plane coordinates are now always available via
plane->state.base (and the i915-adjusted values are stored in
plane->state), so we no longer use the coordinate fields in intel_plane
and can drop them.

Also, note that the error case for pageflip calls update_plane() to
program the values from plane->state; it's simpler to just call
intel_plane_restore() which does the same thing.

v2: Replace manual update_plane() with intel_plane_restore() in pageflip
    error handler.

Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Switch plane handling to use the atomic plane helpers.  This means that
rather than provide our own implementations of .update_plane() and
.disable_plane(), we expose the lower-level check/prepare/commit/cleanup
entrypoints and let the DRM core implement update/disable for us using
those entrypoints.

The other main change that falls out of this patch is that our
drm_plane's will now always have a valid plane->state that contains the
relevant plane state (initial state is allocated at plane creation).
The base drm_plane_state pointed to holds the requested source/dest
coordinates, and the subclassed intel_plane_state holds the adjusted
values that our driver actually uses.

v2:
 - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
 - Fix a copy/paste comment mistake (Bob)

v3:
 - Use prepare/cleanup functions that we've already factored out
 - Use newly refactored pre_commit/commit/post_commit to avoid sleeping
   during vblank evasion

v4:
 - Rebase to latest di-nightly requires adding an 'old_state' parameter
   to atomic_update;

v5:
 - Must have botched a rebase somewhere and lost some work.  Restore
   state 'dirty' flag to let begin/end code know which planes to
   run the pre_commit/post_commit hooks for.  This would have actually
   shown up as broken in the next commit rather than this one.

v6:
 - Squash kerneldoc patch into this one.
 - Previous patches have now already taken care of most of the
   infrastructure that used to be in this patch.  All we're adding here
   now is some thin wrappers.

v7:
 - Check return of intel_plane_duplicate_state() for allocation
   failures.

v8:
 - Drop unused drm_plane_state -> intel_plane_state cast.  (Ander)
 - Squash in actual transition to plane helpers.  Significant
   refactoring earlier in the patchset has made the combined
   prep+transition much easier to swallow than it was in earlier
   iterations. (Ander)

v9:
 - s/track_fbs/disabled_planes/ in the atomic crtc flags.  The only fb's
   we need to update frontbuffer tracking for are those on a plane about
   to be disabled (since the atomic helpers never call prepare_fb() when
   disabling a plane), so the new name more accurately describes what
   we're actually tracking.

Testcase: igt/kms_plane
Testcase: igt/kms_universal_plane
Testcase: igt/kms_cursor_crc
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A few of the sprite-related function names in i915 are very similar
(e.g., intel_enable_planes() vs intel_crtc_enable_planes()) and don't
make it clear whether they only operate on sprite planes, or whether
they also apply to all universal plane types.  Rename a few functions to
be more consistent with our function naming for primary/cursor planes or
to clarify that they apply specifically to sprite planes:

 - s/intel_disable_planes/intel_disable_sprite_planes/
 - s/intel_enable_planes/intel_enable_sprite_planes/

Also, drop the sprite-specific intel_destroy_plane() and just use
the type-agnostic intel_plane_destroy() function.  The extra 'disable'
call that intel_destroy_plane() did is unnecessary since the plane will
already be disabled due to framebuffer destruction by the point it gets
called.

v2: Earlier consolidation patches have reduced the number of functions
    we need to rename here.

v3: Also rename intel_plane_funcs vtable to intel_sprite_plane_funcs
    for consistency with primary/cursor.  (Ander)

v4: Convert comment for intel_plane_destroy() to kerneldoc now that it
    is no longer a static function.  (Ander)

Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the vblank evasion up from the low-level, hw-specific
update_plane() handlers to the general plane commit operation.
Everything inside commit should now be non-sleeping, so this brings us
closer to how vblank evasion will behave once we move over to atomic.

v2:
 - Restore lost intel_crtc->active check on vblank evasion

v3:
 - Replace assert_pipe_enabled() in intel_disable_primary_hw_plane()
   with an intel_crtc->active test; it turns out assert_pipe_enabled()
   grabs some mutexes and can sleep, which we can't do with interrupts
   disabled.

v4:
 - Equivalent to v2; v3 change is now squashed into an earlier patch
   of the series.  (Ander).
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Once we integrate our work into the atomic pipeline, plane commit
operations will need to happen with interrupts disabled, due to vblank
evasion.  Our commit functions today include sleepable work, so those
operations need to be split out and run either before or after the
atomic register programming.

The solution here calculates which of those operations will need to be
performed during the 'check' phase and sets flags in an intel_crtc
sub-struct.  New intel_begin_crtc_commit() and
intel_finish_crtc_commit() functions are added before and after the
actual register programming; these will eventually be called from the
atomic plane helper's .atomic_begin() and .atomic_end() entrypoints.

v2: Fix broken sprite code split

v3: Make the pre/post commit work crtc-based to match how we eventually
    want this to be called from the atomic plane helpers.

v4: Some platforms that haven't had their watermark code reworked were
    waiting for vblank, then calling update_sprite_watermarks in their
    platform-specific disable code.  These also need to be flagged out
    of the critical section.

v5: Sprite plane test for primary show/hide should just set the flag to
    wait for pending flips, not actually perform the wait.  (Ander)

v6:
 - Rebase onto latest di-nightly; picks up an important runtime PM fix.
 - Handle 'wait_for_flips' flag in intel_begin_crtc_commit(). (Ander)
 - Use wait_for_flips flag for primary plane update rather than
   performing the wait in the check routine.
 - Added kerneldoc to pre_disable/post_enable functions that are no
   longer static.  (Ander)
 - Replace assert_pipe_enabled() in intel_disable_primary_hw_plane()
   with an intel_crtc->active test; it turns out assert_pipe_enabled()
   grabs some mutexes and can sleep, which we can't do with interrupts
   disabled.

v7:
 - Check for fb != NULL when deciding whether the sprite plane hides the
   primary plane during a sprite update.  (PRTS)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Like Ivybridge, we have reports that we get random hangs when flipping
with multiple pipes. Extend

commit 2a92d5bc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 8 10:40:29 2014 +0100

    drm/i915: Disable RCS flips on Ivybridge

to also apply to Haswell.
Reported-and-tested-by: NScott Tsai <scottt.tw@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org # 2a92d5bc drm/i915: Disable RCS flips on Ivybridge
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

It is platform/output depenedent when exactly the pipe will start
running. Sometimes we just need the (cpu) pipe enabled, in other cases
the pch transcoder is enough and in yet other cases the (DP) port is
sending the frame start signal.

In a perfect world we'd put the drm_crtc_vblank_on call exactly where
the pipe starts running, but due to cloning and similar things this
will get messy. And the current approach of picking the most
conservative place for all combinations also doesn't work since that
results in legit vblank waits (in encoder->enable hooks, e.g. the 2
vblank waits for sdvo) failing.

Completely going back to the old world before

commit 51e31d49
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 15 12:36:02 2014 +0200

    drm/i915: Use generic vblank wait

isn't great either since screaming when the vblank wait work because
the pipe is off is kinda nice.

Pick a compromise and move the drm_crtc_vblank_on right before the
encoder->enable call. This is a lie on some outputs/platforms, but
after the ->enable callback the pipe is guaranteed to run everywhere.
So not that bad really. Suggested by Ville.

v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've
missed the ibx pipe B select w/a, which also has a vblank wait in the
disable function (while the pipe is obviously still running).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The VGA_2X_MODE bit apparently affects the display even when the VGA
plane is disabled. The bit will set by the BIOS when the panel width
is at least 1280 pixels. So by preserving the bit from the BIOS we
end up with corrupted display on machines with such high res panels.
I only have 1024x768 panels on my gen2 machines so never ran into
this problem.

The original reason for preserving the VGACNTR register was to make
my 830 survive S3 with acpi_sleep=s3_bios option. However after
further 830 fixes that option is no longer needed to make S3 work
and preserving VGACNTR doesn't seem to be necessary without it,
so we can just revert the entire patch.

This reverts
commit 69769f9a
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Aug 15 01:22:08 2014 +0300

    drm/i915: Preserve VGACNTR bits from the BIOS

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

During plane operations, we read/write some registers that only operate
properly if we're not runtime suspended.  At the moment we're not
holding the runtime PM reference across the whole plane operation, so
there's a potential for problems.

This issue was already partially addressed by commit

        commit d6dd6843
        Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
        Date:   Fri Aug 15 15:59:32 2014 -0300

            drm/i915: fix plane/cursor handling when runtime suspended

which took care of holding the runtime PM reference during the pin and
fence operations for plane updates.  However there are still a few
actual plane registers that we also need to hold the runtime PM
reference for.  Recent refactoring patches in preparation for atomic
have rearranged the code and made it increasingly likely that the
hardware will have time to suspend between the pin/fence operation and
the actual register writes. Examples of such registers are the stuff
touched by ivb_get_colorkey.

The solution here grabs the runtime PM reference around the 'commit'
operation for planes, which should cover all the relevant register
reads/writes.

Note that this has only been exposed with

commit 6beb8c23
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Mon Dec 1 15:40:14 2014 -0800

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

so doesn't need to be ported to 3.19.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87180Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Testcase: igt/pm-rpm/legacy-planes
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Augment commit message with information Paulo supplied.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Many distro's have mechanism in place to collect and automatically file
bugs for failed WARN()s.  And since i915 has a lot of hw state sanity
checks which result in WARN(), it generates quite a lot of noise which
is somewhat disconcerting to the end user.

Separate out the internal hw-is-in-the-state-I-expected checks into
I915_STATE_WARN()s and allow configuration via i915.verbose_checks module
param about whether this will generate a full blown stacktrace or just
DRM_ERROR().  The new moduleparam defaults to true, so by default there
is no change in behavior.  And even when disabled, you will still get
an error message logged.

v2: paint the macro names blue, clarify that the default behavior
    remains the same as before
Signed-off-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

v5: Chris suggested to add the case to MISSING_CASE for speedier
debug.

v6: Even some gcc 4.9 versions don't see through the maze, so give up
for now. Keep the skeleton and MISSING_CASE stuff though.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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: 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>

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: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Acked-and-mourned-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Partial revert of

commit 20664591
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Nov 5 14:26:09 2014 -0800

    drm/i915: check for audio and infoframe changes across mode sets v2

References: https://bugs.freedesktop.org/show_bug.cgi?id=86683Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NLi Xu <li.l.xu@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The same logic can be implemented without it, and it even saves a line
of code.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDaniel Vetter <daniel.vetter@intel.com>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NThomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>