It turns out that HSW has a register that tells us how many EUs are
disabled per half-slice (roughly a similar notion to subslice). We
didn't read those registers so far as most userspace drivers didn't
need those values prior to Gen8, but an internal library would like to
have access to this.

Since we already have the getparam interface, there is no harm in
exposing this.

v2: Rename bits value (Joonas)

v3: s/GEM_BUG_ON/MISSING_CASE/ (Joonas)

v4: s/GEM_BUG_ON/MISSING_CASE/ again... (Lionel)
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221204902.23084-1-lionel.g.landwerlin@intel.com

Show GEN11 specific interrupt registers in debugfs

v2: Update for POR changes. (Daniele Ceraolo Spurio)
v3: get runtime pm ref. unify common parts with gen8 (Daniele)

Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220153755.13509-2-mika.kuoppala@linux.intel.com

This is the current PCI ID list in our documentation.

Let's leave the _gt#_ part out for now since our current documentation
is not 100% clear and we don't need this info now anyway.

v2: Use the new ICL_11 naming (Kelvin Gardiner).
v3: Latest IDs as per BSpec (Oscar).
v4: Make it compile (Paulo).
v5: Remove comments (Lucas).
v6: Multile rebases (Paulo).
v7: Rebase (Mika)

Reviewed-by: Anuj Phogat <anuj.phogat@intel.com> (v1)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220153755.13509-1-mika.kuoppala@linux.intel.com

Print out the current request/context before doing the GEM_BUG_ON, so
that we can inspect the values in the ftrace.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221152301.9178-1-chris@chris-wilson.co.uk

Include a GEM_TRACE to show when the context is complete and we advance
the ELSP port.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221151553.9054-1-chris@chris-wilson.co.uk

Load an empty ringbuffer for preemption, ignoring the lite-restore
workaround as we know the preempt context is always idle before preemption.

Note that after some digging by Michal Winiarski, we found that
RING_HEAD is no longer being updated (due to inhibiting context save
restore) so this patch is already in effect!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221133236.29402-1-chris@chris-wilson.co.uk

We want to de-emphasize the link between the request (dependency,
execution and fence tracking) from GEM and so rename the struct from
drm_i915_gem_request to i915_request. That is we may implement the GEM
user interface on top of requests, but they are an abstraction for
tracking execution rather than an implementation detail of GEM. (Since
they are not tied to HW, we keep the i915 prefix as opposed to intel.)

In short, the spatch:
@@

@@
- struct drm_i915_gem_request
+ struct i915_request

A corollary to contracting the type name, we also harmonise on using
'rq' shorthand for local variables where space if of the essence and
repetition makes 'request' unwieldy. For globals and struct members,
'request' is still much preferred for its clarity.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180221095636.6649-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Commit fe49789f ("drm/i915: Deconstruct execute fence") re-arranged
the code and moved the i915_gem_request_execute tracepoint to before the
global seqno is assigned to the request.

We need to move the tracepoint a bit later so this information is once
again available.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: fe49789f ("drm/i915: Deconstruct execute fence")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220104742.565-1-tvrtko.ursulin@linux.intel.com

Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rather than trusting the cached value of plane_state->vma->fence to
imply whether the plane_state itself holds a reference on the
framebuffer's fence, use the information provided in the
plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
is entirely bounded by the plane_state active life span; it's not clear
if that is a safe assumption.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-4-chris@chris-wilson.co.uk

Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-3-chris@chris-wilson.co.uk

Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruct us where to place the VMA so
that it can enable the features it wants. As such, make the pin flags an
argument to i915_gem_object_pin_to_display() and control them from
intel_pin_and_fence_fb_obj()

Whilst taking control of the mapping for ourselves, start tracking how
we use it to avoid trying to free a fence we never claimed:

<3>[  227.151869] GEM_BUG_ON(vma->fence->pin_count <= 0)
<4>[  227.152064] ------------[ cut here ]------------
<2>[  227.152068] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:391!
<4>[  227.152084] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
<0>[  227.152092] Dumping ftrace buffer:
<0>[  227.152099]    (ftrace buffer empty)
<4>[  227.152102] Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me mei prime_numbers
<4>[  227.152131] CPU: 1 PID: 1587 Comm: kworker/u16:49 Tainted: G     U           4.16.0-rc1-gbab67b2f6177-kasan_7+ #1
<4>[  227.152134] Hardware name: Dell Inc. OptiPlex 755                 /0PU052, BIOS A08 02/19/2008
<4>[  227.152236] Workqueue: events_unbound intel_atomic_commit_work [i915]
<4>[  227.152292] RIP: 0010:intel_unpin_fb_vma+0x23a/0x2a0 [i915]
<4>[  227.152295] RSP: 0018:ffff88005aad7b68 EFLAGS: 00010286
<4>[  227.152300] RAX: 0000000000000026 RBX: ffff88005c359580 RCX: 0000000000000000
<4>[  227.152304] RDX: 0000000000000026 RSI: ffffffff8707d840 RDI: ffffed000b55af63
<4>[  227.152307] RBP: ffff880056817e58 R08: 0000000000000001 R09: 0000000000000000
<4>[  227.152311] R10: ffff88005aad7b88 R11: 0000000000000000 R12: ffff8800568184d0
<4>[  227.152314] R13: ffff880065b5ab08 R14: 0000000000000000 R15: dffffc0000000000
<4>[  227.152318] FS:  0000000000000000(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000
<4>[  227.152322] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  227.152325] CR2: 00007f5fb25550a8 CR3: 0000000068c78000 CR4: 00000000000006e0
<4>[  227.152328] Call Trace:
<4>[  227.152385]  intel_cleanup_plane_fb+0x6b/0xd0 [i915]
<4>[  227.152395]  drm_atomic_helper_cleanup_planes+0x166/0x280
<4>[  227.152452]  intel_atomic_commit_tail+0x159d/0x3380 [i915]
<4>[  227.152463]  ? process_one_work+0x66e/0x1460
<4>[  227.152516]  ? skl_update_crtcs+0x9c0/0x9c0 [i915]
<4>[  227.152523]  ? lock_acquire+0x13d/0x390
<4>[  227.152527]  ? lock_acquire+0x13d/0x390
<4>[  227.152534]  process_one_work+0x71a/0x1460
<4>[  227.152540]  ? __schedule+0x815/0x1e20
<4>[  227.152547]  ? pwq_dec_nr_in_flight+0x2b0/0x2b0
<4>[  227.152553]  ? _raw_spin_lock_irq+0xa/0x40
<4>[  227.152559]  worker_thread+0xdf/0xf60
<4>[  227.152569]  ? process_one_work+0x1460/0x1460
<4>[  227.152573]  kthread+0x2cf/0x3c0
<4>[  227.152578]  ? _kthread_create_on_node+0xa0/0xa0
<4>[  227.152583]  ret_from_fork+0x3a/0x50
<4>[  227.152591] Code: c6 00 11 86 c0 48 c7 c7 e0 bd 85 c0 e8 60 e7 a9 c4 0f ff e9 1f fe ff ff 48 c7 c6 40 10 86 c0 48 c7 c7 e0 ca 85 c0 e8 2b 95 bd c4 <0f> 0b 48 89 ef e8 4c 44 e8 c4 e9 ef fd ff ff e8 42 44 e8 c4 e9
<1>[  227.152720] RIP: intel_unpin_fb_vma+0x23a/0x2a0 [i915] RSP: ffff88005aad7b68

v2: i915_vma_pin_fence() is a no-op if a fence isn't required, so check
vma->fence as well.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-2-chris@chris-wilson.co.uk

We cannot simply use !view as shorthand for all normal GGTT views as a
few callers will always populate a i915_ggtt_view struct and set the
type to NORMAL instead. So check for (!view || view->type == NORMAL)
inside i915_gem_object_ggtt_pin().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-1-chris@chris-wilson.co.uk

WaDoubleCursorLP3Latency was meant for pre-production hardware.
Drop it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130203807.13721-6-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

i965 and g4x still have the pipe select bits in the plane control
registers, they're just hardcoded to select a specific pipe. However
plane C on i965 can still move between the pipes, thus we should
program the pipe select bits on i965 if we want to expose plane C
some day.

Since there is no harm in programming the bits on any plane on
i965/g4x let's just always set them. This will also make our
pre-computed register value match what the hardware register
would read, should we want to cross check the two.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130203807.13721-2-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

G4x cursor control registers still allow us to write to the pipe select
bits even though cursors are supposed to be fixed to a specific pipe.
Bspec tells us that we should only ever write 0 to these bits. Let's
follow that recommendation. On ilk+ the bits become hardwired to 0.

Also looks like ICL repurposes these bits for some other use, so
we had better stop setting them to bogus values there.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130203807.13721-1-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Add some compile time assrts to the frontbuffer tracking to make sure
that we have enough bits per pipe to cover all the planes, and that we
have enough total bits to cover all the planes across all pipes.

We'll ignore any potential clash between the overlay bit and the
plane bits because that will allow us to keep using a total of 32
bits for the foreseeable future.

While at it change the macros to use BIT() and GENMASK(). The latter
gets rid of the hardcoded 0xff and thus means we can change the
number of bits per pipe by just changing
INTEL_FRONTBUFFER_BITS_PER_PIPE.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180124183642.32549-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

During igt, we frequently call into the driver to reset both HW and
driver state (idling the device, waiting for it to become idle and
freeing off old objects) to ensure that we start each test/subtest/pass
from known state. This process incurs an RCU barrier or two to ensure
that any such pending frees are indeed flushed before we return.
However, unconditionally waiting on the RCU barrier adds needless delay
to many callers, which adds up to several seconds when repeated thousands
of times. We can skip the rcu_barrier() if by tracking how many outstanding
frees we have, we know there are none.

The same path is used along suspend, where we may be able to save the
unconditional RCU barrier.

To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.

v2: Remove the extra synchronize_rcu() inside i915_drop_caches_set()
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219220631.25001-1-chris@chris-wilson.co.uk

clang spots

drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
        if (INTEL_GEN(dev_priv) >= 10)

but fortunately for us we skip the function unless on a gen10+ device.
However, to keep the function generic in case we do want to re-enable it
for gen9 again, initialise trans_min to 0.

References: ca47667f ("drm/i915/gen10: Calculate and enable transition WM")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115105036.1094-3-chris@chris-wilson.co.ukReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If we fail to unbind the vma (due to a signal on an active buffer that
needs to be moved for the next execbuf), then we need to clear the
persistent tracking state we setup for this execbuf.

Fixes: c7c6e46f ("drm/i915: Convert execbuf to use struct-of-array packing for critical fields")
Testcase: igt/gem_fenced_exec_thrash/no-spare-fences-busy*
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.14+
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219140144.24004-1-chris@chris-wilson.co.uk

The compiler is not automatically caching the i915->regs address inside
a register and emitting a load for every mmio access. For simple
functions like gen8_gt_irq_handler that are already using the raw
accessors, we can open-code them for substantial savings:

add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83)
Function                                     old     new   delta
gen8_gt_irq_handler                          290     266     -24
gen8_gt_irq_ack                              181     122     -59
Total: Before=954637, After=954554, chg -0.01%

v2: Add raw_reg_read/raw_reg_write.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219100926.16554-1-chris@chris-wilson.co.uk

Keep the master iir and use it to reduce the number of reads and writes
to the GT iir array, i.e. only the bits marked as set by the master iir
are valid inside GT iir array and will be handled during the interrupt.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215073713.26985-1-chris@chris-wilson.co.uk

As the driver is called to handle circumstances beyond it's control, we
cannot assume that the pm_runtime core is happy to see us. For example,
if we are called from shrink_slab to free up our pages during suspend,
rpm may be disabled and pm_runtime_if_in_use() decides to fail with
-EINVAL rather than simply say no. This is expected to happen, so don't
warn.  For example,

[  217.429228] Suspending console(s) (use no_console_suspend to debug)
[  217.557179] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  217.559399] sd 0:0:0:0: [sda] Stopping disk
[  218.661567] i915 0000:00:02.0: Resetting chip after gpu hang
[  219.523879] ------------[ cut here ]------------
[  219.524474] pm_runtime_get_if_in_use() failed: -22
[  219.524817] WARNING: CPU: 1 PID: 14 at drivers/gpu/drm/i915/intel_runtime_pm.c:3351 intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[  219.524836] Modules linked in: vgem i915 snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec r8169 lpc_ich snd_hwdep mii snd_hda_core snd_pcm prime_numbers
[  219.525054] CPU: 1 PID: 14 Comm: cpuhp/1 Tainted: G     U           4.16.0-rc1-g740f57c54ecf-kasan_6+ #1
[  219.525070] Hardware name:  /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010
[  219.525294] RIP: 0010:intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[  219.525313] RSP: 0018:ffff880018f5edf8 EFLAGS: 00010286
[  219.525344] RAX: dffffc0000000008 RBX: ffff880007fc0000 RCX: 0000000000000000
[  219.525361] RDX: 0000000000000001 RSI: ffffffff850609c0 RDI: ffffffff872992a0
[  219.525377] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[  219.525394] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880007fc0000
[  219.525411] R13: ffff880018f5f0f8 R14: ffff880007fc8de8 R15: ffff880018f5f0f0
[  219.525429] FS:  0000000000000000(0000) GS:ffff880019c80000(0000) knlGS:0000000000000000
[  219.525446] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  219.525463] CR2: 0000564df7897e86 CR3: 0000000000d7c000 CR4: 00000000000006e0
[  219.525478] Call Trace:
[  219.525734]  i915_gem_shrink+0x841/0xb50 [i915]
[  219.525802]  ? debug_check_no_locks_freed+0x2a0/0x2a0
[  219.525842]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  219.526083]  ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915]
[  219.526131]  ? lock_acquire+0x138/0x3c0
[  219.526157]  ? lock_acquire+0x138/0x3c0
[  219.526391]  ? shrinker_lock+0x49/0x210 [i915]
[  219.526465]  ? mutex_trylock+0x15c/0x1a0
[  219.526694]  ? shrinker_lock+0x49/0x210 [i915]
[  219.526969]  ? i915_gem_shrinker_scan+0xc4/0x320 [i915]
[  219.527200]  i915_gem_shrinker_scan+0xc4/0x320 [i915]
[  219.527448]  ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915]
[  219.527533]  shrink_slab.part.18+0x2d0/0x8d0
[  219.527613]  ? unregister_shrinker+0x1f0/0x1f0
[  219.527668]  ? mem_cgroup_iter+0x37d/0xc50
[  219.527728]  shrink_node+0x882/0xbe0
[  219.527847]  ? shrink_node_memcg+0x11c0/0x11c0
[  219.527882]  ? mark_held_locks+0xa8/0xf0
[  219.527931]  ? trace_hardirqs_on_caller+0x33f/0x590
[  219.527961]  ? ktime_get+0xad/0x140
[  219.528015]  do_try_to_free_pages+0x2d3/0xd70
[  219.528099]  ? allow_direct_reclaim.part.23+0x1d0/0x1d0
[  219.528132]  ? shrink_node+0xbe0/0xbe0
[  219.528213]  try_to_free_pages+0x1cd/0x570
[  219.528257]  ? do_try_to_free_pages+0xd70/0xd70
[  219.528355]  __alloc_pages_nodemask+0xadf/0x2110
[  219.528423]  ? unwind_next_frame+0x870/0x1970
[  219.528465]  ? deref_stack_reg+0x97/0xc0
[  219.528503]  ? gfp_pfmemalloc_allowed+0x150/0x150
[  219.528539]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.528588]  ? unwind_next_frame+0x138/0x1970
[  219.528619]  ? kthread+0x30a/0x3d0
[  219.528677]  ? __read_once_size_nocheck.constprop.4+0x10/0x10
[  219.528698]  ? deref_stack_reg+0xc0/0xc0
[  219.528762]  ? __save_stack_trace+0x6e/0xd0
[  219.528822]  depot_save_stack+0x3bc/0x430
[  219.528870]  kasan_kmalloc+0x142/0x170
[  219.528912]  ? __kmalloc+0xf7/0x340
[  219.528935]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.528957]  ? partition_sched_domains+0x4d4/0x840
[  219.528978]  ? sched_cpu_deactivate+0x11b/0x150
[  219.529001]  ? cpuhp_invoke_callback+0x160/0x15f0
[  219.529023]  ? cpuhp_thread_fun+0x35e/0x710
[  219.529044]  ? smpboot_thread_fn+0x50a/0x7f0
[  219.529065]  ? kthread+0x30a/0x3d0
[  219.529086]  ? ret_from_fork+0x24/0x50
[  219.529141]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529169]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529198]  ? set_track+0x87/0x100
[  219.529225]  ? init_object+0x6e/0x80
[  219.529275]  ? ___slab_alloc.constprop.36+0x232/0x3e0
[  219.529303]  ? ___slab_alloc.constprop.36+0x232/0x3e0
[  219.529325]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529410]  ? mark_held_locks+0xa8/0xf0
[  219.529453]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529479]  ? trace_hardirqs_on_caller+0x33f/0x590
[  219.529532]  __kmalloc+0xf7/0x340
[  219.529557]  ? register_sched_domain_sysctl+0x23a/0x1b90
[  219.529604]  register_sched_domain_sysctl+0x23a/0x1b90
[  219.529684]  ? sched_debug_show+0x20/0x20
[  219.529713]  ? debug_object_activate+0x530/0x530
[  219.529771]  ? rcu_lockdep_current_cpu_online+0xdc/0x130
[  219.529802]  ? partition_sched_domains+0x4ae/0x840
[  219.529825]  ? rcu_read_lock_sched_held+0x10f/0x130
[  219.529875]  partition_sched_domains+0x4d4/0x840
[  219.529955]  ? sched_init_domains+0x110/0x110
[  219.529981]  ? __wait_rcu_gp+0x24f/0x390
[  219.530054]  sched_cpu_deactivate+0x11b/0x150
[  219.530086]  ? sched_cpu_activate+0x1e0/0x1e0
[  219.530112]  ? __call_rcu.constprop.53+0x680/0x680
[  219.530132]  ? call_rcu_bh+0x10/0x10
[  219.530166]  ? debug_check_no_locks_freed+0x2a0/0x2a0
[  219.530201]  ? trace_raw_output_rcu_utilization+0xa0/0xa0
[  219.530267]  ? trace_raw_output_rcu_utilization+0xa0/0xa0
[  219.530337]  ? rcu_lockdep_current_cpu_online+0xdc/0x130
[  219.530370]  ? sched_cpu_activate+0x1e0/0x1e0
[  219.530397]  cpuhp_invoke_callback+0x160/0x15f0
[  219.530424]  ? lock_acquire+0x138/0x3c0
[  219.530445]  ? lock_acquire+0x138/0x3c0
[  219.530471]  ? cpuhp_thread_fun+0xaf/0x710
[  219.530507]  ? pci_mmcfg_check_reserved+0x100/0x100
[  219.530565]  cpuhp_thread_fun+0x35e/0x710
[  219.530618]  ? cpuhp_complete_idle_dead+0x10/0x10
[  219.530639]  smpboot_thread_fn+0x50a/0x7f0
[  219.530678]  ? sort_range+0x20/0x20
[  219.530709]  ? __kthread_parkme+0xba/0x1f0
[  219.530739]  ? schedule+0x84/0x1a0
[  219.530768]  ? __kthread_parkme+0xbf/0x1f0
[  219.530805]  ? sort_range+0x20/0x20
[  219.530831]  kthread+0x30a/0x3d0
[  219.530859]  ? _kthread_create_on_node+0xb0/0xb0
[  219.530900]  ret_from_fork+0x24/0x50
[  219.530999] Code: 01 00 00 00 85 c0 74 4a 89 e8 5b 5d c3 80 3d 48 37 4e 00 00 75 f2 89 c6 48 c7 c7 40 f0 61 c0 c6 05 36 37 4e 00 01 e8 ed 2a e1 c2 <0f> ff eb d9 80 3d 3f 37 4e 00 00 75 94 48 c7 c7 60 e8 61 c0 c6
[  219.531880] ---[ end trace 18ec0139488ea0c8 ]---
[  219.607967] IRQ 16: no longer affine to CPU1
[  219.670291] IRQ 24: no longer affine to CPU2
[  219.701489] IRQ 8: no longer affine to CPU3
[  219.701529] IRQ 9: no longer affine to CPU3
[  219.701582] IRQ 18: no longer affine to CPU3
[  219.701640] IRQ 25: no longer affine to CPU3
[  219.743857]  cache: parent cpu1 should not be sleeping
[  219.784549]  cache: parent cpu2 should not be sleeping
[  219.816041]  cache: parent cpu3 should not be sleeping

v2: Add Returns: information to intel_runtime_pm_get_if_in_use() kerneldoc.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219125046.19363-1-chris@chris-wilson.co.uk

The in-lined comments for channel.port doesn't follow the syntax
described at kernel-doc document, causing the following warning:

	$ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c
	drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter or member 'channel.port' not described in 'bxt_ddi_phy_info'

While the best would be for the Kernel to deduce that from the
context, supporting it is not trivial. So, let's just stick with
the existing syntax.

[Jani: depends on "scripts: kernel-doc: support in-line comments on
nested structs/unions" to actually fix the warning.]
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9ba9ac773f4f9e60770bd9169b0e46ac974d858a.1518788761.git.mchehab@s-opensource.com

Hitting the failure path through check_digital_port_conflicts triggers:

================================================
WARNING: lock held when returning to user space!
4.16.0-rc1-CI-kasan_1+ #1 Tainted: G        W
------------------------------------------------
kms_3d/1439 is leaving the kernel with locks still held!
1 lock held by kms_3d/1439:
 #0:  (drm_connector_list_iter){.+.+}, at: [<000000003745d183>] intel_atomic_check+0x1d9d/0x3ff0 [i915]

Rearrange the code to have a single exit path through the unlock.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215091425.42364-1-maarten.lankhorst@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We can't assert that the execlists are active before we set the flag. So
perform the assert after we are expected to have marked the execlists
active.

Fixes: 339ccd35 ("drm/i915: Assert that we always complete a submission to guc/execlists")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216153210.30551-1-chris@chris-wilson.co.uk

The continual resubmission model for execlists (and emulated over guc)
requires that we keep feeding requests into the HW in order to generate
more CS interrupts to drain the rest of the queue. Add a couple of
asserts to ensure that we don't skip a cycle and come to a grinding
halt.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215162553.23348-1-chris@chris-wilson.co.uk

i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.

Move the fields into drm_i915_gem_object instead and patch the i915 code
with the following sed commands:

sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c
sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c

Change is only compile tested.

v2: move fields around as suggested by Chris.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216124338.9087-1-christian.koenig@amd.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is
defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address
is defined 0x162EDC instead of 0x162E5C, fix it.
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Fixes: 04416108 ("drm/i915/cnl: Add registers related to voltage swing sequences.")
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215095643.3844-2-mahesh1.kumar@intel.com

The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 states if PSR was
active. The frame counter could also have stalled if PSR was active in case
there was no DMC. The frame counter resetting has a user visible impact
of screen freezes.

Make use of drm_vblank_restore() to compute missed vblanks for the duration
in which vblank interrupts were disabled and update the vblank counter with
this value as diff. There's no need to check if PSR was actually active in
the interrupt disabled duration, so simplify the check to a feature check.

Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
from going back again as long as the there are pending interrupts. So, we
don't have to explicity disallow DC5/6 after enabling vblank interrupts to
keep the counter running.

This change is not applicable to CHV, as enabling interrupts does not
prevent the hardware from activating PSR.

v2: Added comments(Rodrigo) and rewrote commit message.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-10-dhinakaran.pandiyan@intel.com

570e8696 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64, store all the bits
without truncating. There is no need to type cast this value down to
32-bits.

Cc: Keith Packard <keithp@keithp.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-3-dhinakaran.pandiyan@intel.com

Core returns a u64 vblank count and intel_crtc_get_vblank_counter()
expects a 32-bit value. Make the typecast explicit to add clarity.

Cc: Keith Packard <keithp@keithp.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-2-dhinakaran.pandiyan@intel.com

Fix inconsistent IS_ERR and PTR_ERR in shrink_boom.
The proper pointer to use is _explode_ instead of _purge_.

This issue was detected with the help of Coccinelle.

Fixes: fe215c8b ("drm/i915/selftests: add missing gtt shrinker test")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214211234.GA22341@embeddedgusReviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Rather than deriving the platform_mask from the
intel_device_static_info->platform at runtime, pre-fill it in the static
data.

v2: Undefine macros at end of their scope
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215081930.11477-3-chris@chris-wilson.co.uk

Be consistent and define the device's GEN as part of the GENx_FEATURE.
It will be overridden by the next gen upon inheriting, as per usual.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215081930.11477-2-chris@chris-wilson.co.uk

Rather than deriving the gen_mask from the static intel_device_info->gen
at runtime, pre-fill it in the static data.

v2: Undefine local macros at end of their scope.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215081930.11477-1-chris@chris-wilson.co.uk

As we presume that we have sufficient coverage of CI for new machines
and new code paths, we do not need to have user impacting WARN_ON for
programming errors inside i915_gem_gtt.c, so convert those over to
GEM_BUG_ON. This leaves the memory debugging WARN_ON in place as they
are not so easy to exercise with CI.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215110759.28603-1-chris@chris-wilson.co.uk

As befitting a file dedicated to the mistakes of the past,

drivers/gpu/drm/i915/i915_ioc32.c:2: warning: Cannot understand  * \file i915_ioc32.c
 on line 2 - I thought it was a doc line
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'filp' not described in 'i915_compat_ioctl'
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'cmd' not described in 'i915_compat_ioctl'
drivers/gpu/drm/i915/i915_ioc32.c:82: warning: Function parameter or member 'arg' not described in 'i915_compat_ioctl'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214160720.19673-1-chris@chris-wilson.co.uk

Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check where
we know pipe >= 0 and next to the array indexing where it makes most
sense.

Fixes: 9965db26 ("drm/i915: Check for fused or unused pipes")
Fixes: 0b7029b7 ("drm/i915: Check for fused or unused pipes")
Cc: <stable@vger.kernel.org> # v4.10+
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214173840.25360-1-jani.nikula@intel.com

We now have a stable cnl on our CI and it seems mostly
green without big risks of blank screen or anything
blowing up on linux installations in the future.

As a reminder i915.alpha_support was created to protect
future linux installation's iso images that might contain a
kernel from the enabling time of the new platform. Without this
protection most of linux installation was recommending
nomodeset option during installation that was getting stick
there after installation.

Specifically, alpha support says nothing about the development
state of the hardware, and everything about the state of the
driver in a kernel release.

This is semantically no different from the old
preliminary_hw_support flag, but the old one was all too often
interpreted as (preliminary hw) support instead of the intended
(preliminary) hw support, and it was misleading for everyone.
Hence the rename.

v2: Fix the typos and include more history about the parameter
rename on commit message. (Jani)

Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-cnl-y3.html
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214204205.4446-1-rodrigo.vivi@intel.com