drm/i915: Broaden FBC resolution limit to 4096*4096

Staring from HSW, the resolution limit of FBC has increased to
4096*4096

Issue: VIZ-2813
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun <daisy.sun@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Added write-enable pte bit supportt

This adds support for a write-enable bit in the entry of GTT.
This is handled via a read-only flag in the GEM buffer object which
is then used to see how to set the bit when writing the GTT entries.
Currently by default the Batch buffer & Ring buffers are marked as read only.

v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
    Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)

v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring Buffers(Daniel).

v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries functions,
    in lieu of overloading the cache_level enum (Daniel).

v5: Removed the superfluous VLV check & changed the definition location of PTE_READ_ONLY flag (Imre)

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Handle disabled primary plane in debugfs i915_display_info (v2)

Now that the primary plane can be disabled independently of the CRTC,
the debugfs code needs to be updated to recognize when the primary plane
is disabled and not try to return information about the primary plane's
framebuffer.

This change prevents a NULL dereference when reading i915_display_info
with a disabled primary plane.

v2: Replace a seq_printf() with seq_puts() (suggested by Damien)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix comment about our plane remapping on gen2/3

Spotted while crawling around in the area.

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

drm/i915: update intel_dp_voltage_max comment

Any comment containing "current Intel hardware supports" quickly
becomes obsolete, so remove it and let people discover the information
by looking at the function implementation.

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

drm/i915: update BDW DDI buffer translations

Two BSpec updates changed the recommended values for BDW eDP and DP
DDI buffer translations. Now the signal levels also match the HSW signal
levels, which simplify things a little bit.

It seems some DP sinks don't work properly without voltage level 0 and
pre-emphasis level 3, so this patch may fix some bugs on
panels/monitors that happen on BDW but not on HSW.

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

drm/i915: Simplify processing of the golden render context state

Rewrite i915_gem_render_state.c for the purposes of clarity and
compactness, in the process we can eliminate some dodgy math that did
not handle 64bit addresses correctly.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Simplify i915_gem_release_all_mmaps()

An object can only have an active gtt mapping if it is currently bound
into the global gtt. Therefore we can simply walk the list of all bound
objects and check the flag upon those for an active gtt mapping.

From commit 48018a57a8f5900e7e53ffaa0adeb784095accfb
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 13 15:22:31 2013 -0200

    drm/i915: release the GTT mmaps when going into D3

Also note that the WARN is inappropriate for this function as GPU
activity is orthogonal to GTT mmap status. Rather it is the caller that
relies upon this condition and so it should assert that the GPU is idle
itself.

References: https://bugs.freedesktop.org/show_bug.cgi?id=80081
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Fix memory leak in intel_dsi_init() error path

intel_dsi_init() bails out without freeing the memory 'intel_dsi' and
'intel_connector' point to. Simply bail out before allocating memory.

Picked up by Coverity - CID 1222750.

Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Improve PSR debugfs status.

Now we have the active/inactive state for exit and this actually changes the
HW enable bit the status was a bit confusing for users. So let's provide
more info.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Force PSR exit by inactivating it.

The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.

However there are many other scenarios that this isn't true. Mainly one right
now is KDE users on HSW and BDW with PSR on. User would miss many screen
updates. For instances any key typed could be seen only when mouse cursor is
moved. So this patch introduces the ability of trigger PSR exit on kernel side
on some common cases that.

Most of the cases are coverred by psr_exit at set_domain. The remaining cases
are coverred by triggering it at set_domain, busy_ioctl, sw_finish and
mark_busy.

The downside here might be reducing the residency time on the cases this
already work very wall like Gnome environment. But so far let's get focused
on fixinge issues sio PSR couild be used for everybody and we could even
get it enabled by default. Later we can add some alternatives to choose the
level of PSR efficiency over boot flag of even over crtc property.

v2: remove exit from connector_dpms. Daniel pointed this is the wrong way and
also this isn't needed for BDW and HSW anyway.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/vlv: disable PPGTT on early revs v3

Early revs didn't have PPGTT support, so disable there.

v2: add debug msg when disabling on early stepping
v3: enable on other B3 packages as well (untested) (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=79669
References: https://bugs.freedesktop.org/show_bug.cgi?id=79670
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix __user sparse warning

CHECK   linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: warning: incorrect type in initializer (different address spaces)
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47:    expected struct drm_i915_gem_exec_object2 *user_exec_list
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47:    got void [noderef] <asn:1>*
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: warning: incorrect type in argument 1 (different address spaces)
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61:    expected void [noderef] <asn:1>*dst
linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61:    got unsigned long long *<noident>

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

drm/i915: Print PCI revision in i915_dump_device_info()

Knowing the device stepping may be crucial in analyzing problems. Since
we always ask bug reporters for dmegs with drm.debug=0xe (or something)
it would be nice if the PCI revision is already included in the dump.
Avoids having to ask for lspci output as well.

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

drm/i915: Add locking around framebuffer_references--

obj->framebuffer_references isn't an atomic_t so the decrement needs to
be protected by some lock. struct_mutex seems like the appropriate lock
here, and we may already take it for the obj unref anyway.

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

drm/i915: PSR HSW: update after enabling sprite.

On the current structure HSW doesn't support PSR with sprites enabled
but sprites can be enabled after PSR was enabled what would cause
user to miss screen updates.

v2: move it to update_plane.

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

drm/i915: BDW PSR: Remove DDIA limitation for Broadwell.

Broadwell has a PSR per transcoder, where DDIA supports
link disable and link standby modes while other
transcoders only support link standby.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: BDW PSR: Remove limitations that aren't valid for BDW.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: BDW PSR: Add single frame update support.

When link is in stand by and PSR exit is triggered by a primary or sprite
plane flip this mode allows only one single updated frame to be send to
display than get back to PSR immediately.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not try to enable PSR when Panel doesn't suport it.

Also do not cache aux info. That info could be related to another panel.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't let update_psr function actually enable PSR.

Being more conservative by enabling PSR only on psr_enable function.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use HAS_PSR to avoid unecessary interactions.

Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.

Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Switch to unified plane cursor handling (v4)

The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support.  This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was called.

The aim here is to transition to the universal plane interface with
minimal code change.  There's a lot of cleanup that can be done (e.g.,
using state stored in crtc->cursor->fb rather than intel_crtc) that is
left to future patches.

v4:
 - Drop drm_gem_object_unreference() that is no longer needed now that
   we receive the GEM obj directly rather than looking up the ID.
v3:
 - Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes,
   even if 'visible' is false.  intel_crtc_cursor_set_obj() will notice
   that the cursor isn't visible and disable it properly, but we still
   need to get intel_crtc->cursor_addr set properly so that we behave
   properly if the cursor becomes visible again in the future without
   changing the cursor buffer (noted by Chris Wilson and verified
   via i-g-t kms_cursor_crc).
 - s/drm_plane_init/drm_universal_plane_init/.  Due to type
   compatibility between enum and bool, everything actually works
   correctly with the wrong init call, except for the type of plane that
   gets exposed to userspace (it shows up as type 'primary' rather than
   type 'cursor').
v2:
 - Remove duplicate dimension checks on cursor
 - Drop explicit cursor disable from crtc destroy (fb & plane
   destruction will take care of that now)
 - Use DRM plane helper to check update parameters

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add intel_crtc_cursor_set_obj() to set cursor buffer (v2)

Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter.  The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call this new function.

This refactoring is in preparation for the universal plane cursor
support where we'll want to update the cursor with an actual GEM buffer
object (obtained via drm_framebuffer) rather than a userspace handle.

v2:  Drop obvious kerneldoc and replace with note about function's
     reference consumption

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Allow drivers to register cursor planes with crtc

Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them.  Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Avoid NULL deference when disabling a plane from userspace

To disable a plane, userspace passes in an framebuffer id of 0. This
causes us to pass CRTC == NULL to setplane_internal, who promptly
deferences it to grab the struct drm_device. Oops.

[ 1296.467327] BUG: unable to handle kernel NULL pointer dereference at   (null)
[ 1296.467332] IP: [<c134dc51>] setplane_internal+0x11/0x280
[ 1296.467338] *pde = 00000000
[ 1296.467341] Oops: 0000 [#1] SMP
[ 1296.467344] Modules linked in: ccm bnep bluetooth snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel arc4 iwldvm snd_hda_controller snd_hda_codec mac80211 snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer iwlwifi sdhci_pci snd cfg80211 x86_pkg_temp_thermal hp_wmi sdhci sparse_keymap mmc_core crc32c_intel rfkill microcode hp_accel lpc_ich lis3lv02d wmi mfd_core serio_raw input_polldev soundcore e1000e ptp pps_core
[ 1296.467367] CPU: 1 PID: 672 Comm: Xorg Tainted: G        W     3.15.0-rc8+ #351
[ 1296.467369] Hardware name: Hewlett-Packard HP ProBook 6360b/1620, BIOS 68SCF Ver. B.42 12/29/2010
[ 1296.467371] task: f423b5c0 ti: c2332000 task.ti: c2332000
[ 1296.467374] EIP: 0060:[<c134dc51>] EFLAGS: 00013286 CPU: 1
[ 1296.467376] EIP is at setplane_internal+0x11/0x280
[ 1296.467378] EAX: 00000000 EBX: c2333e90 ECX: 00000000 EDX: f3165600
[ 1296.467380] ESI: f430f400 EDI: 00000000 EBP: c2333e14 ESP: c2333dd4
[ 1296.467382]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 1296.467384] CR0: 80050033 CR2: 00000000 CR3: 00159000 CR4: 000407d0
[ 1296.467385] Stack:
[ 1296.467387]  000200da 00000002 c2333de8 c15dc4a0 f430f400 c2333e00 c134c54f eeeeeeee
[ 1296.467391]  f430f400 00000007 f416b480 c2333e14 00000000 c2333e90 f430f400 00000000
[ 1296.467396]  c2333e4c c1350aed 00000000 00000000 00000000 00000000 00000000 00000000
[ 1296.467400] Call Trace:
[ 1296.467406]  [<c15dc4a0>] ? mutex_lock+0x10/0x28
[ 1296.467408]  [<c134c54f>] ? _object_find+0x5f/0x90
[ 1296.467413]  [<c1350aed>] drm_mode_setplane+0x10d/0x1f0
[ 1296.467416]  [<c13509e0>] ? drm_mode_getplane+0x100/0x100
[ 1296.467420]  [<c1342e4d>] drm_ioctl+0x1bd/0x4f0
[ 1296.467423]  [<c13509e0>] ? drm_mode_getplane+0x100/0x100
[ 1296.467427]  [<c111c023>] ? handle_mm_fault+0x5d3/0xb30
[ 1296.467431]  [<c1118f31>] ? tlb_finish_mmu+0x11/0x40
[ 1296.467435]  [<c1342c90>] ? drm_ioctl_flags+0x40/0x40
[ 1296.467438]  [<c11593d2>] do_vfs_ioctl+0x2f2/0x4d0
[ 1296.467443]  [<c1226512>] ? inode_has_perm.isra.32+0x32/0x40
[ 1296.467446]  [<c122662f>] ? file_has_perm+0x7f/0x90
[ 1296.467449]  [<c1226fec>] ? selinux_file_ioctl+0x4c/0xf0
[ 1296.467452]  [<c1159610>] SyS_ioctl+0x60/0x90
[ 1296.467456]  [<c15e578c>] sysenter_do_call+0x12/0x22
[ 1296.467457] Code: 3f cf ff eb dd ba 3f 00 00 00 b8 d9 c9 7f c1 e8 e6 3f cf ff eb d9 8d 74 26 00 55 89 e5 57 56 53 83 ec 34 66 66 66 66 90 89 45 f0 <8b> 00 85 c9 89 d6 89 cb 89 45 ec 0f 84 16 01 00 00 8b 45 f0 e8
[ 1296.467485] EIP: [<c134dc51>] setplane_internal+0x11/0x280 SS:ESP 0068:c2

Fixes regression from
commit b02fd7fd8a541c3d590bfdda23365a927b507ceb
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Jun 10 08:28:10 2014 -0700

    drm: Support legacy cursor ioctls via universal planes when possible (v4)

While at it move the plane parameter to the first position in
setplane_internal since that's the main object we're manipulating.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Pallavi G<pallavi.g@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Add note about parameter reordering.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Support legacy cursor ioctls via universal planes when possible (v4)

If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls.  Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition to universal planes will continue to operate
without any change to behavior.

Note that there's a bit of a mismatch between the legacy cursor ioctls
and the universal plane API's --- legacy ioctl's use driver buffer
handles directly whereas the universal plane API takes drm_framebuffers.
Since there's no way to recover the driver handle from a
drm_framebuffer, we can implement legacy ioctl's in terms of universal
plane interfaces, but cannot implement universal plane interfaces in
terms of legacy ioctls.  Specifically, there's no way to create a
general cursor helper in the way we previously created a primary plane
helper.

It's important to land this patch before any patches that add universal
cursor support to individual drivers so that drivers don't have to worry
about juggling two different styles of reference counting for cursor
buffers when userspace mixes and matches legacy and universal cursor
calls.  With this patch, a driver that switches to universal cursor
support may assume that all cursor buffers are wrapped in a
drm_framebuffer and can rely on framebuffer reference counting for all
cursor operations.

v4:
 - Add comments pointing out setplane_internal's reference-eating
   semantics.
v3:
 - Drop drm_mode_rmfb() call that is no longer needed now that we're
   using setplane_internal(), which takes care of deref'ing the
   appropriate framebuffer.
v2:
 - Use new add_framebuffer_internal() function to create framebuffer
   rather than trying to call directly into the ioctl interface and
   look up the handle returned.
 - Use new setplane_internal() function to update the cursor plane
   rather than calling through the ioctl interface.  Note that since
   we're no longer looking up an fb_id, no extra reference will be
   taken here.
 - Grab extra reference to fb under lock in !BO case to avoid issues
   where racing userspace could cause the fb to be destroyed out from
   under us after we grab the fb pointer.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Refactor setplane to allow internal use (v3)

Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID.  We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.

v3:
 - Move integer overflow checking from setplane_internal to setplane
   ioctl.  The upcoming legacy cursor support via universal planes needs
   to maintain current cursor ioctl semantics and not return error for
   these extreme values (found via intel-gpu-tools kms_cursor_crc test).
v2:
 - Allow planes to be disabled without a valid crtc again (and add
   mention of this to setplane's kerneldoc, since it doesn't seem to be
   mentioned anywhere else).
 - Reformat some parameter line wrap

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Refactor framebuffer creation to allow internal use (v2)

Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly.  The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl handler.

v2: Take struct drm_mode_fb_cmd2 parameter directly rather than void*

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Pallavi G<pallavi.g@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Fix "drm/i915/chv: Add a bunch of pre production workarounds"

Correct a merge mishap in commit e4443e459ccf43f2c139358400365fd6a839d40d.

Wa*:chv belongs in cherryview_enable_rps, not gen8_enable_rps.

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bdw: Do not write the Semaphore Sync Registers in GEN8+

These do not exist anymore.

Spotted while reading through intel_ringbuffer.c

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Prefault the entire object on first page fault

Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which we in return receive the benefit of removing the
per-page faulting overhead.

On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces: 8127MiB/s -> 8134MiB/s
Upload rate for 2 tiled surfaces: 8607MiB/s -> 8625MiB/s
Upload rate for 4 linear surfaces: 8127MiB/s -> 8127MiB/s
Upload rate for 4 tiled surfaces: 8611MiB/s -> 8602MiB/s
Upload rate for 8 linear surfaces: 8114MiB/s -> 8124MiB/s
Upload rate for 8 tiled surfaces: 8601MiB/s -> 8603MiB/s
Upload rate for 16 linear surfaces: 8110MiB/s -> 8123MiB/s
Upload rate for 16 tiled surfaces: 8595MiB/s -> 8606MiB/s
Upload rate for 32 linear surfaces: 8104MiB/s -> 8121MiB/s
Upload rate for 32 tiled surfaces: 8589MiB/s -> 8605MiB/s
Upload rate for 64 linear surfaces: 8107MiB/s -> 8121MiB/s
Upload rate for 64 tiled surfaces: 2013MiB/s -> 3017MiB/s

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Testcasee: igt/gem_fence_upload/performance
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix VLV CRC reading.

Adding missing Display mmio reg offset.

Credits-to: Laws, Philip <philip.laws@intel.com>
Cc: He, Shuang <shuang.he@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update DRIVER_DATE to 20140606

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

drm/i915: preserve user forcewake over system suspend/resume

Atm, the forcewake refcount will be incorrectly set to zero during
system suspend if there is any reference held via the
i915_forcewake_user debugfs entry.

Fix this by simply not zeroing the sw counters during suspend and
restoring the original state using them. Note that the only other
places where we zeroed the counters were driver load and unload time,
where it was redundant anyway.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78059
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 possible refcount leak when resetting forcewake

If the timer putting the last forcewake refcount was pending and we
canceled it, we'll leak the corresponding forcewake and RPM references.

v2:
- do the ptr casting at the caller instead of adding a separate helper
  for this (Chris)

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: Use %c in a format string for the pipe name

pipe_name() returns an ascii character.

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

drm/i915/bdw: Add Broadwell support for debugfs rps freq info

Add Broadwell support to i915_frequency_info
and extend i915_max|min_freq_get|set to (gen >= 6).

v2: generalized support for i915_max|min_freq_get|set (Daniel).

Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
[danvet: Fix checkpatch fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't get hw state from DVO chip unless DVO is enabled

Certain DVO chips (ns2501 for example) don't like to be accessed unless
the PLL is running. Simply skip the DVO get_hw_state if the DVO port
is disabled.

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

drm/i915: Use named initializers for gmch wm params

Using names initializers when filling out the watermark structs
saves you from having go look up the struct definition every
single time.

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 the .release hook to drop the stolen drm_mm tracking

Now that we have a release hook into i915_gem_object_free, we can move
the explicit call to the internal stolen function and hook it up
throught the callback instead.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only wait one vblank when disabling crc if the pipe is on

Otherwise we incur an unsightly WARNING. The mutex locking is a bit
overkill, but it curbs races and eventially we might grow a locking
check in the vblank wait code to make sure the right crtc lock is
held.

This is fallout from

commit 9393707190194eb8b42e412b444a03331db6862f
Author:     Jesse Barnes <jbarnes@virtuousgeek.org>
AuthorDate: Fri Apr 4 16:12:09 2014 -0700

    drm/i915: warn when a vblank wait times out

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79612
Tested-by: Guo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Rebase on top of drm core ww locking changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add #defines for short/long pulse on gmch platforms

For no reason at all the public docs lack them, and Dave needs them
for his hpd interrupt rework.

Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Simplify intel_gpu_reset

Replaced ever growing switch for gen version with chained conditionals.
Futre gen's only need to add a new one if they require something different.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Robert Beckett <robert.beckett@intel.com>
[danvet: Picked from internal tree and white-wash commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop unused lut tables from intel_plane

Those LUT where defined in the original sprite patch introducing intel_plane,
but were never used.

  commit b840d907fcf6d5d5ef91af4518b3dab3a5da0f75
  Author: Jesse Barnes <jbarnes@virtuousgeek.org>
  Date:   Tue Dec 13 13:19:38 2011 -0800

    drm/i915: add SNB and IVB video sprite support v6

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Pimp commit message as suggested by Damien]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: runtime PM support for DPMS

Keeping track of the power domains is a bit messy since crtc->active
is currently updated by the platform hooks, but we need to be aware of
which state transition exactly is going on. Maybe we simply need to
shovel all the power domain handling down into platform code to
simplify this. But doing that requires some more auditing since
currently the ->mode_set callbacks still read some random registers
(to e.g. figure out the reference clocks).

Also note that intel_crtc_update_dpms is always call first/last even
for encoders which have their own dpms functions. Hence we really only
need to update this place here.

Being a quick "does it blow up?" run not really tested yet.

v2: Don't do runtime PM in the DPMS hooks for HAS_DDI platforms since
that is stalled. Also add a comment to explain what's going on.

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

drm/i915: enable PPGTT on VLV

Working for real this time.  i915_ppgtt_info has all sorts of good stuff
in it and X is running nicely on top.

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: Use transcoder as index to MIPI regs

Conceptually, the MIPI registers are addressed by the MIPI transcoder
index, not the pipe. It doesn't matter right now, because there's a
1:1 relationship between pipes and MIPI transcoders, but that change
allows us to break that link in the future

V1: Created new patch to address Damien's review comment.
Replacing _PIPE calls to _TRANSCODER calls
V2: Re-basing on patch 2
V3: Re-basing on patch 2
V4: Re-basing on patch 2

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Change Mipi register definitions

Re-define MIPI register definitions in such a way that most of
the existing DSI code can be re-used for future platforms. Register
definitions are re-written using MMIO offset variable, so that without
changing the existing sequence, same code can be generically applied.

V4: Addressing review comments by Damien and Ville, splitting into two patches
This patch removes all the un-necessary formatting changes from previous patch.
V5: Removed 80 char limit formatting for existing MIPI regs
V6: Removed extra space, change one definition

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/dma: style fixes

Fixed several double space pointer notations, and added one newline

Signed-off-by: Robin Schroer <sulamiification@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use shmem helpers if possible

Instead of shuffling gfp-masks all the time, use the
shmem_read_mapping_page() helper. Note that __GFP_IO and __GFP_WAIT are
set in mapping_gfp_mask() for i915, so the behavior is still the same.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Intel-specific primary plane handling (v8)

Intel hardware allows the primary plane to be disabled independently of
the CRTC.  Provide custom primary plane handling to allow this.

v8:
 - Pin/unpin properly when clipping causes the primary plane to be
   disabled when it has previously been enabled.
 - s/drm_primary_helper_check_update/drm_plane_helper_check_update/
v7:
 - Clip primary plane to invisible when crtc is disabled since
   intel_crtc->config.pipe_src_{w,h} may be garbage otherwise.
 - Unpin old fb before pinning new one in the "just pin and
   return" case that is used when the crtc is disabled.
 - Don't treat implicit disabling of the primary plane (caused by
   clipping) the same way as explicit disabling (caused by fb=0).
   For implicit disables, we should leave the fb set and pinned,
   whereas for explicit disables we need to unpin the fb before
   primary->fb is cleared.
v6:
 - Pass rectangles to primary helper check function and get plane
   visibility back.
 - Wait for pending pageflips on primary plane update/disable.
 - Allow primary plane to be updated while the crtc is disabled (changes
   will take effect when the crtc is re-enabled if modeset passes -1
   for the fb id).
 - Drop WARN() if we try to disable the primary plane when it's
   already been disabled.  This will happen if the crtc gets disabled
   after the primary plane has already been disabled independently.
v5:
 - Use new drm_primary_helper_check_update() helper function to check
   setplane parameter validity.
 - Swap primary plane's pipe for pre-gen4 FBC (caught by Ville Syrjälä)
 - Cleanup primary plane properly on crtc init failure
v4:
 - Don't add a primary_plane field to intel_crtc; that was left over
   from a much earlier iteration of this patch series, but is no longer
   needed/used now that the DRM core primary plane support has been
   merged.
v3:
 - Provide gen-specific primary plane format lists (suggested by Daniel
   Vetter).
 - If the primary plane is already enabled, go ahead and just call the
   primary plane helper to do the update (suggested by Daniel Vetter).
 - Don't try to disable the primary plane on destruction; the DRM layer
   should have already taken care of this for us.
v2:
 - Unpin fb properly on primary plane disable
 - Provide an Intel-specific set of primary plane formats
 - Additional sanity checks on setplane (in line with the checks
   currently being done by the DRM core primary plane helper)

Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't force full modeset if primary plane is disabled (v2)

In a future patch, we'll allow the primary plane to be disabled by
userspace via the universal plane API.  If a modeset is requested while
the primary plane is disabled, crtc->primary->fb will be NULL which
generally triggers a full modeset (except in fastboot situations).  If
we detect that the crtc is active, but there's no primary plane fb,
we should still allow a simple plane update rather than a full modeset
if the mode isn't actually changing (after re-enabling the primary plane
of course).

v2:
 - Enable plane after set_base to avoid enabling the plane if set_base
   fails, and to make flip+enable atomic (suggested by Ville)
 - Drop BUG to WARN if we somehow enter the 'fb_changed' modeset case
   with the crtc disabled (suggested by Ville)

Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop locking around fbdev-fb in debugfs

All the date we print is invariant for the lifetime of the driver.
And none of it would be protected by the mode_config.mutex anyway.
So drop it.

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

drm/i915: Fix context locking in debugfs

This goes all the way back to the introduction of this debugfs file,
even though back then no locking really was required. None of the
intermediate patches fixed this.

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

drm/i915: Check for a NULL shared dpll before dereferencing

This doesn't look possible but a little extra defense against the
improbable is worth it - an oops here could lockup the machine.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make intel_dsi_init() return void

Functions that can't fail are such a bliss to work with, it'd be shame
to miss the occasion. The "failure" mode is the DSI connector not being
created, the rest of the initialization can carry on happily.

We weren't even checking that value anyway.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Shobhit Kumar <shobhit.kumar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Also convert the missed return statement due to other patches
merged meanwhile.]
[danvet2: Squash in fixup from Damien to remove empty return; at the
end of intel_dsi_init.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix checkpatch errors

Fix warnings introduced by the following commit -

commit 9c92da2c7c17eea79b6321b37592df0a002d24df
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date:   Fri May 23 21:35:27 2014 +0530

    drm/i915: Add support for Generic MIPI panel driver

Fixed all except the DRM logging which go beyond line 80

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Handle video DIP registers on CHV

The DIP registers are a mess on VLV and CHV. The register block on pipe
A is different than the register block on pipes B and C. In order to
handle that using the pipe offsets, we'd need a new pipe offset per
register, which seems wasteful. So instead just use the _PIPE3() macro
to handle these registers.

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: Don't use pipe_offset stuff for DPLL registers

These are just single registers so wasting space for the pipe offsets
seems a bit pointless. So just use the _PIPE3() macro instead.

Also rewrite the _PIPE3() macro to be more obvious, and protect the
arguments properly.

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

drm/i915/chv: Force PHY clock buffers off after PLL disable

Now that we forced the clock buffers on in .pre_pll_enable() we
should probably undo the damage after we've turned the PLL off.

We do the clock buffer force enable in the .pre_pll_enable() hook
as we need to know which port is going to be used, but in the disable
case we don't need the port since we just disable the clock buffers
to both channels. So we can do this in chv_disable_pll() instead
of having to add any kind of .post_pll_disable() hook.

v2: Improve the commit message

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Force clock buffer enables

Try to force the PHY clock buffer enables to make the clock routing
work.

v2: Fix the pipe B case to actually enable CH0 clock buffers

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Try to program the PHY used clock channel overrides

These should make it possible to feed port C from pipe A or port B from
pipe B. Didn't quite seem to work though.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Freq(opcode) request for CHV.

On CHV, All the freq request should be even. So, we need to make sure we
request the opcode accordingly.

v2: Avoid vairable for freq request (ville)

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Skip gen6_gt_check_fifodbg() on CHV

CHV uses the gen8 shadow register mechanism so we shouldn't be
checking the GT FIFO status.

This effectively removes the posting read, so add an explicit
posting read using FORCEWAKE_ACK_VLV (which is what use in
vlv_forcewake_reset()).

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: CHV doesn't need WaRsForcewakeWaitTC0

Skip __gen6_gt_wait_for_thread_c0() on CHV.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Enable RPS (Turbo) for Cherryview

v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville)

v3: Mass rename of the dev_priv->rps variables in upstream.

v4: Rebase against latest code. (Deepak)

v5: Rebase against latest nightly code. (Deepak)

v6: Rename the variables to match the spec (Mika)

v7: change min/max freq variable naming to match spec (Mika)

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Keep vblank interrupts enabled while enabling/disabling planes

Because of the upcoming vblank interrupt driven watermark update
mechanism we will have use for vblank interrupts during plane
enabling/disabling. So don't call drm_vblank_off() until planes
are off, and call drm_vblank_on() just before we start to enable
the planes.

v2: Pimp commit message (Paulo)

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

drm/i915/chv: Added CHV specific register read and write and Streamline CHV forcewake stuff

Support to individually control Media/Render well based on the register access.
Add CHV specific write function to habdle difference between registers
that are sadowed vs those that need forcewake even for writes.

Streamline the CHV forcewake functions just like was done for VLV.

This will also fix a bug in accessing the common well registers,
where we'd end up trying to wake up the wells too many times
since we'd call force_wake_get/put twice per register access, with
FORCEFAKE_ALL both times.

v2: Drop write FIFO for CHV and add comman well forcewake (Ville)
    Re-factor CHV/VLV Forcewake offsets (Ben)

v3: Fix for decrementing fw count in chv read/write. (Deepak)

v4: Squash the patches (Mika)

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[vsyrjala: Move the register range macros into intel_uncore.c]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/chv: Enable Render Standby (RC6) for Cherryview

v2: Configure PCBR if BIOS fails allocate pcbr (deepak)

v3: Fix PCBR condition check during CHV RC6 Enable flag set

v4: Fixup PCBR comment msg. (Chris)
    Rebase against latest code (Deak)
    Fixup Spurious hunk (Ben)

v5: Fix PCBR and commentis msg (mika)

v6: Rebase patch on latest nightly (Deepak)

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move psr_setup_done to psr struct

"Because our driver assumes only one panel is PSR capable, and we
already have other PSR information on dev_priv instead of intel_dp. If
we ever support multiple PSR panels, we'll have to move struct
i915_psr to intel_dp anyway." (by Paulo)

v2: Avoid more than one setup. Removing initialization
    and trusting allocation. (By Paulo Zanoni).
v3: rebase.
v4: Adding comment.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
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

display rework fixes lots of displayport issues.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (43 commits)
  drm/nouveau/disp/dp: fix tmds passthrough on dp connector
  drm/nouveau/dp: probe dpcd to determine connectedness
  drm/nv50-: trigger update after all connectors disabled
  drm/nv50-: prepare for attaching a SOR to multiple heads
  drm/gf119-/disp: fix debug output on update failure
  drm/nouveau/disp/dp: make use of postcursor when its available
  drm/g94-/disp/dp: take max pullup value across all lanes
  drm/nouveau/bios/dp: parse lane postcursor data
  drm/nouveau/dp: fix support for dpms
  drm/nouveau: register a drm_dp_aux channel for each dp connector
  drm/g94-/disp: add method to power-off dp lanes
  drm/nouveau/disp/dp: maintain link in response to hpd signal
  drm/g94-/disp: bash and wait for something after changing lane power regs
  drm/nouveau/disp/dp: split link config/power into two steps
  drm/nv50/disp: train PIOR-attached DP from second supervisor
  drm/nouveau/disp/dp: make use of existing output data for link training
  drm/gf119/disp: start removing direct vbios parsing from supervisor
  drm/nv50/disp: start removing direct vbios parsing from supervisor
  drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal
  drm/nouveau/disp/dp: create subclass for dp outputs
  ...

drm/nouveau/disp/dp: fix tmds passthrough on dp connector

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

drm/nouveau/dp: probe dpcd to determine connectedness

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

drm/nv50-: trigger update after all connectors disabled

We were sending the necessary state changes to unset the mode, but
never actually hit the big GO button unless another modeset happens
afterwards.

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

drm/nv50-: prepare for attaching a SOR to multiple heads

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

drm/gf119-/disp: fix debug output on update failure

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

drm/nouveau/disp/dp: make use of postcursor when its available

And at the same time, obey the spec better wrt out-of-range requests.

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

drm/g94-/disp/dp: take max pullup value across all lanes

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

drm/nouveau/bios/dp: parse lane postcursor data

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

drm/nouveau/dp: fix support for dpms

SOR_PWR has no effect to power-off DP links, unlike other SOR protocols.

Instead, on the source side, we cut power to the lanes after having put
the sink into D3.  Link training takes care of everything required to
bring it back again.

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

drm/nouveau: register a drm_dp_aux channel for each dp connector

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

drm/g94-/disp: add method to power-off dp lanes

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

drm/nouveau/disp/dp: maintain link in response to hpd signal

This previously worked for the most part due to userspace doing a
modeset in response to HPD interrupts.  This will allow us to
properly handle cases where sync is lost for other reasons, or if
userspace isn't caring.

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

drm/g94-/disp: bash and wait for something after changing lane power regs

Some kind of update?  Needed to make the power-down take effect at least.

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

drm/nouveau/disp/dp: split link config/power into two steps

We want to be able to power down the lanes for DPMS off.

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

drm/nv50/disp: train PIOR-attached DP from second supervisor

Same place as for SOR, between detach and attach phases.

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

drm/nouveau/disp/dp: make use of existing output data for link training

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

drm/gf119/disp: start removing direct vbios parsing from supervisor

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

drm/nv50/disp: start removing direct vbios parsing from supervisor

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

drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal

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

drm/nouveau/disp/dp: create subclass for dp outputs

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

drm/nouveau: use connector events for HPD instead of GPIO watching

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

drm/nouveau/disp: add internal representaion of output paths and connectors

This will, at some point, be used to replace various bits and pieces of
code doing direct bios parsing.  For now, it'll just be used for some
DP improvements.

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

drm/nouveau/bios: extend connector table parsing

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

drm/nouveau/disp: nothing to see here

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

drm/nouveau/i2c/anx9805: add debugging to aux transactions

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

drm/nouveau/i2c: introduce locking at a per-port level

There's also provisions to allow a pad to be locked with a specific
routing, for an indefinite period of time.  This will be used in
future patches.

The G94+ pad driver will now also power-down pads when not required.

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

drm/nouveau/i2c: balance port acquire/release

This was a half-finished hack before, just enough to handle the shared
aux/i2c pad thing on G94 and up.

We got lucky with locking etc up until now, as this was (generally) all
protected by the DRM mode_config lock.  It's about to become a lot more
likely to hit the races.

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

drm/gk104/i2c: add aux channel interrupt driver

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