Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().

The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.

So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.

v2 (from Paulo):
  - Write a commit message since the original patch left it empty.
  - Rebase after the intel_power_well_{en,dis}able rename.
  - Use lookup_power_well() instead of hardcoded indexes.

Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92211
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92605Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com

The current lookup code wouldn't find a power well if it's not in any
power domain. There wasn't any power wells before but an upcoming patch
will detach the power domains from power well#1 and the MISC IO power
wells, so fix things up accordingly.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-3-git-send-email-imre.deak@intel.com

lookup_power_well() expects uniq power well IDs, but atm we have
uninitialized IDs which would clash with those power wells with a 0
ID. This wasn't a problem so far since nothing looked up such a power
well, but an upcoming patch will (Misc IO for SKL), so fix this up on
platforms where this matters.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-2-git-send-email-imre.deak@intel.com

After fixing the same issue in the set_caching IOCTL and Chris' request
to check out the possibilities for an improved RPM ref handling I
noticed that we have the same issue in the set_tiling IOCTL. Fix this
up.I didn't see any bug reports about this one, but the GTT unbind
operation on this path accesses the HW, which needs the ref.
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/1447092986-11165-1-git-send-email-imre.deak@intel.com

When accessing through the GTT from one CPU whilst concurrently updating
the GGTT PTEs in another thread, the hardware likes to return random
data. As we have strong serialisation prevent us from modifying the PTE
of an active GTT mmapping, we have to conclude that it whilst modifying
other PTE's that error occurs. (I have not looked for any pattern such
as modifying PTE within the same page or cacheline as active PTE -
though checking whether revoking neighbouring objects should be enough
to test that theory.) The corruption also seems restricted to Braswell
and disappears with maxcpus=0. This patch stops all access through the
GTT by other CPUs when we update any PTE by stopping the machine around
the GGTT update.

Note that splitting up the 64 bit write into two 32 bit writes was
tried and found to fail too.

Testcase: igt/gem_concurrent_blit
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89079Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about 2x 32bits failing too.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Compliance test 4.3.1.11 requires source to perform link training
always if the automated test requests for it. This patch
enforces this requirement.
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Automated test data that is updated when a test is requested is not cleared
till next automated test request is recevied which can cause various
problems. This patch fixes this by clearing this during the next
short pulse and on hot unplug.

For example, when TEST_LINK_TRAINING is requested it is updated
to appropriate variable inside intel_dp_handle_test_request
but is also cleared only inside the same function. if the next
short pulse does not have the AUTOMATED_TEST_REQUEST bits set
the variable will not be cleared resulting in carrying incorrect
test status in local variables.

v2: Added comments and moved nack and defer variables before set_edid
(Sonika)
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If ddb allocation for planes in current CRTC is changed, that doesn't
lead to ddb allocation change for other CRTCs, because our DDB allocation
is not dynamic according to plane parameters, ddb is allocated according
to number of CRTC enabled, & divided equally among CTRC's.

In current condition check during Watermark calculation, if number of
plane/ddb allocation changes for current CRTC, Watermark for other pipes
are recalculated. But there is no change in DDB allocation of other pipe
so watermark is also not changed, This leads to warning messages.
WARN_ON(!wm_changed)

This patch corrects this and check if DDB allocation for pipes is changed,
then only recalculate watermarks.

v2 (by Matt): Rebased to latest -nightly and fixed a typo
Signed-off-by: NKumar, Mahesh <mahesh1.kumar@intel.com>
Reviewed-by(v1): Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Split up the ctl vs. data reg handling like in the normal AUX code
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-8-git-send-email-ville.syrjala@linux.intel.com

Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
under dev_priv, like we for DSI and GPIO for example.

TODO: could probably move a bunch of this kind of stuff into the device
info instead...

v2: Drop the spurious whitespace change (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-7-git-send-email-ville.syrjala@linux.intel.com

Rather than computing on demand, store also the aux data reg
offsets under intel_dp.

v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-6-git-send-email-ville.syrjala@linux.intel.com

Currently we determine the location of the AUX registers in a confusing
way. First we assume the PCH registers are used always, but then we
override it for everything but HSW/BDW to use DP+0x10. Very confusing.

Let's just make it straightforward and simply add a few functions to
pick the right AUX_CTL based on the DP port.

To deal with VLV/CHV we'll include the display_mmio_offset into the
AUX register defines.

v2: Reorder patches (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-5-git-send-email-ville.syrjala@linux.intel.com

v2: Keep some MISSING_CASE() stuff (Jani)
    s/-1/-PIPE_B/ in the register macro
    Fix typo in patch subject
v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)
v4: Reorder patches (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v3)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-4-git-send-email-ville.syrjala@linux.intel.com

Use kasprintf() to generate the "DPDDC-<port>" name for the aux helper.

To deal with errors properly make intel_dp_aux_init() return something,
and adjust the caller to match. It seems we were also missing a
intel_dp_mst_encoder_cleanup() call on edp (non-port A) init failures,
so add that too.

The whole error/cleanup ordering doesn't feel entirely sane to me, but
I'll leave that part alone for now.

v2: Use kasprintf() instead of a table, reorder patches (Chis)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Instead of checking what aux_ch_ctl_reg is, we can simply check the port
when determining the right timeout value to program.

v2: Reorder patches to reduce churn (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-2-git-send-email-ville.syrjala@linux.intel.com

While comparing the B-Spec with the code I noticed that several
values in these tables have been updated in the spec, so I
changed the code to match..

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJim Bride <jim.bride@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com

The i_boost level in the DDI translation tables are stored per level.
However, skl_ddi_set_iboos() would choose an entry of that table based
on the port argument.

Cc: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NJim Bride <jim.bride@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447247754-802-1-git-send-email-ander.conselvan.de.oliveira@intel.com

As during disabling dc6 no need to check for csr firmware
loading status, so removed the assert call (Requested by Damien).

Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-14-git-send-email-imre.deak@intel.com

Currently during system s/r we enable/disable DC6, so before we do so
make sure that the firmware loading is complete.

Note that whether we need to enable DC6 for S3/S4 is still open.  At
least the firmware program is lost during S3 and we need to reprogram it
after resuming. Until this is clarified we keep the current behavior and
enable/disable DC6.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-13-git-send-email-imre.deak@intel.com

During driver unload to ensure we dont have any pending task,
flush_work added to complete firmware loading task.

v1: Initial version.

v2: As per review comments from Daniel,
Removed flush_work from skl_set_power_well. As we have taken
power well refernece and rpm count during firmware loading
by using display_power_domain_get/put - this will always
ensure rpm will be blocked if firmware is not loaded.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-12-git-send-email-imre.deak@intel.com

Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
  which is a notch more obvious what it does than having a special
  completion.

The next patch will properly synchronize against the async loader in
the resume and unload code.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-11-git-send-email-imre.deak@intel.com

The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.

v2-v3:
- unchanged
v4:
- rebased on top of latest drm-intel-nightly

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[imre: remove note about BE cast from commit message, it's not relevant
 any more]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: fix checkpatch warn on multiple blank lines]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341089-2735-1-git-send-email-imre.deak@intel.com

As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com

We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-8-git-send-email-imre.deak@intel.com

If we really want to we can be more verbose here, but we really don't
need an entire function for this.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-7-git-send-email-imre.deak@intel.com

Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.

Apply this across the entire file since it was sticking out a bit too
much.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from the commit message, it's
 not relevant any more]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-6-git-send-email-imre.deak@intel.com

This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
  form, whether callbacks, workers or other threads). This is what the
  mutex_lock/unlock seems to have been for in intel_csr_load_program.
  Instead ordering should be ensured with the generic
  wait_for_completion()/complete(). Or more specific functions
  provided by the core kernel like e.g.
  flush_work()/cancel_work_sync() in the case of synchronizing with a
  work item.

- Don't invent own completion like the following code did with the
  (already removed) wait_for(csr_load_status_get()) pattern - it's
  really hard to get these right when you want them to be _really_
  correct (and be fast) in all cases. Furthermore it's easier to read
  code using the well-known primitives than new ones using
  non-standard names.

Before enabling/disabling DC6 check if the firmware is loaded
successfully. This is guaranteed during runtime s/r, since otherwise we
don't enable RPM, but not during system s/r.

Note that it's still unclear whether we need to enable/disable DC6
during system s/r, until that's clarified, keep the current behavior and
enable/disable DC6.

Also after this patch there is a race during system s/r where the
firmware may not be loaded yet, that's addressed in an upcoming patch.

v2-v3:
- unchanged
v4:
- rebased on latest drm-intel-nightly

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[imre: added code and note about checking if the firmware loaded ok,
 before enabling/disabling it]
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com

Avoids non-static functions since all the callers are in intel_rpm.c.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from commit message, since
 it's not relevant any more]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: make assert_csr_loaded static]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com

Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).

Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit too
much, but since the firmware loading task should completely fairly
quickly this won't be a real problem really.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-3-git-send-email-imre.deak@intel.com

Skl is fully dependent on dmc for going to low power state (dc5/dc6).
This requires a trigger from rpm. To ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference if firmware loading is
not completed.

So moved the intel_csr_ucode_init call after runtime pm enable.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
[imre: moved the call right after power domain init to avoid race with
 the console modesetting]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-2-git-send-email-imre.deak@intel.com

Have only one if ladder for platforms and only one range check for
size. Makes it easier to handle new platforms. Remove the use of
negative return values in char, which might underflow to be positive for
some negative error codes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-3-git-send-email-jani.nikula@intel.com

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-2-git-send-email-jani.nikula@intel.com

Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-1-git-send-email-jani.nikula@intel.com

No need to verify VMA belongs to GGTT since:

1. The function must return a normal VMA belonging to passed in VM.
2. There can only be one normal VMA for any VM.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447329595-17495-1-git-send-email-tvrtko.ursulin@linux.intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Minor fixup to d0669d00 ("drm/i915: Clean up LVDS register
handling") which intended to read lvds_reg just once at the
beginning of intel_lvds_init() and use that throughout the rest
of the function but accidentally missed one register readout.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20151107141244.AB7616E242@gabe.freedesktop.orgSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Reading the driver load/unload code leaves one confused as there's
an async_schedule() in the load, but not async_synchronize_full()
in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
async_schedule() into intel_fbdev.c as well so that it's next to the
async_synchronize_full(), which should make the relationship easier
to see.

Plus this way we won't schedule a nop function call when fbdev is
disabled. And we were passing a pointer to a static inline
function to async_schedule(), which seems rather dubious to me.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

We set up fbdev last during load, so doing the fbdev cleanup should be
first.

We weren't supposed to drop the init power during driver unload, but since
the fbdev teardown happened after intel_power_domains_fini() that could
have happened due in one of two ways. First it could have happened
during the modeset caused by normal fbdev cleanup. But in addition it
could have happened already via the intel_fbdev_initial_config() since
that is executed asynhronously, and the async_synchronize_full() was
done during fbdev cleanup, after intel_power_domains_fini(). All of
that got eliminated by
commit 292b990e ("drm/i915: Update power domains on readout.")
since we now drop the init power synchronously during driver load.

So there is no real bug wrt. the init power anymore, but still it seems
better to do the fbdev cleanup first, before we've potentially cleaned
up something else important.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

intel_runtime_pm_disable() takes an extra rpm reference which combined
with the one we leak from intel_display_set_init_power() leaves the
usage count at <original>+1 after the driver has been unloaded.
The original ref is dropped explicitly in intel_runtime_pm_enable().
So the next time we load the driver we can no longer do runtime PM ever.

This used to work, but
commit 292b990e ("drm/i915: Update power domains on readout.")
broke things by not dropping the init power domain during fbdev
teardown. Based on the comment in intel_power_domains_fini(), the
way it used to to work wasn't intentional. As in we weren't supposed
to drop the init power during driver unload. And since we no longer
do, we now leak an extra rpm reference.

So fix things by throwing intel_runtime_pm_disable() to the bin, so
that the only leaked reference comes from the init power domain.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Fixes: 292b990e ("drm/i915: Update power domains on readout.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Set up the DDI->PLL mapping on SKL also for MST links. Might help make
MST operational on SKL.

v2: Rebased due to KBL
    Improve the patch subject, Jesse provided the new one

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1439826380-18403-1-git-send-email-ville.syrjala@linux.intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=91791Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

ironlake_set_pll_cpu_edp() only gets called just before
ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on().

Also toss in a debug print into ironlake_edp_pll_off() to match the one
we have in ironlake_edp_pll_on().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-15-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>