Rename and document the GGTT init functions to give a better
idea of the context where they are called from.

i915_gem_gtt_init => i915_ggtt_init_hw
i915_gem_init_global_gtt => i915_gem_init_ggtt
i915_global_gtt_cleanup => i915_ggtt_cleanup_hw

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458830866-12578-1-git-send-email-joonas.lahtinen@linux.intel.com

Lets BUG_ON and don't bother with a WARN and returning an error, so we can
remove the need to pollute the code with error handling, after all it is
a programmer error to provide NULL view. Also while we're here remove
redundant NULL ggtt_view check.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834860-7898-1-git-send-email-matthew.auld@intel.com

commit e2c8b870 moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:

 =============================================
 [ INFO: possible recursive locking detected ]
 4.6.0-rc1 #385 Not tainted
 ---------------------------------------------
 kworker/0:3/88 is trying to acquire lock:
  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]

 but task is already holding lock:
  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&dev->mode_config.mutex);
   lock(&dev->mode_config.mutex);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 7 locks held by kworker/0:3/88:
  #0:  ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
  #1:  ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
  #2:  ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
  #3:  (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
  #4:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
  #5:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
  #6:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]

 stack backtrace:
 CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 Workqueue: kacpi_notify acpi_os_execute_deferred
  0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
  ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
  000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
 Call Trace:
  [<ffffffff8124af06>] dump_stack+0x67/0x90
  [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
  [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
  [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb
  [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
  [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
  [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
  [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
  [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
  [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
  [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
  [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
  [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
  [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
  [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
  [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
  [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
  [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
  [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
  [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
  [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
  [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
  [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b
  [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
  [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
  [<ffffffff81068f17>] process_one_work+0x265/0x50b
  [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd
  [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
  [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
  [<ffffffff8106e2d6>] kthread+0xe0/0xe8
  [<ffffffff8107bc47>] ? local_clock+0x19/0x22
  [<ffffffff81484f42>] ret_from_fork+0x22/0x40
  [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5

Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no

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

Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.

This order was originally changed in

	commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state")

In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.

CC: stable@vger.kernel.org
Signed-off-by: NLyude <cpaul@redhat.com>
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.

We might likewise receive hotplug events before we've had a chance to
fully set up the fbdev.

Fix by waiting for the asynchronous thread to finish.

v2:
An async_synchronize_full() was also added to intel_fbdev_set_suspend()
in v1 which turned out to be entirely gratuitous. It caused a deadlock
on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
for CI support) and was unnecessary since a device is never suspended
until its ->probe callback (and all asynchronous tasks it scheduled)
have finished. See dpm_prepare(), which calls wait_for_device_probe(),
which calls async_synchronize_full().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Reported-by: NGustav Fägerlind <gustav.fagerlind@gmail.com>
Reported-by: N"Li, Weinan Z" <weinan.z.li@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org

Set from VBT, but never used. Good riddance.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-5-git-send-email-jani.nikula@intel.com

Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-4-git-send-email-jani.nikula@intel.com

Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-3-git-send-email-jani.nikula@intel.com

Housekeeping, similar to psr, backlight, and dsi. No functional changes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-2-git-send-email-jani.nikula@intel.com

Having provided for_each_engine_id() for cases where the third (id)
argument is useful, we can now replace all the remaining instances with
a simpler version that takes only two parameters. In many cases, this
also allows the elimination of the local variable used in the iterator
(usually 'i').

v2:
    s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson]
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458757194-17783-2-git-send-email-david.s.gordon@intel.com

Equivalent to the existing for_each_engine() macro, this will replace
the latter wherever the third argument *is* actually wanted (in most
places, it is not used). The third argument is renamed to emphasise
that it is an engine id (type enum intel_engine_id). All the callers of
the macro that actually need the third argument are updated to use this
version, and the argument (generally 'i') is also updated to be 'id'.
Other callers (where the third argument is unused) are untouched for
now; they will be updated in the next patch.
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Currently the machine hangs during booting while accessing the
BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
experimentation I found that the hang is caused by the DSI PLL being
disabled, or it being enabled but with an incorrect divider
configuration. Enabling the PLL got rid of the boot problem, so fix
this by checking the PLL enabled state/configuration before attempting
to read out the HW state.

The DSI_PLL_ENABLE register is in the always-on power well, while the
BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
transcoder power domain, but what we really need is just a runtime PM
reference, which is provided by any power domain.

Ville also found this dependency specified in BSpec, so I added a
reference to that too.

v2:
- Make sure we hold a power reference while accessing the PLL registers.
v3: (Jani)
- Simplify check in bxt_get_dsi_transcoder_state()
- Add comment explaining why we check for valid dividers in
  bxt_dsi_pll_is_enabled()

CC: Shashank Sharma <shashank.sharma@intel.com>
CC: Uma Shankar <uma.shankar@intel.com>
CC: Jani Nikula <jani.nikula@intel.com>
Fixes: c6c794a2 ("drm/i915/bxt: Initialize MIPI DSI for BXT")
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458816100-31269-1-git-send-email-imre.deak@intel.com

intel_post_plane_update did an extra vblank wait that's no longer needed when enabling ips.

Changes since v1:
- Add comment explaining why vblank wait is performed. (Paulo)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56F29B28.5070804@linux.intel.com

In commit 0a878716
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 14:23:01 2015 +0200

    drm/i915: restore ggtt double-bind avoidance

we wrote the ggtt_bind_vma() observing a number of cleanups we could do
over the template of aliasing_gtt_bind_vma(). Now let's apply the
cleanups we made there back to the original. The essence is to avoid
redundant variables and assignements, and by doing so make the code
easier to read.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448015238-24639-1-git-send-email-chris@chris-wilson.co.uk

Split a pnv_crtc_compute_clock(), so the differences between platforms
become more obvious.

With this, there are no more users of intel_limit() or the ->find_dpll()
hook, so get rid of them.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-16-git-send-email-ander.conselvan.de.oliveira@intel.com

Split a G4X specific version from i9xx_crtc_compute_clock(). With this
the differences between platforms become more obvious.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-15-git-send-email-ander.conselvan.de.oliveira@intel.com

Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this
there is no need for i9xx_get_refclk() anymore, and the differences
between platforms become more obvious.

v2: Use i8xx as prefix instead of gen2. (Ville and Daniel)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458653723-17951-1-git-send-email-ander.conselvan.de.oliveira@intel.com

In order for VLV and CHV to use i9xx_crtc_compute_clocks(), a number
of if ladders is necessary: one for setting the find_dpll() hook, one
for choosing the limits struct, one for choosing the right compute dpll
function and one for initializing the crtc_compute_clock() hook.

By extracting a platform specific implementation for each platform, the
number of if-ladders is reduced to one.

While at it also clean up bxt_find_best_dpll() which depends on some of
the CHV code.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-13-git-send-email-ander.conselvan.de.oliveira@intel.com

Merge ironlake_compute_clocks() into ironlake_crtc_compute_clock() so
the clock computation logic is all in one place. The resulting function
is still quite simple. Follow up patches will make the similar code for
GMCH platforms look similar.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-12-git-send-email-ander.conselvan.de.oliveira@intel.com

Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and
move the lower level details of setting crtc_state->dpll_hw_state into
the _compute_dpll() function.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-11-git-send-email-ander.conselvan.de.oliveira@intel.com

When calculating clocks, just pass a pointer to crtc_state->dpll
directly to the find_dpll() hook. Back when this was introduced in
commit f47709a9 ("drm/i915: create pipe_config->dpll for clock
state") there was no staged crtc config or atomic crtc state, so it was
possible to overwrite the current configuration on error. That hasn't
been the case for a while now, so finally make it "disappear".
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-10-git-send-email-ander.conselvan.de.oliveira@intel.com

None of the code in ironlake_crtc_compute_clock() is relevant for CPU
eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off}
from the DP code and that doesn't depend on the crtc_state->dpll values,
so just return early in that case.

v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-9-git-send-email-ander.conselvan.de.oliveira@intel.com

The checks were added in commit 5dc5298b ("drm/i915: add proper
CPU/PCH checks to crtc_mode_set functions") in a time when there was
doubts on what PCHs would be supported by HSW. There are similar checks
for PCH type in intel_detect_pch() and the function pointers are
initialized based on platform/pch information, so the removed WARN can't
ever be reached.

v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-8-git-send-email-ander.conselvan.de.oliveira@intel.com

Remove the clock calculation from ironlake_crtc_compute_clock() when the
encoder compute_config() already set one. The value was just thrown away
in that case.

Note that the previously set clock is not validated against the limits
anymore. That is ok since the fixed clocks from DP and SDVO are within
the supported range, so the call to ironlake_compute_clocks() would
never fail in that case.

v2: Add note about not checking fixed clocks agains limits. (Maarten)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-7-git-send-email-ander.conselvan.de.oliveira@intel.com

Check has_reduced_clock only once when setting dpll_hw_state, making the
code slightly more readable.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-6-git-send-email-ander.conselvan.de.oliveira@intel.com

The call to dev_priv->display.find_dpll() is already in platform
specific code, so avoid the extra detour.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-5-git-send-email-ander.conselvan.de.oliveira@intel.com

The function intel_ironlake_limit() is only called by the crtc compute
clock path. By merging it into ironlake_compute_clocks(), the code gets
clearer, since there's no more if-ladders to follow.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-4-git-send-email-ander.conselvan.de.oliveira@intel.com

A previous patch made ironlake_get_refclk() very simple, so merge
it into its only caller.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-3-git-send-email-ander.conselvan.de.oliveira@intel.com

LVDS is not cloneable, so the check is unnecessary. Removing it makes
the code neater.

v2: Remove checks from GMCH code too, not only ILK+. (Ville)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-2-git-send-email-ander.conselvan.de.oliveira@intel.com

The wait for other gens was added in commit 564ed191 ("drm/i915:
gmch: fix stuck primary plane due to memory self-refresh mode") since
that's necessary when disabling cxsr. However, cxsr disabling was later
moved to intel_pre_disable_primary() in commit 87d4300a ("drm/i915:
Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
it there.") and that function got its own vblank wait for cxsr in commit
262cd2e1 ("drm/i915: CHV DDR DVFS support and another watermark
rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().

Cc: Kalyan Kondapally <kalyan.kondapally@intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458634284-6080-1-git-send-email-ander.conselvan.de.oliveira@intel.com

Commit d15d7538 ("drm/i915: Tune down init error message due
to failure injection") added i915_load_error message to failure
path on device initialization. The message is printed
after the device is freed. And as the message printing helper
uses the device structure, this leads to use after free.

Spotted by Kasan.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458721906-10625-1-git-send-email-mika.kuoppala@intel.com

This patch contains following changes:
1. Add BXT MIPI display address base.
2. Call dsi_init from display_setup function.

v2: Rebased on latest nightly branch

v3 by Jani: init dsi after ddi
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458640910-5338-1-git-send-email-jani.nikula@intel.com

Joonas and Daniel remarked that our debugging output should stay compatible
with the core DRM's debug facility. The recently added __i915_printk() would
output debug messages even if debugging is completely disabled via the
drm.debug option. To fix this make __i915_printk behave the same as
DRM_DEBUG_DRIVER in this case.

CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458572937-21712-1-git-send-email-imre.deak@intel.com

At the end of an atomic commit, we currently wait for vblanks to
complete, call put() on the various runtime PM references, and then try
to optimize our watermarks (on platforms that need two-step watermark
programming).  This can lead to watermark registers being programmed
while the power well is powered down.  We need to wait until after
watermark optimization is complete before dropping our runtime power
references.

Note that in the future the watermark optimization is probably going to
move to an asynchronous workqueue task that happens at some arbitrary
point after vblank.  When we make that change, we'll no longer
necessarily be operating under the power reference held here, so we'll
need to wrap the watermark register programmin in a call to
intel_runtime_pm_get_if_in_use() or similar.

Cc: arun.siluvery@linux.intel.com
Cc: ville.syrjala@linux.intel.com
Cc: maarten.lankhorst@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94349
Fixes: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457135979-23727-1-git-send-email-matthew.d.roper@intel.com

In preparation for engine reset, the wedged argument of i915_handle_error()
is extended to reflect as a mask of engines that are hung. This is further
passed down to error state capture functions which are also updated.

Engine reset recovery mechanism uses this mask and schedules recovery work
for those particular engines.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331676-567-3-git-send-email-arun.siluvery@linux.intel.com

Initialize hangcheck struct during driver load. Since we do the same after
recovering from a reset, this is extracted into a helper function.

v2: remove redundant hangcheck init during load as this is done when
engines are initialized (Chris)

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458577619-12006-1-git-send-email-arun.siluvery@linux.intel.com

Patch based on a previous series by Shashank Sharma.

v2: Update contributors

v3: Refactor degamma/gamma LUTs load into a single function

v4: Remove unused variable
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NKumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: NKausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-5-git-send-email-lionel.g.landwerlin@intel.com

Patch based on a previous series by Shashank Sharma.

v2: Do not read GAMMA_MODE register to figure what mode we're in

v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0

    Add documentation on how the Broadcast RGB property is affected by CTM

v4: Update contributors

v5: Refactor degamma/gamma LUTs load into a single function

v6: Fix missing intel_crtc variable (bisect issue)

v7: Fix & simplify limited range matrix multiplication (Matt Roper's
    comment)
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NKumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: NKausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Acknowledged-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-4-git-send-email-lionel.g.landwerlin@intel.com

Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

v2: Read GAMMA_MODE register value at init (Matt Roper's comment)

v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
    with other registers (Matt Roper's comment).

v4: Mask GAMMA_MODE register with interesting bits when reading
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-3-git-send-email-lionel.g.landwerlin@intel.com