The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().

In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
  again, which means the plane->fb pointer won't change, hence can't
  leak.
- Drivers using drm_atomic_helper_shutdown call the fbdev cleanup
  first, and that usually cleans up the fb through
  drm_remove_framebuffer, which does this correctly.
- Without fbdev the only framebuffers are from userspace, and those
  get cleaned up (again using drm_remove_framebuffer) befor the driver
  can even be unloaded.

But in i915 I've switched the cleanup sequence around so that the
_shutdown() calls happens after the drm_remove_framebuffer(), which is
how I discovered this issue.

v2: My analysis why the current code was ok for gpu reset and
suspend/resume was correct, but then I totally failed to realize that
we better keep this symmetric. Thanksfully CI noticed that for
balance, a refcounting bug must exist at 2 places if previously there
was no issue ...

v3: Don't be lazy and compute the plane_mask in
commit_duplicated_state properly too, instead of just using ~0U.

Cc: martin.peres@free.fr
Cc: chris@chris-wilson.co.uk
Acked-by: Dave Airlie <airlied@gmail.com> (v1)
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170715093106.19873-1-daniel.vetter@ffwll.ch

Supply a pm_domain and its ops for our mock GEM device so that
device runtime pm doesn't complain even though we only want to mark it
permanently active!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170718173028.31207-1-chris@chris-wilson.co.ukTested-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>

Workers on the i915->wq may rearm themselves so for completeness we need
to replace our flush_workqueue() with a call to drain_workqueue() before
unloading the device.

v2: Reinforce the drain_workqueue with an preceding rcu_barrier() as a
few of the tasks that need to be drained may first be armed by RCU.

References: https://bugs.freedesktop.org/show_bug.cgi?id=101627Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170718134124.14832-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

I've found a bios with an off-by-one at the other end. There's a pnp
reservation for 0xc5400000-0xc7fffffe and we want stolen in 0xc6000000
through 0xc8000000.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99872
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98683
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: NMartin Peres <martin.peres@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170719100043.30851-1-daniel.vetter@ffwll.ch

ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.

This fixes the following compiler warning:

drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0 or 1.

Changes since v1:
- Rebase, was missing the changes to the macro names.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: d555cb58 ("drm/i915/skl+: use linetime latency if ddb size is not available")
Cc: "Mahesh Kumar" <mahesh1.kumar@intel.com>
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Cc: David Binderman <dcb314@hotmail.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170717120230.2023-1-maarten.lankhorst@linux.intel.comReviewed-by: NMahesh Kumar <mahesh1.kumar@intel.com>

This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170718142536.2306-1-paul.kocialkowski@linux.intel.com

Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.

Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.

Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.

Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com

The current code uses in some instances enum transcoder for PCH
transcoders and enum pipe in others. This is error prone and clang
raises warnings like this:

drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
  from enumeration type 'enum pipe' to different enumeration type
  'enum transcoder' [-Wenum-conversion]
    intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);

Consistently use the type enum pipe for PCH transcoders.
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170717181403.57324-1-mka@chromium.org

Fix the sizeof(ptr) vs. sizeof(*ptr) typo.

Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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/20170714151242.517-2-imre.deak@intel.com

1acfc104 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.

Fixes: 1acfc104 ("drm/i915: Enable rcu-only context lookups")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-1-imre.deak@intel.com

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

We could probably hit this already with our current async fbdev init,
but it's much easier to hit this with the new deferred fbdev setup
that I'm working on polishing.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-2-daniel.vetter@ffwll.ch

With deferred fbdev setup we always need to forward hotplug events,
even if fbdev isn't fully set up yet. Otherwise the deferred setup
will neer happen.

Originally this check was added in

commit c45eb4fe (tag: drm-intel-next-fixes-2016-08-05)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 13 18:34:45 2016 +0100

    drm/i915/fbdev: Check for the framebuffer before use

But the specific case of the hotplug function blowing up was fixed in

commit 50c3dc97
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 27 17:19:22 2014 +0200

    drm/fb-helper: Fix hpd vs. initial config races

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-1-daniel.vetter@ffwll.ch

use same cpp value in different phase of plane WM caluclation.
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-7-mahesh1.kumar@intel.com

height of plane was require to swap width/height in case of 90/270
rotation. Now src structure contains already swapped values, So we
don't have to calculate height of the plane.
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-6-mahesh1.kumar@intel.com

This patch introduce addition wrapper for fixed point 16.16 operations.
Which will be used by later patches to avoid direct member variables
access of fixed_16_16_t structure.

add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t
add_fixed16_u32 : takes fixed_16_16_t & u32 variable & returns fixed_16_16_t
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-5-mahesh1.kumar@intel.com

This patch make naming of fixed-point wrappers consistent
operation_<any_post_operation>_<1st operand>_<2nd operand>
also shorten the name for fixed_16_16 to fixed16

s/u32_to_fixed_16_16/u32_to_fixed16
s/fixed_16_16_to_u32/fixed16_to_u32
s/fixed_16_16_to_u32_round_up/fixed16_to_u32_round_up
s/min_fixed_16_16/min_fixed16
s/max_fixed_16_16/max_fixed16
s/mul_u32_fixed_16_16/mul_u32_fixed16
s/fixed_16_16_div/div_fixed16

Changes Since V1:
 - Split the patch in more logical patches (Maarten)
Changes Since V2:
 - Rebase
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-4-mahesh1.kumar@intel.com

This patch combines fixed_16_16_div & fixed_16_16_div_u64 wrappers.
And new fixed_16_16_div wrapper always performs division operation in
u64 internally, to avoid any data loss which was happening in earlier
version of wrapper.
earlier wrapper was converting u32 to fixed16 in 32 bit so we were
losing 16-MSB data.
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-3-mahesh1.kumar@intel.com
[mlankhorst: Fix typo in commit message.]

This patch creates a new function for clamping u64 to fixed16.
And make use of this function in other fixed16 wrappers.
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705143154.32132-2-mahesh1.kumar@intel.com

Paulo had noticed that inside cnl_ddi_vswing_program
the case was handling voltage but with no indication
of type where a missing type could also take us to that
path. So my first attempt was to add a message to
let clear who trigger that path.

However DK had a better idea that is to handle the
missed type sooner before it might take to that path.
So this v2 here uses his approach.

v2: Handle missed type sooner.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170710205852.28352-1-rodrigo.vivi@intel.com

Resync with the main drm-next pull request for 4.13. What we really
need is to fully resync with pending drm-misc, but that's not yet
possible due to the still ongoing merge window.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This is a follow-up after enabling DC states with
commit: "drm/i915/DMC/CNL: Load DMC on CNL".

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499373908-26761-1-git-send-email-rodrigo.vivi@intel.com

Commit 9a148a96 ("drm/i915/debugfs: add dp mst info") adds support
for DP-MST to intel_connector_info, but forgot to remove the early
return for DP-MST.

Remove it, and print out MST connectors directly.

Fixes: 9a148a96 ("drm/i915/debugfs: add dp mst info")
Cc: <stable@vger.kernel.org> # v4.11+
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626083349.24389-1-maarten.lankhorst@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

PLLs are the source clocks for the DDIs so in order
to determine the ddi clock we need to check the PLL
configuration.

v2: Mika pointed out that 24 was hardcoded while it
    should consider ref clock that can be either 24KHz
    or 19.2KHz on CNL.
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499374321-31152-1-git-send-email-rodrigo.vivi@intel.com

Apparently no change on RPS stuff from previous platforms.

v2: Merging to rps related patches in one and also adding
    missed cases.

Cc: David Weinehall <david.weinehall@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499373673-25066-1-git-send-email-rodrigo.vivi@intel.com

No change on render context size is required for Gen10.

So this patch doesn't change the default behaviour,
but only avoid the missing_case message.

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Link: http://patchwork.freedesktop.org/patch/msgid/1499375184-5725-1-git-send-email-rodrigo.vivi@intel.com

Cannon Lake's VBT that is currently available for B0 stepping
states that port D uses alternate pin 3 messing up with the
default pin-port mapping table. Using that information we cannot
get HDMI working properly. So for now we don't relly on VBT for
this information.

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NClinton Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499375295-6454-1-git-send-email-rodrigo.vivi@intel.com

The ppgtt should be get directly from i915_address_space *vm instead of
vma->vm.

v2:
- add one more fix for bxt. (Chris)

Fixes: 4a234c5f ("drm/i915: pass the vma to insert_entries")
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=101713Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com> v1
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499421059-18262-1-git-send-email-chuanxiao.dong@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Cannonlake has same color setup as Geminilake.
Legacy color load luts doesn't work anymore on Cannonlake+.

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NClinton Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499374873-2454-1-git-send-email-rodrigo.vivi@intel.com

By spec there is no change on force wake registers
for Cannonlake. Let's reuse gen9 one.

v2: Adding missing case for the write part. (Tvrtko)
v3: Rebase on recent tree.
v4: Make it for gen9+ instead adding gen10 only. (by Joonas).

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499302831-17773-1-git-send-email-rodrigo.vivi@intel.com

So don't forget to reserve its stolen memory bits.

v2: Add ack and remove "TODO" from commit message.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Link: http://patchwork.freedesktop.org/patch/msgid/1499302845-17856-1-git-send-email-rodrigo.vivi@intel.com

The comments match an earlier version of the patch, fix them to match
the current state.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com

So far in an attempt to make sure all power wells get disabled during
display uninitialization the driver removed any secondary request bits
(BIOS, KVMR, DEBUG) that were set for a given power well. The known
source for these requests was DMC's request on power well 1 and the misc
IO power well. Since DMC is inactive (DC states are disabled) at the
point we disable these power wells, there shouldn't be any reason to
leave them on. However there are two problems with the above
assumption: Bspec requires that the misc IO power well stays enabled
(without providing a reason) and there can be KVMR requests that we
can't remove anyway (the KVMR request register is R/O). Atm, a KVMR
request can trigger a timeout WARN when trying to disable power wells.

To make the code aligned to Bspec and to get rid of the KVMR WARN, don't
try to remove the secondary requests, only detect them and stop polling
for the power well disabled state when any one is set.

Also add a comment about the timeout values required by Bspec when
enabling power wells and the fact that waiting for them to get disabled
is not required by Bspec.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-5-git-send-email-imre.deak@intel.com

What we want to assert based on the conditions required by Bspec is that
power well 2 is disabled, so no need to check for other power wells.
In addition we can only check if the driver's request is removed, the
actual state depends on whether the other request bits are set or not
(BIOS, KVMR, DEBUG). So check only the driver's request bit.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-4-git-send-email-imre.deak@intel.com

Bspec requires leaving the misc IO power well enabled during display
uninit, so align the code accordingly.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-3-git-send-email-imre.deak@intel.com

Bspec requires a 10 us delay after disabling power well 1 and - if not
toggled on-demand - the AUX IO power wells during display uninit.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-2-git-send-email-imre.deak@intel.com

Currently, we move all unreferenced contexts to an RCU free list and
then onto a worker for eventual reaping. To compensate against this
growing into a long list with frequent allocations starving the system
of available memory, before we allocate a new context we reap all the
stale contexts. This puts all the cost of destroying the context into
the next allocator, which is presumably more sensitive to syscall
latency and unfair. We can limit the number of contexts being freed by
the new allocator to both keep the list trimmed and to allow the
allocator to be reasonably fast.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-4-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Before we create a new context, we try and reap all the stale contexts
(i.e. those that are freed but waiting for a worker to come and return
their allocations to the system). Before we do this, we retire all
requests so that we clear any inflight no longer used contexts (who are
only being kept alived by those inflght requests). However, any context
that is finally unreferenced by this retirement is put onto an RCU list
and not available for immediately reaping, we stall for no immediate
benefit.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-3-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

We need to reap the stale contexts for all new contexts, be they created
by user in i915_gem_context_ioctl or from opening a new file in
i915_gem_context_open. Both paths may be called very frequently
accumulating many stale contexts before any worker has a chance to run
and free their memory.

Fixes: 1acfc104 ("drm/i915: Enable rcu-only context lookups")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-2-chris@chris-wilson.co.uk

Avoid any pointer dereference in inspecting a potential PTR_ERR by
checking for the error pointer before checking for an invalid context.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-1-chris@chris-wilson.co.uk