As we know by inspection whether any engine is still busy as we retire
all the requests, we can pass that information back via return value
rather than check again afterwards.

v2: A little more polish missed in patch splitting
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160827075401.16470-1-chris@chris-wilson.co.uk

With full-ppgtt, we want the user to have full control over their memory
layout, with a separate instance per context. Forcing them to use a
shared memory layout for !RCS not only duplicates the amount of work we
have to do, but also defeats the memory segregation on offer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20160822080350.4964-4-chris@chris-wilson.co.ukReviewed-by: NJohn Harrison <john.c.harrison@intel.com>
Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to the CI test machines, SNB also uses the
GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
GEN6_PCODE_MIN_FREQ_TABLE request.

[  157.744641] WARNING: CPU: 5 PID: 9238 at
drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744642] Missing switch case (16) in gen6_check_mailbox_status
[  157.744642] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me lpc_ich snd_pcm mei broadcom bcm_phy_lib tg3 ptp pps_core [last unloaded: vgem]
[  157.744658] CPU: 5 PID: 9238 Comm: drv_hangman Tainted: G     U  W 4.8.0-rc3-CI-CI_DRM_1589+ #1
[  157.744658] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[  157.744659]  0000000000000000 ffff88011f093a98 ffffffff81426415 ffff88011f093ae8
[  157.744662]  0000000000000000 ffff88011f093ad8 ffffffff8107d2a6 00001e50810d3c9f
[  157.744663]  ffff880128680000 0000000000000008 0000000000000000 ffff88012868a650
[  157.744665] Call Trace:
[  157.744669]  [<ffffffff81426415>] dump_stack+0x67/0x92
[  157.744672]  [<ffffffff8107d2a6>] __warn+0xc6/0xe0
[  157.744673]  [<ffffffff8107d30a>] warn_slowpath_fmt+0x4a/0x50
[  157.744685]  [<ffffffffa0029831>] sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744697]  [<ffffffffa002a88a>] intel_enable_gt_powersave+0x64a/0x1330 [i915]
[  157.744712]  [<ffffffffa006b4cb>] ? i9xx_emit_request+0x1b/0x80 [i915]
[  157.744725]  [<ffffffffa0055ed3>] __i915_add_request+0x1e3/0x370 [i915]
[  157.744738]  [<ffffffffa00428bd>] i915_gem_do_execbuffer.isra.16+0xced/0x1b80 [i915]
[  157.744740]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744752]  [<ffffffffa0043b72>] i915_gem_execbuffer2+0xc2/0x2a0 [i915]
[  157.744753]  [<ffffffff815485b7>] drm_ioctl+0x207/0x4c0
[  157.744765]  [<ffffffffa0043ab0>] ? i915_gem_execbuffer+0x360/0x360 [i915]
[  157.744767]  [<ffffffff810ea4ad>] ?  debug_lockdep_rcu_enabled+0x1d/0x20
[  157.744769]  [<ffffffff811fe09e>] do_vfs_ioctl+0x8e/0x680
[  157.744770]  [<ffffffff811a2377>] ? __might_fault+0x87/0x90
[  157.744771]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744773]  [<ffffffff810d3df2>] ?  trace_hardirqs_on_caller+0x122/0x1b0
[  157.744774]  [<ffffffff811fe6cc>] SyS_ioctl+0x3c/0x70
[  157.744776]  [<ffffffff8180fe69>] entry_SYSCALL_64_fastpath+0x1c/0xac

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97491
Fixes: 87660502 ("drm/i915/gen6+: Interpret mailbox error flags")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160826105926.3413-1-chris@chris-wilson.co.ukAcked-by: NMika Kuoppala <mika.kuoppala@intel.com>

The eDP backlight and panel enable/disable delays are quite
useful to know when measuring time consumed by suspend/resume,
and while the information is printed to the kernel log as debug
messages, having this information in debugfs makes things easier.
Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823092356.7610-1-david.weinehall@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Now that we have working partial VMA and faulting support for all
objects, including fence support, advertise to userspace that it can
take advantage of unlimited GGTT mmaps.

v2: Make room in the kerneldoc for a more detailed explanation of the
limitations of the GTT mmap interface.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160825180519.11341-1-chris@chris-wilson.co.uk

Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxxxxxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()
Changes since v4:
 - Remove the second loop in intel_update_crtcs() and use Ville's
   suggestion for updating the ddb allocations in the right order
 - Get rid of the second loop and just use the ddb state as it updates
   to determine what order to update everything in (thanks for the
   suggestion Ville)
 - Simplify skl_ddb_allocation_overlaps()
 - Split actual overlap checking into it's own helper

Fixes: 0e8fb7ba ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5b ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Testcase: plane-all-modeset-transition
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-2-git-send-email-cpaul@redhat.com

Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.

Based off of Matt Rope's suggestions

Changes since v1:
 - Drop pipe_config->base.active check in intel_update_crtcs() since we
   check that before calling the function
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471961565-28540-1-git-send-email-cpaul@redhat.com

A side effect of removing the midlayer from driver loading was the loss
of a useful message announcing to userspace that i915 had successfully
started, e.g.:

	[drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0
Reported-by: NTimo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 8f460e2c ("drm/i915: Demidlayer driver loading")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160825072314.17402-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order for the RC6 autoenable worker to take any action, RC6 first
must be disabled. Upon resume or reset, the sw state may be stale and so
we require a forced restore.

Fixes: b7137e0c ("drm/i915: Defer enabling rc6 til after we submit...")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160824092701.19178-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

The D_COMP (render decompression) register write is followed by a status
check and another error (either that the decompression shutdown or the
lpll is enabled). Since we are followed by another, more pertinent,
error we can reduce the pcode timeout to a debug and squelch a sporadic
error message during suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97465Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20160824101607.13671-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>

This reverts commit 8678fdaf ("drm/i915/fbc: Allow on unfenced surfaces,
for recent gen") as Skylake has issues with unfenced FBC tracking (and
yes Skylake doesn't even enable FBC yet). Paulo would like to do a full
review of all existing workarounds to see if any more are missing prior
to allowing FBC on unfenced surfaces. In the meantime lets hope that all
framebuffers are idle and naturally fit within the mappable aperture.
Requested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Fixes: 8678fdaf ("drm/i915/fbc: Allow on unfenced surfaces...");
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160824180053.24239-1-chris@chris-wilson.co.ukSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

No functional change, just clean up.
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470897673-29292-3-git-send-email-dhinakaran.pandiyan@intel.com

A full dump of link status can be handy in debugging link training
failures. Let's add that to the debug messages when link training fails.

v2: Removing unrelated clean up (Jani)
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470343716-5574-3-git-send-email-dhinakaran.pandiyan@intel.com

Currently we do not print the training pattern used in any of the DP link
training stages. Including this piece of information in debug messages will
help debugging.

Also, use the wrapper intel_dp_program_link_training_pattern() in
intel_dp_enable_port() instead of implementing it.

v2: Downgraded log level from error to debug (Chris)
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470343716-5574-2-git-send-email-dhinakaran.pandiyan@intel.com

We need to free the allocated intel_fb in the error path, not
intel_fb->base. Otherwise we risk calling kfree with a non-kmalloc'd
address, which is bound to give us grief at some point.
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471964444-24460-1-git-send-email-matthew.auld@intel.com

If we hit the error path, we have never called drm_encoder_init() and so
have nothing to cleanup. Doing so hits a null dereference:

[   10.066261] BUG: unable to handle kernel NULL pointer dereference at 00000104
[   10.066273] IP: [<c16054b4>] mutex_lock+0xa/0x15
[   10.066287] *pde = 00000000
[   10.066295] Oops: 0002 [#1]
[   10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom lm85 hwmon_vid autofs4
[   10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted 4.8.0-rc3-00013-gef0e1ea8 #34
[   10.066389] Hardware name: MicroLink                               /D865GLC                        , BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005
[   10.066401] task: f62db800 task.stack: f5970000
[   10.066409] EIP: 0060:[<c16054b4>] EFLAGS: 00010286 CPU: 0
[   10.066417] EIP is at mutex_lock+0xa/0x15
[   10.066424] EAX: 00000104 EBX: 00000104 ECX: 00000000 EDX: 80000000
[   10.066432] ESI: 00000000 EDI: 00000104 EBP: f5be8000 ESP: f5971b58
[   10.066439]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
[   10.066446] CR0: 80050033 CR2: 00000104 CR3: 35945000 CR4: 000006d0
[   10.066453] Stack:
[   10.066459]  f503d740 f824dddf 00000000 f61170c0 f61170c0 f82371ae f850f40e 00000001
[   10.066476]  f61170c0 f5971bcc f5be8000 f9c2d401 00000001 f8236fcc 00000001 00000000
[   10.066491]  f5144014 f5be8104 00000008 f9c5267c 00000007 f61170c0 f5144400 f9c4ff00
[   10.066507] Call Trace:
[   10.066526]  [<f824dddf>] ? drm_modeset_lock_all+0x27/0xb3 [drm]
[   10.066545]  [<f82371ae>] ? drm_encoder_cleanup+0x1a/0x132 [drm]
[   10.066559]  [<f850f40e>] ? drm_atomic_helper_connector_reset+0x3f/0x5c [drm_kms_helper]
[   10.066644]  [<f9c2d401>] ? intel_dvo_init+0x569/0x788 [i915]
[   10.066663]  [<f8236fcc>] ? drm_encoder_init+0x43/0x20b [drm]
[   10.066734]  [<f9bf1fce>] ? intel_modeset_init+0x1436/0x17dd [i915]
[   10.066791]  [<f9b37636>] ? i915_driver_load+0x85a/0x15d3 [i915]
[   10.066846]  [<f9b3603d>] ? i915_driver_open+0x5/0x5 [i915]
[   10.066857]  [<c14af4d0>] ? firmware_map_add_entry.part.2+0xc/0xc
[   10.066868]  [<c1343daf>] ? pci_device_probe+0x8e/0x11c
[   10.066878]  [<c140cec8>] ? driver_probe_device+0x1db/0x62e
[   10.066888]  [<c120c010>] ? kernfs_new_node+0x29/0x9c
[   10.066897]  [<c13438e0>] ? pci_match_device+0xd9/0x161
[   10.066905]  [<c120c48b>] ? kernfs_create_dir_ns+0x42/0x88
[   10.066914]  [<c140d401>] ? __driver_attach+0xe6/0x11b
[   10.066924]  [<c1303b13>] ? kobject_add_internal+0x1bb/0x44f
[   10.066933]  [<c140d31b>] ? driver_probe_device+0x62e/0x62e
[   10.066941]  [<c140a2d2>] ? bus_for_each_dev+0x46/0x7f
[   10.066950]  [<c140c502>] ? driver_attach+0x1a/0x34
[   10.066958]  [<c140d31b>] ? driver_probe_device+0x62e/0x62e
[   10.066966]  [<c140b758>] ? bus_add_driver+0x217/0x32a
[   10.066975]  [<f8403000>] ? 0xf8403000
[   10.066982]  [<c140de27>] ? driver_register+0x5f/0x108
[   10.066991]  [<c1000493>] ? do_one_initcall+0x49/0x1f6
[   10.067000]  [<c1082299>] ? pick_next_task_fair+0x14b/0x2a3
[   10.067008]  [<c1603c8d>] ? __schedule+0x15c/0x4fe
[   10.067016]  [<c1604104>] ? preempt_schedule_common+0x19/0x3c
[   10.067027]  [<c11051de>] ? do_init_module+0x17/0x230
[   10.067035]  [<c1604139>] ? _cond_resched+0x12/0x1a
[   10.067044]  [<c116f9aa>] ? kmem_cache_alloc+0x8f/0x11f
[   10.067052]  [<c11051de>] ? do_init_module+0x17/0x230
[   10.067060]  [<c11703dd>] ? kfree+0x137/0x203
[   10.067068]  [<c110523d>] ? do_init_module+0x76/0x230
[   10.067078]  [<c10cadf3>] ? load_module+0x2a39/0x333f
[   10.067087]  [<c10cb8b2>] ? SyS_finit_module+0x96/0xd5
[   10.067096]  [<c1132231>] ? vm_mmap_pgoff+0x79/0xa0
[   10.067105]  [<c1001e96>] ? do_fast_syscall_32+0xb5/0x1b0
[   10.067114]  [<c16086a6>] ? sysenter_past_esp+0x47/0x75
[   10.067121] Code: c8 f7 76 c1 e8 8e cc d2 ff e9 45 fe ff ff 66 90 66 90 66 90 66 90 90 ff 00 7f 05 e8 4e 0c 00 00 c3 53 89 c3 e8 75 ec ff ff 89 d8 <ff> 08 79 05 e8 fa 0a 00 00 5b c3 53 89 c3 85 c0 74 1b 8b 03 83
[   10.067180] EIP: [<c16054b4>] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58
[   10.067190] CR2: 0000000000000104
[   10.067222] ---[ end trace 049f1f09da45a856 ]---
Reported-by: NMeelis Roos <mroos@linux.ee>
Fixes: 580d8ed5 ("drm/i915: Give encoders useful names")
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823092558.14931-1-chris@chris-wilson.co.uk

Instead of iterating overthe connectors manually, run the last part of
DDI disabling inside the crt post disable function.

This was meant to be addressed before submitting the other commit,
but I missed the review comments.

Fixes: fd6bbda9 ("drm/i915: Pass crtc_state and connector_state to encoder functions")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471961888-10771-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[mlankhorst: Fix extra whitespace between functions.]

This makes the code in intel_sanitize_encoder slightly more readable.
This was meant to be addressed in fd6bbda9, but I missed that
review comment.

Fixes: fd6bbda9 ("drm/i915: Pass crtc_state and connector_state to encoder functions")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471961888-10771-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[mlankhorst: Fix unused variable reported by kbuild.]

Somehow architectures can't agree on this. And for good measure make
sure we have a fallback which should work everywhere (fingers
crossed).

v2: Make it compile properly, needs a defined() for the #elif.

Fixes: ac96b556 ("io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: linux-mm@kvack.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823202233.4681-1-daniel.vetter@ffwll.ch

PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t
used for the iomapped region, it itself is just PAGE_KERNEL. On all
other arches, PAGE_KERNEL_IO is undefined so in a general header we must
refrain from using it.

v2: include pgtable for pgprot_combine()
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Fixes: cafaf14a ("io-mapping: Always create a struct to hold metadata about the io-mapping")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: linux-mm@kvack.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823155024.22379-1-chris@chris-wilson.co.uk

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
     - intel_pre_plane_update:
        - intel_update_watermarks()
     - {vblank happens; new watermarks + old plane values => underrun }
     - drm_atomic_helper_commit_planes_on_crtc:
        - start vblank evasion
        - write new plane registers
        - end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
     - crtc_enable:
        - intel_update_watermarks()
     - {vblank happens; new watermarks + old plane values => underrun }
     - drm_atomic_helper_commit_planes_on_crtc:
        - start vblank evasion
        - write new plane registers
        - end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
     - intel_pre_plane_update:
        - intel_update_watermarks() (wm values aren't written yet)
     - drm_atomic_helper_commit_planes_on_crtc:
        - start vblank evasion
        - write new plane registers
        - write new wm values
        - end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
     - crtc_enable:
        - intel_update_watermarks() (actual wm values aren't written
          yet)
     - drm_atomic_helper_commit_planes_on_crtc:
        - start vblank evasion
        - write new plane registers
	- write new wm values
        - end vblank evasion
  }

So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.

Changes since original patch series:
 - Remove mutex_lock/mutex_unlock since they don't do anything and we're
   not touching global state
 - Move skl_write_cursor_wm/skl_write_plane_wm functions into
   intel_pm.c, make externally visible
 - Add skl_write_plane_wm calls to skl_update_plane
 - Fix conditional for for loop in skl_write_plane_wm (level < max_level
   should be level <= max_level)
 - Make diagram in commit more accurate to what's actually happening
 - Add Fixes:

Changes since v1:
 - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
   then just Skylake
 - Update description to make it clear this patch doesn't fix everything
 - Check if pipes were actually changed before writing watermarks

Changes since v2:
 - Write PIPE_WM_LINETIME during vblank evasion

Changes since v3:
 - Rebase against new SAGV patch changes

Changes since v4:
 - Add a parameter to choose what skl_wm_values struct to use when
   writing new plane watermarks

Changes since v5:
 - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
   patch 6
 - Write WM_LINETIME in intel_begin_crtc_commit()

Changes since v6:
 - Remove redundant dirty_pipes check in skl_write_plane_wm (we check
   this in all places where we call this function, and it was supposed
   to have been removed earlier anyway)
 - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
   IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
   needs to be done for gen10 as well

Changes since v7:
 - Fix rebase fail (unused variable obj)
 - Make struct skl_wm_values *wm const
 - Fix indenting
 - Use INTEL_GEN() instead of dev_priv->info.gen

Changes since v8:
 - Don't forget calls to skl_write_plane_wm() when disabling planes
 - Use INTEL_GEN(), not INTEL_INFO()->gen in intel_begin_crtc_commit()

Fixes: 2d41c0b5 ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cpaul@redhat.com
Link: http://patchwork.freedesktop.org/patch/msgid/1471884608-10671-1-git-send-email-cpaul@redhat.com

crtc_state is already passed around, use it instead of crtc->config.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-16-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Slightly less straightforward. Some of the drrs calls are done from
workers or from intel_ddi.c, pass along crtc_state when we can,
or crtc->config when we can't.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-15-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-14-git-send-email-maarten.lankhorst@linux.intel.com
[mlankhorst: Address bikeshed.]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-13-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[mlankhorst: Small fixup wrt register renames.]

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-12-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-11-git-send-email-maarten.lankhorst@linux.intel.com
[mlankhorst: Unbreak bxt_dsi_get_pipe_config]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-10-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-9-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that conn_state is passed in as argument to compute_config, it's
guaranteed that there is a connector for the argument. The code that
looks for the connector is now dead, and completely unused. Delete it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-8-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some places iterate over connector_state to find the right
connector, pass it along as argument.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-7-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is mostly code churn, with exception of a few places:
- intel_display.c has changes in intel_sanitize_encoder
- intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable,
  and required a function change. Also affects intel_display.c
- intel_dp_mst.c passes a NULL crtc_state and conn_state to
  intel_ddi_post_disable for shutting down the real encoder.

  If we would pass conn_state, then conn_state->connector !=
  intel_dig_port->connector and conn_state->best_encoder !=
  to_intel_encoder(intel_dig_port).

  We also shouldn't pass crtc_state, because in that case the
  disabling sequence may potentially be different depending on
  which crtc is disabled last. Nice way to introduce bugs.

No other functional changes are done, diff stat is already huge.
Each encoder type will need to be fixed to use the atomic states
separately.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-6-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This cleans up another possible use of the connector list,
encoder->crtc is legacy state and should not be used.

With the atomic state as argument it's easy to find the encoder from
the connector it belongs to.

intel_opregion_notify_encoder is a noop for !HAS_DDI, so it's harmless
to unconditionally include it in encoder enable/disable.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-5-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-4-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is required for supporting nonblocking modesets. Iterating over
the connector list will no longer be allowed when we don't hold
connection_mutex, so we have to use the atomic state.

Fix disable_noatomic by populating the minimal state required to
disable a connector.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-3-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No idea if it supports it, but this is the minimum required from get_dpll.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we do many register reads within a very short period of time, hold
the GMBUS powerwell from start to finish.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160819164503.17845-1-chris@chris-wilson.co.ukReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>

An unlikely ABBA deadlock in debugfs that no one has reported.

[  284.922349] ======================================================
[  284.922355] [ INFO: possible circular locking dependency detected ]
[  284.922361] 4.8.0-rc2+ #430 Tainted: G        W
[  284.922366] -------------------------------------------------------
[  284.922371] cat/1197 is trying to acquire lock:
[  284.922376]  (&dev->filelist_mutex){+.+...}, at: [<ffffffffa0055ba2>] i915_ppgtt_info+0x82/0x390 [i915]
[  284.922423]
[  284.922423] but task is already holding lock:
[  284.922429]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0055b55>] i915_ppgtt_info+0x35/0x390 [i915]
[  284.922465]
[  284.922465] which lock already depends on the new lock.
[  284.922465]
[  284.922471]
[  284.922471] the existing dependency chain (in reverse order) is:
[  284.922477]
-> #1 (&dev->struct_mutex){+.+.+.}:
[  284.922493]        [<ffffffff81087710>] lock_acquire+0x60/0x80
[  284.922505]        [<ffffffff8143e96f>] mutex_lock_nested+0x5f/0x360
[  284.922520]        [<ffffffffa004f877>] print_context_stats+0x37/0xf0 [i915]
[  284.922549]        [<ffffffffa00535f5>] i915_gem_object_info+0x265/0x490 [i915]
[  284.922581]        [<ffffffff81144491>] seq_read+0xe1/0x3b0
[  284.922592]        [<ffffffff811f77b3>] full_proxy_read+0x83/0xb0
[  284.922604]        [<ffffffff8111ba03>] __vfs_read+0x23/0x110
[  284.922616]        [<ffffffff8111c9b9>] vfs_read+0x89/0x110
[  284.922626]        [<ffffffff8111dbf4>] SyS_read+0x44/0xa0
[  284.922636]        [<ffffffff81442be9>] entry_SYSCALL_64_fastpath+0x1c/0xac
[  284.922648]
-> #0 (&dev->filelist_mutex){+.+...}:
[  284.922667]        [<ffffffff810871fc>] __lock_acquire+0x10fc/0x1270
[  284.922678]        [<ffffffff81087710>] lock_acquire+0x60/0x80
[  284.922689]        [<ffffffff8143e96f>] mutex_lock_nested+0x5f/0x360
[  284.922701]        [<ffffffffa0055ba2>] i915_ppgtt_info+0x82/0x390 [i915]
[  284.922729]        [<ffffffff81144491>] seq_read+0xe1/0x3b0
[  284.922739]        [<ffffffff811f77b3>] full_proxy_read+0x83/0xb0
[  284.922750]        [<ffffffff8111ba03>] __vfs_read+0x23/0x110
[  284.922761]        [<ffffffff8111c9b9>] vfs_read+0x89/0x110
[  284.922771]        [<ffffffff8111dbf4>] SyS_read+0x44/0xa0
[  284.922781]        [<ffffffff81442be9>] entry_SYSCALL_64_fastpath+0x1c/0xac
[  284.922793]
[  284.922793] other info that might help us debug this:
[  284.922793]
[  284.922809]  Possible unsafe locking scenario:
[  284.922809]
[  284.922818]        CPU0                    CPU1
[  284.922825]        ----                    ----
[  284.922831]   lock(&dev->struct_mutex);
[  284.922842]                                lock(&dev->filelist_mutex);
[  284.922854]                                lock(&dev->struct_mutex);
[  284.922865]   lock(&dev->filelist_mutex);
[  284.922875]
[  284.922875]  *** DEADLOCK ***
[  284.922875]
[  284.922888] 3 locks held by cat/1197:
[  284.922895]  #0:  (debugfs_srcu){......}, at: [<ffffffff811f7730>] full_proxy_read+0x0/0xb0
[  284.922919]  #1:  (&p->lock){+.+.+.}, at: [<ffffffff811443e8>] seq_read+0x38/0x3b0
[  284.922942]  #2:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0055b55>] i915_ppgtt_info+0x35/0x390 [i915]
[  284.922983]

Fixes: 1d2ac403 ("drm: Protect dev->filelist with its own mutex")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160822132820.21725-1-chris@chris-wilson.co.uk

If the engine isn't being retired (worker starvation?) then it is
possible for us to repeatedly observe that between consecutive
hangchecks the seqno on the ring to be the same and there remain
unretired requests. Ignore these completely and only regard the engine
as busy for the purpose of hang detection (not stall detection) if there
are outstanding breadcrumbs.

In recent history we have looked at using both the request and seqno as
indication of activity on the engine, but that was reduced to just
inspecting seqno in commit cffa781e ("drm/i915: Simplify check for
idleness in hangcheck"). However, in commit dcff85c8 ("drm/i915:
Enable i915_gem_wait_for_idle() without holding struct_mutex"), I made
the decision to use the new common lockless function, under the
assumption that request retirement was more frequent than hangcheck and
so we would not have a stuck busy check. The flaw there was in
forgetting that we accumulate the hang score, and so successive checks
seeing a stuck request, albeit with the GPU advancing elsewhere and so
not necessary the same stuck request, would eventually trigger the hang.

Fixes: dcff85c8 ("drm/i915: Enable i915_gem_wait_for_idle()...")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160820145408.32180-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

As we never need to directly access the pages we allocate for scratch and
the pagetables, and always remap them into the GTT through the dma
remapper, we do not need to limit the allocations to lowmem i.e. we can
pass in the __GFP_HIGHMEM flag to the page allocation.

For backwards compatibility, e.g. certain old GPUs not liking highmem
for certain functions that may be accidentally mapped to the scratch
page by userspace, keep the GMCH probe as only allocating from DMA32.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20160822074431.26872-3-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>