This patch is based on the upstream commit 5ac1c4bc and amended
for v4.2 to make sure it works as intended.

Repeated calls to begin_crtc_commit can cause warnings like this:
[  169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
[  169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[  169.127840] 3 locks held by kms_flip/1947:
[  169.127843]  #0:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130
[  169.127860]  #1:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130
[  169.127870]  #2:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110
[  169.127879] irq event stamp: 665690
[  169.127882] hardirqs last  enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70
[  169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915]
[  169.127936] softirqs last  enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650
[  169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0
[  169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039
[  169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  169.127957]  ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001
[  169.127964]  0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046
[  169.127970]  ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88
[  169.127981] Call Trace:
[  169.127992]  [<ffffffff817f6907>] dump_stack+0x4f/0x7b
[  169.128001]  [<ffffffff810aebed>] ___might_sleep+0x16d/0x270
[  169.128008]  [<ffffffff810aed38>] __might_sleep+0x48/0x90
[  169.128017]  [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410
[  169.128073]  [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915]
[  169.128138]  [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915]
[  169.128198]  [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915]
[  169.128253]  [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915]
[  169.128279]  [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
[  169.128338]  [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915]
[  169.128378]  [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915]
[  169.128385]  [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10
[  169.128391]  [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120
[  169.128398]  [<ffffffff8119b547>] ? might_fault+0x57/0xb0
[  169.128403]  [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620
[  169.128409]  [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0
[  169.128415]  [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
[  169.128424]  [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530
[  169.128429]  [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10
[  169.128435]  [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100
[  169.128439]  [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0
[  169.128445]  [<ffffffff81800697>] system_call_fastpath+0x12/0x6f

Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc.

The problem here was that the drm_atomic_helper_commit_planes() helper
we were using was basically designed to do

    begin_crtc_commit(crtc #1)
    begin_crtc_commit(crtc #2)
    ...
    commit all planes
    finish_crtc_commit(crtc #1)
    finish_crtc_commit(crtc #2)

The problem here is that since our hardware relies on vblank evasion,
our CRTC 'begin' function waits until we're out of the danger zone in
which register writes might wind up straddling the vblank, then disables
interrupts; our 'finish' function re-enables interrupts after the
registers have been written.  The expectation is that the operations between
'begin' and 'end' must be performed without sleeping (since interrupts
are disabled) and should happen as quickly as possible.  By clumping all
of the 'begin' calls together, we introducing a couple problems:
 * Subsequent 'begin' invocations might sleep (which is illegal)
 * The first 'begin' ensured that we were far enough from the vblank that
   we could write our registers safely and ensure they all fell within
   the same frame.  Adding extra delay waiting for subsequent CRTC's
   wasn't accounted for and could put us back into the 'danger zone' for
   CRTC #1.

This commit solves the problem by using a new helper that allows an
order of operations like:

   for each crtc {
        begin_crtc_commit(crtc)  // sleep (maybe), then disable interrupts
        commit planes for this specific CRTC
        end_crtc_commit(crtc)    // reenable interrupts
   }

so that sleeps will only be performed while interrupts are enabled and
we can be sure that registers for a CRTC will be written immediately
once we know we're in the safe zone.

The crtc->config->base.crtc update may seem unrelated, but the helper
will use it to obtain the crtc for the state. Without the update it
will dereference NULL and crash.

Changes since v1:
- Use Matt Roper's commit message.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90398Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This should be much cleaner, with the same effects.

(cherry picked for v4.2 from commit fb9d6cf8)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90398Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In

commit d328c9d7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Apr 10 16:22:37 2015 +0200

    drm/i915: Select starting pipe bpp irrespective or the primary plane

we started to select the pipe bpp from sink capabilities and not from
the primary framebuffer - that one might change (and we don't want to
incur a modeset) and sprites might contain higher bpp content too.

We also selected dithering on a 8 bpc screen displaying a 24bpp rgb
primary, because pipe_bpp is 24 for such a typical 8 bpc sink, but since
the commit mentioned above, base_bpp is always the absolute maximum
supported by the hardware, e.g., 36 bpp on my Ironlake chip. Iow. the
only way to not get dithering would have been to connect a deep color 12
bpc display, so pipe_bpp == 36 == base_bpp.

Hence only enable dithering on 6bpc screens where we difinitely and
always want it.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Reported-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When resuming with dpms off, the following warn can happen:

[  118.334082] ------------[ cut here ]------------
[  118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]()
[  118.334106] WARN_ON(!crtc->state->enable)
[  118.334137] Modules linked in: i915
[  118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148
[  118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  118.334144] Workqueue: events_unbound async_run_entry_fn
[  118.334147]  ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001
[  118.334149]  ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8
[  118.334151]  ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668
[  118.334151] Call Trace:
[  118.334155]  [<ffffffff817aa62a>] dump_stack+0x4f/0x7b
[  118.334157]  [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0
[  118.334158]  [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50
[  118.334173]  [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915]
[  118.334188]  [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915]
[  118.334191]  [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80
[  118.334205]  [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915]
[  118.334219]  [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915]
[  118.334232]  [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915]
[  118.334246]  [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915]
[  118.334248]  [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90
[  118.334255]  [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915]
[  118.334262]  [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915]
[  118.334263]  [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0
[  118.334266]  [<ffffffff81467550>] dpm_run_callback+0x70/0x420
[  118.334267]  [<ffffffff81467cbd>] device_resume+0x9d/0x1c0
[  118.334269]  [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60
[  118.334270]  [<ffffffff81467dfc>] async_resume+0x1c/0x50
[  118.334271]  [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0
[  118.334273]  [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0
[  118.334275]  [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0
[  118.334276]  [<ffffffff8109daf9>] worker_thread+0x49/0x450
[  118.334278]  [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0
[  118.334280]  [<ffffffff810a3cb9>] kthread+0xf9/0x110
[  118.334282]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334284]  [<ffffffff817b414f>] ret_from_fork+0x3f/0x70
[  118.334286]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334287] ---[ end trace 01f2cf6371b82d7a ]---

This warn is harmless, and can be fixed by not calling intel_crtc_disable when
the crtc is already disabled.
Reported-and-Tested-by: NJörg Otte <jrg.otte@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
> > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
>
> Ugh. Please enable KALLSYMS to get sane symbols.
>
> But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
> so it's pretty clearly just that change frm
>
> -       if (intel_crtc->active) {
> +       if (crtc_state->base.active) {
>
> and "crtc_state" is NULL.
>
> And the code very much knows that crtc_state can be NULL, since it's
> initialized with
>
>         crtc_state = state->base.state ?
>                 intel_atomic_get_crtc_state(state->base.state,
> intel_crtc) : NULL;
>
> Tssk. Daniel? Should I just revert that commit dec4f799
> ("drm/i915: Use crtc_state->active in primary check_plane func") for
> now, or is there a better fix? Like just checking crtc_state for NULL?

Indeed embarrassing. I've missed that we still have 1 caller left that's
using the transitional helpers, and those don't fill out
plane_state->state backpointers to the global atomic update since there is
no global atomic update for transitional helpers. Below diff should fix
this - we need to preferentially check crts_state->active and if that's
not set intel_crtc->active should yield the right result for the one
remaining caller (it's in the crtc_disable paths).

This fixes a regression introduced in

commit dec4f799
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jul 7 11:15:47 2015 +0200

    drm/i915: Use crtc_state->active in primary check_plane func

which was quickly reverted in

commit 01e2d062
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 12 15:00:20 2015 -0700

    Revert "drm/i915: Use crtc_state->active in primary check_plane func"

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This reverts commit dec4f799.

Jörg Otte reports a NULL pointder dereference due to this commit, as
'crtc_state' very much can be NULL:

        crtc_state = state->base.state ?
                intel_atomic_get_crtc_state(state->base.state, intel_crtc) : NULL;

So the change to test 'crtc_state->base.active' cannot possibly be
correct as-is.

There may be some other minimal fix (like just checking crtc_state for
NULL), but I'm just reverting it now for the rc2 release, and people
like Daniel Vetter who actually know this code will figure out what the
right solution is in the longer term.
Reported-and-bisected-by: NJörg Otte <jrg.otte@gmail.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since

commit 8c7b5ccb
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Apr 21 17:13:19 2015 +0300

    drm/i915: Use atomic helpers for computing changed flags

we compute the plane state for a modeset before actually committing
any changes, which means crtc->active won't be correct yet. Looking at
future work in the modeset conversion targetting 4.3 the only places
where crtc_state->active isn't accurate is when disabling other CRTCs
than the one the modeset is for (when stealing connectors). Which
isn't the case here. And that's also confirmed by an audit, we do
unconditionally update crtc_state->active for the current pipe.

We also don't need to update any other plane check functions since we
only ever add the primary state to the modeset update right now.

Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was lost in

commit ce22dba9
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Apr 21 17:12:56 2015 +0300

    drm/i915: Move toggling planes out of crtc enable/disable.

and we still need that crtc->active check since the overall modeset
flow doesn't yet take dpms state into account properly. Fixes WARNING
backtraces on at least bdw/hsw due to the ips disabling code being
upset about being run on a switched-off pipe.

We don't need a corresponding change on the enable side since with the
old setCrtc semantics we always force-enable the pipe after a modeset.
And the dpms function intel_crtc_control already checks for ->active.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ville noticed that the PLL HW readout code parsed the fractional
divider value as if the fractional divider was always enabled. This may
result in a port clock state check mismatch if the preceeding modeset
disabled the fractional divider, but left a non-zero divider value in
the register.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We cannot let IPS enabled with no plane on the pipe:

BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and BDW.

However a shortcut path on update primary plane function
to make primary plane invisible by setting DSPCTRL to 0
was leting IPS enabled while there was no
other plane enabled on the pipe causing flickerings that we were
believing that it was caused by that other restriction where
ips cannot be used when pixel rate is greater than 95% of cdclok.

v2: Don't mess with Atomic path as pointed out by Ville.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Silence the following -Wmaybe-uninitialized warnings and make the code
more clear.

drivers/gpu/drm/i915/intel_display.c: In function ‘__intel_set_mode’:
drivers/gpu/drm/i915/intel_display.c:11844:14: warning: ‘crtc_state’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return state->mode_changed || state->active_changed;
              ^
drivers/gpu/drm/i915/intel_display.c:11854:25: note: ‘crtc_state’ was declared here
  struct drm_crtc_state *crtc_state;
                         ^
drivers/gpu/drm/i915/intel_display.c:11868:6: warning: ‘crtc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (crtc != intel_encoder->base.crtc)
      ^
drivers/gpu/drm/i915/intel_display.c:11853:19: note: ‘crtc’ was declared here
  struct drm_crtc *crtc;
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The code in intel_crtc_restore_mode() sets the enabled value of all the
CRTCs when restoring the mode after a suspend/resume cycle. When more
than one CRTC is enabled, that causes drm_atomic_helper_check_modeset()
to fail if there is more than one pipe enabled, since all but one CRTC
has valid connector data. Instead, set only the enabled value for the
CRTC passed as an argument.

v2: Don't leak atomic state. (Matt)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90468
References: https://bugs.freedesktop.org/show_bug.cgi?id=90396Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>

The force restore path relies on the staged config to preserve the
configuration used before a suspend/resume cycle. The update done to it
in intel_modeset_fixup_state() would cause that information to be lost
after the first modeset, making it impossible to restore the modes for
pipes B and C.

References: https://bugs.freedesktop.org/show_bug.cgi?id=90468Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since the force restore logic will restore the CRTCs state one at a
time, it is possible that the state will be inconsistent until the whole
operation finishes. A call to intel_modeset_check_state() is done once
it's over, so don't check the state multiple times in between. This
regression was introduced in:

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

    drm/i915: factor out compute_config from __intel_set_mode v3

v2: Rename check parameter to force_restore. (Matt)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Without this frontbuffer flip when enabling planes PSR got compromised
and wasn't being enabled waiting forever on the flush that never
arrived.

Another solution would to create a enable_cursor function and split this
frontbuffer flip among the different plane enable and disable functions.
But if necessary this can be done in a follow up work. For now let's
just fix the regression.

It was removed by:

commit 87d4300a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Apr 21 17:12:54 2015 +0300

    drm/i915: Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use it there.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

chv_enable_pll() doesn't need to hold sb_lock for the entire duration of
the function. Drop the lock as soon as possible.

valleyview_set_cdclk() does a potential lock+unlock+lock+unlock cycle
with sb_lock. Grab the lock a few lines earlier so we can make do
with a single lock+unlock cycle always.
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>

Rename dpio_lock to sb_lock to inform the reader that its primary
purpose is to protect the sideband mailbox rather than some DPIO
state.
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 primary plane frobbing was removed from the sprite code in
 commit ecce87ea
 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
 Date:   Tue Apr 21 17:12:50 2015 +0300

    drm/i915: Remove implicitly disabling primary plane for now

but the intel_flush_primary_plane() calls were left behind. Replace them
with straight forward POSTING_READ() of the sprite surface address
register.

The other user of intel_flush_primary_plane() is g4x_disable_trickle_feed()
where we can just inline the steps directly.

This allows intel_flush_primary_plane() to be killed off.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is a mplayer video failure reported with xv.
This is because there is a request to do both plane scaling
and colorkey. Because skl hw doesn't support plane scaling
and colorkey at the same time, request is failed which is expected
behavior.

To make xv operate, this patch allows colorkey continue to work
without using scaler. Then behavior would be similar to platforms
without plane scaler support.
Signed-off-by: NChandra Konduru <chandra.konduru@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90449
[danvet: change can_scale to bool as requested by Ville.]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec says we should disable the FDI RX/TX before disabling the PCH
ports. Do so.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we're always enabling enhanced framing on CPT even if the sink
doesn't support it. Fix this up by actaully looking at what the sink
tells us.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to re-init the display hardware when going out of suspend. This
includes:

  - Hooking the PCH to the reset logic
  - Restoring CDCDLK
  - Enabling the DDB power

Among those, only the CDCDLK one is a bit tricky. There's some
complexity in that:

  - DPLL0 (which is the source for CDCLK) has two VCOs, each with a set
    of supported frequencies. As eDP also uses DPLL0 for its link rate,
    once DPLL0 is on, we restrict the possible eDP link rates the chosen
    VCO.
  - CDCLK also limits the bandwidth available to push pixels.

So, as a first step, this commit restore what the BIOS set, until I can
do more testing.

In case that's of interest for the reviewer, I've unit tested the
function that derives the decimal frequency field:

  #include <stdio.h>
  #include <stdint.h>
  #include <assert.h>

  #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))

  static const struct dpll_freq {
          unsigned int freq;
          unsigned int decimal;
  } freqs[] = {
          { .freq = 308570, .decimal = 0b01001100111},
          { .freq = 337500, .decimal = 0b01010100001},
          { .freq = 432000, .decimal = 0b01101011110},
          { .freq = 450000, .decimal = 0b01110000010},
          { .freq = 540000, .decimal = 0b10000110110},
          { .freq = 617140, .decimal = 0b10011010000},
          { .freq = 675000, .decimal = 0b10101000100},
  };

  static void intbits(unsigned int v)
  {
          int i;

          for(i = 10; i >= 0; i--)
                  putchar('0' + ((v >> i) & 1));
  }

  static unsigned int freq_decimal(unsigned int freq /* in kHz */)
  {
          return (freq - 1000) / 500;
  }

  static void test_freq(const struct dpll_freq *entry)
  {
          unsigned int decimal = freq_decimal(entry->freq);

          printf("freq: %d, expected: ", entry->freq);
          intbits(entry->decimal);
          printf(", got: ");
          intbits(decimal);
          putchar('\n');

          assert(decimal == entry->decimal);
  }

  int main(int argc, char **argv)
  {
          int i;

          for (i = 0; i < ARRAY_SIZE(freqs); i++)
                  test_freq(&freqs[i]);

          return 0;
  }

v2:
  - Rebase on top of -nightly
  - Use (freq - 1000) / 500 for the decimal frequency (Ville)
  - Fix setting the enable bit of HSW_NDE_RSTWRN_OPT (Ville)
  - Rename skl_display_{resume,suspend} to skl_{init,uninit}_cdclk to
    be consistent with the BXT code (Ville)
  - Store boot CDCLK in ddi_pll_init (Ville)
  - Merge dev_priv's skl_boot_cdclk into cdclk_freq
  - Use LCPLL_PLL_LOCK instead of (1 << 30) (Ville)
  - Replace various '0' by SKL_DPLL0 to be a bit more explicit that
    we're programming DPLL0
  - Busy poll the PCU before doing the frequency change. It takes about
    3/4 cycles, each separated by 10us, to get the ACK from the CPU
    (Ville)

v3:
  - Restore dev_priv->skl_boot_cdclk, leaving unification with
    dev_priv->cdclk_freq for a later patch (Daniel, 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>

Since we will often pageflip to an active surface, we will often have to
wait for the surface to be written before issuing the flip. Also we are
likely to wait on that surface in plenty of time before the vblank.
Since we have a mechanism for boosting when a flip misses the expected
vblank, curtain the number of times we RPS boost when simply waiting for
mmioflip.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: s/rq/req/]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly impacting the current performance of Broadwell versus Haswell in
certain workloads (like video decode). With the introduction of
reference counted requests, it is much easier to track the last request
per ring, as well as the last global write request so that we can
optimise inter-engine read read requests (as well as better optimise
certain CPU waits).

v2: Fix inverted readonly condition for nonblocking waits.
v3: Handle non-continguous engine array after waits
v4: Rebase, tidy, rewrite ring list debugging
v5: Use obj->active as a bitfield, it looks cool
v6: Micro-optimise, mostly involving moving code around
v7: Fix retire-requests-upto for execlists (and multiple rq->ringbuf)
v8: Rebase
v9: Refactor i915_gem_object_sync() to allow the compiler to better
optimise it.

Benchmark: igt/gem_read_read_speed
hsw:gt3e (with semaphores):
Before: Time to read-read 1024k:		275.794µs
After:  Time to read-read 1024k:		123.260µs

hsw:gt3e (w/o semaphores):
Before: Time to read-read 1024k:		230.433µs
After:  Time to read-read 1024k:		124.593µs

bdw-u (w/o semaphores):             Before          After
Time to read-read 1x1:            26.274µs       10.350µs
Time to read-read 128x128:        40.097µs       21.366µs
Time to read-read 256x256:        77.087µs       42.608µs
Time to read-read 512x512:       281.999µs      181.155µs
Time to read-read 1024x1024:    1196.141µs     1118.223µs
Time to read-read 2048x2048:    5639.072µs     5225.837µs
Time to read-read 4096x4096:   22401.662µs    21137.067µs
Time to read-read 8192x8192:   89617.735µs    85637.681µs

Testcase: igt/gem_concurrent_blit (read-read and friends)
Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [v8]
[danvet: s/\<rq\>/req/g]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The merged seqno->request conversion from John called request
variables req, but some (not all) of Chris' recent patches changed
those to just rq. We've had a lenghty (and inconclusive) discussion on
irc which is the more meaningful name with maybe at most a slight bias
towards req.

Given that the "don't change names without good reason to avoid
conflicts" rule applies, so lets go back to a req everywhere for
consistency. I'll sed any patches for which this will cause conflicts
before applying.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
[danvet: s/origina/merged/ as pointed out by Chris - the first
mass-conversion patch was from Chris, the merged one from John.]
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since DRM_ROTATE is counter clockwise (which is compliant with Xrandr),
and HW rotation is clockwise, swapping 90/270 to work as expected from
userspace.

v2: Rebased
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Explain why a few fields of the new pipe_config have their values
preserved, while the others are zeroed.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ARGB8888 is used for cursors on all platforms so we need to allow it
everywhere.

ABGR8888 is currently only honoured:
  - on VLV/CHV in sprite planes
  - on SKL+ for primary and sprite planes
so only allow it for those platforms.

Note that we only support ARGB8888/ABGR8888 on the primary plane for
SKL/BXT because we have in line of sight the pipe bottom color on those
platforms and because the primary plane programming on VLV/CHV doesn't
anything different for those formats today.

v2: Fix the logic to forbid the creation ABGR2101010 fbs (Ville)
v3: Still allow the creation of ARGB8888 fbs now that cursor planes use
    real fb objects (found by PRTS).
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>

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

We just have have VLV and CHV sprites programming the hardware
differently for the ABGR2101010 so keep them working.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

That define makes it hard to figure out what is the actual list of
formats at a glance. Expand it then.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the modeset code is reached with a CRTC that only needs a flip, the
code that assigns PLLs is skipped. But since there is still a state swap
for that CRTC, the current PLL assignment needs to be preserved. I
missed the ddi_pll_sel field in the following commit, which causes
warnings in DDI platforms.

commit 4978cc93
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Apr 21 17:13:21 2015 +0300

    drm/i915: Preserve shared DPLL information in new pipe_config

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90410Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Split strings to 80 char, add ddi_pll_sel and fixed typo. (Damien Lespiau)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the following commit, the place where the contents of dpll_hw_state
in crtc_state where zeroed was changed. Prior to that commit, it
happened when the new state was allocated, but now that happens just
before the call the .crtc_compute_clock() hook. The DP code for SKL,
however, sets up the (private) PLL in the encoder compute config
function that has already run by the time that memset() is reached,
causing the previous value to be lost.

This patch fixes the issue by moving the memset() down the call chain,
so that it is only called if the values in dpll_hw_state are going to be
updated.

commit 4978cc93
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Apr 21 17:13:21 2015 +0300

    drm/i915: Preserve shared DPLL information in new pipe_config

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Reported-and-tested-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just so it is grouped logically in line with other data and makes a
rather verbose output a bit shorter.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NChandra Konduru <chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ville noticed in another patch we we didn't need them at all, so remove
them. It's worth saying that it makes no difference to code generated as
gcc is clever enough to optimize it out.

v2: Remove 'break' after 'return' in switches (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
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>

We now prefix our functions/enums/data with the first platform it has
been introduced. Do that for the primary plane formats.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: s/gen2/i8xx/ and s/gen4/i965/ ...]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We advertize C8 in the primary plane formats didn't have the
corresponding code to set PLANE_CTL accordingly.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's be consistent with the others skl_plane_ctl_*() functions and use
a MISSING_CASE(). Not only that, but it's a rude to BUG() the whole
machine here.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No reason to not follow the 80 chars rule, renaming the local variable
makes it easy.

Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>