crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is stale.

v2: Clear new_config in disable_crtc_nofb() too (Imre)
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lead to an oops within the modeset code.

Check for NULL fb when restoring the configuration, and instead of
oopsing simply disable the pipe.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute phase,
so that we can make accurate decisions about global resource usage.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 446f2545.

I've left the masking in the pageflip code since that seems to be some
useful piece of preemptive robustness.

Iirc I've merged this patch under the assumption that the BIOS leaves
some random gunk in the lower bits and gets unhappy if we trample on
them. We have quite a few case like this, so this made sense.

Now I've just learned that there's actual hardware features bits in
the low 12 bits, and the kernel needs to preserve them to allow a
userspace blob to do its job. Given Dave Airlie's clear stance on
userspace blob drivers I've quickly chatted with him and he doesn't
seem too happy. So let's revert this.

If there are indeed bits that we must preserve in this range then we
can ressurrect this patch, but with proper documentation for those
bits supplied. And we probably also need to think a bit about
interactions with our driver.

Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add new definitions for hotplug live status bits for VLV2 since they're
in reverse order from the gen4x ones.

Changelog:
- Restored gen4 bit definitions
- Added new definitions for VLV2
- Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct
  bit defintions
- Replaced a lost trailing brace for the added switch()
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951
[danvet: Switch to _VLV postfix instead of prefix and regroupg
comments again so that the g4x warning is right next to those defines.
Also add a _G4X suffix for those special ones. Also cc stable.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Nothing's changed here; we just need to bump the generation check.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since an old pageflip will keep its scanout buffer object pinned until
it has executed its unpin task on the common workqueue, we can clog up
our GGTT with stale pinned objects. As we cannot flush those workqueues
without dropping our locks, we have to resort to falling back to
userspace and telling them to repeat the operation in order to have a
chance to run our workqueues and free up the required memory. If we
fail, then we are forced to report ENOSPC back to userspace causing the
operation to fail and best-case scenario is that it introduces temporary
corruption.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the unpin workqueue. This is unpredictable by userspace
and leads to random EDEADLK when submitting an otherwise benign
execbuffer. However, we can detect when we have an outstanding flip and
so cause userspace to wait upon their completion before finally
declaring that the system is starved of fences. This is really no worse
than forcing the GPU to stall waiting for older execbuffer to retire and
release their fences before we can reallocate them for the next
execbuffer.

v2: move the test for a pending fb unpin to a common routine for
later reuse during eviction

Reported-and-tested-by: dimon@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.

As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.

v2:
- fix explanation of change impact (Chris)
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.

Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).

Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.

See also the next patch fixing the other half of this issue.

Solution suggested by Ville.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

My 855gm doesn't register the intel backlight but it still ends up
calling the backlight code to enable/disable the backlight via the
LVDS code. This leads to some WARNs due to backlight.max being 0.

Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight()
check whether there's a backlight present or not.

Also move the backlight.present check from asle_set_backlight() into
intel_panel_set_backlight() for some extra symmetry.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix typo possibly leading to timed out DP aux transactions on ports C,D.

Introduced in:

Commmit 4aeebd74
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 31 09:53:36 2013 +0100

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210
Signed off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to defer the free request until the object/vma is capable of
being freed - or else we have a problem  when we try to destroy the
context.

The exact same issue is described and fixed here:
commit e2078043
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Dec 6 14:11:22 2013 -0800

    drm/i915: Defer request freeing

I had this fix previously, but decided not to keep it for some reason I
can no longer remember.

gem_reset_stats is a really good test at hitting the problem.

For the inquisitive:
[  170.516392] ------------[ cut here ]------------
[  170.517227] WARNING: CPU: 1 PID: 105 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]()
[  170.518064] Memory manager not clean during takedown.
[  170.518941] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 3.13.0-rc4-BEN+ #28
[  170.519787] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012
[  170.520662] Call Trace:
[  170.521517]  [<ffffffff814f0589>] dump_stack+0x4e/0x7a
[  170.522373]  [<ffffffff81049e6d>] warn_slowpath_common+0x7d/0xa0
[  170.523227]  [<ffffffff81049edc>] warn_slowpath_fmt+0x4c/0x50
[  170.524079]  [<ffffffffa06c414e>] drm_mm_takedown+0x2e/0x30 [drm]
[  170.524934]  [<ffffffffa07213f3>] gen6_ppgtt_cleanup+0x23/0x110
[i915]
[  170.525777]  [<ffffffffa07837ed>] ppgtt_release.part.5+0x24/0x29
[i915]
[  170.526603]  [<ffffffffa071aaa5>] i915_gem_context_free+0x195/0x1a0
[i915]
[  170.527423]  [<ffffffffa071189d>] i915_gem_free_request+0x9d/0xb0
[i915]
[  170.528247]  [<ffffffffa0718af9>] i915_gem_reset+0x1f9/0x3f0 [i915]
[  170.529065]  [<ffffffffa0700cce>] i915_reset+0x4e/0x180 [i915]
[  170.529870]  [<ffffffffa070829d>] i915_error_work_func+0xcd/0x120
[i915]
[  170.530666]  [<ffffffff8106c13a>] process_one_work+0x1fa/0x6d0
[  170.531453]  [<ffffffff8106c0d8>] ? process_one_work+0x198/0x6d0
[  170.532230]  [<ffffffff8106c72b>] worker_thread+0x11b/0x3a0
[  170.532996]  [<ffffffff8106c610>] ? process_one_work+0x6d0/0x6d0
[  170.533771]  [<ffffffff810743ef>] kthread+0xff/0x120
[  170.534548]  [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[  170.535322]  [<ffffffff814f97ac>] ret_from_fork+0x7c/0xb0
[  170.536089]  [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[  170.536847] ---[ end trace 3d4c12892e42d58f ]---

v2: Whitespace fix. (Chris)

Note: This is a bug that only hits the ppgtt topic branch but I've
figured that doing the request cleanup in this order is generally the
right thing to do.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Add a code comment to clarify what's actually going on since
the lifetime rules aroung ppgtt cleanup are ... fuzzy a best atm. Also
add a note about why we need this.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The opregion notification for runtime suspend is currently D1, not D3.
Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It ought to work ok in 3.14.  We have some fun stuff coming after that,
but all the basics are in place now and seem relatively stable.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is user-triggerable and hence we should not allow it to spam
dmesg. Also, it upsets the nice dmesg tracking piglit does.

Note that this is just extra debugging information, mostly
unwanted, in case of a hang and that there is a separate message to the
user giving instructions on how to report a bug for a GPU hang.

v2: Add note as suggests in Chris' reply.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A couple patches in the upcoming rework of semaphores will break if
semaphores are toggled by the user at various times. Since the code
cleanups there seem to be an overall win, and toggling semaphores at
runtime is not a terribly useful thing to do, simply make the module
parameter read-only.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.

This was introduced:
commit 52ed2325
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Mon Dec 16 20:50:38 2013 -0800

    drm/i915: Don't emit mbox updates without semaphores

FWIW, the bug was fixed later in the series.

/me hangs head in shame.

Daniel: Also note that we should have merged the read-only semaphore
modparam before this patch.
Reported-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While trying to find a random -EINVAL from a failing test, I noticed we
had a few hard to follow return values.

The first two hunks in this patch replace completely useless
initialization of ret. The last several hunks help to distinguish
between altering 'return ret' and 'return <ERROR>'
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Here's the vblank timestamp pull request you wanted.

I addressed the few bugs that Mario pointed out and added
the r-bs.

As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.

* 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux:
  drm/i915: Add a kludge for DSL incrementing too late and ISR not working
  drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
  drm: Pass 'flags' from the caller to .get_scanout_position()
  drm: Fix vblank timestamping constants for interlaced modes
  drm/i915: Fix scanoutpos calculations for interlaced modes
  drm: Change {pixel,line,frame}dur_ns from s64 to int
  drm: Use crtc_clock in drm_calc_timestamping_constants()
  drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()
  drm: Simplify the math in drm_calc_timestamping_constants()
  drm: Improve drm_calc_timestamping_constants() documentation
  drm/i915: Call drm_calc_timestamping_constants() earlier
  drm/i915: Kill hwmode save/restore
  drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()
  drm: Pass the display mode to drm_calc_timestamping_constants()

Some straggling drm core patches

* 'topic/core-stuff' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/gem: Always initialize the gem object in object_init
  drm/edid: Populate picture aspect ratio for CEA modes
  drm/edid: parse the list of additional 3D modes
  drm/edid: split VIC display mode lookup into a separate function
  drm: Make the connector mode_valid() vfunc return a drm_mode_status enum

Just a single fix for sparse/smatch warnings introduced by the previous
vmwgfx-next pull.

* 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errors

Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrant <jakob@vmware.com>

At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail when userspace is hitting open file limits.

Doing the structure init even when the shmem file allocation fails
prevents this Oops.

This is a regression from

commit 89c8233f
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Thu Jul 11 11:56:32 2013 +0200

    drm/gem: simplify object initialization

v2: Add regression note which Chris supplied.

Testcase: igt/gem_fd_exhaustion
Reported-and-Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Cc: stable@vger.kernel.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

New tree with the INFO ioctl merge fixed up.  This also adds a couple
of additional minor fixes.

A few more changes for 3.14, mostly just bug fixes.  Note that:
drm/radeon: add query to fetch the max engine clock.
will conflict with 3.13 final, but the fix is pretty obvious.

* 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux: (22 commits)
  drm/radeon: add UVD support for OLAND
  drm/radeon: fix minor typos in si_dpm.c
  drm/radeon: set the full cache bit for fences on r7xx+
  drm/radeon: fix surface sync in fence on cayman (v2)
  drm/radeon/dpm: disable mclk switching on desktop RV770
  drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table
  drm/radeon: write gfx pg bases even when gfx pg is disabled
  drm/radeon: bail early from enable ss in certain cases
  drm/radeon: handle ss percentage divider properly
  drm/radeon: add query to fetch the max engine clock (v2)
  drm/radeon/dp: sleep after powering up the display
  drm/radeon/dp: use usleep_range rather than udelay
  drm/radeon/dp: bump i2c-over-aux retries to 7
  drm/radeon: disable ss on DP for DCE3.x
  drm/radeon/cik: use hw defaults for TC_CFG registers
  drm/radeon: disable dpm on BTC
  drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush
  drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush
  drm/radeon: consolidate sdma hdp flushing code for CIK
  drm/radeon: consolidate cp hdp flushing code for CIK
  ...

It seems this got dropped when we merged UVD support
last year.  Add this back now.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Copy/paste typos from the ni code. Should not
have any functional change.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Needed to properly flush the read caches for fences.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to set the engine bit to select the ME and
also set the full cache bit.  Should help stability
on TN and cayman.

V2: fix up surface sync in ib execute as well
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Mclk switching doesn't seem to work reliably on these
cards.  Most RV770 boards specify the same mclk for all
performance levels anyway so in most cases, this has
no affect.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73067Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to swap the data for big endian.
Notcied by sylware in IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For consistency.  These buffers aren't used when pg is
disabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the ss percentage is 0 or we are using external ss,
just bail when enabling ss.  We disable it explicitly
earlier in the modeset already.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's either 100 or 1000 depending on the flags in the
table.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is needed for reporting the max GPU engine clock
in OpenCL.  This just reports the max possible engine
clock, it does not take into account current conditions
that may limit that clock.

v2: fix query number for merge with 3.13
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.

v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to the DP 1.1 spec, the sink must power
up within 1ms.  Noticed while reviewing Thierry's
drm/dp patches.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>