Replace __raw_i915_read32() with I915_READ_FW() in the workaround for
the SKL+ scanline counter hardware fail. The two are the same thing
but everyone else uses I915_READ_FW() so let's follow suit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-3-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Optimize the multi-register read in i915_get_vblank_counter() a little
bit by grabbing the uncore lock manually and using I915_READ_FW().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Check that the sink really declared 12bpc support before we enable it.
This should not actually never happen since it's mandatory for HDMI
sinks to support 12bpc if they support any deep color modes. But
reality disagrees with the theory and there are actually sinks in
the wild that violate the spec.

v2: Fix the output_types check
    Update commit message to state that these things are in fact real

Cc: stable@vger.kernel.org
Cc: Nicholas Sielicki <nicholas.sielicki@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99250Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170213175818.24958-1-ville.syrjala@linux.intel.comReviewed-by: NShashank Sharma <shashank.sharma@intel.com>

i915_drpc_info missed covering a few register read with the runtime pm
wakelock. Be simple and cover the entire function with a single wakelock
so that new additions are not similarly missed in future.

  WARNING: CPU: 2 PID: 1334 at drivers/gpu/drm/i915/intel_drv.h:1743 gen6_read32+0x192/0x1e0 [i915]
  RPM wakelock ref not held during HW access
  Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver netconsole nfsd auth_rpcgss ipmi_watchdog ipmi_poweroff ipmi_devintf ipmi_msghandler overlay btrfs xor raid6_pq dm_mod sg sd_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ata_generic pata_acpi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel kvm_intel snd_hda_codec kvm eeepc_wmi irqbypass snd_hda_core crct10dif_pclmul crc32_pclmul crc32c_intel asus_wmi sparse_keymap ghash_clmulni_intel snd_hwdep i915 rfkill ppdev pcbc aesni_intel ata_piix crypto_simd glue_helper snd_pcm pata_via cryptd pcspkr snd_timer drm_kms_helper syscopyarea snd sysfillrect libata sysimgblt fb_sys_fops soundcore shpchp drm wmi parport_pc parport tpm_infineon video
  CPU: 2 PID: 1334 Comm: php5 Not tainted 4.10.0-rc8-01615-g1f58c8e7 #1
  Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 1002 04/01/2011
  Call Trace:
   dump_stack+0x63/0x8a
   __warn+0xcb/0xf0
   warn_slowpath_fmt+0x4f/0x60
   ? seq_vprintf+0x35/0x50
   gen6_read32+0x192/0x1e0 [i915]
   i915_drpc_info+0x55d/0x990 [i915]
   seq_read+0xf2/0x3b0
   full_proxy_read+0x51/0x80
   __vfs_read+0x28/0x130
   ? security_file_permission+0x9b/0xc0
   ? rw_verify_area+0x4e/0xb0
   vfs_read+0xa8/0x170
   SyS_read+0x46/0xa0
   entry_SYSCALL_64_fastpath+0x1a/0xa9
  RIP: 0033:0x7fd97bf175a0
  RSP: 002b:00007ffdf730db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
  RAX: ffffffffffffffda RBX: 00007fd978028738 RCX: 00007fd97bf175a0
  RDX: 0000000000002000 RSI: 00007fd97740e0d8 RDI: 0000000000000005
  RBP: 0000000000000001 R08: 0000000000e97840 R09: 00007fd977ef8d58
  R10: 0000000000000027 R11: 0000000000000246 R12: 00007fd977ef8d58
  R13: 0000000000000000 R14: 0000000000eb4640 R15: 0000000000000000
Reported-by: Nkernel test robot <xiaolong.ye@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170313095617.29010-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
object code.

v2: Use const markup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170312135426.2216-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

The patch 791ff39a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:

        drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
        error: 'file' dereferencing possible ERR_PTR()
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 791ff39a ("drm/i915: Live testing for context execution")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170313124724.10614-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

The patch 6e32ab3d: "drm/i915: Fill different pages of the GTT"
from Feb 13, 2017, leads to the following static checker warning:

        drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
        error: 'vma' dereferencing possible ERR_PTR()
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 6e32ab3d ("drm/i915: Fill different pages of the GTT"
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170313100750.2685-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>

If the object is coherent, we can simply update the cache domain on the
whole object rather than calculate the before/after clflushes. The
advantage is that we then get correct tracking of ellided flushes when
changing coherency later.

Testcase: igt/gem_pwrite_snooped
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170310000942.11661-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The REDIRECT_TO_GUC bit is a strange beast as it is a disable bit -
setting the bit in the pm interrupt generation stops the interrupt going
to the guc (not sending it to the guc as the name implies). To help the
reader rename it to DISABLE_REDIRECT_TO_GUC so that we keep the bspec
greppable name without it being as confusing!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170312132745.9618-1-chris@chris-wilson.co.ukReviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>

Calculating the max pixel rate requires the new state, so use it there.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-6-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a big fat warning in __intel_display_resume that the old state is
invalid, and use the correct state everywhere.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-5-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[mlankhorst: Change one occurence of conn_state to new_conn_state in
             verify_connector_state, and drop old_conn_state there]

The watermark code needs to look at the new allocations, so use
for_each_new_crtc_in_state everywhere.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-4-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use for_each_new_plane_in_state, only the new state is needed.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-3-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use for_each_new_connector_in_state instead of for_each_connector_in_state.
Also make the function static, it's only used inside intel_ddi.c
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We don't use the error return for anything other than reporting and
logging that there is no VBT. We can pull the logging in the function,
and remove the error status return. Moreover, if we needed the
information for something later on, we'd probably be better off storing
the bit in dev_priv, and using it where it's needed, instead of using
the error return.

While at it, improve the comments.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/438ebbb0d5f0d321c625065b9cc78532a1dab24f.1489152288.git.jani.nikula@intel.com

Merge tag 'topic/designware-baytrail-2017-03-02' of git://anongit.freedesktop.org/git/drm-intel into drm-intel-next-queued

Baytrail PMIC vs. PMU race fixes from Hans de Goede

This time the right version (v4), with the compile fix.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and
Execlists. Updating it inside guc_interrupts_* routines as in those
routines GuC load/submission params are sanitized and it should not be set
based on HAS_GUC_SCHED during intel_irq_init.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-3-git-send-email-sagar.a.kamble@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

"pm_intr_keep" is not conveying the intent that it is bitmask
of interrupts that must be zero(mbz) in GEN6_PMINTRMSK.
Name it "pm_intrmsk_mbz".

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-2-git-send-email-sagar.a.kamble@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like capture of GuC interrupts while enabling GuC submission, release
them while disabling GuC submission.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-1-git-send-email-sagar.a.kamble@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-3-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

Currently, we sum the render and media cycles (on different engines) to
compute a percentage - but we fail to factor in the duplication into the
threshold calculations. This makes us very eager to upclock!

If we just consider the maximum busy cycles of either counter, we should
have an accurate reflection on whether there are cycles to spare to
handle the workload at this frequency.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-2-chris@chris-wilson.co.uk

On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.

v2: Fixup gen6_rps_pm_mask() as well
v3: Inline vlv_c0_above() to combine the now identical elapsed
calculation for up/down and simplify the threshold testing

Fixes: 43cf3bf0 ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

Sometimes we want to explicitly page out all available objects from igt,
i.e. call i915_gem_shrink_all() and check that subsequent operations
succeed. This adds DROP_SHRINK_ALL [0x8] to the set of flags for
debugfs/i915_drop_caches for that purpose.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308144622.23194-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only need to clflush those cachelines that we have validated to be
read by the GPU. Userspace typically fills the batch length in
correctly, the exceptions tend to be explicit tests within igt.

v2: Use ptr_mask_bits() to make Mika happy
v3: cmd is not advanced on MI_BBE, so make sure to include an extra
dword in the clflush.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170310115518.13832-1-chris@chris-wilson.co.uk

In commit 003342a5 ("drm/i915: Keep track of active
forcewake domains in a bitmask") I forgot to adjust the
newly introduce fw_domains_active state across reset.

This caused the assert_forcewakes_inactive to trigger
during suspend and resume if there were user held
forcewakes.

v2: Bitmask checks are required since vfuncs are not
    always present.

v3: Move bitmask tracking to get/put vfunc for simplicity.
    (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 003342a5 ("drm/i915: Keep track of active forcewake domains in a bitmask")
Testcase: igt/drv_suspend/forcewake
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: "Paneri, Praveen" <praveen.paneri@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: v4.10+ <stable@vger.kernel.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170310093249.4484-1-tvrtko.ursulin@linux.intel.com

In I915 driver, there are many places where variable name for
intel_encoder object is given as 'intel_encoder' whereas it would
make more sense to call it just 'encoder' when possible.

This patch does this cleanup in file intel_ddi.c.

PS: There are few functions where both drm_encoder and intel_encoder
are present. For such functions, this patch does nothing.
Suggested-by: NAnder Conselvan De Oliveira <conselvan2@gmail.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NAnder Conselvan De Oliveira <conselvan2@gmail.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489067021-4709-1-git-send-email-shashank.sharma@intel.com

gcc-4.4.4 has issues with anonymous union initializers.

In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68:
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error: unknown field 'mock' specified in initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: missing braces around initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: (near initialization for 'mock_selftests[0].<anonymous>')
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:12: error: unknown field 'mock' specified in initializer
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:13: error: unknown field 'm
...

Work around this.

Fixes: 953c7f82 ("drm/i915: Provide a hook for selftests")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170310090314.3142-1-chris@chris-wilson.co.ukSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to ensure no missed interrupts we must first re-direct
the interrupts to GuC, and only then re-submit the requests to
be replayed after a GPU reset. Otherwise context switch can fire
before GuC has been set up to receive it triggering more hangs.

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309132005.1317-1-tvrtko.ursulin@linux.intel.com

There is no easily digestible single self-refresh status bit, so don't
report one for debugfs/i915_sr_status on gen9+. For the moment this
avoids a read of the non-existent WM1_LP_ILK register.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170309142049.16033-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Driver needs to ensure that it doesn't mask the PM interrupts, which are
unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of
interrupts to be kept unmasked, pm_intr_keep.

pm_intr_keep was determined across GuC load. GuC gets loaded in different
scenarios and it is not going to change the pm_intr_keep so this patch
moves its setup to intel_irq_init.

This patch fixes incorrect RPS masking leading to UP interrupts triggered
even when at cur_freq=max and inversly for Down interrupts.

Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1488862355-9768-1-git-send-email-sagar.a.kamble@intel.com

printks are slow so we should not be doing them from the vblank evade
critical section. These could explain why we sometimes seem to
blow past our 100 usec deadline.

The problem has been there ever since commit c331879c ("drm/i915:
skylake sprite plane scaling using shared scalers.") but it may not have
been readily visible until commit e1edbd44 ("drm/i915: Complain
if we take too long under vblank evasion.") increased our chances
of noticing it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488974407-25175-1-git-send-email-maarten.lankhorst@linux.intel.com
Fixes: c331879c ("drm/i915: skylake sprite plane scaling using shared scalers")
Cc: <stable@vger.kernel.org> # v4.2+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[mlankhorst: Add missing tags, point to the correct offending commit]

Add a selftest to exercise evicting neighbouring nodes that conflict due
to page colouring in the GTT.

v2: add a peppering of comments
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170306235414.23407-4-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It looks like we were incorrectly comparing vma->node against itself
instead of the target node, when evicting for a node on systems where we
need guard pages between regions with different cache domains. As a
consequence we can end up trying to needlessly evict neighbouring nodes,
even if they have the same cache domain, and if they were pinned we
would fail the eviction.

Fixes: 625d988a ("drm/i915: Extract reserving space in the GTT to a helper")
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170306235414.23407-3-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

For our fake dma objects we can leak the underlying gem object if we
fail to pin our "backing storage".

[   39.952618] =============================================================================
[   39.952625] BUG mock_object (Tainted: G     U         ): Objects remaining in mock_object on __kmem_cache_shutdown()
[   39.952629] -----------------------------------------------------------------------------

[   39.952633] Disabling lock debugging due to kernel taint
[   39.952635] INFO: Slab 0xffffea00086c6a00 objects=21 used=1 fp=0xffff88021b1abc00 flags=0x5fff8000008100
[   39.952640] CPU: 1 PID: 1258 Comm: drv_selftest Tainted: G    BU          4.10.0+ #46
[   39.952641] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS MBP111.88Z.0138.B17.1602221718 02/22/2016
[   39.952642] Call Trace:
[   39.952648]  dump_stack+0x4d/0x6f
[   39.952651]  slab_err+0x9d/0xb0
[   39.952654]  ? ksm_migrate_page+0xe0/0xe0
[   39.952657]  ? on_each_cpu_cond+0x9a/0xc0
[   39.952658]  ? __kmalloc+0x1af/0x1c0
[   39.952660]  ? __kmem_cache_shutdown+0x173/0x3e0
[   39.952661]  __kmem_cache_shutdown+0x196/0x3e0
[   39.952664]  kmem_cache_destroy+0xa0/0x150
[   39.952708]  mock_device_release+0x113/0x140 [i915]
[   39.952726]  drm_dev_release+0x20/0x40 [drm]
[   39.952735]  drm_dev_unref+0x23/0x30 [drm]
[   39.952768]  i915_gem_gtt_mock_selftests+0x55/0x70 [i915]
[   39.952803]  __run_selftests+0x169/0x1c0 [i915]
[   39.952805]  ? 0xffffffffa0151000
[   39.952840]  i915_mock_selftests+0x30/0x60 [i915]
[   39.952869]  i915_init+0xc/0x78 [i915]
[   39.952870]  ? 0xffffffffa0151000
[   39.952872]  do_one_initcall+0x43/0x170
[   39.952874]  ? __vunmap+0x81/0xd0
[   39.952875]  ? kmem_cache_alloc_trace+0x37/0x170
[   39.952877]  ? do_init_module+0x27/0x1f8
[   39.952879]  do_init_module+0x5f/0x1f8
[   39.952881]  load_module+0x2423/0x29b0
[   39.952882]  ? __symbol_put+0x40/0x40
[   39.952885]  ? kernel_read_file+0x1a3/0x1c0
[   39.952887]  SYSC_finit_module+0xbc/0xf0
[   39.952889]  SyS_finit_module+0xe/0x10
[   39.952892]  entry_SYSCALL_64_fastpath+0x13/0x94

v2: use onion teardown and favour i915_gem_object_put

Fixes: 8d28ba45 ("drm/i915: Exercise filling the top/bottom portions of the ppgtt")
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170306235414.23407-2-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we allow the user to convert a GTT mmap address into a userptr, we
may end up in recursion hell, where currently we hit a mutex deadlock
but other possibilities include use-after-free during the
unbind/cancel_userptr.

[  143.203989] gem_userptr_bli D    0   902    898 0x00000000
[  143.204054] Call Trace:
[  143.204137]  __schedule+0x511/0x1180
[  143.204195]  ? pci_mmcfg_check_reserved+0xc0/0xc0
[  143.204274]  schedule+0x57/0xe0
[  143.204327]  schedule_timeout+0x383/0x670
[  143.204374]  ? trace_hardirqs_on_caller+0x187/0x280
[  143.204457]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  143.204507]  ? usleep_range+0x110/0x110
[  143.204657]  ? irq_exit+0x89/0x100
[  143.204710]  ? retint_kernel+0x2d/0x2d
[  143.204794]  ? trace_hardirqs_on_caller+0x187/0x280
[  143.204857]  ? _raw_spin_unlock_irq+0x33/0x60
[  143.204944]  wait_for_common+0x1f0/0x2f0
[  143.205006]  ? out_of_line_wait_on_atomic_t+0x170/0x170
[  143.205103]  ? wake_up_q+0xa0/0xa0
[  143.205159]  ? flush_workqueue_prep_pwqs+0x15a/0x2c0
[  143.205237]  wait_for_completion+0x1d/0x20
[  143.205292]  flush_workqueue+0x2e9/0xbb0
[  143.205339]  ? flush_workqueue+0x163/0xbb0
[  143.205418]  ? __schedule+0x533/0x1180
[  143.205498]  ? check_flush_dependency+0x1a0/0x1a0
[  143.205681]  i915_gem_userptr_mn_invalidate_range_start+0x1c7/0x270 [i915]
[  143.205865]  ? i915_gem_userptr_dmabuf_export+0x40/0x40 [i915]
[  143.205955]  __mmu_notifier_invalidate_range_start+0xc6/0x120
[  143.206044]  ? __mmu_notifier_invalidate_range_start+0x51/0x120
[  143.206123]  zap_page_range_single+0x1c7/0x1f0
[  143.206171]  ? unmap_single_vma+0x160/0x160
[  143.206260]  ? unmap_mapping_range+0xa9/0x1b0
[  143.206308]  ? vma_interval_tree_subtree_search+0x75/0xd0
[  143.206397]  unmap_mapping_range+0x18f/0x1b0
[  143.206444]  ? zap_vma_ptes+0x70/0x70
[  143.206524]  ? __pm_runtime_resume+0x67/0xa0
[  143.206723]  i915_gem_release_mmap+0x1ba/0x1c0 [i915]
[  143.206846]  i915_vma_unbind+0x5c2/0x690 [i915]
[  143.206925]  ? __lock_is_held+0x52/0x100
[  143.207076]  i915_gem_object_set_tiling+0x1db/0x650 [i915]
[  143.207236]  i915_gem_set_tiling_ioctl+0x1d3/0x3b0 [i915]
[  143.207377]  ? i915_gem_set_tiling_ioctl+0x5/0x3b0 [i915]
[  143.207457]  drm_ioctl+0x36c/0x670
[  143.207535]  ? debug_lockdep_rcu_enabled.part.0+0x1a/0x30
[  143.207730]  ? i915_gem_object_set_tiling+0x650/0x650 [i915]
[  143.207793]  ? drm_getunique+0x120/0x120
[  143.207875]  ? __handle_mm_fault+0x996/0x14a0
[  143.207939]  ? vm_insert_page+0x340/0x340
[  143.208028]  ? up_write+0x28/0x50
[  143.208086]  ? vm_mmap_pgoff+0x160/0x190
[  143.208163]  do_vfs_ioctl+0x12c/0xa60
[  143.208218]  ? debug_lockdep_rcu_enabled+0x35/0x40
[  143.208267]  ? ioctl_preallocate+0x150/0x150
[  143.208353]  ? __do_page_fault+0x36a/0x6e0
[  143.208400]  ? mark_held_locks+0x23/0xc0
[  143.208479]  ? up_read+0x1f/0x40
[  143.208526]  ? entry_SYSCALL_64_fastpath+0x5/0xc6
[  143.208669]  ? __fget_light+0xa7/0xc0
[  143.208747]  SyS_ioctl+0x41/0x70

To prevent the possibility of a deadlock, we defer scheduling the worker
until after we have proven that given the current mm, the userptr range
does not overlap a GGTT mmaping. If another thread tries to remap the
GGTT over the userptr before the worker is scheduled, it will be stopped
by its invalidate-range flushing the current work, before the deadlock
can occur.

v2: Improve discussion of how we end up in the deadlock.
v3: Don't forget to mark the userptr as active after a successful
gup_fast. Rename overlaps_ggtt to noncontiguous_or_overlaps_ggtt.
v4: Fix test ordering between invalid GTT mmaping and range completion
(Tvrtko)
Reported-by: NMichał Winiarski <michal.winiarski@intel.com>
Testcase: igt/gem_userptr_blits/map-fixed-invalidate-gup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308215903.24171-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

To avoid waiting for work from other invalidate-range threads where
not required, only wait on the userptr cancel workqueue if we have added
some work to it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307205851.32578-2-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

If the worker fails, it no longer has pages to release and can be
immediately removed from the invalidate-tree.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307205851.32578-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

The trouble here is that looking at all connector->state in the
verifier isn't good, because that's run from the commit work, which
doesn't hold the connection_mutex. Which means we're only allowed to
look at states in our atomic update.

The simple fix for future proofing would be to switch over to
drm_for_each_connector_in_state, but that has the problem that the
verification then fails if not all connectors are in the state. And we
also need to be careful to check both old and new encoders, and not
screw things up when an encoder gets reassigned.

Note that this isn't the full fix, since we still look at
connector->state. To fix that, we need Maarten's patch series to
switch over to state pointers within drm_atomic_state, but that's a
different series.

v2: Use oldnew iterator (Maarten).

v3: Rebase onto the iter_get/put->iter_begin/end rename.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-6-daniel.vetter@ffwll.ch

This gets rid of the last users of for_each_intel_connector(), remove
that too.

At first I wasn't sure whether the 2 loops in the modeset state
checker should instead only loop over the connectors in the atomic
commit. But we never add connectors to an atomic update if they don't
(or won't have) a CRTC assigned, which means there'd be a gap in check
coverage. Hence loop over everything on those too.

v2: Rebase onto the iter_get/put->iter_begin/end rename.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-5-daniel.vetter@ffwll.ch

Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-4-daniel.vetter@ffwll.ch