Currently we perform our own wait in post_plane_update,
but the atomic core performs another one in wait_for_vblanks.
This means that 2 vblanks are done when a fb is changed,
which is a bit overkill.

Merge them by creating a helper function that takes a crtc mask
for the planes to wait on.

The broadwell vblank workaround may look gone entirely but this is
not the case. pipe_config->wm_changed is set to true
when any plane is turned on, which forces a vblank wait.

Changes since v1:
- Removing the double vblank wait on broadwell moved to its own commit.
Changes since v2:
- Move out POWER_DOMAIN_MODESET handling to its own commit.
Changes since v3:
- Do not wait for vblank on legacy cursor updates. (Ville)
- Move broadwell vblank workaround comment to page_flip_finished. (Ville)
Changes since v4:
- Compile fix, legacy_cursor_flip -> *_update.
Changes since v5:
- Kill brackets.
- Add WARN_ON when wait_for_vblanks fails.
- Remove extra newlines.
- Split the checks whether vblank is needed to a separate function,
  with comments why a vblank is needed.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56CD84DA.5030507@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

Right now there's separate power domain handling for update_pipe and
modesets. Unify this and only grab POWER_DOMAIN_MODESET once.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-3-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

Use our newly created encoder_mask to iterate over the encoders.
This makes it possible to get the crtc power domains from the
crtc_state at any time, without any locks or having to look at
the legacy state.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

We have an open coded loop which tries to see if the encoder has any
connectors linked to it. Let's extract that to a helper similar to
intel_crtc_has_encoders().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455737325-14777-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of restoring dpms and a flag for whether a temp fb is allocated duplicate
an atomic state before the new state is committed, and commit it the old state
in intel_release_load_detect_pipe.

Changes since v1:
- Use a real atomic state. (Ville)
Changes since v2:
- Do not preserve shared_dpll any more, no need to do so. (Ville)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-2-git-send-email-maarten.lankhorst@linux.intel.com

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Revieved-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com

Unfortunately i915 is still not fully atomic, and expects mode_config.mutex
to be held during modeset until we finally fix it.

This fixes the following WARN when resuming:

[  425.208983] ------------[ cut here ]------------
[  425.208990] WARNING: CPU: 0 PID: 6828 at drivers/gpu/drm/drm_edid.c:3555 drm_select_eld+0xa5/0xd0()
[  425.209015] Modules linked in: pl2303 usbserial snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm i2c_hid i2c_designware_platform i2c_designware_core r8169 mii sdhci_acpi sdhci mmc_core
[  425.209018] CPU: 0 PID: 6828 Comm: kworker/u4:5 Tainted: G     U  W       4.5.0-rc4-gfxbench+ #1
[  425.209020] Hardware name: \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK, BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
[  425.209027] Workqueue: events_unbound async_run_entry_fn
[  425.209032]  0000000000000000 ffff880072433958 ffffffff813f6b05 0000000000000000
[  425.209036]  ffffffff81aaef2d ffff880072433990 ffffffff81078291 ffff880036b933d8
[  425.209039]  ffff88006d528000 ffff88006d52b3d8 ffff88006d52b3d8 ffff88007315b6f8
[  425.209040] Call Trace:
[  425.209045]  [<ffffffff813f6b05>] dump_stack+0x67/0x92
[  425.209049]  [<ffffffff81078291>] warn_slowpath_common+0x81/0xc0
[  425.209052]  [<ffffffff81078385>] warn_slowpath_null+0x15/0x20
[  425.209054]  [<ffffffff8151e195>] drm_select_eld+0xa5/0xd0
[  425.209101]  [<ffffffffa01f34f4>] intel_audio_codec_enable+0x44/0x160 [i915]
[  425.209135]  [<ffffffffa023eac7>] intel_enable_hdmi_audio+0x87/0x90 [i915]
[  425.209169]  [<ffffffffa023eb5a>] g4x_enable_hdmi+0x8a/0xa0 [i915]
[  425.209202]  [<ffffffffa023f41b>] vlv_hdmi_pre_enable+0x1cb/0x240 [i915]
[  425.209236]  [<ffffffffa020edcf>] valleyview_crtc_enable+0x10f/0x290 [i915]
[  425.209270]  [<ffffffffa020ba49>] intel_atomic_commit+0x769/0x17a0 [i915]
[  425.209274]  [<ffffffff81526ad5>] ? drm_atomic_check_only+0x145/0x660
[  425.209276]  [<ffffffff81527022>] drm_atomic_commit+0x32/0x50
[  425.209310]  [<ffffffffa0215fa0>] intel_display_resume+0xa0/0x130 [i915]
[  425.209338]  [<ffffffffa018c1bb>] i915_drm_resume+0xcb/0x160 [i915]
[  425.209366]  [<ffffffffa018c272>] i915_pm_resume+0x22/0x30 [i915]
[  425.209370]  [<ffffffff8143d91e>] pci_pm_resume+0x6e/0xe0
[  425.209373]  [<ffffffff8143d8b0>] ? pci_pm_resume_noirq+0xa0/0xa0
[  425.209375]  [<ffffffff815409ae>] dpm_run_callback+0x6e/0x280
[  425.209378]  [<ffffffff815410b2>] device_resume+0x92/0x250
[  425.209380]  [<ffffffff81541288>] async_resume+0x18/0x40
[  425.209382]  [<ffffffff8109c7a5>] async_run_entry_fn+0x45/0x140
[  425.209386]  [<ffffffff81093293>] process_one_work+0x1e3/0x620
[  425.209388]  [<ffffffff810931f7>] ? process_one_work+0x147/0x620
[  425.209391]  [<ffffffff81093719>] worker_thread+0x49/0x490
[  425.209393]  [<ffffffff810936d0>] ? process_one_work+0x620/0x620
[  425.209396]  [<ffffffff81099e0a>] kthread+0xea/0x100
[  425.209400]  [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0
[  425.209404]  [<ffffffff817ba03f>] ret_from_fork+0x3f/0x70
[  425.209407]  [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0
[  425.209409] ---[ end trace d1b247107f34a8b2 ]---

Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455632862-18557-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The check for active_crtcs == 0 was performed by the callers, when changing
the patches I forgot to remove those hunks.

This resulted in skylake scalers still not having the correct cdclk to
calculate scaling when all crtc's were dpms off.

Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455614711-9045-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Instead of duplicating the functionality now that we no longer need
to preserve dpll state we can move to using the upstream suspend helper.

Changes since v1:
- Call hw readout with all mutexes held.
- Rework intel_display_suspend to only assign modeset_restore_state
  on success.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56C2E686.5060803@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

RPS lock must be taken before the struct_mutex to avoid
locking inversion. So stop grabbing it for the whole
powersave initialization and instead only take it during
the sections which need it.

Also, struct_mutex is not needed any more since dedicated
RPS lock was added in:

   commit 4fc688ce
   Author: Jesse Barnes <jbarnes@virtuousgeek.org>
   Date:   Fri Nov 2 11:14:01 2012 -0700

       drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex

Based on prototype patch by Chris Wilson and a subsequent
mailing list discussion involving Ville, Imre, Chris and
Daniel.

v2: More details in the commit.

v3: Use drm_gem_object_unreference_unlocked. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

VMA creation and GEM list management need the big lock.

v2:

Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)

Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.

v3:

Some callers of i915_gem_object_create_stolen_for_preallocated
already hold the lock so move the mutex into the other caller
as well.

v4:

Changed to lockdep_assert_held. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Atomic resume was preserving the dpll state because it was required
for clearing pll state correctly. If we look at the old_crtc_state
for pll to clear this is not needed and the hack can be removed.

Changes since v1:
- Rename dpll variable to old_dpll. (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455022343-15222-1-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Skip DDI PLL selection if display type is DSI/MIPI.
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454671768-27062-1-git-send-email-mika.kahola@intel.com

This allows iteration over encoders without requiring connection_mutex.

Changes since v1:
- Add a set_best_encoder helper function and update encoder_mask inside
  it.
Changes since v2:
- Relax the WARN_ON(!crtc), with explanation.
- Call set_best_encoder when connector is moved between crtc's.
- Add some paranoia to steal_encoder to prevent accidentally setting
  best_encoder to NULL.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/56AA200A.6070501@linux.intel.com

This should only be touched by drm_atomic_helper.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452160762-30487-4-git-send-email-maarten.lankhorst@linux.intel.com

It's safe to assume cxsr is already disabled when the crtc is off.
This prevents an unclaimed register warning when the required power
wells are not enabled.

[  262.864984] ------------[ cut here ]------------
[  262.865025] WARNING: CPU: 1 PID: 6799 at drivers/gpu/drm/i915/intel_uncore.c:638 __unclaimed_reg_debug+0x68/0x80 [i915]()
[  262.865029] Unclaimed register detected before reading register 0x186500
[  262.865032] Modules linked in: i915 intel_powerclamp
[  262.865057] CPU: 1 PID: 6799 Comm: kms_pipe_crc_ba Tainted: G     U  W       4.4.0-gfxbench+ #1
[  262.865060] Hardware name: DN2820FYK, BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
[  262.865064]  ffffffffa0338cf8 ffff88007448ba78 ffffffff813df90c ffff88007448bac0
[  262.865071]  ffff88007448bab0 ffffffff810746e1 0000000000186500 0000000000000001
[  262.865077]  0000000000000001 ffff880074420000 0000000000000000 ffff88007448bb10
[  262.865083] Call Trace:
[  262.865092]  [<ffffffff813df90c>] dump_stack+0x4e/0x82
[  262.865098]  [<ffffffff810746e1>] warn_slowpath_common+0x81/0xc0
[  262.865102]  [<ffffffff81074767>] warn_slowpath_fmt+0x47/0x50
[  262.865128]  [<ffffffffa02a07e8>] __unclaimed_reg_debug+0x68/0x80 [i915]
[  262.865154]  [<ffffffffa02a0e4e>] vlv_read32+0x2de/0x370 [i915]
[  262.865173]  [<ffffffffa0256837>] intel_set_memory_cxsr+0x87/0x1a0 [i915]
[  262.865200]  [<ffffffffa02c4cb3>] intel_pre_plane_update+0xb3/0xf0 [i915]
[  262.865228]  [<ffffffffa02c54b5>] intel_atomic_commit+0x3b5/0x17c0 [i915]
[  262.865234]  [<ffffffff8150dc45>] ? drm_atomic_check_only+0x145/0x660
[  262.865239]  [<ffffffff8150d75a>] ? drm_atomic_set_crtc_for_connector+0x6a/0xe0
[  262.865243]  [<ffffffff8150e192>] drm_atomic_commit+0x32/0x50
[  262.865249]  [<ffffffff814eb155>] drm_atomic_helper_set_config+0x75/0xb0
[  262.865253]  [<ffffffff814fd090>] drm_mode_set_config_internal+0x60/0x110
[  262.865258]  [<ffffffff81501e26>] drm_mode_setcrtc+0x186/0x4f0
[  262.865263]  [<ffffffff814f3eed>] drm_ioctl+0x13d/0x590
[  262.865267]  [<ffffffff81501ca0>] ? drm_mode_setplane+0x1b0/0x1b0
[  262.865273]  [<ffffffff811d4c4c>] do_vfs_ioctl+0x2fc/0x550
[  262.865278]  [<ffffffff8118d5ea>] ? vm_munmap+0x4a/0x60
[  262.865283]  [<ffffffff811e06ba>] ? __fget_light+0x6a/0x90
[  262.865287]  [<ffffffff811d4edc>] SyS_ioctl+0x3c/0x70
[  262.865292]  [<ffffffff8179a75b>] entry_SYSCALL_64_fastpath+0x16/0x73
[  262.865296] ---[ end trace 6387a0ad001bb39f ]---

Testcase: kms_flip.basic-flip-vs-wf_vblank
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93698Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-4-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

This can be derived from the atomic state in pre_plane_update,
which makes it more clear when it's supposed to be called.
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-3-git-send-email-maarten.lankhorst@linux.intel.com

This is a revert of commit 066cf55b "drm/i915: Fix IPS related flicker".
intel_pre_disable_primary already handles this, and now everything
goes through the atomic path there's no need to try to disable ips twice.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-2-git-send-email-maarten.lankhorst@linux.intel.com

Now that the drm core unlinks/disarms events there's no need to do so
ourselves anymore. Nuke the code.
Acked-by: NDaniel Stone <daniels@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453756616-28942-4-git-send-email-daniel.vetter@ffwll.ch

FBC is already deactivated at this point.

Besides, nothing should be calling these lower-level function
pointers. A few months ago, the only caller of
dev_priv->fbc.deactivate was intel_pipe_set_base_atomic(), which was
the kgdboc function. But the following commit added it to the SKL
function:

    commit a8d201af
    Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Date:   Thu Jan 7 11:54:11 2016 +0100
        drm/i915: Use plane state for primary plane updates.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454101060-23198-1-git-send-email-paulo.r.zanoni@intel.com

Make sure we do the pre_update - which also deactivates FBC - before
we actually schedule the page flip, just to make sure we don't
flip to the new FB with FBC still activated for the previous FB.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-24-git-send-email-paulo.r.zanoni@intel.com

Move intel_fbc_enable to a place where it is called regardless of the
"modeset" variable, and make sure intel_fbc_enable can be called
multiple times without intel_fbc_disable being called.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-20-git-send-email-paulo.r.zanoni@intel.com

Instead of duplicating the calls for every platform, let's just put
them in the correct places inside intel_atomic_commit. This will also
make it easier for us to move the enable call in order to support
fasbtoot.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-19-git-send-email-paulo.r.zanoni@intel.com

This opens the possibility of implementing nicer schemes to choose the
CRTC, such as checking the amount of stolen memory available, or
choosing the best pipe on platforms that don't die FBC to pipe or
plane A.

This code was written for another refactor that I ended up discarding,
so I don't actually need it, but I figured this patch would be an
improvement on its own so I kept it on the series.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-18-git-send-email-paulo.r.zanoni@intel.com

We already have a dev variable, there's no need to access state->dev.
Also, I plan to add another dev_priv user here, so declare one for the
current user.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-17-git-send-email-paulo.r.zanoni@intel.com

Older FBC platforms have this restriction where FBC can't be enabled
if multiple pipes are enabled. In the current code, we disable FBC
before the second pipe becomes visible.

One of the problems with this code is that the current
multiple_pipes_ok() implementation just iterates through all CRTCs
looking at their states, but it doesn't make sure that the state
locks are grabbed. It also can't just grab the locks for every CRTC
since this would kill one of the biggest advantages of atomic
modesetting.

After the recent FBC changes, we now have the appropriate locks for
the given CRTC, so we can just try to maintain the state of each CRTC
and update it once intel_fbc_pre_update is called.

As a last note, I don't have gen 2/3 machines to test this code. My
current plan is to enable FBC on just the newer platforms, so this
patch is just an attempt to get the gen 2/3 code at least looking
sane, so if one day someone decide to fix FBC on these platforms, they
may have less work to do.

Not-tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (only on HSW+)
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-16-git-send-email-paulo.r.zanoni@intel.com

Instead of:
 - intel_fbc_disable_crtc(crtc)
 - intel_fbc_disable(dev_priv)
we now have:
 - intel_fbc_disable(crtc)
 - intel_fbc_global_disable(dev_priv)

This is because all the other functions that take a CRTC are called
 - intel_fbc_something(crtc)
Instead of:
 - intel_fbc_something_crtc(crtc)

And I also hope that the word "global" is going to help make it more
explicit that "global" is the unusual case, not the opposite.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-14-git-send-email-paulo.r.zanoni@intel.com

We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
during atomic commits. This will continue to guarantee that we
deactivate FBC and it will also update the state checking structures
at the correct time. Then, later, at the point where we were calling
intel_fbc_update, we'll only need to call intel_fbc_post_update.

Also add the proper warnings in case we don't have the appropriate
locks. Daniel mentioned the warnings will have to be removed for async
commits, but let's keep them here while we can.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-12-git-send-email-paulo.r.zanoni@intel.com

We unconditionally disable/update FBC even during the page flip
IOCTLs, and an unconditional disable/update at every atomic commit
touching the primary plane shouldn't impact PC state residency
noticeably. Besides, the code that checks for rotation is a good hint
that we may be forgetting something else, so let's leave all the
decisions to intel_fbc.c, making the code much safer.

Once we have the code to properly make FBC enable/update decisions
based on atomic states, with proper locking, then we'll be able to
evaluate whether it will be worth trying to optimize the cases where a
disable isn't needed.

v2: Upstream moved and now our patch needs to remove dev_priv.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453406837-10511-1-git-send-email-paulo.r.zanoni@intel.com

Before this patch, page flips would call intel_frontbuffer_flip() and
intel_frontbuffer_flip_complete(), which would call intel_fbc_flush(),
which would call intel_fbc_update(). The problem is that drawing
operations also trigger intel_fbc_flush() calls, so it's not
guaranteed that we have the CRTC and FB locks grabbed when
intel_fbc_flush() happens, since the call trace may come from the
rendering path.

We're trying to make the FBC code grab the appropriate CRTC/FB locks,
so split the drawing and the flipping logic in order to achieve that
in later patches. So now the frontbuffer tracking code is just going
to be used for frontbuffer drawing, and intel_fbc_update() is going to
be used directly for actual page flips.

As a note, we don't need to call intel_fbc_flip() during the two
places where we call intel_frontbuffer_flip() since in one of them we
already have an intel_fbc_update() call, and in the other we have the
planes disabled.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-7-git-send-email-paulo.r.zanoni@intel.com

In this atomic age, we can't trust the plane->fb pointer anymore.
It might get update too late. Instead we are supposed to use the
plane_state->fb pointer instead. Let's do that in
intel_plane_obj_offset() and avoid problems from dereferencing the
potentially stale plane->fb pointer.

Paulo found this with 'kms_frontbuffer_tracking --show-hidden --run-subtest nop-1p-rte'
but it can be reproduced with just plain old kms_setplane.

I was too lazy to bisect this, so not sure exactly when it broke. The
most obvious candidate
commit ce7f1728 ("drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly")
was actually still fine, so it must have broken some time after that.

Here's the resulting fireworks:
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915]
PGD 8a5f6067 PUD 8a5f5067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole mousedev hid_generic psmouse usbhid atkbd libps2 coretemp hwmon efi_pstore intel_rapl iosf_mbi x86_pkg_temp_thermal efivars pcspkr e1000e sdhci_pci ptp pps_core sdhci i2c_i801 mmc_core i2c_hid hid i8042 serio evdev sch_fq_codel ip_tables x_tables ipv6 autofs4
CPU: 1 PID: 260 Comm: kms_plane Not tainted 4.4.0-skl+ #171
Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B00.1511030553 11/03/2015
task: ffff88008bde2d80 ti: ffff88008a6ec000 task.ti: ffff88008a6ec000
RIP: 0010:[<ffffffffa02d2d9a>]  [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915]
RSP: 0018:ffff88008a6efa10  EFLAGS: 00010086
RAX: 0000000000000001 RBX: ffff8801674f4240 RCX: 0000000000000014
RDX: ffff88008a7440c0 RSI: 0000000000000000 RDI: ffff88008a6efa40
RBP: ffff88008a6efa30 R08: ffff88008bde3598 R09: 0000000000000001
R10: ffff88008b782000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88008a7440c0 R14: 0000000000000000 R15: ffff88008a7449c0
FS:  00007fa0c07a28c0(0000) GS:ffff88016ec40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000008a6ff000 CR4: 00000000003406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff8801674f4240 0000000000000000 ffff88008a7440c0 0000000000000000
 ffff88008a6efaa0 ffffffffa02daf25 ffffffff814ec80e 0000000000070298
 ffff8800850d0000 ffff88008a6efaa0 ffffffffa02c49c2 0000000000000002
Call Trace:
 [<ffffffffa02daf25>] intel_plane_obj_offset+0x2d/0xa9 [i915]
 [<ffffffff814ec80e>] ? _raw_spin_unlock_irqrestore+0x4b/0x60
 [<ffffffffa02c49c2>] ? gen9_write32+0x2e8/0x3b8 [i915]
 [<ffffffffa02eecfc>] skl_update_plane+0x203/0x4c5 [i915]
 [<ffffffffa02ca1ab>] intel_plane_atomic_update+0x53/0x6a [i915]
 [<ffffffffa02494a4>] drm_atomic_helper_commit_planes_on_crtc+0x142/0x1d5 [drm_kms_helper]
 [<ffffffffa02de44b>] intel_atomic_commit+0x1262/0x1350 [i915]
 [<ffffffffa024a0ee>] ? __drm_atomic_helper_crtc_duplicate_state+0x2f/0x41 [drm_kms_helper]
 [<ffffffffa01ef089>] ? drm_atomic_check_only+0x3e3/0x552 [drm]
 [<ffffffffa01ef245>] drm_atomic_commit+0x4d/0x52 [drm]
 [<ffffffffa024996b>] drm_atomic_helper_update_plane+0xcb/0x118 [drm_kms_helper]
 [<ffffffffa01e42e8>] __setplane_internal+0x1c8/0x224 [drm]
 [<ffffffffa01e477f>] drm_mode_setplane+0x14e/0x172 [drm]
 [<ffffffffa01d8117>] drm_ioctl+0x265/0x3ad [drm]
 [<ffffffffa01e4631>] ? drm_mode_cursor_common+0x158/0x158 [drm]
 [<ffffffff810d00ab>] ? current_kernel_time64+0x5e/0x98
 [<ffffffff810a76ea>] ? trace_hardirqs_on_caller+0x17a/0x196
 [<ffffffff8119880f>] do_vfs_ioctl+0x42b/0x4ea
 [<ffffffff811a2b72>] ? __fget_light+0x4d/0x71
 [<ffffffff81198911>] SyS_ioctl+0x43/0x61
 [<ffffffff814ed057>] entry_SYSCALL_64_fastpath+0x12/0x6f

Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_plane
Reported-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453220597-28973-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit e7941294)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logic.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 061e4b8d ("drm/i915: clean up atomic plane check functions, v2.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 693bdc28)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.

The clamping has been HDMI specific since its introduction in

commit 996a2239
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Apr 19 11:24:34 2013 +0200

    drm/i915: Disable high-bpc on pre-1.4 EDID screens

Cc: stable@vger.kernel.org
Reported-and-tested-by: NDihan Wickremasuriya <nayomal@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 013dd9e0)

The fb_modifiers and cpp arguments passed to intel_tile_width() in
intel_fill_fb_ggtt_view() got accidentally swapped around. I'm pretty
sure I fixed this already, but could be I lost the fix accidentally
during some rebases or something. Anyway, fix it up for real.

Fixes: d9b3288e ("drm/i915: change intel_fill_fb_ggtt_view() to use the real tile size")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-8-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_rotation_crc/primary-rotation-90
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: drm-intel-fixes@lists.freedesktop.org

We more or less randomly call the "bytes per pixel" value
'cpp', 'bytes_per_pixel', 'pixel_size', or even 'bpp'. Let's just pick
one and stick to it. I've chosen 'cpp'.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
'u32' instead since we've not yet seen a >4GiB ggtt.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also rename 'rotation_info' to 'rotated' to match the view type exactly,
this should avoid confusion which union members is valid for each view
type.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>