drm/i915: Add windowing for primary planes on gen2/3 and chv

Plane B and C (note that we don't actually expose plane C currently)
on gen2/3 have a window generator, as does the primary plane on CHV
pipe B. So let's allow positioning of these planes freely within the
pipe source area.

Plane A on gen2/3 seems to have some kind of partial window generator
which would allow you to cut the plane off midway through the scanout,
but it would still have to start at the top-left corner of the pipe,
and it would have to be full width. That's doesn't sound all that
useful, so for simplicity let's just keep to the idea that plane A
has to be fullscreen.

Gen4 removed the plane A/B windowing support entirely, and it wasn't
reintroduced until SKL (apart from the CHV pipe B special case).

v2: s/plane/i9xx_plane/ etc. (James)
v3: Make it less confusing
v4: Deal with IS_GEN()

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-2-ville.syrjala@linux.intel.com

drm/i915: Move dev_priv->pm_i{m, e}r into intel_gt

PM interrupts belong to the GT so move the variables to be inside
struct intel_gt.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-3-tvrtko.ursulin@linux.intel.com

drm/i915: Remove some legacy mmio accessors from interrupt handling

Mostly in gen11 interrupt handling and a couple neighbouring functions
which were easy since uncore local was already available.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-2-tvrtko.ursulin@linux.intel.com

drm/i915: Rework some interrupt handling functions to take intel_gt

Some interrupt handling functions already have gt in their names
suggesting them as obvious candidates to make them take struct intel_gt
instead of i915.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-1-tvrtko.ursulin@linux.intel.com

drm/i915: Show instdone for each engine in debugfs

Although polling each engine quickly is preferable as it should give us
a sample of each engine at roughly the same time, keep it simple and
just sample the engine as print out the debug state.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704200455.14870-3-chris@chris-wilson.co.uk

drm/i915/selftests: Be engine agnostic

When using MI operations, we do not care which engine we use, so use
them all where possible, and where inconvenient double check we have the
engine we selected at random.

v2: Drop the local copy of engine->sseu to avoid an unchecked deref

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704212343.6820-1-chris@chris-wilson.co.uk

drm/i915/overlay: Stash the kernel context on initialisation

Simplify runtime request creation by storing the context we need to use
during initialisation. This allows us to remove one more hardcoded
engine lookup.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704200455.14870-1-chris@chris-wilson.co.uk

drm/i915/hangcheck: Look at instdone for all engines

It seems intel_engine_get_instdone is able to get instdone for all engines
but intel_hangcheck.c/subunits_stuck decides to ignore it for non render.

We can just drop the check in subunits_stuck since the checks on
unavailable fields will always return stuck, which when bitwise and with
the potential unstuck instdone is harmless.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703144116.15593-1-tvrtko.ursulin@linux.intel.com

drm/i915/selftests: Drain the freedlists between exec passes

During the context execution tests, we issue a lot of work and discard a
lot of objects without releasing the lock and allowing the background
reaper to free those objects. Insert a small break between each pass to
flush the worker.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704165317.21060-1-chris@chris-wilson.co.uk

drm/i915/gtt: Mark the freed page table entries with scratch

On unwinding the allocation error path and having freed the page table
entry, it is imperative that we mark it as scratch.

<4> [416.075569] general protection fault: 0000 [#1] PREEMPT SMP PTI
<4> [416.075801] CPU: 0 PID: 2385 Comm: kworker/u2:11 Tainted: G     U            5.2.0-rc7-CI-Patchwork_13534+ #1
<4> [416.076162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
<4> [416.076522] Workqueue: i915 __i915_vm_release [i915]
<4> [416.076754] RIP: 0010:gen8_ppgtt_cleanup_3lvl+0x58/0xb0 [i915]
<4> [416.077023] Code: 81 e2 04 fe ff ff 81 c2 ff 01 00 00 4c 8d 74 d6 58 4d 8b 65 00 4d 3b a7 28 02 00 00 74 40 49 8d 5c 24 50 49 81 c4 50 10 00 00 <48> 8b 2b 49 3b af 20 02 00 00 74 13 4c 89 ff 48 89 ee e8 01 fb ff
<4> [416.077445] RSP: 0018:ffffc9000046bd98 EFLAGS: 00010206
<4> [416.077625] RAX: 0001000000000000 RBX: 6b6b6b6b6b6b6bbb RCX: 8b4b56d500000000
<4> [416.077838] RDX: 00000000000001ff RSI: ffff88805a578008 RDI: ffff88805bd0efc8
<4> [416.078167] RBP: ffff88805bd0efc8 R08: 0000000004e42b93 R09: 0000000000000001
<4> [416.078381] R10: 0000000000000000 R11: ffff888077a1b0b8 R12: 6b6b6b6b6b6b7bbb
<4> [416.078594] R13: ffff88805a578058 R14: ffff88805a579058 R15: ffff88805bd0efc8
<4> [416.078815] FS:  0000000000000000(0000) GS:ffff88807da00000(0000) knlGS:0000000000000000
<4> [416.079395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [416.079851] CR2: 000056160fec2b14 CR3: 0000000071bbc003 CR4: 00000000003606f0
<4> [416.080388] Call Trace:
<4> [416.080828]  gen8_ppgtt_cleanup+0x64/0x100 [i915]
<4> [416.081399]  __i915_vm_release+0xfc/0x1d0 [i915]

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704201656.15775-1-chris@chris-wilson.co.uk

drm/i915/gt: Pull engine w/a initialisation into common

We need to setup the workarounds on all engines, with the knowledge
about which platforms each workaround applies to kept together in the
workaround list. As such, we can pull the w/a initialisation into the
common setup and try to avoid duplicating knowledge about when to setup
the workarounds.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703135805.7310-2-chris@chris-wilson.co.uk

drm/i915: Dump w/a lists on all engines

We store separate wa_list on every engine, so be sure to include all
when dumping the current set via debugfs.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703135805.7310-1-chris@chris-wilson.co.uk

drm/i915/guc: Upgrade to GuC 33.0.0

New GuC firmware is available. Let's use it.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703113640.31100-1-michal.wajdeczko@intel.com

drm/i915/gtt: Handle double alloc failures

Matthew pointed out that we could face a double failure with concurrent
allocations/frees, and so the assumption that the local var alloc was
NULL was fraught with danger. Rather than complicate the error paths too
much to add a second local for a second free, just do the second free
earlier on the unwind path.

Reported-by: Matthew Auld <matthew.william.auld@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704104345.6603-1-chris@chris-wilson.co.uk

drm/i915: Show support for accurate sw PMU busyness tracking

Expose whether or not we support the PMU software tracking in our
scheduler capabilities, so userspace can query at runtime.

v2: Use I915_SCHEDULER_CAP_ENGINE_BUSY_STATS for a less ambiguous
capability name.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703143702.11339-1-chris@chris-wilson.co.uk

drm/i915/gem: Defer obj->base.resv fini until RCU callback

Since reservation_object_fini() does an immediate free, rather than
kfree_rcu as normal, we have to delay the release until after the RCU
grace period has elapsed (i.e. from the rcu cleanup callback) so that we
can rely on the RCU protected access to the fences while the object is a
zombie.

i915_gem_busy_ioctl relies on having an RCU barrier to protect the
reservation in order to avoid having to take a reference and strong
memory barriers.

v2: Order is important; only release after putting the pages!

Fixes: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the object")
Testcase: igt/gem_busy/close-race
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-chris@chris-wilson.co.uk

drm/i915/gt: Ignore forcewake acquisition for posting_reads

We don't care about the result of the read, so it may be garbage, we
only care that the mmio is flushed. As such, we can forgo using an
individual forcewake and lock around any posting-read for an engine.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-4-chris@chris-wilson.co.uk

drm/i915/gt: Assume we hold forcewake for execlists resume

We can assume the caller is holding a blanket forcewake for the
register writes during resume, and so we can skip taking individual
locks around each write inside execlists resume.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-3-chris@chris-wilson.co.uk

drm/i915/gt: Use caller provided forcewake for intel_mocs_init_engine

During post-reset resume, we call intel_mocs_init_engine to reinitialise
the MOCS registers. Suprisingly, especially when enhanced by lockdep,
the acquisition of the forcewake lock around each register write takes a
substantial portion of the reset time. We don't need to use the
individual forcewake here as we can assume that the caller is holding a
blanket forcewake for the reset&resume and the resume is serialised.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-2-chris@chris-wilson.co.uk

drm/i915: Check caller held wakerefs in assert_forcewakes_active

The intent of the assert is to document that the caller took the
appropriate wakerefs for the function. However, as Tvrtko pointed out,
we simply check whether the fw_domains are active and may be confused by
the auto wakeref which may be dropped between the check and use. Let's
be more careful in the assert and check that each fw_domain has an
explicit caller wakeref above and beyond the automatic wakeref.

v2: Fix spelling for config DRM_I915_DEBUG_RUNTIME_PM
v3: Timer may still be active after we drop the autowakeref, we need to
check domain->active instead.
v4: The timer checks domain->active, but we still need to check the
timer. (This is starting to look weird...)

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704102048.6436-1-chris@chris-wilson.co.uk

drm/i915: Flush the workqueue before draining

Trying to drain a workqueue while we may still be adding to it from
background tasks is, according to kernel/workqueue.c, verboten. So, add
a flush_workqueue() at the start of our cleanup procedure.

References: https://bugs.freedesktop.org/show_bug.cgi?id=110550
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-4-chris@chris-wilson.co.uk

drm/i915: Move the renderstate setup under gt/

The render state is used to initialise the default RCS context, and only
used during early setup from within the gt code. As such, it makes a
good candidate for placing within gt/, even if it is not yet entirely
clean of our GEM heritage.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704091925.7391-1-chris@chris-wilson.co.uk

drm/i915/gtt: Defer the free for alloc error paths

If we hit an error while allocating the page tables, we have to unwind
the incomplete updates, and wish to free the unused pd. However, we are
not allowed to be hoding the spinlock at that point, and so must use the
later free to defer it until after we drop the lock.

<3> [414.363795] BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/i915_gem_gtt.c:472
<3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: i915_selftest
<4> [414.364406] 3 locks held by i915_selftest/3905:
<4> [414.364408]  #0: 0000000034fe8aa8 (&dev->mutex){....}, at: device_driver_attach+0x18/0x50
<4> [414.364415]  #1: 000000006bd8a560 (&dev->struct_mutex){+.+.}, at: igt_ctx_exec+0xb7/0x410 [i915]
<4> [414.364476]  #2: 000000003dfdc766 (&(&pd->lock)->rlock){+.+.}, at: gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
<3> [414.364529] Preemption disabled at:
<4> [414.364530] [<0000000000000000>] 0x0
<4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G     U            5.2.0-rc7-CI-CI_DRM_6403+ #1
<4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
<4> [414.364699] Call Trace:
<4> [414.364704]  dump_stack+0x67/0x9b
<4> [414.364708]  ___might_sleep+0x167/0x250
<4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
<4> [414.364852]  free_pd+0xf/0x20 [i915]
<4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
<4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
<4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
<4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
<4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111050
Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-3-chris@chris-wilson.co.uk

drm/i915: Add N & CTS values for 10/12 bit deep color

Adding N & CTS values for 10/12 bit deep color from Appendix C
table in HDMI 2.0 spec. The correct values for N is not chosen
automatically by hardware for deep color modes.

v2: Remove unnecessary initialization of size

Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-2-aditya.swarup@intel.com

drm/i915: Use port clock to set correct N value

Use port_clock to check the clock values in n/cts lookup table instead
of crtc_clock. As port_clock is already adjusted based on color mode set
(8 bit or deep color), this will help in checking clock values for deep
color modes from n/cts lookup table.

Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-1-aditya.swarup@intel.com

drm/i915: Deal with machines that expose less than three QGV points

When SAGV is forced to disabled/min/med/max in the BIOS pcode will
only hand us a single QGV point instead of the normal three. Fix
the code to deal with that instead declaring the bandwidth limit
to be 0 MB/s (and thus preventing any planes from being enabled).

Also shrink the max_bw sturct a bit while at it, and change the
deratedbw type to unsigned since the code returns the bw as
an unsigned int.

Since we now keep track of how many qgv points we got from pcode
we can drop the earlier check added for the "pcode doesn't
support the memory subsystem query" case.

Cc: felix.j.degrood@intel.com
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Fixes: c457d9cf256e ("drm/i915: Make sure we have enough memory bandwidth on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

drm/i915: Mark up vma->active as safe for use inside shrinkers

Since a shrinker may be forced to wait on GPU activity,
i915_active_wait(&vma->active) must be safe for use inside a shrinker,
and so let's mark up the lock as being acquired by the shrinker to avoid
any nasty surprises creeping in.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-8-chris@chris-wilson.co.uk

drm/i915: Markup potential lock for i915_active

Make the lockchains more deterministic via i915_active by flagging the
potential lock.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-7-chris@chris-wilson.co.uk

drm/i915/gem: Free pages before rcu-freeing the object

As we have dropped the final reference to the object, we do not need to
wait until after the rcu grace period to drop its pages. We still require
struct_mutex to completely unbind the object to release the pages, so we
still need a free-worker to manage that from process context. By
scheduling the release of pages before waiting for the rcu should mean
that we are not trapping those pages from beyond the reach of the
shrinker.

v2: Pass along the request to skip if the vma is busy to the underlying
unbind routine, to avoid checking the reservation underneath the
i915->mm.obj_lock which may be used from inside irq context.

v3: Flip the bit for unbinding while active, for later convenience.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111035
Fixes: a93615f900bd ("drm/i915: Throw away the active object retirement complexity")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-6-chris@chris-wilson.co.uk

drm/i915/execlists: Hesitate before slicing

Be a little more hesitant before injecting a timeslice, and try to take
into account any change in priority that is due for the running task
before switching to another task. This will allow us to arbitrarily
prevent switching away from a request if we deem it necessarily to
disable preemption, for instance.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-9-chris@chris-wilson.co.uk

drm/i915/selftests: Lock the drm_mm while modifying

Remember to lock the drm_mm as we modify it, lest it be modified in the
background by retire/free workers!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-2-chris@chris-wilson.co.uk

drm/i915/selftests: Common live setup/teardown

We frequently, but not frequently enough!, remember to flush residual
operations and objects at the end of a live subtest. The purpose is to
cleanup after every subtest, leaving a clean slate for the next subtest,
and perform early detection of leaky state. As this should ideally be
common for all live subtests, pull the task into a common teardown
routine.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-1-chris@chris-wilson.co.uk

drm/i915/display: Handle lost primary_port across suspend

icl-dsi is dying on suspend/resume at

RIP: 0010:icl_update_active_dpll+0x2c/0xa0 [i915]

which appears due to the loss of the time primary_port across suspend.
Protect against the potential NULL dereference by assuming
ICL_PORT_DPLL_DEFAULT unless the port is actively specified otherwise.

Fixes: 24a7bfe0c2d7 ("drm/i915: Keep the TypeC port mode fixed when the port is active")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk

drm/i915: synchronize_irq() against the actual irq

When eliminating our use of drm_irq_install() I failed to convert
all our synchronize_irq() calls to consult pdev->irq instead of
dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq
we're no longer synchronizing against anything.

v2: Add intel_syncrhonize_irq() (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Imre Deak <imre.deak@intel.com>
Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702151723.29739-1-ville.syrjala@linux.intel.com

drm/i915/gtt: Don't check PPGTT presence on PPGTT-only platforms

We missed one place where we check PPGTT-only platform for PPGTT
presence. Let's remove it.
While I'm here let's assert that this particular code is never called on
pre-gen8 platforms.

References: 4bdafb9ddfa4 ("drm/i915: Remove i915.enable_ppgtt override")
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702113149.21200-2-michal.winiarski@intel.com

Revert "drm/i915: Introduce private PAT management"

This reverts commit 4395890a48551982549d222d1923e2833dac47cf.

It's been over a year since this was merged, and the actual users of
intel_ppat_get / intel_ppat_put never materialized.

Time to remove it!

v2: Unbreak suspend (Chris)
v3: Rebase, drop fixes tag to avoid confusion

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702113149.21200-1-michal.winiarski@intel.com

drm/i915: Fix memleak in runtime wakeref tracking

If we untrack wakerefs, the actual count may reach zero.
However the krealloced owners array is still there and
needs to be taken care of. Free the owners unconditionally
to fix the leak.

Fixes: bd780f37a361 ("drm/i915: Track all held rpm wakerefs")
Reported-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190701104442.9319-1-mika.kuoppala@linux.intel.com

drm/i915/icl: whitelist PS_(DEPTH|INVOCATION)_COUNT

The same tests failing on CFL+ platforms are also failing on ICL.
Documentation doesn't list the
WaAllowPMDepthAndInvocationCountAccessFromUMD workaround for ICL but
applying it fixes the same tests as CFL.

v2: Use only one whitelist entry (Lionel)

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-4-lionel.g.landwerlin@intel.com

drm/i915: whitelist PS_(DEPTH|INVOCATION)_COUNT

CFL:C0+ changed the status of those registers which are now
blacklisted by default.

This is breaking a number of CTS tests on GL & Vulkan :

  KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations (GL)

  dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* (Vulkan)

v2: Only use one whitelist entry (Lionel)

Bspec: 14091
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-3-lionel.g.landwerlin@intel.com

drm/i915: fix whitelist selftests with readonly registers

When a register is readonly there is not much we can tell about its
value (apart from its default value?). This can be covered by tests
exercising the value of the register from userspace.

For PS_INVOCATION_COUNT we've got the following piglit tests :

   KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations

Vulkan CTS tests :

   dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.*

v2: Use a local to shrink under 80cols.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 86554f48e511 ("drm/i915/selftests: Verify whitelist of context registers")
Tested-by: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190629131350.31185-1-chris@chris-wilson.co.uk

drm/i915: Report if i915_active is still busy upon waiting

If we try to wait on an i915_active from within a critical section, it
will remain busy (such as if we are shrinking from within
i915_active_ref). Report the failure so that we do not proceed thinking
it is idle.

Extracted from a future patch "drm/i915: Coordinate i915_active with its
own mutex".

Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190702092117.1707-1-chris@chris-wilson.co.uk

drm/i915/execlists: Refactor CSB state machine

Daniele pointed out that the CSB status information will change with
Tigerlake and suggested that we could rearrange our state machine to
hide the differences in generation. gcc also prefers the explicit state
machine, so make it so:

process_csb                                 1980    1967     -13

Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190701100502.15639-4-chris@chris-wilson.co.uk

drm/i915/ehl: Don't program PHY_MISC on EHL PHY C

Although EHL added a third combo PHY, no PHY_MISC register was added for
PHY C.  The bspec indicates that there's no need to program the "DE to
IO Comp Pwr Down" setting for this PHY that we usually need to set in
PHY_MISC.

v2:
 - Add IS_ELKHARTLAKE() guards since future platforms that have a PHY C
   are likely to reinstate the PHY_MISC register.  (Jose)
 - Use goto's to skip PHY_MISC programming & minimize code deltas. (Jose)

Bspec: 33148
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-4-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915/ehl: Add third combo PHY offset

v2: Rename register to _EHL_COMBOPHY_C.  (Jose)

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-3-matthew.d.roper@intel.com

drm/i915/icl: Drop port parameter to icl_get_combo_buf_trans()

The port parameter hasn't been used since the last bspec phy programming
update.  Drop it to make some upcoming changes simpler.

References: 9659c1af451a ("drm/i915/icl: combo port vswing programming changes per BSPEC")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-2-matthew.d.roper@intel.com

drm/i915/guc: Avoid reclaim locks during reset

During reset, we must be very selective in which locks we take as most
are tainted by being held across a wait or reclaim (kmalloc) which
implicitly waits. Inside the guc reset path, we reset the ADS to sane
defaults, but must keep it pinned from initialisation to avoid having to
pin it during reset.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190701100502.15639-1-chris@chris-wilson.co.uk

drm/i915: WARN about invalid lane reversal in TBT-alt/DP-alt modes

Lane reversal happens only in the FIA module for TBT-alt/DP-alt mode, so
WARN if lane reversal is attempted at a different level. See the
BSpec DDI_BUF_CTL register description.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-24-imre.deak@intel.com

drm/i915: Remove unneeded disconnect in TypeC legacy port mode

Disconnecting the TypeC PHY when the port is in legacy mode is not
necessary:
- BSpec doesn't specify a disconnect sequence for legacy mode.
- The use of the PHY is dedicated for the display in legacy mode.
- We keep the PHY always connected during runtime as well in legacy
  mode.

We disconnect the PHY when needed during a disabling modeset for the
port, so we can also remove the disconnect call from the destroy hook.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-23-imre.deak@intel.com

drm/i915: Add state verification for the TypeC port mode

Add state verification for the TypeC port mode wrt. the port's AUX power
well enabling/disabling. Also check the correctness of changing the port
mode:
- When enabling/disabling the AUX power well for a TypeC port we must hold
  the TypeC port lock - the case for AUX transfers - or hold a Type C
  port link reference - the case for modeset enabling/disabling.
- When changing the TypeC port mode the port's AUX power domain must be
  disabled.

v2: (Ville)
- Simplify power_well_async_ref_count().
- Fix the commit log, clarifying what are the valid conditions to
  enable/disable the AUX power wells.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-22-imre.deak@intel.com

drm/i915: Keep the TypeC port mode fixed when the port is active

The TypeC port mode needs to stay fixed whenever the port is active. Do
that by introducing a tc_link_refcount to account for active ports,
avoiding changing the port mode if a reference is held.

During the modeset commit phase we also have to reset the port mode and
update the active PLL reflecting the new port mode. We can do this only
once the port and its old PLL has been already disabled. Add the new
encoder update_prepare/complete hooks that are called around the whole
enabling sequence. The TypeC specific hooks of these will reset the port
mode, update the active PLL if the port will be active and ensure that
the port mode will stay fixed for the duration of the whole enabling
sequence by holding a tc_link_refcount.

During the port enabling, the pre_pll_enable/post_pll_disable hooks will
take/release a tc_link_refcount to ensure the port mode stays fixed
while the port is active.

Changing the port mode should also be avoided during connector detection
and AUX transfers if the port is active, we'll do that by checking the
port's tc_link_refcount.

When resetting the port mode we also have to take into account the
maximum lanes provided by the FIA. It's guaranteed to be 4 in TBT-alt
and legacy modes, but there may be less lanes available in DP-alt mode,
in which case we have to fall back to TBT-alt mode.

While at it also update icl_tc_phy_connect()'s code comment, reflecting
the current way of switching the port mode.

v2:
- Add the update_prepare/complete hooks to the encoder instead of the
  connector. (Ville)
- Simplify intel_connector_needs_modeset() by removing redundant if.
  (Ville)
v3:
- Fix sparse warning, marking static functions as such.
v4:
- Rebase on drm-tip.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-21-imre.deak@intel.com

drm/i915/icl: Reserve all required PLLs for TypeC ports

When enabling a TypeC port we need to reserve all the required PLLs for
it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks.
We can select the proper PLL for the current port mode from the reserved
PLLs only once we selected and locked down the port mode for the whole
duration of the port's active state. Resetting and locking down the port
mode can in turn happen only during the modeset commit phase once we
disabled the given port and the PLL it used.

To support the above reserve-and-select PLL semantic we store the
reserved PLLs along with their HW state in the CRTC state and provide a
way to select the active PLL from these. The selected PLL along with its
HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as
in the case of other port types.

Besides reserving all required PLLs no functional changes.

v2:
- Fix releasing the ICL PLLs, not clearing the PLLs from the old
  crtc_state.
- Init port_dpll to ICL_PORT_DPLL_DEFAULT closer to where port_dpll is
  used for symmetry with the corresponding ICL_PORT_DPLL_MG_PHY init.
  (Ville)
v3:
- Add FIXME: for clearing the ICL port PLLs from the new crtc state.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-20-imre.deak@intel.com

drm/i915/icl: Split getting the DPLLs to port type specific functions

For clarity factor out the combo PHY and TypeC PHY specific code from
icl_get_dplls() into their own functions.

No functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-19-imre.deak@intel.com

drm/i915: Sanitize the shared DPLL find/reference interface

Pass the PLL HW state to the PLL find/reference functions making it
clearer what is their input. Also pass to these the atomic state and the
CRTC object instead of the CRTC state, since they don't require the
latter.

Move setting the PLL in the crtc_state to the get_dpll() hook, which
is the more logical place for this, where the related PLL HW state was also
set.

This refactoring is also a preparation for a follow-up patch that will
have to find/reference multiple PLLs.

No functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-18-imre.deak@intel.com

drm/i915: Sanitize the shared DPLL reserve/release interface

For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/
to better match intel_release_shared_dplls(). Also, pass to the
reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and
CRTC object, that way these functions can look up the old or new state
as needed.

Also release the PLLs from the atomic state via a new
put_dplls->intel_unreference_shared_dpll() call chain for better
symmetry with the reservation via the
get_dplls->intel_reference_shared_dpll() call chain.

Since nothing uses the PLL returned by intel_reserve_shared_dplls(),
make it return only a bool.

While at it also clarify the reserve/release function docbook headers
making it clear that multiple DPLLs will be reserved/released and
whether the new or old atomic CRTC state is affected.

This refactoring is also a preparation for a follow-up change that needs
to reserve multiple DPLLs.

Kudos to Ville for the idea to pass intel_atomic_state around, to make
things clearer locally where an object's old/new atomic state is
required.

No functional changes.

v2:
- Fix checkpatch issue: typo in code comment.
v3:
- Rebase on drm-tip.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-17-imre.deak@intel.com

drm/i915: Sanitize the TypeC FIA lane configuration decoding

Use hex numbers, since that makes more sense when decoding a bit pattern.

No functional change.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-16-imre.deak@intel.com

drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers

We must keep the TypeC port mode fixed for the duration of the connector
detection and each AUX transfers. Add a new TypeC lock holding it around
these two sequences. For consistency also hold the lock during the port
mode sanitization.

Whenever resetting the port mode (only during the detection for now) the
port's AUX power domain must be disabled already. Flush the async power
domain disabling work to ensure this.

A follow-up patch will make the port mode changing more robust by
postponing the change for active ports.

v2:
- Fix checkpatch issue: missing annotation for tc_lock.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-15-imre.deak@intel.com

drm/i915: Fix the TypeC port mode sanitization during loading/resume

For using the correct AUX power domains we have to sanitize the TypeC
port mode early, so move that before encoder sanitization. To do this
properly read out the actual port mode instead of just relying on the
VBT legacy port flag (which can be incorrect).

We also verify that the PHY is connected as expected if the port is
active. In case the port is inactive we connect the PHY in case of a
legacy port - as we did so far. The PHY will be connected during
detection for DP-alt mode - as it was done so far. For TBT-alt mode
nothing needs to be done to connect the PHY.

v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
v3:
- Detect TCCOLD any time PORT_TX_DFLEXDPCSSS is read. (Ville)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-14-imre.deak@intel.com

drm/i915: Sanitize the TypeC connect/detect sequences

Make the order during detection more consistent: first reset the TypeC
port mode if needed (adding new helpers for this), then detect any
connected sink.

To check if a port mode reset is needed determine first the target port
mode based on the live status if a sink is already connected or the
PHY status complete flag otherwise.

Add a WARN in legacy mode if unexpectedly we can't set the unsafe mode
or if the FIA doesn't provide the 4 lanes required.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-13-imre.deak@intel.com

drm/i915: Handle the TCCOLD power-down event

Based on a recent BSpec update (Index/21750) we must handle the TCCOLD
event associated with the DP-alt mode. We can detect this event by
reading an invalid all-1s value from FIA registers.

After detecting TCCOLD we will:
- fall back to TBT-alt mode when attempting to switch to DP-alt mode
- conclude that nothing is connected during live status detection
- WARN when already in unsafe mode, since then TCCOLD is unexpected

v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
v3:
- Use 0xffffffff instead of -1 as invalid FIA reg value.
  (José, Ville)
- Check for TCCOLD in icl_tc_phy_status_complete() too. (Ville)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-12-imre.deak@intel.com

drm/i915: Wait for TypeC PHY complete flag to clear in safe mode

The PHY status complete flag normally clears when disconnecting the PHY
in DP-alt mode (achieved by switching to safe mode), so wait for the
flag to clear.

v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-11-imre.deak@intel.com

drm/i915: Factor out common parts from TypeC port handling functions

Factor out helpers reading/parsing the TypeC specific registers, making
current users of them clearer and letting us use them later.

While at it also:
- Simplify icl_tc_phy_connect() with an early return in legacy mode.
- Simplify the live status check using one bitmask for all HPD bits.
- Remove a micro-optimisation of the repeated safe-mode clearing.
- Make sure we fix the legacy port flag in all cases.

Except for the last two, no functional changes.

v2:
- Don't do reg reads at variable declarations. (Jani)
- Prevent constant truncated compiler warning when assigning the
  valid_hpd_mask. (Nick)
- s/intel_tc_port_get_lane_info/intel_tc_port_get_lane_mask/ (Ville)
v3:
- Make valid_hpd_mask init clear. (Ville)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-10-imre.deak@intel.com

drm/i915: Unify the TypeC port notation in debug/error messages

Unify the TypeC port notation in log messages, so that it matches the
spec. For instance the first ICL TypeC port will read as 'Port C/TC#1'.

v2:
- Format print the name only once. (José)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-9-imre.deak@intel.com

drm/i915: Use the correct AUX power domain in TypeC TBT-alt mode

In the TypeC TBT-alt port mode we must use the TBT AUX power domain,
fix that.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-8-imre.deak@intel.com

drm/i915: Fix the TBT AUX power well enabling

Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL
register.

Fixes: c7375d9542f1 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com

drm/i915: Don't enable the DDI-IO power in the TypeC TBT-alt mode

According to the spec we should not enable the DDI-IO power domain if
the TypeC port is in the TBT-alt mode, so do that only in the other
TypeC modes or for non-TypeC ports. See the internal BSpec Index/22243.

v2:
- Add the internal BSpec reference to the log message. (José)

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-6-imre.deak@intel.com

drm/i915: Sanitize the terminology used for TypeC port modes

The TypeC port mode can switch dynamically, to reflect that better call
the port's mode as 'mode' rather than 'type'.

While at it:
- s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/.
  'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality.

- Remove the 'unknown' TypeC port mode. The mode is always known, it's
  the TBT-alt/safe mode after HW reset and after disconnecting the PHY.
  Simplify the tc_port/tc_type checks accordingly.

- Don't WARN if the port mode changes, that can happen normally.

No functional changes.

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-5-imre.deak@intel.com

drm/i915: Move the TypeC port handling code to a separate file

Move the TypeC port handling functions to a new file for clarity.

While at it:
- s/icl_tc_port_connected()/intel_tc_port_connected()/
  icl_tc_phy_disconnect(), will be unexported later.

- s/intel_dp_get_fia_supported_lane_count()/
    intel_tc_port_fia_max_lane_count()/
  It's used for HDMI legacy mode too.

- Simplify function interfaces by passing only dig_port to them.

No functional changes.

v2:
- Fix checkpatch issues: +1/-1 empty lines in intel_tc.c and add
  missing SPDX to intel_tc.h. (Jani)

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-4-imre.deak@intel.com

drm/i915: Tune down WARNs about TBT AUX power well enabling

The HW completion flag for the TBT AUX power well enabling/disabling
gets stuck if the firmware tears down the TBT DP tunnel before the
completion.

We shouldn't complain about the timeout, since it's expected to happen
and doesn't cause further issues. We suppress the disabling timeout
already, do the same for enabling.

v2:
- Make the debug message more precise. (José)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-3-imre.deak@intel.com

drm/i915/icl: Add support to read out the TBT PLL HW state

Add support to read out the TBT PLL HW state.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-2-imre.deak@intel.com

drm/i915: Use intel state as much as possible in wm code

Instead of directly referencing drm_crtc_state, convert to
intel_ctc_state and use the base struct. This is useful when we're
making the split between uapi and hw state, and also makes the
code slightly more readable.

A lot of places also use cstate, instead of the more common crtc_state.
Clean those up to use crtc_state. Same for pstate vs plane_state. (Ville)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-7-maarten.lankhorst@linux.intel.com

drm/i915: Pass intel state to plane functions as well

Pass along the correct state as much as possible, instead of relying
on the drm state internally. This is required to rely on hw state
internally soon.

While at it, clean up intel_plane_atomic_check slightly, by using a
helper function to get the intel_crtc. (Ville)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-6-maarten.lankhorst@linux.intel.com

drm/i915: Use intel_crtc_state in sanitize_watermarks() too

Get rid of all instances of drm_crtc_state, and rename cstate to
crtc_state for more clarity.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-5-maarten.lankhorst@linux.intel.com

drm/i915: Convert hw state verifier to take more intel state, v2.

Like the rest of the intel atomic functions we should pass along
intel_crtc_state, and dereference drm_crtc_state only through
intel_crtc_state->base

While at it, rename old/new_state to old/new_crtc_state. (Ville)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-4-maarten.lankhorst@linux.intel.com

drm/i915: Convert most of atomic commit to take more intel state

Instead of passing along drm_crtc_state and drm_atomic_state, pass
along more intel_atomic_state and intel_crtc_state. This will
make the code more readable by not casting between drm state
and intel state all the time.

While at it, rename old_state to state, with the get_new/old helpers
there is no point in distinguishing between state before and after
swapping state any more. (Ville)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-3-maarten.lankhorst@linux.intel.com

drm/i915: Pass intel_crtc_state to needs_modeset()

In i915 we should use intel_crtc_state as much as possible, pass
intel_crtc_state to needs_modeset, before we clean up all other uses
of drm_crtc_state.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-2-maarten.lankhorst@linux.intel.com

drm/i915: rework reading pipe disable fuses

This prepares to have possibly more than 3 pipes. I didn't want to
continue the previous approach since the check for "are the disabled
pipes the last ones" poses a combinatory explosion. We need that check
because in several places of the code we have that assumption. If that
ever becomes false in a new HW, other parts of the code would have to
change.

Now we start by considering we have info->num_pipes enabled and disable
each pipe that is marked as disabled. Then it's a simple matter of
checking if we have at least one pipe and that all the enabled ones are
the first pipes, i.e. there are no holes in the bitmask.

Cc: Jose Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190625175437.14840-3-lucas.demarchi@intel.com

drm/i915: Make i945gm_vblank_work_func static

drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
drivers/gpu/drm/i915/i915_irq.c:3382:6: error: no previous prototype for ‘i945gm_vblank_work_func’ [-Werror=missing-prototypes]
 void i945gm_vblank_work_func(struct work_struct *work)

Jani wrote the idential patch, so for posterity:

The static keyword was apparently accidentally removed in commit
08fa8fd0faa5 ("drm/i915: Switch to per-crtc vblank vfuncs"), leading to
sparse warning:

drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol
'i945gm_vblank_work_func' was not declared. Should it be static?

Make the function static again.

Meanwhile, the 0-day kbuilder also spotted the mistake.

Fixes: 08fa8fd0faa5 ("drm/i915: Switch to per-crtc vblank vfuncs")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626224212.10141-1-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20190627091914.30795-1-jani.nikula@intel.com

drm/i915: make intel_uc_fw.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-13-jani.nikula@intel.com

drm/i915: make intel_gvt.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-12-jani.nikula@intel.com

drm/i915: make intel_guc_reg.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

v2: also include i915_reg.h (Michal)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-11-jani.nikula@intel.com

drm/i915: make intel_guc_fwif.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-10-jani.nikula@intel.com

drm/i915: make intel_guc_ct.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-9-jani.nikula@intel.com

drm/i915: make i915_vgpu.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-8-jani.nikula@intel.com

drm/i915: make i915_pvinfo.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-7-jani.nikula@intel.com

drm/i915: make i915_globals.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-6-jani.nikula@intel.com

drm/i915: make i915_fixed.h self-contained

Add the minimal includes/declarations to make the header self-contained,
and ensure it stays that way.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626144020.2155-4-jani.nikula@intel.com

drm/i915: add header search path to subdir Makefiles

With the subdirectories we lost the ability to build individual files on
the command line, for example:

$ make drivers/gpu/drm/i915/display/intel_display.o

This was due to the top level directory missing from header search
path. Add the header search paths to subdir Makefiles.

Note that none of the other options in the top level i915 Makefile are
taken into account when building individual files. Usually this is not a
concern.

Reported-by: Imre Deak <imre.deak@intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626143618.21800-2-jani.nikula@intel.com

drm/i915: prefix header search path with $(srctree)/

Per commit 43068cb7ba1f ("drm: prefix header search paths with
$(srctree)/") this is what we should be doing. Follow suit.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626143618.21800-1-jani.nikula@intel.com

drm/i915: Move OA files to separate folder

OA files look to be auto-generated so we can keep them all in
dedicated subdirectory.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626123826.39760-1-michal.wajdeczko@intel.com

drm/i915/ehl: Add voltage level requirement table

EHL has it own voltage level requirement depending on cd clock.

BSpec: 21809
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-3-jose.souza@intel.com

drm/i915/ehl: Remove unsupported cd clocks

EHL do not support 648 and 652.8 MHz.

v2:
- Limiting maximum CD clock by max_cdclk_freq instead of remove it
from icl_calc_cdclk()(Ville and Jani)

BSpec: 20598
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-2-jose.souza@intel.com

drm/i915/icl: Add new supported CD clocks

Now 180, 172.8 and 192 MHz are supported.

180 and 172.8 MHz CD clocks will only be used when audio is not
enabled as state by BSpec and implemented in
intel_crtc_compute_min_cdclk(), CD clock must be at least twice of
Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz
but we are not reading it.

v3:
- making icl clock arrays static (Ville)

BSpec: 20598
BSpec: 15729
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-1-jose.souza@intel.com

drm/i915: Lift intel_engines_resume() to callers

Since the reset path wants to recover the engines itself, it only wants
to reinitialise the hardware using i915_gem_init_hw(). Pull the call to
intel_engines_resume() to the module init/resume path so we can avoid it
during reset.

Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-3-chris@chris-wilson.co.uk

drm/i915: Only recover active engines

If we issue a reset to a currently idle engine, leave it idle
afterwards. This is useful to excise a linkage between reset and the
shrinker. When waking the engine, we need to pin the default context
image which we use for overwriting a guilty context -- if the engine is
idle we do not need this pinned image! However, this pinning means that
waking the engine acquires the FS_RECLAIM, and so may trigger the
shrinker. The shrinker itself may need to wait upon the GPU to unbind
and object and so may require services of reset; ergo we should avoid
the engine wake up path.

The danger in skipping the recovery for idle engines is that we leave the
engine with no context defined, which may interfere with the operation of
the power context on some older platforms. In practice, we should only
be resetting an active GPU but it something to look out for on Ironlake
(if memory serves).

Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-2-chris@chris-wilson.co.uk

drm/i915: Add a wakeref getter for iff the wakeref is already active

For use in the next patch, we want to acquire a wakeref without having
to wake the device up -- i.e. only acquire the engine wakeref if the
engine is already active.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-1-chris@chris-wilson.co.uk

drm/i915: Initialize drm_driver vblank funcs at compile time

Move the .get_vblank_timestamp() and .get_scanout_position()
initialization to happen at compile time. No point in delaying
it since we always assign the same functions.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-5-ville.syrjala@linux.intel.com

drm/i915: Nuke drm_driver irq vfuncs

Stop using the irq vfuncs under drm_driver. That's not going to fly
in a mixed gen environment since the structure is shared between all
the devices.

v2: Allow intel_irq_uninstall() to be called twice due to
    intel_modeset_cleanup() calling it as well. Toss in a
    FIXME to remind us that this is not great.

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

drm/i915: Switch to per-crtc vblank vfuncs

Switch from the driver-wide vblank vfuncs to the per-crtc ones so that
we don't have so many platform specific vfuncs in the driver struct.

We still need to do something about the rest fo the irq vfuncs...

v2: s/INTEL_GEN>=3/IS_GEN3/

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Fix various tracepoints for gen2

Gen2 doesn't have a frame counter and apparently we no longer provide
a fake .get_vblank_counter() hook for it. That means all tracepoints
calling that hook will oops. Update the tracepoints to use
intel_crtc_get_vblank_counter() which will gracefully fall back to
using the software counter. This is actually a better approach since
we now get (hopefully accurate) frame numbers in the traces.

This also gets rid of the raw driver->get_vblank_counter() calls, which
we need to do in order to switch to the per-crtc vblank vfuncs.

v2: Deal with new tracepoints
v3: Use a distinct variable name for the internal crtc iterator (Chris)

Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 967dd4841787 ("drm: remove drm_vblank_no_hw_counter assignment from driver code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-2-ville.syrjala@linux.intel.com

drm/i915/selftests: Fixup atomic reset checking

We require that the intel_gpu_reset() was atomic, not the whole of
i915_reset() which is guarded by a mutex. However, we do require that
i915_reset_engine() is atomic for use from within the submission tasklet.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190626134433.6318-3-chris@chris-wilson.co.uk