G92's seem to require some additional bit of initialization before the
BSP engine can work. It feels like clocks are not set up for the
underlying VLD engine, which means that all commands submitted to the
xtensa chip end up hanging. VP seems to work fine though.

This still allows people to force-enable the bsp engine if they want to
play around with it, but makes it harder for the card to hang by
default.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Even though we've zeroed the PDE, the GPU may have cached the PD, so we
need to flush when deleting them.

Noticed while working on replacement MMU code, but a backport might be a
good idea, so let's fix it in the current code too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

The hardware state readout oopses after several warnings when trying to
use HDMI on port A, if such a combination is configured in VBT. Filter
the combo out already at the VBT parsing phase.

v2: also ignore DVI (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
Cc: stable@vger.kernel.org
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NDaniel Drake <dan@reactivated.net>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170921141920.18172-1-jani.nikula@intel.com
(cherry picked from commit d27ffc1d)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

hw_check is being assigned and updated but is no longer being read,
hence it is redundant and can be removed.

Detected by clang scan-build:
"warning: Value stored to 'hw_check' during its initialization
is never read"

Fixes: f6d1973d ("drm/i915: Move modeset state verifier calls")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914162154.11304-1-colin.king@canonical.com
(cherry picked from commit 4babc5e2)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

drm_edid_to_eld() initializes the connector ELD to zero, overwriting the
ELD connector type initialized in intel_audio_codec_enable(). If
userspace does getconnector and thus get_modes after modeset, a
subsequent audio component i915_audio_component_get_eld() call will
receive an ELD without the connector type properly set. It's fine for
HDMI, but screws up audio for DP.

Always set the ELD connector type at intel_connector_update_modes()
based on the connector type. We can drop the connector type update from
intel_audio_codec_enable().

Credits to Joseph Nuzman <jnuzman@gmail.com> for figuring this out.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joseph Nuzman <jnuzman@gmail.com>
Reported-by: NJoseph Nuzman <jnuzman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101583Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NJoseph Nuzman <jnuzman@gmail.com>
Cc: stable@vger.kernel.org # v4.10+, maybe earlier
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170919153813.29808-1-jani.nikula@intel.com
(cherry picked from commit d81fb7fd)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The TRACE_INCLUDE_FILE macro needs to specify the path relative to the
define_trace.h header rather than relative to the file defining it.
Reported-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823171326.23620-1-thierry.reding@gmail.com

qxl_plane_cleanup_fb() unpins the just activated framebuffer
instead of the old one.  Oops.  Fix it.

Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Fixes: 1277eed5Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170918074145.2257-1-kraxel@redhat.com

Now that the cec-pin framework has been merged, we can remove the safeguard
that were preventing the CEC part of the sun4i HDMI driver and actually
start to use it.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

To avoid spamming the log.
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Avoid intermediate negative numbers when doing calculations with a mix
of signed and unsigned variables where implicit conversions can lead
to unexpected results.

When kernel queue buffer wraps around to 0, we need to check that rptr
won't be overwritten by the new packet.
Signed-off-by: NYong Zhao <yong.zhao@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

When uninitializing a kernel queue.
Signed-off-by: NYong Zhao <yong.zhao@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Function hdmi_mode_fixup() used bare list_for_each entry, which was
unsafe and caused memory corruption detected by kasan.
It now uses drm_for_each_connector_iter macro, which is now recommended
by the documentation and safe.
Signed-off-by: NMaciej Purski <m.purski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

I ran into a build error on x86:

drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_conf_irq':
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:706:2: error: implicit declaration of function 'irq_set_status_flags'; did you mean 'dquot_state_flag'? [-Werror=implicit-function-declaration]
  irq_set_status_flags(irq, IRQ_NOAUTOEN);

Adding the missing include fixes the error.

Fixes: b37d53a0 ("drm/exynos/decon5433: move TE handling to DECON")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit 7d902c05 ("drm: Nuke drm_atomic_helper_connector_dpms")
removed drm_atomic_helper_connector_dpms() helper saying that it was a dead
code. It was however indirectly used by Exynos DRM driver for implementing
suspend/resume support. To fix this regression (after that patch Exynos DRM
suspend/resume functions became no-ops and hardware fails to suspend),
this patch rewrites them with drm_atomic_helper_suspend/resume() helpers.

Fixes: 7d902c05 ("drm: Nuke drm_atomic_helper_connector_dpms")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit 48a92916 ("drm/exynos: use drm_for_each_connector_iter()")
replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter()
and removed surrounding drm_modeset_lock calls. However, that lock was
there not only to protect unsafe drm_for_each_connector(), but it was also
required to be held by the dpms code which was called from the loop body.
This patch restores those drm_modeset_lock calls to fix broken suspend
and resume of Exynos DRM subsystem in v4.13 kernel.

Fixes: 48a92916 ("drm/exynos: use drm_for_each_connector_iter()")
CC: stable@vger.kernel.org # v4.13
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Commit 1bf6ad62 ("drm/vblank: drop the mode argument from
drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but
did not remove the local variable. Do so now.

Fixes: 1bf6ad62 ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914164213.18461-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit e01e71fc)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Min brightness value from vbt was missing for CNP platform.
This setting have to refer backlight ic spec to restrict
min backlight output. Without this restriction, driver would
allow to configure lower brightness value and violate
backlight ic requirement.

Fixes: 4c9f7086 ("drm/i915/cnp: Backlight support for CNP.")
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NShawn Lee <shawn.c.lee@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505279961-16140-1-git-send-email-shawn.c.lee@intel.com
(cherry picked from commit f44e354f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

This reverts commit bbdf0b2f ("drm/i915/bxt: Disable device ready
before shutdown command").

Disable device ready before shutdown command was added previously to
avoid a split screen issue seen on dual link DSI panels. As of now, dual
link is not supported and will need some rework in the upstream
code. For single link DSI panels, the change is not required. This will
cause failure in sending SHUTDOWN packet during disable. Hence reverting
the change. Will handle the change as part of dual link enabling in
upstream.

Fixes: bbdf0b2f ("drm/i915/bxt: Disable device ready before shutdown command")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NVidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1504604671-17237-1-git-send-email-vidya.srinivas@intel.com
(cherry picked from commit 33c8d887)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Min brightness value from vbt was missing for BXT platform.
This setting have to refer backlight ic spec to restrict
min backlight output. Without this restriction, driver would
allow to configure lower brightness value and violate
backlight ic requirement.

Fixes: 0fb890c0 ("drm/i915/bxt: BLC implementation")
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Gary C Wang <gary.c.wang@intel.com>
Signed-off-by: NShawn Lee <shawn.c.lee@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505187390-7039-1-git-send-email-shawn.c.lee@intel.com
(cherry picked from commit c3881128)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We should go through the error handling path to decrease the
'framebuffer_references' as done everywhere else in this function.

Fixes: 2e2adb05 ("drm/i915: Add render decompression support")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170910085642.13673-1-christophe.jaillet@wanadoo.fr
(cherry picked from commit 37875d6b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Looking at our virtual PCI device, we can see surprising Region 4 and Region 5.
00:10.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 06) (prog-if 00 [VGA controller])
        ....
        Region 0: Memory at 140000000 (64-bit, non-prefetchable) [size=16M]
        Region 2: Memory at 180000000 (64-bit, prefetchable) [size=1G]
        Region 4: Memory at <ignored> (32-bit, non-prefetchable)
        Region 5: Memory at <ignored> (32-bit, non-prefetchable)
        Expansion ROM at febd6000 [disabled] [size=2K]

The fact is that we only implemented BAR0 and BAR2. Surprising Region 4 and
Region 5 are shown because we report their size as 0xffffffff. They should
report size 0 instead.

BTW, the physical GPU has a PIO BAR. GVTg hasn't implemented PIO access, so
we ignored this BAR for vGPU device.

v2: fix BAR size value calculation.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458032Signed-off-by: NChangbin Du <changbin.du@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit f1751362)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Fixes a hibernation regression on APUs.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=191571
Fixes: 274ad65c (drm/radeon: hard reset r600 and newer GPU when hibernating.)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Several users have complained that the tile table update broke Oland
support. Despite several attempts to fix it, the root cause is still
unknown at this point and no solution is available. As it is not
acceptable to leave a known regression breaking a major functionality
in the kernel for several releases, let's just reverse this
optimization for now. It can be implemented again later if and only
if the breakage is understood and fixed.

As there were no complaints for Hainan so far, only the Oland part of
the offending commit is reverted. Optimization is preserved on
Hainan, so this commit isn't an actual revert of the original.

This fixes bug #194761:
https://bugzilla.kernel.org/show_bug.cgi?id=194761Reviewed-by: NMarek Olšák <marek.olsak@amd.com>
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Fixes: f8d9422e ("drm/amdgpu: update tile table for oland/hainan")
Cc: Flora Cui <Flora.Cui@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

... and __initconst if applicable.

Based on similar work for an older kernel in the Grsecurity patch.

[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
primary motivation was to allow users to tell that an allocation is
short lived and so the allocator can try to place such allocations close
together and prevent long term fragmentation.  As much as this sounds
like a reasonable semantic it becomes much less clear when to use the
highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
context holding that memory sleep? Can it take locks? It seems there is
no good answer for those questions.

The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
__GFP_RECLAIMABLE which in itself is tricky because basically none of
the existing caller provide a way to reclaim the allocated memory.  So
this is rather misleading and hard to evaluate for any benefits.

I have checked some random users and none of them has added the flag
with a specific justification.  I suspect most of them just copied from
other existing users and others just thought it might be a good idea to
use without any measuring.  This suggests that GFP_TEMPORARY just
motivates for cargo cult usage without any reasoning.

I believe that our gfp flags are quite complex already and especially
those with highlevel semantic should be clearly defined to prevent from
confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
replace all existing users to simply use GFP_KERNEL.  Please note that
SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
so they will be placed properly for memory fragmentation prevention.

I can see reasons we might want some gfp flag to reflect shorterm
allocations but I propose starting from a clear semantic definition and
only then add users with proper justification.

This was been brought up before LSF this year by Matthew [1] and it
turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
seems to be a heuristic without any measured advantage for most (if not
all) its current users.  The follow up discussion has revealed that
opinions on what might be temporary allocation differ a lot between
developers.  So rather than trying to tweak existing users into a
semantic which they haven't expected I propose to simply remove the flag
and start from scratch if we really need a semantic for short term
allocations.

[1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org

[akpm@linux-foundation.org: fix typo]
[akpm@linux-foundation.org: coding-style fixes]
[sfr@canb.auug.org.au: drm/i915: fix up]
  Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NMel Gorman <mgorman@suse.de>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Neil Brown <neilb@suse.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

All manipulations of the gem_object list need to be protected by
the list mutex, as GEM objects can be created and freed in parallel.
This fixes a kernel memory corruption.

CC: stable@vger.kernel.org
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

If the gpu submit fails, bail out to avoid accessing a potentially
unititalized fence.

CC: stable@vger.kernel.org #4.12+
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

This reverts commit 10e709cb.

The patch doesn't work at all:
1. The CS can still be blocked because of amdgpu_ctx_add_fence().
2. The order of submission isn't correct any more.
3. We could end up using freed up memory because we now drop the
   ctx reference to early.

This needs to be fixed cleanly by doing the context handling after the BO
handling, but this is a larger task just avoid the obvious crashes for now.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu monk.liu@amd.com
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The atomic conversion of the qxl driver didn't got the primary surface
handling completely right.  It works in the common simple cases, but
fails for example when changing the display resolution using xrandr or
in multihead setups.

The rules are simple:  There is one primary surface.  Before defining a
new one you have to destroy the old one.

This patch makes qxl_primary_atomic_update() destroy the primary surface
before defining a new one.  It fixes is_primary flag updates.  It adds
is_primary checks so we don't try to update the primary surface in case
it already has the state we want it being in.

Fixes: 3538e80a ("drm: qxl: Atomic phase 1: Implement mode_set_nofb")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102338
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196777Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170911093950.22401-1-kraxel@redhat.com

Allow interval trees to quickly check for overlaps to avoid unnecesary
tree lookups in interval_tree_iter_first().

As of this patch, all interval tree flavors will require using a
'rb_root_cached' such that we can have the leftmost node easily
available.  While most users will make use of this feature, those with
special functions (in addition to the generic insert, delete, search
calls) will avoid using the cached option as they can do funky things
with insertions -- for example, vma_interval_tree_insert_after().

[jglisse@redhat.com: fix deadlock from typo vm_lock_anon_vma()]
  Link: http://lkml.kernel.org/r/20170808225719.20723-1-jglisse@redhat.com
Link: http://lkml.kernel.org/r/20170719014603.19029-12-dave@stgolabs.netSigned-off-by: NDavidlohr Bueso <dbueso@suse.de>
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: NDoug Ledford <dledford@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Christian Benvenuti <benve@cisco.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The call to kfd_device_by_id can potentially return null, so check that
dev is null and return with -EINVAL to avoid a null pointer dereference.

Detected by CoverityScan CID#1454629 ("Dereference null return value")

Fixes: 5d71dbc3 ("drm/amdkfd: Implement image tiling mode support v2")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

shrink_slab() allows us to report back the number of objects we
successfully scanned (out of the target shrinkctl->nr_to_scan).  As
report the number of pages owned by each GEM object as a separate item
to the shrinker, we cannot precisely control the number of shrinker
objects we scan on each pass; and indeed may free more than requested.
If we fail to tell the shrinker about the number of objects we process,
it will continue to hold a grudge against us as any objects left
unscanned are added to the next reclaim -- and so we will keep on
"unfairly" shrinking our own slab in comparison to other slabs.

Link: http://lkml.kernel.org/r/20170822135325.9191-2-chris@chris-wilson.co.ukSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Shaohua Li <shli@fb.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
reset. That was causing the display to show garbage on his 945gm. On my
i915gm the effect was far more severe; re-enabling the display following
the reset without PGETBL_CTL being enabled lead to an immediate hard
hang.

We do have a routine to re-enable PGETBL_CTL which is applicable to
gen2-4, although on gen4 it is documented that a graphics reset doesn't
alter the register (no such wording is given for gen3) and should be safe
to call to punch back in the enable bit. However, that leaves the question
of whether we need to completely re-initialise the register and the
rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
page table, its contents do seem to be kept, and so we should be able to
recover without having to reinitialise the GTT from scratch (as prior to
g33, that register is configured by the BIOS and we leave alone except
for the enable bit).

This appears to have been broken by commit 5fbd0418 ("drm/i915:
Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
reset) to add it earlier during hw init and resume, missing the reset
path.

v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
match init/resume
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 5fbd0418 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170906111405.27110-1-chris@chris-wilson.co.ukTested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 0db8c961)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add the missing __user to the urelocs cast to fix the following sparse
warning:
i915_gem_execbuffer.c:1541:47: warning: cast removes address space of expression
i915_gem_execbuffer.c:1541:62: warning: incorrect type in argument 2 (different address spaces)
i915_gem_execbuffer.c:1541:62:    expected void const [noderef] <asn:1>*from
i915_gem_execbuffer.c:1541:62:    got char *

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901165434.24636-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
(cherry picked from commit 908a6105)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Sparse enforces that GFP flags are only manipulated inside gfp_t locals.

Fixes: 4d470f73 ("drm/i915: Avoid undefined behaviour of "u32 >> 32"")
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: https://patchwork.freedesktop.org/patch/msgid/20170901145729.21363-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 0d95c883)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

radix_tree_for_each_slot() wants an __rcu annotated pointer for the
slot. So let's add the annotation.

Fixes the following sparse warnings:
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:2217:9:    expected void [noderef] <asn:4>**slot
i915_gem.c:2217:9:    got void **slot
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit c23aa71b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add back the GEN8_PPAT_WB cache attributes in cnl_setup_private_ppat(),
which are missed on CNL.

Fixes: 4e34935f ("drm/i915/cnl: Setup PAT Index.")
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@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/1504208177-27784-1-git-send-email-zhi.a.wang@intel.com
(cherry picked from commit 6e31cdcf)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Remove one duplicated MMIO GEN6_PCODE_MAILBOX. Duplicated MMIO will
cause host GVT-g initialization failure.

Fixes: 9c3a16c8 ("drm/i915/hsw+: Add support for multiple power well regs")
Signed-off-by: NJian Jun Chen <jian.jun.chen@intel.com>
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

In VI, the destroy mqd function needs to inquire fields present in the mqd
structure. That's why we need to pass it to that function instead of NULL.
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Use enum pipe for PCH transcoders also in the FIFO underrun code.

Fixes the following new sparse warnings:
intel_fifo_underrun.c:340:49: warning: mixing different enum types
intel_fifo_underrun.c:340:49:     int enum pipe  versus
intel_fifo_underrun.c:340:49:     int enum transcoder
intel_fifo_underrun.c:344:49: warning: mixing different enum types
intel_fifo_underrun.c:344:49:     int enum pipe  versus
intel_fifo_underrun.c:344:49:     int enum transcoder
intel_fifo_underrun.c:397:57: warning: mixing different enum types
intel_fifo_underrun.c:397:57:     int enum pipe  versus
intel_fifo_underrun.c:397:57:     int enum transcoder
intel_fifo_underrun.c:398:17: warning: mixing different enum types
intel_fifo_underrun.c:398:17:     int enum pipe  versus
intel_fifo_underrun.c:398:17:     int enum transcoder

Cc: Matthias Kaehlcke <mka@chromium.org>
Fixes: a2196033 ("drm/i915: Consistently use enum pipe for PCH transcoders")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 41c32e5d)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>