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

In a IGD passthrough environment, the real ISA bridge may doesn't exist.
then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
LPT_H,then errors occur when i915 runs on LPT_LP machines with igd
passthrough.

This patch set pch_id for HSW/BDW according to IGD type and isn't fully
correct. But it solves such issue on HSW/BDW ult/ulx machines.
QA CI system is blocked by this issue for a long time, it's better that
we could merge it to unblock QA CI system.

We know the root cause is in device model of virtual passthrough, and
will resolve it in the future with several parts cooperation in kernel,
qemu and xen.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1497496305-5364-1-git-send-email-xiong.y.zhang@intel.com

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
   4028	   1088	      0	   5116	   13fc	drivers/gpu/drm/i915/i915_sysfs.o

File size After adding 'const':
   text	   data	    bss	    dec	    hex	filename
   4196	    928	      0	   5124	   1404	drivers/gpu/drm/i915/i915_sysfs.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/13b5c875e677c10e6257be4fac31b2b6c77a494f.1499079914.git.arvind.yadav.cs@gmail.com

This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be set to 800ms which is 300msecs more than
the minimum value specified in the eDP spec. So a quirk is
implemented for that specific PCI device.

v4:
* Add Bugzilla links for FDO bugs in the commit message (Ville, Jani)
v3:
* Change some comments, specify the delay as 800 * 10 (Ville)
v2:
* Change the function and variable names to from PPS_T12_
to _T12 since it is a T12 delay (Clint)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101154
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101167
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101515
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NClinton Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498840428-23176-1-git-send-email-manasi.d.navare@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

GEN9+ Interlace fetch mode doesn't support pipe/plane scaling,
This patch adds check to fail the flip if pipe/plane scaling is
requested in Interlace fetch mode.

Changes since V1:
 - move check to skl_update_scaler (ville)
 - mode to adjusted_mode (ville)
 - combine pipe/plane scaling check
Changes since V2:
 - Indentation fix
 - Added TODO to handle/reject NV12 with interlace mode
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630121100.20159-3-mahesh1.kumar@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

In Gen9 platform Interlaced fetch mode doesn't support following plane
configuration:
 - Y/Yf tiling
 - 90/270 rotation
 - YUV420 hybrid planar source pixel formats.

This patch adds check to fail the flip if any of the above configuration
is requested.

Changes since V1:
 - handle checks in intel_plane_atomic_check_with_state (ville)
 - takeout plane scaler checks combile with pipe scaler in next patch
Changes since V2:
 - No need to check for NV12 as it need scaling, so it will be rejected
   by scaling check (ville)
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630121100.20159-2-mahesh1.kumar@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90238Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Commit fabef825 ("drm/i915: Drop struct_mutex around frontbuffer
flushes") adds a dependency to ifbdev->vma when flushing the framebufer,
but the checks are only against the existence of the ifbdev->fb and not
against ifbdev->vma. This leaves a window of opportunity where we may
try to operate on the fbdev prior to it being probed (thanks to
asynchronous booting).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534
Fixes: fabef825 ("drm/i915: Drop struct_mutex around frontbuffer flushes")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622160211.783-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org

When iterating the list of contexts to free, we need to use a safe
iterator as we are freeing the link as we go. Pass an extra thick brown
paper bag.

Fixes: 5f09a9c8 ("drm/i915: Allow contexts to be unreferenced locklessly")
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>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630230517.1938-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>

When reading all debugfs files on a system with DP-MST the kernel panics
on a null pointer dereference because intel_dp is null for a DP-MST
connector. Detect this case and skip those connectors.

Also fix the write for the DP compliance file in the same way.

Changes since v1:
- Fix i915_displayport_test_active_write too. (DK)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626081835.24251-1-maarten.lankhorst@linux.intel.com

OA buffer initialization involves access to HW registers to set
the OA base, head and tail. Ensure device is awake while setting
these. With this, all oa.ops are covered under RPM and forcewake
wakelock.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498585181-23048-1-git-send-email-sagar.a.kamble@intel.com
Fixes: d7965152 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Cc: <stable@vger.kernel.org> # v4.11+

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

The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
and hence the CURSOR_COEFF_MASK should be (0x3F << 0)

Fixes: 04416108 ("drm/i915/cnl: Add registers related to voltage
swing sequences.")
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498785241-21138-1-git-send-email-manasi.d.navare@intel.com

During the review of Coffee Lake workarounds Mika pointed out
that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
should be removed from CFL and with that I should carry the rv-b.

However when doing the v2 I removed another Workaround that should
remain because although not mentioned by spec the history of hangs
around it advocates on its favor.

On some follow-up patches I continued operating on the wrong
workardound, but Ville noticed that, so here is the fix for the
current CFL code that is upstream already.

Fixes: 46c26662 ("drm/i915/cfl: Introduce Coffee Lake workarounds.")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

When computing a hash for looking up relocation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
halve it until the allocation succeeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting a value by the width of the operand is
undefined, so limit the smallest hash table we use to order 1.

v2: Keep the retry allocation flag for the final pass

Fixes: 4ff4b44c ("drm/i915: Store a direct lookup from object handle to vma")
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/20170629150425.27508-1-chris@chris-wilson.co.uk

There are still cases on these platforms where an attempt is made to
configure the CDCLK while the power domain is off, like when coming back
from a suspend.  So the workaround below is still needed.

This effectively reverts commit 63ff3044 ("drm/i915: Nuke the
VLV/CHV PFI programming power domain workaround").

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Once a client has requested a waitboost, we keep that waitboost active
until all clients are no longer waiting. This is because we don't
distinguish which waiter deserves the boost. However, with the advent of
fence signaling, the signaler threads appear as waiters to the RPS
interrupt handler. So instead of using a single boolean to track when to
keep the waitboost active, use a counter of all outstanding waitboosted
requests.

At this point, I have removed all vestiges of the rate limiting on
clients. Whilst this means that compositors should remain more fluid,
it also means that boosts are more prevalent. See commit b29c19b6
("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion
on the pros and cons of both approaches.

A drawback of this implementation is that it requires constant request
submission to keep the waitboost trimmed (as it is now cancelled when the
request is completed). This will be fine for a busy system, but near
idle the boosts may be kept for longer than desired (effectively tens of
vblanks worstcase) and there is a reliance on rc6 instead.

v2: Remove defunct rps.client_lock
Reported-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628123548.9236-1-chris@chris-wilson.co.uk

i915_gem_suspend() is called from all of our finalization paths
(suspend, hibernate, unload). i915_gem_drain_freed_objects() adds an
arbitrary delay as it uses an rcu_barrier() to ensure that there are no
more freed objects in flight, and this delay causes a large amount of
variability in suspend timings. For S3 suspend, we do not need to free
pages as doing so does not impact at all upon the system in its
suspended state, unlike S4 hibernation where we do want the hibernation
image to be as small as possible. Therefore we can forgo waiting inside
i915_gem_suspend(), so long as we ensure that we do cleanup before
unload (see i915_gem_load_cleanup()) and prefer to reap our objects
prior to hibernation (see i915_gem_freeze()).

Removing the rcu_barrier() from i915_gem_suspend() improves S3 latency
by about 30ms on Skylake (ymmv).
Reported-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627173731.11566-1-chris@chris-wilson.co.ukTested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>

Due to the slight asynchronicity in handling the execlists interrupts
(i.e. we defer the work to a handler that may consume more than one
interrupt event), when the engine is idle we may still have an irq
tasklet queued (especially when it has been deferred to a ksoftirqd).
At the beginning of the tasklet, we assert that we do hold a device
wakeref for the access we are about to perform. This assumes that when
we idle and release the GT wakeref, all execlists work has been
completed (since the elsp tracking says the hw is idle). However, there
may still be a tasklet queued, so as we mark the engine idle, also
cancel any pending tasklet.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627152510.28589-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

'dma_buf_vmap' returns NULL on error, not an error pointer.

Fixes: 6cca22ed ("drm/i915: Add some mock tests for dmabuf interop")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627053854.21152-1-christophe.jaillet@wanadoo.frReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Smatch spots:

drivers/gpu/drm/i915/selftests/intel_hangcheck.c:669 igt_render_engine_reset_fallback() error: double unlock 'mutex:&i915->drm.struct_mutex'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170623131907.24236-1-chris@chris-wilson.co.ukReviewed-by: NMichel Thierry <michel.thierry@intel.com>

We have pretty clear evidence that MSIs are getting lost on g4x and
somehow the interrupt logic doesn't seem to recover from that state
even if we try hard to clear the IIR.

Disabling IER around the normal IIR clearing in the irq handler isn't
sufficient to avoid this, so the problem really seems to be further
up the interrupt chain. This should guarantee that there's always
an edge if any IIR bits are set after the interrupt handler is done,
which should normally guarantee that the CPU interrupt is generated.
That approach seems to work perfectly on VLV/CHV, but apparently
not on g4x.

MSI is documented to be broken on 965gm at least. The chipset spec
says MSI is defeatured because interrupts can be delayed or lost,
which fits well with what we're seeing on g4x. Previously we've
already disabled GMBUS interrupts on g4x because somehow GMBUS
manages to raise legacy interrupts even when MSI is enabled.

Since there's such widespread MSI breakahge all over in the pre-gen5
land let's just give up on MSI on these platforms.

Seqno reporting might be negatively affected by this since the legcy
interrupts aren't guaranteed to be ordered with the seqno writes,
whereas MSI interrupts may be? But an occasioanlly missed seqno
seems like a small price to pay for generally working interrupts.

Cc: stable@vger.kernel.org
Cc: Diego Viola <diego.viola@gmail.com>
Tested-by: NDiego Viola <diego.viola@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now the VBT.seq->t11_t12 value adds 100ms to both Gen9_LP
as well as non Gen9_LP cases so no need to special case
and do -1 during HW readout and +1 during pp_div write
for Gen9_LP/CNP case.
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Suggested-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498504905-21067-2-git-send-email-manasi.d.navare@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

When we read the VBT t11_t12 value for panel power cycle delay,
it is a zero based value so we need to 100ms to that. And then it
needs to be multiplied by 10 to store it in 100usecs unit same as
SW VBT.

v3:
* Add it as part of series
v2:
* Change the VBT value instead of HW readout and pp div (Ville Syrjala)
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498504905-21067-1-git-send-email-manasi.d.navare@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset. As modesetting doesn't
allow its locks to be broken and restarted, or for its *own* reset
mechanism to take over the display, we have to do something very
evil instead. If we detect that we are stuck waiting to prepare the
display reset (by using a very simple timeout), resort to cancelling all
in-flight requests and throwing the user data into /dev/null, which is
marginally better than the driver locking up and keeping that data to
itself.

This is not a fix; this is just a workaround that unbreaks machines
until we can resolve the deadlock in a way that doesn't lose data!

v2: Move the retirement from set-wegded to the i915_reset() error path,
after which we no longer any delayed worker cleanup for
i915_handle_error()
v3: C abuse for syntactic sugar
v4: Cover all waits with the timeout to catch more driver breakage

References: https://bugs.freedesktop.org/show_bug.cgi?id=99093Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622105625.16952-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Signed-off-by: NPuthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-4-puthik@chromium.org

Add heuristic to decide that AUX or PWM pin should use for
backlight brightness adjustment and modify i915 param description
to have auto, force disable, and force enable.

The heuristic to determine that using AUX pin is better than using
PWM pin is that the panel support any of the feature list here.
- Regional backlight brightness adjustment
- Backlight PWM frequency set
- More than 8 bits resolution of brightness level
- Backlight enablement via AUX and not by BL_ENABLE pin
Signed-off-by: NPuthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-3-puthik@chromium.org

Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.
Signed-off-by: NPuthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-2-puthik@chromium.org

Make the code less confusiong by always using the top 9 bits of the
LPC bridge device ID to detect the PCH type. We need to add a bit of
new code for WPT, and we need to adjust the KBP ID as well. All the
other pre-CNP IDs are fine as is.

The virtualization cases I think are fine. These P2X and P3X IDs
actually just look like the old PIIX4 and PIIX3 IDs to me. Not sure
why they're not called PIIX3/4 though. The qemu one has a comment
saying the full ID is 0x2918 which is fine with 9 bits.

v2: Keep the CNP ID as 0xa300 (DK)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621174944.23306-1-ville.syrjala@linux.intel.com

Write the '!(SNB||IVB)' checks in the CPT/PPT detections
as '!SNB && !IVB' to make it less messy looking, and clear out
some useless parens the from the virtualization PCH detection case.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

For our purposes PPT is equivalent to CPT, and WPT is equivalent to
LPT. Document that fact.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Fix a typo in the PCH type debug message.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

We have a few cases comparing pch_type directly. Let's just replace
them with HAS_PCH_CPT() since CPT/PPT is what they're looking for.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

The vma already contains most of the information we need for insertion.
But also in preparation for supporting huge gtt pages, it would be
useful to know the details of the vma, such that we can we can easily
determine the page sizes we are allowed to use when inserting into the
48b PPGTT.  This is especially true for 64K where we can't just
arbitrarily use it, since we require aligning/padding the vm space to
2M, which sometimes we can't enforce in the upper levels.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622095836.6800-1-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

commit 2889caa9 ("drm/i915: Eliminate lots of iterations over the
execobjects array") jiggled around the error handling and replace a test
that we cleaned up properly after ourselves with an assertion. That
assertion failed because in the release function (moments after the
assertion) we were indeed forgetting to mark the vma as cleared. The
consequence was when testing an invalid relocation address, we would try
to release the vma twice (following the couple of attempts to verify the
address) and on the second release notice that the first release was
incomplete.

Testcase: igt/gem_reloc_overflow/invalid-address
Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array")
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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622104722.2583-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Highly unlikely, but if the stop_machine() did suspend the tasklet, we
want to make sure that when it wakes it finds there is nothing to do.
Otherwise, it will loudly complain that the ELSP port tracking no longer
matches the hardware, and we will be mightly confused.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621124804.4529-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

As we walk the obj->vma_list in per_file_stats(), we need to hold
struct_mutex to prevent alteration of that list.

Fixes: 1d2ac403 ("drm: Protect dev->filelist with its own mutex")
Fixes: c84455b4 ("drm/i915: Move debug only per-request pid tracking from request to ctx")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101460Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170617115744.4452-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

In looking at a use-after-free on Baytrail, it looks like the VMA's
activity tracking is suspect. Add some asserts to catch freeing the VMA
before we have decoupled all of its i915_gem_active trackers.

References: https://bugs.freedesktop.org/show_bug.cgi?id=101511Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-3-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>

Since we may track unfenced access (GPU access to the vma that
explicitly requires no fence), vma->last_fence may be set without any
attached fence (vma->fence) and so will not be flushed when we call
i915_vma_put_fence(). Since we stopped doing a full retire of the
activity trackers for unbind, we need to explicitly retire each tracker.

Fixes: b0decaf7 ("drm/i915: Track active vma requests")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>

kbuild test robot found a build failure when building with thin
archives:

http://marc.info/?l=linux-kbuild&m=149802285009737&w=2Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621063420.24913-1-npiggin@gmail.com

i915_vma_move_to_active() takes the execobject flags and not a boolean!
Instead of passing EXEC_OBJECT_WRITE we passed true [i.e.
EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the
vma->last_fence access and since we forgot to clear that on unbinding,
we caused a use-after-free.

[  321.263854] BUG: KASAN: use-after-free in i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264001] Read of size 8 at addr ffff880100fc67d8 by task gem_exec_reloc/2868

[  321.264181] CPU: 0 PID: 2868 Comm: gem_exec_reloc Not tainted 4.12.0-rc6-CI-Custom_2759+ #1
[  321.264195] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F6 02/17/2015
[  321.264208] Call Trace:
[  321.264234]  dump_stack+0x67/0x99
[  321.264260]  print_address_description+0x77/0x290
[  321.264437]  ? i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264459]  kasan_report+0x269/0x350
[  321.264487]  __asan_report_load8_noabort+0x14/0x20
[  321.264660]  i915_gem_request_retire+0x1728/0x1740 [i915]
[  321.264841]  ? intel_ring_context_pin+0x131/0x690 [i915]
[  321.265021]  i915_gem_request_alloc+0x2c6/0x1220 [i915]
[  321.265044]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  321.265226]  i915_gem_do_execbuffer+0xac0/0x2a20 [i915]
[  321.265250]  ? __lock_acquire+0xceb/0x5450
[  321.265269]  ? entry_SYSCALL_64_fastpath+0x1c/0xb1
[  321.265291]  ? kvmalloc_node+0x6b/0x80
[  321.265310]  ? kvmalloc_node+0x6b/0x80
[  321.265489]  ? eb_relocate_slow+0xbe0/0xbe0 [i915]
[  321.265520]  ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[  321.265549]  ? debug_check_no_locks_freed+0x280/0x280
[  321.265591]  ? __might_fault+0xc6/0x1b0
[  321.265782]  i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[  321.265815]  drm_ioctl+0x4ba/0xaa0
[  321.265986]  ? i915_gem_execbuffer+0xde0/0xde0 [i915]
[  321.266017]  ? drm_getunique+0x270/0x270
[  321.266068]  do_vfs_ioctl+0x17f/0xfa0
[  321.266091]  ? __fget+0x1ba/0x330
[  321.266112]  ? lock_acquire+0x390/0x390
[  321.266133]  ? ioctl_preallocate+0x1d0/0x1d0
[  321.266164]  ? __fget+0x1db/0x330
[  321.266194]  ? __fget_light+0x79/0x1f0
[  321.266219]  SyS_ioctl+0x3c/0x70
[  321.266247]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  321.266265] RIP: 0033:0x7fcede207357
[  321.266279] RSP: 002b:00007ffef0effe58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  321.266307] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fcede207357
[  321.266321] RDX: 00007ffef0effef0 RSI: 0000000040406469 RDI: 0000000000000004
[  321.266335] RBP: ffffffff812097c6 R08: 0000000000000008 R09: 0000000000000000
[  321.266349] R10: 0000000000000008 R11: 0000000000000246 R12: ffff880116bcff98
[  321.266363] R13: ffffffff81cb7cb3 R14: ffff880116bcff70 R15: 0000000000000000
[  321.266385]  ? __this_cpu_preempt_check+0x13/0x20
[  321.266406]  ? trace_hardirqs_off_caller+0x1d6/0x2c0

[  321.266487] Allocated by task 2868:
[  321.266568]  save_stack_trace+0x16/0x20
[  321.266586]  kasan_kmalloc+0xee/0x180
[  321.266602]  kasan_slab_alloc+0x12/0x20
[  321.266620]  kmem_cache_alloc+0xc7/0x2e0
[  321.266795]  i915_vma_instance+0x28c/0x1540 [i915]
[  321.266964]  eb_lookup_vmas+0x5a7/0x2250 [i915]
[  321.267130]  i915_gem_do_execbuffer+0x69a/0x2a20 [i915]
[  321.267296]  i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[  321.267315]  drm_ioctl+0x4ba/0xaa0
[  321.267333]  do_vfs_ioctl+0x17f/0xfa0
[  321.267350]  SyS_ioctl+0x3c/0x70
[  321.267369]  entry_SYSCALL_64_fastpath+0x1c/0xb1

[  321.267428] Freed by task 177:
[  321.267502]  save_stack_trace+0x16/0x20
[  321.267521]  kasan_slab_free+0xad/0x180
[  321.267539]  kmem_cache_free+0xc5/0x340
[  321.267710]  i915_vma_unbind+0x666/0x10a0 [i915]
[  321.267880]  i915_vma_close+0x23a/0x2f0 [i915]
[  321.268048]  __i915_gem_free_objects+0x17d/0xc70 [i915]
[  321.268215]  __i915_gem_free_work+0x49/0x70 [i915]
[  321.268234]  process_one_work+0x66f/0x1410
[  321.268252]  worker_thread+0xe1/0xe90
[  321.268269]  kthread+0x304/0x410
[  321.268285]  ret_from_fork+0x27/0x40

[  321.268346] The buggy address belongs to the object at ffff880100fc6640
                which belongs to the cache i915_vma of size 656
[  321.268550] The buggy address is located 408 bytes inside of
                656-byte region [ffff880100fc6640, ffff880100fc68d0)
[  321.268741] The buggy address belongs to the page:
[  321.268837] page:ffffea000403f000 count:1 mapcount:0 mapping:          (null) index:0xffff880100fc5980 compound_mapcount: 0
[  321.269045] flags: 0x8000000000008100(slab|head)
[  321.269147] raw: 8000000000008100 0000000000000000 ffff880100fc5980 00000001001e001d
[  321.269312] raw: ffffea0004038e20 ffff880116b46240 ffff88011646c640 0000000000000000
[  321.269484] page dumped because: kasan: bad access detected

[  321.269665] Memory state around the buggy address:
[  321.269778]  ffff880100fc6680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.269949]  ffff880100fc6700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270115] >ffff880100fc6780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270279]                                                     ^
[  321.270410]  ffff880100fc6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  321.270576]  ffff880100fc6880: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
[  321.270740] ==================================================================
[  321.270903] Disabling lock debugging due to kernel taint

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101511
Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-2-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>