drm/i915: Don't access snooped pages through the GTT (even for error capture)

We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page fault instead.

This has not been a problem in the past as we only dumped ringbuffers
and batchbuffers, both of which must be not snooped. However, the
introduction of HWS page dumping leads to a read of a snooped object
through the GTT. This was introduced by

commit f3ce3821393e31a3f1a8ca6c24eb2d735a428445
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 23 22:40:36 2014 +0000

    drm/i915: Include HW status page in error capture

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet:s/uncached/not snooped/ for one case in the commit message as
requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only print information for filing bug reports once

Repeating the same information multiple times is just annoying.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Tune down debug output when context is banned

If we have stopped rings then we know that test is running
so no need for spam. In addition, only spam when default
context gets banned.

v2: - make sure default context ban gets shown (Chris)
    - use helper for checking for default context, everywhere (Chris)

v3: - dont be quiet when debug is set (Ben, Daniel)

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=73652
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use i915_hw_context to set reset stats

With full ppgtt support drm_i915_file_private gained knowledge
about the default context. Also reset stats are now inside
i915_hw_context so we can use proper abstraction.

v2: Move BUG_ON and WARN_ON to more proper locations (Ben)

v3: Pass dev directly to i915_context_is_banned to avoid the need to
dereference ctx->last_ring. Spotted by Mika when checking my
s/BUG/WARN/ change, I've missed this ->last_ring dereference.

Suggested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v2)
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v2)
[danvet: s/BUG/WARN/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable HiZ Raw Stall Optimization on IVB

The optimization helps IVB too.  No piglit regression.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable HiZ Raw Stall Optimization on HSW

The optimization is available on Ivy Bridge and later, and is disabled by
default.  Enabling it helps certain workloads such as GLBenchmark TRex test.

No piglit regression.

v2
 - no need to save the register before suspend as init_clock_gating can
   correctly program it after resume
 - split IVB change to another commit

Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Capture PPGTT info on error capture

v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)

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

drm/i915: Add some more registers to error state

Chris:
Do we also want to capture?
  GAC_ECO_BITS /* gen6,7 */
  GAM_ECOCHK /* gen6,7 */
  GAB_CTL /* gen6 */
  GFX_MODE /* gen6 */

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

drm/i915: Move per ring error state to ring_error

v2: Moved num_requests up (Chris)
Rebased on new hws page capture which required a rename since it made
two members named, 'hws' in the per ring error state. (Ben)

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

drm/i915: Reorder struct members

This helps make an upcoming patch a bit more reviewable

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

drm/i915: Logically reorder error register capture

Create logical sections in an attempt to clean up, and continue to keep
future additions clean.

v2: Reworded the comments. Added section headers (Chris)

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

drm/i915: Extract register state error capture

The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.

A subsequent patch will clean this function up.

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

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued

Backmerge drm-next - I need to backmerge drm-intel-fixes patches
touching the error capture code to be able to merge Ben's cleanup
patches.

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

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

Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next

more fixes for nouveau.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau: resume display if any later suspend bits fail
  drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip
  drm/nouveau: implement hooks for needed for drm vblank timestamping support
  drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping
  drm/nv50: fill in crtc mode struct members from crtc_mode_fixup

Merge branch 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-next

more radeon fixes

* 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon/dce8: workaround for atom BlankCrtc table
  drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
  drm/radeon: set si_notify_smc_display_change properly
  drm/radeon: fix DAC interrupt handling on DCE5+
  drm/radeon: clean up active vram sizing
  drm/radeon: skip async dma init on r6xx
  drm/radeon/runpm: don't runtime suspend non-PX cards
  drm/radeon: add ring to fence trace functions
  drm/radeon: add missing trace point
  drm/radeon: fix VMID use tracking

drm/nouveau: resume display if any later suspend bits fail

If either idling channels or suspending the fence were to fail, the
display would never be resumed. Also if a client fails, resume the fence
(not functionally important, but it would potentially leak memory).

See https://bugs.freedesktop.org/show_bug.cgi?id=70213

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip

Fixes a regression introduced by d5c1e84b3a130f0
"drm/nouveau: hold mutex while syncing to kernel channel".

Cc: stable@vger.kernel.org #3.13
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: implement hooks for needed for drm vblank timestamping support

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50: fill in crtc mode struct members from crtc_mode_fixup

The DRM uses the adjusted mode to calculate constants for vblank
timestamping.  Our encoder mode_fixup (usually) replaces this data
with our backend mode information, which doesn't have the needed
data filled in already.

Reported-by: Mario Kleiner mario.kleiner.de@gmail.com
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/i915: Kerneldoc for i915_gem_evict.c

Request by Ben Widawsky in his review of a patch touching this code.

v2: Clarify the disdinction between evicting vmas (to free up virtual
address space) and evicting objects (to free up actual system memory).
Suggested by Ben.

Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/radeon/dce8: workaround for atom BlankCrtc table

Some DCE8 boards have a funky BlankCrtc table that results
in a timeout when trying to blank the display.  The
timeout is harmless (all operations needed from the table
are complete), but wastes time and is confusing to users so
work around it.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73420

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/DCE4+: clear bios scratch dpms bit (v2)

The BlankCrtc table in some DCE8 boards has some
logic shortcuts for the vbios when this bit is set.
Clear it for driver use.

v2: fix typo

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73420

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: set si_notify_smc_display_change properly

This is effectively a revert of 4573388c92ee60b4ed72b8d95b73df861189988c.

Forcing a display active when there is none causes problems with
dpm on some SI boards which results in improperly initialized
dpm state and boot failures on some boards.  As for the bug commit
4573388c92ee tried to address, one can manually force the state to
high for better performance when using the card as a headless compute
node until a better fix is developed.

bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=73788
https://bugs.freedesktop.org/show_bug.cgi?id=69395

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
cc: stable@vger.kernel.org

drm/i915: VM eviction only targets address space not physical pages

During eviction, we are only considering how to free up space within the
current address space and not concerned with freeing up physical memory.
As such we need only skip nodes that pinned in the current VM and not
globally.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/radeon: fix DAC interrupt handling on DCE5+

DCE5 and newer hardware only has 1 DAC.  Use the correct
offset.  This may fix display problems on certain board
configurations.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: clean up active vram sizing

If we are not able to properly initialize one of the gpu
engines for buffer paging, we limit vram to the size of
the cpu visible aperture.  We generally either use the gfx
or dma engine to do this.  Clean up the size limiting code
to only adjust the size based on what ring is selected
for buffer paging rather than making assumptions about which
engine is selected for paging.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

drm/radeon: skip async dma init on r6xx

The hw is buggy and it's not currently used, but it's
currently still initialized by the driver.  Skip the init.
Skipping init also seems to improve stability with dpm on
some r6xx asics.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=66963

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

drm/radeon/runpm: don't runtime suspend non-PX cards

Prevent runtime suspend of non-PX GPUs.  Runtime suspend is
not what we want in those cases.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: add ring to fence trace functions

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add missing trace point

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix VMID use tracking

Otherwise we allocate a new VMID on nearly every submit.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/i915: fix initial timestamps for PP sequencing logic

The initial jiffies value can be non-0, so set the inital panel power
sequencer timestamps accordingly. This didn't cause a problem on 64 bit
machines but on 32 bit jiffies is initially -300*HZ, so if the panel
power is initally off in the call from edp_panel_vdd_on()->
wait_panel_power_cycle() we'd wait up to ~300 sec more than needed.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix wait_remaining_ms_from_jiffies

schedule_timeout_uninterruptible() takes jiffies not ms.

v2:
- ignore the overflow issue, the practical part of that should
  be solved instead in the caller (Chris)

Note that this issue was introduced in

commit dce56b3c626fb1d533258a624d42a1a3fc17da17
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Dec 19 14:29:40 2013 -0200

drm/i915: save some time when waiting the eDP timings

I've accidentally merged the broken v4 version of the patch (where
Jani noticed the issue [1]) instead of the v5, which was fixed [2].

[1] http://mid.gmane.org/87fvpnkgyg.fsf@intel.com
[2] http://mid.gmane.org/1388778311-2020-1-git-send-email-przanoni@gmail.com

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add admission of incompetence in the form of a note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable/Enable PM Intrrupts based on the current freq.

When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for PM DOWN THRESHOLD INTRRUPTS.

v2: Use bool variables (Daniel)

v3: Fix Interrupt masking bit (Deepak)

v4: Use existing symbolic constants in i915_reg.h (Daniel)

v5: Add pm interrupt mask after new_delay calculation (Ville)

Signed-off-by: Deepak S <deepak.s@intel.com>
[danvet: Pass new_delay by value as suggested by Ville. Also appease
checkpatch.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: set conservative clock gating values on VLV v2"

We're disabling a boatload of clock gating features on VLV. Maybe these
days we don't need to do that. At least I'm not aware of any workarounds
with this level of paranoia.

This reverts commit 4e8c84a5b14bbb5b88c63941f1d939560f4abd0b.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Clarify WaDisable4x2SubspanOptimization situation for VLV

WaDisable4x2SubspanOptimization isn't listed for VLV in the workaround
database, but BSpec says that the relevant bit must be set. Add a
comment to remind people of this.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV wants WaVSThreadDispatchOverride too

Call gen7_setup_fixed_func_scheduler() on VLV as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't apply WaVSThreadDispatchOverride on HSW

BSpec states that the thread override values set by
gen7_setup_fixed_func_scheduler() are invalid for HSW. So let's not
muck around with them.

Since gen7_setup_fixed_func_scheduler() now has two totally independent
parts, one for IVB and one for HSW, move the HSW part directly into
haswell_init_clock_gating().

Note tht there's another workaround by the name of
WaHSWVSRefCountFullforceMissDisable which basically claims that later
steppings don't need the fix, but since WaVSRefCountFullforceMissDisable
is listed to be needed for all steppings play it safe and keep applying
the workaround.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: gen7_setup_fixed_func_scheduler() actually implements WaVSThreadDispatchOverride

The current comments indicate that this function implements
WaVSRefCountFullforceMissDisable, which is only true for HSW.
The original purpose of the function is to implement
WaVSThreadDispatchOverride (and a bit more). Fix up the comments
to match reality.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop WaDisableTDLUnitClockGating:vlv

WaDisableTDLUnitClockGating is only relevant for early steppings of VLV.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop WaDisableVDSUtnitClockGating:vlv

WaDisableVDSUtnitClockGating was only relevant for early steepings of
VLV.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux into drm-next

drm/tegra: Changes for v3.14-rc1 (update)

These patches fix some issues caused by the DRM panel support from the
previous pull request and add two more panels (for the Toshiba AC100 as
well as the Seaboard and Ventana).

* tag 'drm/for-3.14-rc1-20140123' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: Obtain head number from DT
  drm/panel: update EDID BLOB in panel_simple_get_modes()
  gpu: host1x: Remove unnecessary include
  drm/tegra: Use proper data type
  drm/tegra: Clarify how panel modes override others
  drm/tegra: Fix possible CRTC mask for RGB outputs
  drm/i915: Use drm_encoder_crtc_ok()
  drm: Move drm_encoder_crtc_ok() to core
  drm: provide a helper for the encoder possible_crtcs mask
  drm/tegra: Don't check resource with devm_ioremap_resource()
  drm/panel: Add support for Chunghwa CLAA101WA01A panel
  drm/panel: Add support for Samsung LTN101NT05 panel

drm: ast,cirrus,mgag200: use drm_can_sleep

these 3 were checking in_interrupt but we have situations where
calling vunmap under this could cause a BUG to be hit in
smp_call_function_many. Use the drm_can_sleep macro instead,
which should stop this path from been taken in this case.

Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'drm-intel-fixes-2014-01-28' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Pile of -fixes all over the place. Lot's of cc: stable.

Only big thing is that we've dropped the preliminary hw support tag for
bdw - it seems to work. Which also means that I'll shovel a few more bdw
patches through -fixes, there's 5 w/a patches from Ken already on
intel-gfx.

* tag 'drm-intel-fixes-2014-01-28' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Fix the offset issue for the stolen GEM objects
  drm/i915: Decouple GPU error reporting from ring initialisation
  i915: remove pm_qos request on error
  Revert "drm/i915: Mask reserved bits in display/sprite address registers"
  drm/i915: VLV2 - Fix hotplug detect bits
  drm/i915: Allow reading the TIMESTAMP register on Gen8.
  drm/i915: Repeat evictions whilst pageflip completions are outstanding
  drm/i915: Wait for completion of pending flips when starved of fences
  drm/i915: don't disable DP port after a failed link training
  drm/i915: don't disable the DP port if the link is lost
  drm/i915: Eliminate lots of WARNs when there's no backlight present
  drm/i915: g4x/vlv: fix dp aux interrupt mask
  drm/i915/ppgtt: Defer request freeing on reset
  i915: send D1 opregion notification
  drm/i915/bdw: remove preliminary_hw_support flag from BDW
  drm/i915: Tune down reset_stat output from ERROR to debug
  drm/i915: Make semaphore modparam RO
  drm/i915: Fix disabled semaphores
  drm/i915: Clarify relocation errnos
  drm/i915: Spelling s/auxilliary/auxiliary/

Merge branch 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next

Just one-liner which corrects a select statement for DRM_KMS_FB_HELPER
which looks like it was missed in the initial merge.  Based on 3.13.

* 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox: (55 commits)
  DRM: armada: fix missing DRM_KMS_FB_HELPER select

Merge tag 'omapdrm-3.14' of git://git./linux/kernel/git/tomba/linux into drm-next

omapdrm patches for 3.14

* tag 'omapdrm-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  drm/omap: Enable DT support for DMM
  drm/omap: fix: change dev_unload order
  drm/omap: fix: disable encoder before destroying it
  drm/omap: fix: disconnect devices when omapdrm module is removed
  drm/omap: fix: Defer probe if an omapdss device requests for it at connect
  drm/omap: fix (un)registering irqs inside an irq handler

Conflicts:
drivers/gpu/drm/omapdrm/omap_drv.c

Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next

Only two patches this time around. One trivial and one locking fix.

* 'gma500-next' of git://github.com/patjak/drm-gma500:
  drm/gma500: Lock struct_mutex around cursor updates
  drivers: gpu: Mark function as static in cdv_intel_dp.c

drm/i915: Add debugfs hooks for messign with watermark latencies

Add a few new debugfs files which allow changing the watermark memory
latency values during runtime. This can be used to determine the if the
original BIOS provided latency values are no good.

v2: Drop superfluous plane name from output
    Take modeset locks around the latency value read/write

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop WaDisableRCPBUnitClockGating:vlv

Only early VLV steppings needed thist. Should no longer be relevant.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop WaApplyL3ControlAndL3ChickenMode:hsw

WaApplyL3ControlAndL3ChickenMode is only relevant to early HSW
steppings..

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop WaDisableRCZUnitClockGating:hsw

WaDisableRCZUnitClockGating was needed with early HSW steppings only.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop bogus comment about RCPB unit clock gating on IVB

Someone copy pasted the comment from the SNB code w/o reading it.
We never actually implemented the workaround to disable RCPB unit
clock gating on IVB. It would have been needed for early steppings,
but we don't care about those anymore, so just remove the stale
comment.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaDisableRHWOOptimizationForRenderHang isn't applicable to VLV

Can't find WaDisableRHWOOptimizationForRenderHang listed for VLV.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaDisableRHWOOptimizationForRenderHang isn't applicable to HSW

Can't find WaDisableRHWOOptimizationForRenderHang listed for HSW.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaDisableRCCUnitClockGating isn't applicaple to VLV

WaDisableRCCUnitClockGating is only relevant for SNB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaDisableRCCUnitClockGating isn't applicable to IVB

WaDisableRCCUnitClockGating is only relevant for SNB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaDisableVDSUnitClockGating isn't applicable to SNB

Can't find any mention of WaDisableVDSUnitClockGating ever being
relevant for SNB. Remove it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/gma500: Lock struct_mutex around cursor updates

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64361
Cc: <stable@vger.kernel.org>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

drm/i915: Create a USES_PPGTT macro

There are cases where we want to know if there is a full, or aliased
PPGTT. Currently, in fact the only distinction we ever need to make is
when we're using full PPGTT.

This patch is simply to promote readability and clarify for the
confusing existing usage where "aliasing" meant aliasing and full.

v2: Remove USES_ALIASING_PPGTT since there are currently no cases where
we need to check if we're using aliasing, but not full PPGTT. (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix the offset issue for the stolen GEM objects

The 'offset' field of the 'scatterlist' structure was wrongly
programmed with the offset value from the base of stolen area,
whereas this field indicates the offset from where the interested
data starts within the first PAGE pointed to by 'scattterlist'
structure. As a result when a new GEM object allocated from stolen
area is mapped to GTT, it could lead to an overwrite of GTT entries
as the page count calculation will go wrong, refer the function
'sg_page_count'.

v2: Modified the commit message. (Chris)

Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

DRM: armada: fix missing DRM_KMS_FB_HELPER select

Commit 92b6f89f6b8f (drm: Add separate Kconfig option for fbdev helpers)
happened in parallel with the inclusion of Armada DRM into mainline,
and so missed this update.  Add the necessary select statement to avoid
build errors.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters

Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: GEN7_MSG_CONTROL is ivb-only

At least I couldn't find it in the Haswell Bspec any more and we've
tried to test-boot a Haswell machine with num_pipes forced to 0 (i.e.
hit the PCH_NOP path) and the unclaimed register logic complained.

So restrict this dance to just ivb platforms.

v2: Art pointed out that the bits simply moved on hsw+

v3: Buy code terseneness with a notch of sublety as suggested by
Chris.

v4: Frob the right bit, spotted by Art.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Constify the drm_i915_private pointer a bit more

A lot of the WM functions are only reading from that structure and are
already using const. While converting the code to use dev_priv instead
of dev, I noticed a few places where we can give that hint.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move module parameters into a struct, in a new file

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaMiSetContext_Hang

WaMiSetContext_Hang tells us that a MI_NOOP must follow MI_SET_CONTEXT.

The other thing WaMiSetContext_Hang seems to say is that URB_FENCE isn't
allowed to straddle two cachelines. But we don't issue those from the
kernel so we don't care.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableRCCUnitClockGating:snb

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaApplyL3ControlAndL3ChickenMode isn't applicable for VLV

WaApplyL3ControlAndL3ChickenMode is only listed for IVB and HSW in
W/A database and BSpec.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableL3CacheAging:vlv

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaPsdDispatchEnable seems to be another name for WaDisablePSDDualDispatchEnable

The w/a database lists both WaPsdDispatchEnable and
WaDisablePSDDualDispatchEnable for VLV. They appear to be the same
thing, so list both names.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaEnableVGAAccessThroughIOPort:ctg, elk, ilk, snb, ivb, vlv, hsw

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableL3Bank2xClockGate:vlv

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Include HW status page in error capture

Many times in the past we have concluded that the cause of the GPU hang
has been that the hw status page was stale, usually because the GPU and
CPU disagreed over the address of the page. Having stumbled across yet
another issue that seems to be related to the HWSP, it is time to
include that information in the GPU error dump.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always pin the default context

Through a twisty and circuituous path it is possible to currently trick
the code into creating a default context and forgetting to pin it
immediately into the GGTT. (This requires a system using contexts without
an aliasing ppgtt, which is currently restricted to Baytrails machines
manually specifying a module parameter to force enable contexts, or
on Sandybridge and later that manually disable the aliasing ppgtt.) The
consequence is that during module unload we attempt to unpin the default
context twice and encounter a BUG remonstrating that we attempt to unpin
an unbound object.

[  161.002869] Kernel BUG at f84861f8 [verbose debug info unavailable]
[  161.002875] invalid opcode: 0000 [#1] SMP
[  161.002882] Modules linked in: coretemp kvm_intel kvm crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul ablk_helper cryptd hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_magn_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio hid_sensor_iio_common snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event dm_multipath scsi_dh asix ppdev usbnet snd_rawmidi mii hid_sensor_hub microcode snd_seq rfcomm bnep snd_seq_device bluetooth snd_timer snd parport_pc binfmt_misc soundcore dw_dmac_pci dw_dmac_core mac_hid lp parport dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915(O-) drm_kms_helper(O) igb dca ptp pps_core i2c_algo_bit drm(O) ahci libahci video
[  161.002991] CPU: 0 PID: 2114 Comm: rmmod Tainted: G        W  O 3.13.0-rc8+ #2
[  161.002997] Hardware name: NEXCOM VTC1010/Aptio CRB, BIOS 5.6.5 09/24/2013
[  161.003004] task: dbdd6800 ti: dbe0e000 task.ti: dbe0e000
[  161.003010] EIP: 0060:[<f84861f8>] EFLAGS: 00010246 CPU: 0
[  161.003044] EIP is at i915_gem_object_ggtt_unpin+0x88/0x90 [i915]
[  161.003050] EAX: dfce3840 EBX: 00000000 ECX: dfafd690 EDX: dfce3874
[  161.003056] ESI: c0086b40 EDI: df962e00 EBP: dbe0fe1c ESP: dbe0fe0c
[  161.003062]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.003068] CR0: 8005003b CR2: b7718000 CR3: 1bec0000 CR4: 001007f0
[  161.003076] Stack:
[  161.003081]  00afc014 00000004 c0086b40 dfafc000 dbe0fe38 f8487e5a dfaa5400 c0086b40
[  161.003099]  dfafc000 dfaa5400 dfaa5414 dbe0fe58 f84741aa 00000000 f89c34b9 dfaa5414
[  161.003117]  dfaa5400 dfaa5400 f644b000 dbe0fe6c f89a5443 dfaa5400 f8505000 f644b000
[  161.003134] Call Trace:
[  161.003169]  [<f8487e5a>] i915_gem_context_fini+0xba/0x1c0 [i915]
[  161.003202]  [<f84741aa>] i915_driver_unload+0x1fa/0x2f0 [i915]
[  161.003232]  [<f89a5443>] drm_dev_unregister+0x23/0x90 [drm]
[  161.003259]  [<f89a54ed>] drm_put_dev+0x3d/0x70 [drm]
[  161.003294]  [<f8470615>] i915_pci_remove+0x15/0x20 [i915]
[  161.003306]  [<c1338a6f>] pci_device_remove+0x2f/0xa0
[  161.003317]  [<c140c871>] __device_release_driver+0x61/0xc0
[  161.003328]  [<c140d12f>] driver_detach+0x8f/0xa0
[  161.003341]  [<c140c54f>] bus_remove_driver+0x4f/0xc0
[  161.003353]  [<c140d708>] driver_unregister+0x28/0x60
[  161.003362]  [<c10cee42>] ? stop_cpus+0x32/0x40
[  161.003372]  [<c10bd510>] ? module_refcount+0x90/0x90
[  161.003383]  [<c13378c5>] pci_unregister_driver+0x15/0x60
[  161.003413]  [<f89a739f>] drm_pci_exit+0x9f/0xb0 [drm]
[  161.003458]  [<f84e624a>] i915_exit+0x1b/0x1d [i915]
[  161.003468]  [<c10bf8a8>] SyS_delete_module+0x158/0x1f0
[  161.003480]  [<c1173d5d>] ? ____fput+0xd/0x10
[  161.003488]  [<c106f0fe>] ? task_work_run+0x7e/0xb0
[  161.003499]  [<c165a68d>] sysenter_do_call+0x12/0x28
[  161.003505] Code: 0f b6 4d f3 8d 51 0f 83 e1 f0 83 e2 0f 09 d1 84 d2 88 48 54 75 07 80 a7 91 00 00 00 7f 83 c4 04 5b 5e 5f 5d c3 8d b6 00 00 00 00 <0f> 0b 8d b6 00 00 00 00 55 89 e5 57 56 53 83 ec 64 3e 8d 74 26
[  161.003586] EIP: [<f84861f8>] i915_gem_object_ggtt_unpin+0x88/0x90 [i915] SS:ESP 0068:dbe0fe0c

v2: Rename the local variable (is_default_ctx) to avoid confusion with
the function is_default_ctx(). And correct Jesse's email address.

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73985
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: Fix up the rebase fail from my first attempt, thankfully
pointed out by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Decouple GPU error reporting from ring initialisation

Currently we report through our error state only the rings that have
been initialised (as detected by ring->obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print out any of the vital information for debugging the hang.

This (and the implied object leak) is a regression from

commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Mon Oct 14 10:01:36 2013 -0700

    drm/i915: Do a fuller init after reset

Note that we are already starting to get bug reports with incomplete
error states from 3.13, which also hampers debugging userspace driver
issues.

v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
    the scratch obj may be NULL.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
Cc: stable@vger.kernel.org # please don't delay since it's a
vital support/debug feature for the intel gfx stack in general
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a bit of fluff to make it clear we need this expedited in
stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: debugfs: Add support for probing DP sink CRC.

This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.

v2: Accepted all Daniel's suggestions:
    * grab modeset lock
    * loop over connector and check DPMS on
    * return errors
    * use _eDP1 suffix for easy future extension
    * don't cache crc_supported neither latest crc
    * return crc as a full array and read it at once with aux.
    * use 0 to turn TEST_SINK off.
    * split the drm_helpers definitions in another patch.

v3: Accepted 2 Damien's suggestion: remove h from printf hexa
    and return ENODEV when eDP not present instead of EAGAIN.

v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove
    _retry from aux read.

v5: removing last missing useless _retry (by Damien)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: dp helper: Add DP test sink CRC definition.

This address will be used to verify panel CRC for test and
validation purposes.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Fix whitespace fail.]
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix FBC_FENCE_OFF

Having a 4 byte register at 0x321b seems unlikely as that's not
4 byte aligned. Since later platforms have more or less the same FBC
registers with new names, assume that FBC_FENCE_OFF is at 0x3218 just
like DPFC_FENCE_YOFF.

This feels like a simple typo in BSpec. 321Bh looks a lot like 3218h
after all.

Should still be tested on real hardware of course. But I don't have
any mobile gen4 systems.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix FBC1 enable message

The debug message telling FBC1 has been enabled is missing a newline.
Add it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't preserve DPFC_CONTROL bits ILK/SNB

On CTG and IVB+ we don't try to preserve any bits from the
DPFC_CONTROL register. Follow suit on ILK/SNB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill most of the FBC register save/restore

We will anyway re-enable FBC normally after resume, so trying to save
and restore the register makes little sense.

We do need to preserve the FBC1 interval bits in FBC_CONTROL since
we only initialize them during driver load, and try to preserve them
after that.

v2: s/I915_HAS_FBC/HAS_FBC/ and fix the check for gen4

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Actually write the correct bits to DPFC_CONTROL on CTG

We set up all the bits for DPFC_CONTROL but forgot to actually
write them to the register. Oops.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use 1/2 compression ratio limit for 16bpp on FBC2

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Improve FBC plane defines a bit

Make the FBC plane macros take the plane as a parameter.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't set DPFC_HT_MODIFY bit on CTG/ILK/SNB

The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit.
CTG docs clearly state that it should be set only when tracking
back buffer modification in persistent mode. The bit is supposed
to be set by software after the first CPU modification to the
back buffer, and it would get automagically cleared by the hardware
on the next page flip.

Since we only track front buffer modification we don't need to set
this bit. GTT modification tracking still appears to work on ILK
and SNB with the bit unset. I don't have a CTG to verify how that
behaves.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't set persistent FBC mode on ILK/SNB

The ILK/SNB docs are a bit unclear what the persistent mode does, but
the CTG docs clearly state that it was meant to be used when we're
tracking back buffer modifications. We never do that, so leave it in
non-persistent mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't write IVB_FBC_RT_BASE

We use nuking instead of render tracking on IVB+, so there's
no point in writing IVB_FBC_RT_BASE.

v2: Drop the IVB_FBC_RT_BASE write too
v3: Move the SNB stuff elsewhere, leaving only IVB+ here

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'topic/ppgtt' into drm-intel-next-queued

Because whatever.*

* This should contain a fairly long list of issues and still
unresolved resgressions, but I didn't really get a vote.

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

drm/i915: Make underruns DRM_ERROR

I want to see these without having full debugs enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fix the gen8 irq handler as spotted by Paulo in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Limit FIFO underrun reports on GMCH platforms

Currently we print all pipe underruns on GMCH platforms. Hook up the
same logic we use on PCH platforms where we disable the underrun
reporting after the first underrun.

Underruns don't actually generate interrupts themselves on GMCH
platforms, we just can detect them whenever we service other
interrupts. So we don't have any enable bits to worry about. We just
need to remember to clear the underrun status when enabling underrun
reporting.

Note that the underrun handling needs to be moved to the non-locked
pipe_stats[] loop in the interrupt handlers to avoid having to rework
the locking in intel_set_cpu_fifo_underrun_reporting().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Place the Global GTT VM first in the list of VM

This is useful for debugging as we then know that the first entry is
always the global GTT, and all later entries the per-process GTT VM.

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

i915: remove pm_qos request on error

Not removing pm qos request and free memory for it can cause crash,
when some other driver use pm qos. For example, this oops:

BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0
Call Trace:
 [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0
 [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100
 [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e]

was caused by earlier i915 probe failure:

[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000
[drm:i915_driver_load] *ERROR* failed to init modeset
i915: probe of 0000:00:02.0 failed with error -5

Bug report:
http://bugzilla.redhat.com/show_bug.cgi?id=1057533

Reported-by: Giandomenico De Tullio <ghisha@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
[danvet: Drop unnecessary code movement.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix WRPLL clock calculation

Forgot to convert to using the refclk variable when I added refclk
readout support, and Paulo noticed the resulting calculation was off due
to the way p & r are stored.

Reported-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove incorrect comment about struct mutex

This statenment became false here:

commit 4fc688ce79772496503d22263d61b071a8fb596e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Nov 2 11:14:01 2012 -0700

    drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: always check clocks when comparing pipe configs

Now that we have DDI support, we can check these all the time.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clock readout support for DDI v3

Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.

v2: do the work from ddi_get_config (Ville)
v3: check WRPLL reference clock (Ville)
    add additional SPLL freqs (Ville)
    clean up port/crtc clock calc (Ville)
    fix up crtc_clock conditionals (Ville)
    drop superfluous dp_get_m_n from get_config (Ville)

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

drm/i915: Introduce a get_aux_send_ctl() vfunc

We need a bit more flexibility here in the future, bits get shuffled
around.

v2: more descriptive commit message (Jani Nikula)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reorder the AUX_CTL bits in descending order

So it's easier to compare what we program with the documentation, not
having to jump at all.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>