BACKPORT: drm/i915: Kill vlv_update_rps_cur_delay()

Polling to make sure the current GPU frequency matches the last
requested frequency should not be necessay, and if there's some
throttling involved, the two might not match anyway.

Since we're still seeing this trigger occasionally, and it just
introduces a rather pointless 10 ms delay, it seems like better
to kill it off.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next
(cherry picked from commit 4c7915616a7a09be0c1e5b76c26381df15fe671b)

BUG=None
TEST=May increase RC6 residency on light graphical workloads

Change-Id: Ib689409bceb272b50b76e3795852dfcf08440b9d
Signed-off-by: Joe Konno <joe.konno@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/179233
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
BACKPORT: drm/i915/vlv: use a lower RC6 timeout on VLV

We use timeout mode, and we need to lower the timeout to get good RC6
residency when loads are running.  This gets me from 0% residency during
glxgears to 77%, which is a pretty good improvement.  This value also
matches the current BWG recommentations.

Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next
(cherry picked from commit 2f0aa30425414f3105bc29dd39bfdb40cb684393)

BUG=None
TEST=May increase RC6 residency on light graphical workloads

Change-Id: I66a6ae7409bc1c2a1100de18aa57616ac551dead
Signed-off-by: Joe Konno <joe.konno@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/179234
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
BACKPORT: drm/i915/vlv: use parallel context restore when coming out of RC6

Setting this bit restores all ring contexts in parallel rather than
serially.  Matches current BWG recommendations.

Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Deepak S <deepak.s@inel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued
(cherry picked from commit 6b88f295690d3340fcbd01c1ff46991ea4f83c9f)

BUG=None
TEST=May increase RC6 residency on light graphical workloads

Change-Id: I44f0249a8ea4440271b3ede6c70d4fe10609738f
Signed-off-by: Joe Konno <joe.konno@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/179235
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
BACKPORT: drm/i915: Drop forcewake w/a for missed interrupts/seqno on Sandybridge

I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
wait for an interrupts, is no longer required. This leaves us dependent
on the second workaround of forcing an UC read of the ACTHD before
reading back the seqno from the snooped HWS. Dropping the forcewake
should allow us to conserve a little power, not much as the GPU is meant
to be busy whilst we wait for it!

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next
(cherry picked from commit 67e5871be82fec1451801d448b51d9a403d1ffac)

BUG=None
TEST=May increase RC6 residency on light graphical workloads

Change-Id: I49d77fdfef6bd34e6672b887059827a6b26edbea
Signed-off-by: Joe Konno <joe.konno@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/179236
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
CHROMIUM: drm: Remove extra mutex_unlock

This mutex_unlock was added during 3.10 rebase.
Commit 1a47db5c2773e63721a4e453344dbd510c211df5 has it, while
the original commit 514e951f64dcfe77b9f7e2919825b86164d3ed1f
doesn't.

This effectively makes the struct mutex useless, causing tons of
bugs everywhere.

BUG=chrome-os-partner:24818,chrome-os-partner:24819,chrome-os-partner:24172,chrome-os-partner:24320
TEST=build and runs

Change-Id: I4e3257e365f154879d4cf5709381cbf26ad3a335
Reviewed-on: https://chromium-review.googlesource.com/182854
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM:kernel/3.10 - Enable PSR by default in the i915 driver

BUG=chrome-os-partner:24286
TEST=By pushing to samus
Signed-off-by: sivachandra@chromium.org

Change-Id: Ib758dd4f25d07299e5cc4038143a50ed5900a2c4
Reviewed-on: https://chromium-review.googlesource.com/182522
Tested-by: Siva Reddy <sivachandra@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Siva Reddy <sivachandra@chromium.org>
Revert "BACKPORT 3.11: drm/i915: update FBC maximum fb sizes"

This reverts commit aa2bec6ff246798a3b5203cca7214e936270ec1d.

It seems like the larger FBC sizes don't work at the hw level; they
cause GPU lockups and complete machine freezes. This is fairly
difficult to reproduce, so went unnoticed for a while.

Bug chromium:338588 has been filed to track solving this mystery and
reenabling FBC on link. For now, we just disable it and ship this
thing.

BUG=chromium:328929
TEST=on 8 link machines, run vimeo + webgl aquarium + youtube for 2 hours (so 16 hours of runtime total), no crash

Conflicts:
	drivers/gpu/drm/i915/intel_pm.c

Change-Id: I9f32212c686eb1bc33b26c9fe917de7eff07dc5f
Reviewed-on: https://chromium-review.googlesource.com/184052
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: radeon: Switch to arch_phys_wc_add and add a missing ..._del

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 07ebea251d08ae851d501f7402359f053d038862)
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Change-Id: Ie7723956b96b6b5c49598097d4408e5746604f0b
Reviewed-on: https://chromium-review.googlesource.com/184512
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
BACKPORT: drm/radeon: remove stale gem->driver_private access

This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit e552df37ad589f75af969d536ee9c70c94cacccf)
Signed-off-by: Dominik Behr <dbehr@chromium.org>

Change-Id: Ie28d8bb6396d0f90d4f6e0e96a9752fb95f24ec7
Reviewed-on: https://chromium-review.googlesource.com/184513
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Dominik Behr <dbehr@chromium.org>
UPSTREAM: drm/nouveau: unpin notify object in chan_fini

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 198c14a0da9d9407c7394e1a346d4b95fc6258a6)

[bleung : cherry-picked to resolve difference later on]
BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I11c67b7a0b36cdee8ade20bd52b2c2bec0826c18
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184539
Reviewed-by: Dominik Behr <dbehr@chromium.org>
UPSTREAM: drm/vma: add access management helpers

The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

v2: add drm_vma_node_verify_access() helper

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 88d7ebe59341dc3b82e662b80809694e3c6b3766)

[bleung : cherry-picked to resolve difference later on]

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I2cbb97634e7d28d0f8b8e9742e52851f516d2ff8
Reviewed-on: https://chromium-review.googlesource.com/184590
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
UPSTREAM: drm: verify vma access in TTM+GEM drivers

GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit acb4652703f0a452405a3ab9319594eddc41391b)

[bleung : picked to resolve conflict ]

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I5f6bdb71acbdc48616fe3494212d38e3b03018f2
Reviewed-on: https://chromium-review.googlesource.com/184591
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
UPSTREAM: drm/nouveau: fixup fbcon failure paths

Add missing calls, and fix a leak from forgetting to call the unpin function.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 1e2bd5f53b6282e711e9f074765911868f8e7dc1)

Signed-off-by: Benson Leung <bleung@chromium.org>

[bleung : cherry-picked to resolve difference later on]
BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I44905a7ce5148c3fe35883ce23b17b0806007cc0
Reviewed-on: https://chromium-review.googlesource.com/184592
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
UPSTREAM: drm/nouveau: complain loudly if buffer is pinned during destruction

Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 27f06b2dbb84cf44b9ff404db1b93f14796ba559)

[bleung : cherry-picked to resolve difference later on]

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I26f7987546c7bf233dde27004bbb733970bdc22f
Reviewed-on: https://chromium-review.googlesource.com/184593
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
UPSTREAM: drm/nouveau: do not unpin in nouveau_gem_object_del

This should no longer be required, and is harmful for framebuffer pinning.
Also add a warning if unpin causes the pin count to drop below 0.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
(cherry picked from commit 4f3855997c5d2bf6443853800eb1a03f61ad9140)

[bleung : cherry-picked to resolve difference later on]

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: Ib0c239ad220d6f63657878288a5ca85efeff464a
Reviewed-on: https://chromium-review.googlesource.com/184594
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
BACKPORT: drm/nouveau: embed gem object in nouveau_bo

There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.

The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.

For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.

Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 55fb74adc628b99424360b0123f47ea4484c56fd)

Conflicts:

	drivers/gpu/drm/nouveau/nouveau_gem.c

[bleung : Backported to remove driver_private membe]

Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:322351
TEST=With whole series, test that x86-generic builds.

Change-Id: I163378964c05a676779ded0c86749f7a85b0467d
Reviewed-on: https://chromium-review.googlesource.com/184595
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
CHROMIUM: firmware: do not install radeon firmware

it has been superceeded by linux-firmware package

BUG=chromium:338504
TEST=build and install amd64generic kernel, it should not install
anything to /lib/firmware/radeon

Change-Id: Ia8fed3f39f75fa480d27baa77ab82e99d4ea99be
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184962
Reviewed-by: Olof Johansson <olofj@chromium.org>
Revert "CHROMIUM: Firmware: Add AMD fusion firmware."

These firmware have been superceeded by linux-firmware package

This reverts commit af8e083323c89620f9039d5d2d00bc2391414aa6.
BUG=chromium:338504
TEST=none

Change-Id: I97d90c58b88905ac8a5dd4bc18e1372683b573df
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184980
Reviewed-by: Olof Johansson <olofj@chromium.org>
Revert "CHROMIUM: firmware: import amd fusion gpu firmware"

This reverts commit a11632c3019c6dbec4147f53a854aa9532fd5f37.

These firmware files are superceeded by linux-firmare package.

BUG=chromium:338504
TEST=none

Change-Id: Ica18ab4c1fd8bee869eabb4ff9ca8bb309a5fb92
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184981
Reviewed-by: Olof Johansson <olofj@chromium.org>
Revert "Add radeon firmware to x86-generic kernels."

This reverts commit 814f066ea2dad9f2d96feea2d7a89b4ec4a76393.

These firmware files are superceeded by linux-firmware package.

BUG=chromium:338504
TEST=none

Change-Id: Id73f1ebc61d2f3929b5710e228ec6fb4a66a01d3
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184982
Reviewed-by: Olof Johansson <olofj@chromium.org>