Use tegra124_(primary|overlay)_formats for Tegra124, otherwise the count
specified in the Tegra124 SoC info structure will be different from the
array size and cause a crash.

Fixes: 511c7023 ("drm/tegra: dc: Support more formats")
Signed-off-by: NStefan Agner <stefan@agner.ch>
Acked-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Since commit 846c7dfc ("drm/atomic: Try to preserve the crtc enabled
state in drm_atomic_remove_fb, v2."), removing the last framebuffer will
no longer disable the corresponding pipeline, which causes the KMS core
to complain about leaked connectors on driver unbind.

Fix this by calling drm_atomic_helper_shutdown() on driver unbind, which
will cause all display pipelines to be shut down and therefore drop the
extra references on the connectors.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The regulator is controlled as part of runtime PM, so it should not be
additionally disabled from the ->exit() callback.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Detaching from an IOMMU group multiple times can lead to a crash. This
could potentially be fixed in the IOMMU driver, but it's easy to avoid
the subsequent detach operations in this driver, so do that as well.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Keep old 'dependent' state of unaffected planes, this way new state takes
into account current state of unaffected planes.

Fixes: ebae8d07 ("drm/tegra: dc: Implement legacy blending")
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The opaque/alpha format conversion code is currently only looking at
XRGB formats because they have an equivalent ARGB format. The opaque
format for RGB565 is RGB565 itself, much like the YUV formats map to
themselves.
Reported-by: NDmitry Osipenko <digetx@gmail.com>
Fixes: ebae8d07 ("drm/tegra: dc: Implement legacy blending")
Signed-off-by: NThierry Reding <treding@nvidia.com>

This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Update VBT defs to reflect revision 216. While at it, default the
expected child device struct size to sizeof the size rather than a
hardcoded value.

v2: Fix bit order (David)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180118153310.32437-1-jani.nikula@intel.com
(cherry picked from commit c4fb60b9)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If the table result is out of bounds on the array map
there is something really wrong with VBT pin so we don't
return that vbt_pin, but only return 0 instead.

This basically reverts commit 'a8e6f388 ("drm/i915/cnp:
Ignore VBT request for know invalid DDC pin.")'

Also this properly fixes commit 9c3b2689 ("drm/i915/cnl:
Map VBT DDC Pin to BSpec DDC Pin.")

v2: Do in a way that we don't break other platforms. (Jani)

v3: Keep debug message (Jani)

v4: Don't mess with 0 mapping was noticed by Jani and
    addressed with a simple solution suggested by Lucas
    that makes this even simpler.

Fixes: a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")
Fixes: 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Suggested-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com
(cherry picked from commit 3393ce1e)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Let's ignore VBT request if the pin is clearly wrong.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.comReviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
(cherry picked from commit a8e6f388)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.

If the offset ends up outside of the command length, reject the command.

Fixes: 351e3db2 ("drm/i915: Implement command buffer parsing logic")
Signed-off-by: NMichal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-2-chris@chris-wilson.co.uk
(cherry picked from commit 3aec7f87)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.

In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as MI_STORE_REGISTER_MEM. When trying to check
such command, the find_reg would dereference NULL pointer.

Now it will just return NULL meaning that the register was not found and the
command will be rejected.

Fixes: 76ff480e ("drm/i915/cmdparser: Use binary search for faster register lookup")
Signed-off-by: NMichal Srb <msrb@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-1-chris@chris-wilson.co.uk
register lookup")
(cherry picked from commit 2f265fad)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.

Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)

This issue is similar to
commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.

v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.4+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
(cherry picked from commit e76019a8)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

For KVMGT, the guest opregion, which is handled by VFIO, is actually a
piece of guest memory which won't be accessed by devices. So, its mfn
shouldn't be obtained through VFIO interface. This patch uses KVM r/w
interface to access the data in guest opregion.

Fix the guest opregion accessing issue when host "intel_iommu=on".

v3:
- Remove mapped flag for KVM/VFIO usage, as it's useless for KVM.

v2:
- Set the gpa correctly when invoking KVM r/w operations. (Zhenyu)
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>
Cc: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest
is emulated. But the vgpu_aperture_rw() function take wrong offset when
do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture.
This mistake cause GPU command in guest get lost and so the seqno is not
updated in engine HWSP.

This patch fix this, and it also move the emulation code to kvmgt.
Because only vfio need to emulate it. Put aperture rw to MMIO emulation
path breaks assumptions in xengt.

v2: Remove PAGE_ALIGN for size (zhenyu)

Fixes: f090a00d ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach")
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Only reset vgpu execlist state of the exact engine which gets reset
request from VM. After read context status from HWSP enabled, KMD will use
the saved CSB read pointer but not always read from MMIO. When one engine
reset happen, only the read pointer of this engine will be reset, in GVT-g
host side also need to align with this policy, otherwise VM may get wrong
CSB status after one engine reset compeleted.

v2: Split refine and fix patch, code refine(Zhenyu)
v3: Move active flag of vgpu scheduler into sched_data(Zhenyu)

Cc: Fred Gao <fred.gao@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Using per engine ops will be more flexible, here refine sub-ops(init,
clean) as per engine operation align with reset operation. This change also
will be used in next fix patch for VM engine reset.

Cc: Fred Gao <fred.gao@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The CGCG feature on Stoney is causing GFX related
issues such as freezes and blank outs.
Signed-off-by: NShirish S <shirish.s@amd.com>
Reviewed-by: NArindam Nath <arindam.nath@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The Rockchip LVDS driver fails to build after commit 23c35f48
("pinctrl: remove include file from <linux/device.h>") because it relies
on the pinctrl/consumer.h and pinctrl/devinfo.h being pulled in by the
device.h header implicitly.

Include these headers explicitly to avoid the build failure.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gcc thinks that interpreting a multiplication result as a bool
is confusing:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context]

Adding a temporary variable to contain the divisor helps make
it clear what is going on and avoids that warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: NLuis de Bethencourt <luisbg@kernel.org>
Reviewed-by: NKarol Herbst <kherbst@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This adds the NvPmEnableGating config option to nouveau, which can be
used to enable or disable clockgating for supported chipsets. Enabling
can be done by passing

	config=NvPmEnableGating=1

To nouveau. If your chipset supports it, you'll see a message in your
kernel log indicating that clockgating is enabled. Since clockgating has
only had limited testing thus far, we leave this option disabled by
default for now.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating.  The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before taking affect. As with the previous series, this
results in another noticeable drop in power consumption and is
programmed in the same manner.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Same as the previous patch, but for Kepler2 now
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more power hungry then they need to be, so the nvidia driver
writes it's own more optimized set of BLCG settings before enabling
CG_CTRL. This adds support for programming the optimized BLCG values
during engine/subdev init, which enables rather significant power
savings.

This introduces the nvkm_therm_clkgate_init() helper, which we use to
program the optimized BLCG settings before enabling clockgating with
nvkm_therm_clkgate_enable.

As well, this commit shares a lot more code with Fermi since BLCG is
mostly the same there as far as we can tell. In the future, it's likely
we'll reformat the clkgate_packs for kepler1 so that they share a list
of mmio packs with Fermi.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).

This introduces two therm helpers for controlling basic clockgating:
	nvkm_therm_clkgate_enable() - enables clockgating through
	CG_CTRL, done after initializing the GPU fully
	nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
	driver unload

A lot of this code was originally going to be based off of fermi;
however it turns out that while Fermi's the first line of GPUs that
introduced this kind of power saving, Fermi requires more fine tuned
control of the CG_CTRL registers from the driver while reclocking that
we don't entirely understand yet.

For the simple parts we will be sharing with Fermi for certain however,
we at least add those into a new subdev/therm/gf100.h header.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We've still been directly using the legacy crtc gamma_set() hook even
after conversion to atomic modesetting.

For userspace clients this was fine, however, fbcon will use the atomic
property when it's running on an atomic driver, which means we miss its
colormap updates - which is particularly bad for 8bpp framebuffers!

This commit converts the driver to use the atomic property + the helper
function implementing the legacy hook on top of atomic.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

For some reason forgotten by history, we've been using a 1025-entry LUT
mode, and sparsely filling it with the 256-entry LUT we're handed.

Until we land support for the full atomic colour management properties,
this commit switches to using the 257-entry mode to fix colour mapping
with depth 30 framebuffers.
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is what was done prior to the big refactor in kernel 3.8, and what
was done by xf86-video-nv. Experimentally, it seems like there's some
sort of issue with the high-res lut to be used there. Tested on G92.

This ends up mattering because fbcon/fbdev chooses the C8 fb format for
low-vram systems, which can occur with some IGP-based configurations
with little "stolen" vram.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need to double-buffer LUTs to handle their update atomically.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is a common, awkward sequence.  Let's wrap it up!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Useful for debugging.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NGourav Samaiya <gsamaiya@nvidia.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NGourav Samaiya <gsamaiya@nvidia.com>

It's entirely possibly that the other r375 code is relevant to r370 too,
but I've not confirmed this, so I'll leave it where it is for now.

NVIDIA's copyright headers maintained, as it's still all their code.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NGourav Samaiya <gsamaiya@nvidia.com>

gcc-8 reports

drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd':
include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation]

We need one less byte or call strlcpy() to make it a
nul-terminated string.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The kbuild test bot complained about a new coccinelle warning nearby,
which sparked a discussion about the assignment to 'memory' inside of
the conditional expression.  See Link below for the original post.

Fix the assignment to silence the coccinelle warning and also make the
code look a little nicer.

Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.htmlSigned-off-by: NChristoph Böhmwalder <christoph@boehmwalder.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NKarol Herbst <kherbst@redhat.com>

Fixes failure to compile with recent envyas as a result of the 'movw'
alias being removed for v5.

A bit of history:

v3 only has a 16-bit sign-extended immediate mov op. In order to set
the high bits, there's a separate 'sethi' op. envyas validates that
the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
to simplify macros that load both the low and high word, a 'movw'
alias was added which takes an unsigned 16-bit immediate. However the
actual hardware op still sign extends.

v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op
is gone (loads 0 into the dst reg). However due to a bug in envyas,
the movw alias still existed, and selected the no-longer-present v3
16-bit immediate mov op. As a result usage of movw on v5 is the same
as mov with a 0x0 argument.

The proper fix throughout is to only ever use the 'movw' alias in
combination with 'sethi'. Anything else should get the sign-extended
validation to ensure that the intended value ends up in the
destination register.

Changes in fuc3 binaries is the result of a different encoding being
selected for a mov with an 8-bit value.

v2: added commit message written by Ilia, thanks for that!
v3: messed up rebasing, now it should apply
Signed-off-by: NKarol Herbst <kherbst@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Commit e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
believed that because it did not insert its freshly allocated page
directory into the pd tree, it was safe from the shrinker. I failed to
heed the lesson learnt from commit dd19674b ("drm/i915: Remove bitmap
tracking for used-ptes") that we need to pin all the levels in the tree
before hitting the shrinker or else the shrinker may free an upper layer
as we proceed to allocate the tree. Thus leaving dangling pointers
everywhere and a GPF should we hit direct reclaim at just the wrong
moment.

CPU: 0 PID: 7374 Comm: chromium Tainted: P           O    4.14.13-1-ARCH #1
Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017
task: ffff994f696c2c40 task.stack: ffffb1a789d4c000
RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
RSP: 0018:ffffb1a789d4f940 EFLAGS: 00010206
RAX: 81c1788cc4f68138 RBX: ffff994f54db8000 RCX: ffff994f696c2c40
RDX: 000000023bc73003 RSI: ffff994d598b6b80 RDI: ffff994f54db8000
RBP: ffff994d598b6b80 R08: 0000000000000000 R09: 0000000000000000
R10: ffffb1a789d4f550 R11: ffff994eaf3c3208 R12: 0000000000000027
R13: 0000000000005000 R14: 0000000004e8f000 R15: ffff994f54dba000
FS:  00007f585886aa00(0000) GS:ffff994faec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004ac8e8 CR3: 00000002552c8004 CR4: 00000000003606f0
Call Trace:
 gen8_ppgtt_alloc_pdp+0x178/0x320 [i915]
 gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915]
 ppgtt_bind_vma+0x30/0x70 [i915]
 i915_vma_bind+0x68/0xd0 [i915]
 __i915_vma_do_pin+0x2d6/0x3a0 [i915]
 eb_lookup_vmas+0x7a2/0xb50 [i915]
 i915_gem_do_execbuffer+0x4d7/0x10e0 [i915]
 ? sock_wfree+0x34/0x60
 ? unix_stream_read_generic+0x1f9/0x7e0
 ? import_iovec+0x37/0xd0
 ? i915_gem_execbuffer2+0x5d/0x390 [i915]
 i915_gem_execbuffer2+0x1b7/0x390 [i915]
 ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
 drm_ioctl_kernel+0x59/0xb0 [drm]
 drm_ioctl+0x2d5/0x370 [drm]
 ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
 ? __seccomp_filter+0x3b/0x260
 do_vfs_ioctl+0xa1/0x610
 ? syscall_trace_enter+0xdb/0x2b0
 SyS_ioctl+0x74/0x80
 do_syscall_64+0x55/0x110
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f584fa82d27
RSP: 002b:00007ffee14a7828 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000003b0126a1030 RCX: 00007f584fa82d27
RDX: 00007ffee14a7870 RSI: 0000000040406469 RDI: 0000000000000080
RBP: 00007ffee14a7870 R08: 0000000000000002 R09: 0000000000000077
R10: 00007f5839f2b780 R11: 0000000000000246 R12: 0000000040406469
R13: 0000000000000080 R14: 00007f5842b00040 R15: 0000000000000000
Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3
RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: ffffb1a789d4f940
Reported-by: NEric Blau <eblau@eblau.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Fixes: e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
References: dd19674b ("drm/i915: Remove bitmap tracking for used-ptes")
Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>
(cherry picked from commit b715a2f0)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit
4680816b ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.

If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. We just have to remember to be careful that
we do not declare a GPU hang when idly waiting for the next request to
be come ready, as we will run hangcheck continuously even when the
engines are stalled waiting for external events. This should be true
already as we should only be tracking requests submitted to hardware for
execution as an indicator that the engine is busy.

Fixes: 4680816b ("drm/i915: Wait first for submission, before waiting for request completion"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104840Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129144104.3921-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
(cherry picked from commit 88923048)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>