Now that we're not using MSI anymore on gen4 we can start
using GMBUS and AUX interrupts again. These were disabled on
account of them causing the hardware to somehow generate
legacy interrupts even when MSI was enabled.

See commit c12aba5a ("drm/i915: stop using GMBUS IRQs on Gen4
chips") and commit 4e6b788c ("drm/i915: Disable dp aux irq on
g4x") for more details.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-17-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>

All the irq_preinstall and irq_uninstall hooks are now identical. Let's
just rename them all the irq_reset and remove the pointless duplicates.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-16-ville.syrjala@linux.intel.com

Currently we're unmasking some random looking bits in HWSTAM
on gen3/4/5. The two bits we apparently unmask are 0 and 12,
and also bits 16-31 on gen4/5.
What those bits do depends on the gen as follows:
 bit 0: Breakpoint (gen2), ASLE (gen3), reserved (gen4), render user interrupt (gen5)
 bit 12: Sync flush statusa (gen2-4), reserved (gen5)
 bit 16-31: The ones that can unmasked seem to be mostly some
            display stuff on gen4. Bit 18 is the PIPE_CONTROL notify,
	    which might be the only intresting one. On gen5 all the
	    bits are reserved.

So I don't know whether we actually depend on that status page write
somehow. Extra seqno coherency by accident perhaps? Except we don't
even unmask the user interrupt bit in HWSTAM except on gen5, and
sync flush isn't something we use normally, so seems unlikely. So
let's just assume we don't need any of this and mask everything in
HWSTAM.

From gen6 onwards there's a separate HWSTAM for each engine, and so
we deal with them during the engine setup.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-15-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

The execlist code already masks everything in the ring HWSTAM, but
the ringbuffer code doesn't. Let's go ahead and do that. Pre-gen6
platforms setup HWSTAM during irq setup already since there's just
the one register, and it also contains bits for non-ring interrupts.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-13-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

We're always specifying description of each module param in
separate macro. Let's combine description into our main macro.
Started with Coccinelle, followed by minor cleanup.

@match1@
declarer name MODULE_PARM_DESC;
identifier n;
constant c;
@@
(
-	MODULE_PARM_DESC(n, c);
)

@fix1 depends on match1@
declarer name i915_param_named;
declarer name i915_param_named_unsafe;
identifier match1.n;
constant match1.c;
@@
(
	i915_param_named(n, ...
+	, c
	);
|
	i915_param_named_unsafe(n, ...
+	, c
	);
)
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914150805.28376-4-michal.wajdeczko@intel.com

As we now use same name for public module param and its local
representation we can simplify param definition macro.

Changes done with Coccinelle:

@@
declarer name module_param_named;
declarer name module_param_named_unsafe;
declarer name i915_param_named;
declarer name i915_param_named_unsafe;
identifier n;
@@

(
-module_param_named(n, i915.n,
+i915_module_param_named(n,
  ...);
|
-module_param_named_unsafe(n, i915.n,
+i915_module_param_named_unsafe(n,
 ...);
)
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914150805.28376-3-michal.wajdeczko@intel.com

This modparam affects not only LVDS but also eDP panels. Additionally
with this rename we will keep modparam and i915_params field name in sync.
This patch will unblock us with further improvements around params defs.
Suggested-by: NVille Syrjala <ville.syrjala@intel.com>
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914150805.28376-2-michal.wajdeczko@intel.com

To silence the critcs:

[56532.161115] workqueue: PF_MEMALLOC task 36(khugepaged) is flushing !WQ_MEM_RECLAIM i915-userptr-release:          (null)
[56532.161138] ------------[ cut here ]------------
[56532.161144] WARNING: CPU: 1 PID: 36 at kernel/workqueue.c:2418 check_flush_dependency+0xe8/0xf0
[56532.161145] Modules linked in: wmi_bmof
[56532.161148] CPU: 1 PID: 36 Comm: khugepaged Not tainted 4.13.0-krejzi #1
[56532.161149] Hardware name: HP HP ProBook 470 G3/8102, BIOS N78 Ver. 01.17 06/08/2017
[56532.161150] task: ffff8802371ee200 task.stack: ffffc90000174000
[56532.161152] RIP: 0010:check_flush_dependency+0xe8/0xf0
[56532.161152] RSP: 0018:ffffc900001777b8 EFLAGS: 00010286
[56532.161153] RAX: 000000000000006c RBX: ffff88022fc5a000 RCX: 0000000000000001
[56532.161154] RDX: 0000000000000000 RSI: 0000000000000086 RDI: 00000000ffffffff
[56532.161155] RBP: 0000000000000000 R08: 14f038bb55f6dae0 R09: 0000000000000516
[56532.161155] R10: ffffc900001778a0 R11: 000000006c756e28 R12: ffff8802371ee200
[56532.161156] R13: 0000000000000000 R14: 000000000000000b R15: ffffc90000177810
[56532.161157] FS:  0000000000000000(0000) GS:ffff880240480000(0000) knlGS:0000000000000000
[56532.161158] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[56532.161158] CR2: 0000000004795ff8 CR3: 000000000220a000 CR4: 00000000003406e0
[56532.161159] Call Trace:
[56532.161161]  ? flush_workqueue+0x136/0x3e0
[56532.161178]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[56532.161179]  ? try_to_wake_up+0x1ce/0x3b0
[56532.161183]  ? i915_gem_userptr_mn_invalidate_range_start+0x13f/0x150
[56532.161184]  ? _raw_spin_unlock+0xd/0x20
[56532.161186]  ? i915_gem_userptr_mn_invalidate_range_start+0x13f/0x150
[56532.161189]  ? __mmu_notifier_invalidate_range_start+0x4a/0x70
[56532.161191]  ? try_to_unmap_one+0x5e5/0x660
[56532.161193]  ? rmap_walk_file+0xe4/0x240
[56532.161195]  ? __ClearPageMovable+0x10/0x10
[56532.161196]  ? try_to_unmap+0x8c/0xe0
[56532.161197]  ? page_remove_rmap+0x280/0x280
[56532.161199]  ? page_not_mapped+0x10/0x10
[56532.161200]  ? page_get_anon_vma+0x90/0x90
[56532.161202]  ? migrate_pages+0x6a5/0x940
[56532.161203]  ? isolate_freepages_block+0x330/0x330
[56532.161205]  ? compact_zone+0x593/0x6a0
[56532.161206]  ? enqueue_task_fair+0xc3/0x1180
[56532.161208]  ? compact_zone_order+0x9b/0xc0
[56532.161210]  ? get_page_from_freelist+0x24a/0x900
[56532.161212]  ? try_to_compact_pages+0xc8/0x240
[56532.161213]  ? try_to_compact_pages+0xc8/0x240
[56532.161215]  ? __alloc_pages_direct_compact+0x45/0xe0
[56532.161216]  ? __alloc_pages_slowpath+0x845/0xb90
[56532.161218]  ? __alloc_pages_nodemask+0x176/0x1f0
[56532.161220]  ? wait_woken+0x80/0x80
[56532.161222]  ? khugepaged+0x29e/0x17d0
[56532.161223]  ? wait_woken+0x80/0x80
[56532.161225]  ? collapse_shmem.isra.39+0xa60/0xa60
[56532.161226]  ? kthread+0x10d/0x130
[56532.161227]  ? kthread_create_on_node+0x60/0x60
[56532.161228]  ? ret_from_fork+0x22/0x30
[56532.161229] Code: 00 8b b0 10 05 00 00 48 8d 8b b0 00 00 00 48 8d 90 b8 06 00 00 49 89 e8 48 c7 c7 38 55 09 82 c6 05 f9 c6 1d 01 01 e8 0e a1 03 00 <0f> ff e9 6b ff ff ff 90 48 8b 37 40 f6 c6 04 75 1b 48 c1 ee 05
[56532.161251] ---[ end trace 2ce2b4f5f69b803b ]---
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170911084135.22903-2-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>

Commit 1bf6ad62 ("drm/vblank: drop the mode argument from
drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but
did not remove the local variable. Do so now.

Fixes: 1bf6ad62 ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914164213.18461-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

No functional changes. Only change the macro from
"DPLL_CFGCR0_DC0_FRAC_SHIFT to DPLL_CFGCR0_DCO_FRACTION_SHIFT
to be consistent with DPLL_CFGCR0_DCO_FRACTION_MASK
and DPLL_CFGCR0_DCO_FRACTION

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505413899-30876-1-git-send-email-manasi.d.navare@intel.com

Bspec claims that HWSTAM is only 16 bits on gen3, but the other
interrupts registers are 32 bits and there are 18 valid interrupt
bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the
bits, so it seems the spec is incorrect about the size of the
register. And indeed I can clear bits 16 and 17 just fine with
a 32 bit write. So let's adjust the code to treat the register
as 32 bits.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-14-ville.syrjala@linux.intel.com

Eliminate the loops from the gen2-3 irq handlers. Since we don't use
MSI anymore on these platforms, and thus the CPU interrupt will be level
triggered, we shouldn't need to play any tricks with IER to induce edges
from IIR. IIR itself still detects only edges from PIPESTAT & co. on
gen4 but since IIR is double buffered and we only clear one bit per irq
handler invocation we can use the normal "clear PIPESTAT & co. -> clear
IIR" approach to ack the interrupts. On gen2 everything is level
triggered, and gen3 presumably follows either the gen2 or gen4 approach
since nothing else would really make sense.

v2: Drop the IER tricks since we no longer use MSI

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/20170818183705.27850-12-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Extract the gen2-4 PIPESTAT irq handling into separate functions just
like we already do on VLV/CHV.

We can share valleyview_pipestat_irq_ack() on all gmch platforms to
actually read and clear the PIPESTAT status bits, so let's rename
it to i9xx_pipestat_irq_ack().
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-11-ville.syrjala@linux.intel.com

There should be no way to land in irq_uninstall without a
valid dev_priv. Let's kill off the remaining checks, which are
probably some kind of UMS leftovers. Not all the irq_uninstall
hooks even had them anymore.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-10-ville.syrjala@linux.intel.com

Do the irq_mask/enable_mask setup in the same way on gen3/4, and also
reorder the steps to make the code more uniform.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-9-ville.syrjala@linux.intel.com

We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook
so doing it again in the .irq_postinstall is pointless.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-8-ville.syrjala@linux.intel.com

Unify the appaerance of the gen2-4 irq postinstall hooks a little
bit by doing the EMR setup first on all the platforms.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-7-ville.syrjala@linux.intel.com

Unify the appearance of the gen2 irq code with the gen3+ code by
introducing the GEN2_IRQ_RESET/INIT macros.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-6-ville.syrjala@linux.intel.com

Replace the manual IMR+IER+IIR write sequences with the appropriate
GEN3_IRQ_RESET/INIT macro invocations in gen3/4.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-5-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for
gen3/4 hardware as those have 32 bit interrupt registers. Let's
rename the macros to reflect that fact.

Gen2 on the other hand has 16 bit interrupt registers so these
macros aren't really appropriate there.

v2: Fix patch subject (Maarten)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-4-ville.syrjala@linux.intel.com

We have a lot of different ways of clearing the PIPESTAT registers.
Let's unify it all into one function. There's no magic in PIPESTAT
that would require any of the double clearing and whatnot that
some of the code tries to do. All we can really do is clear the status
bits and disable the enable bits. There is no way to mask anything
so as soon as another event happens the status bit will become set
again, and trying to clear them twice or something can't protect
against that.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

commit fd3a4024 ("drm/i915: Rip out legacy page_flip completion/irq
handling") removed the code to hande the flip done/pending interrupts,
but it failed to actually disable/mask those interrupts. Let's do that
now.

Also remove a stale comment that was left behind.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-2-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Remove the "INDEX" suffix from PPAT marcos as they are bits actually, not
indexes.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505392783-4084-2-git-send-email-zhi.a.wang@intel.com

The private PAT management is to support PPAT entry manipulation. Two
APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
and intel_ppat_put.

intel_ppat_get will search for an existing PPAT entry which perfectly
matches the required PPAT value. If not, it will try to allocate a new
entry if there is any available PPAT indexs, or return a partially
matched PPAT entry if there is no available PPAT indexes.

intel_ppat_put will put back the PPAT entry which comes from
intel_ppat_get. If it's dynamically allocated, the reference count will
be decreased. If the reference count turns into zero, the PPAT index is
freed again.

Besides, another two callbacks are introduced to support the private PAT
management framework. One is ppat->update_hw(), which writes the PPAT
configurations in ppat->entries into HW. Another one is ppat->match, which
will return a score to show how two PPAT values match with each other.

v17:

- Refine the comparision of score of BDW. (Joonas)

v16:

- Fix a bug in PPAT match function of BDW. (Joonas)

v15:

- Refine some code flow. (Joonas)

v12:

- Fix a problem "not returning the entry of best score". (Zhenyu)

v7:

- Keep all the register writes unchanged in this patch. (Joonas)

v6:

- Address all comments from Chris:
http://www.spinics.net/lists/intel-gfx/msg136850.html

- Address all comments from Joonas:
http://www.spinics.net/lists/intel-gfx/msg136845.html

v5:

- Add check and warnnings for those platforms which don't have PPAT.

v3:

- Introduce dirty bitmap for PPAT registers. (Chris)
- Change the name of the pointer "dev_priv" to "i915". (Chris)
- intel_ppat_{get, put} returns/takes a const intel_ppat_entry *. (Chris)

v2:

- API re-design. (Chris)
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v7
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
[Joonas: Use BIT() in the enum in bdw_private_pat_match]
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505392783-4084-1-git-send-email-zhi.a.wang@intel.com

Use the LLC/eLLC hotspot avoidance mode for CCS on LLC machines. This is
reported to give better performance.

Testing has indicated that we don't need to enforce any massive 2 or 4
MiB alignment for all compressed resources even though there are still
plenty of stale comments in the spec suggesting that we do.

We do need to make sure every hardware unit that deals with the
compressed data uses the same hash mode.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-4-ville.syrjala@linux.intel.comReviewed-by: NBen Widawsky <ben@bwidawsk.net>

Convert to use the freshly available made INTEL_GEN_MASK for easier
grepping and improve function readability and clarify the UABI
documentation.

No functional changes.

v2:
- Lift GEM_BUG_ONs and use is_power_of_2 (Chris)
- Retain -EINVAL on bad flags behavior (Chris)

v3:
- Extract flags with 'entry->size - 1' (Chris)

v4:
- Add GEM_BUG_ON on for flags vs entry offset (Chris)

v5:
- Use 'u16' to match 'dev_priv' (Ville)

v6:
- Fix checkpatch.pl errors
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913115255.13851-2-joonas.lahtinen@linux.intel.com

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable
within static declarations (unlike compound statements).

v2:
- s/combound/compound/ (Tvrtko)
- Fix whitespace (yes, we need automatic checkpatch.pl)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913115255.13851-1-joonas.lahtinen@linux.intel.com

DK had pointed out a comment there was hard to understand, so I
tried to read back again and I couldn't understand that as well.
So let me re-phrase that in a way that anyone can understand
later, even myself.

Also fixed the comment block style.

v2: Accept DK's suggestion on PSR_state 2 and PSR_state 3 named
    as spec.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170912183059.5086-1-rodrigo.vivi@intel.com

The engine also provides a mirror of the CSB write pointer in the HWSP,
but not of our read pointer. To take advantage of this we need to
remember where we read up to on the last interrupt and continue off from
there. This poses a problem following a reset, as we don't know where
the hw will start writing from, and due to the use of power contexts we
cannot perform that query during the reset itself. So we continue the
current modus operandi of delaying the first read of the context-status
read/write pointers until after the first interrupt. With this we should
now have eliminated all uncached mmio reads in handling the
context-status interrupt, though we still have the uncached mmio writes
for submitting new work, and many uncached mmio reads in the global
interrupt handler itself. Still a step in the right direction towards
reducing our resubmit latency, although it appears lost in the noise!

v2: Cannonlake moved the CSB write index
v3: Include the sw/hwsp state in debugfs/i915_engine_info
v4: Also revert to using CSB mmio for GVT-g
v5: Prevent the compiler reloading tail (Mika)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Acked-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-6-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

The engine provides a mirror of the CSB in the HWSP. If we use the
cacheable reads from the HWSP, we can shave off a few mmio reads per
context-switch interrupt (which are quite frequent!). Just removing a
couple of mmio is not enough to actually reduce any latency, but a small
reduction in overall cpu usage.

Much appreciation for Ben dropping the bombshell that the CSB was in the
HWSP and for Michel in digging out the details.

v2: Don't be lazy, add the defines for the indices.
v3: Include the HWSP in debugfs/i915_engine_info
v4: Check for GVT-g, it currently depends on intercepting CSB mmio
v5: Fixup GVT-g mmio path
v6: Disable HWSP if VT-d is active as the iommu adds unpredictable
memory latency. (Mika)
v7: Also markup the CSB read with READ_ONCE() as it may still be an mmio
read and we want to stop the compiler from issuing a later (v.slow) reload.
Suggested-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Acked-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913133534.26927-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

At the time of commit 1f767e02 ("drm/i915: HWS must be in the
mappable region for g33"), drm_mm insertion would often default to
placing a new object high in the zone forcing us to specify that certain
HWSP must be bound within the low mappable region. Since then, drm_mm
has gained more finesse over its placement and exposes that to the
caller, commit 4e64e553 ("drm: Improve drm_mm search (and fix
topdown allocation) with rbtrees"). As such where possible we want the
HWSP to be outside of the mappable aperture and so need to specify that
can be pinned high.
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>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-4-chris@chris-wilson.co.uk

On gen8+ we're currently using the PPHWSP of the kernel ctx as the
global HWSP. However, when the kernel ctx gets submitted (e.g. from
__intel_autoenable_gt_powersave) the HW will use that page as both
HWSP and PPHWSP. This causes a conflict in the register arena of the
HWSP, i.e. dword indices below 0x30. We don't current utilize this arena,
but in the following patches we will take advantage of the cached
register state for handling execlist's context status interrupt.

To avoid the conflict, instead of re-using the PPHWSP of the kernel
ctx we can allocate a separate page for the HWSP like what happens for
pre-execlists platform.

v2: Add a use-case for the register arena of the HWSP.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-email-daniele.ceraolospurio@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-3-chris@chris-wilson.co.uk

Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption, get the
lrca offset from the kernel_context engine state.

And while looking at this part of the GuC interaction, it was also
noticed that the firmware expects the size of only the engine context
(context minus the execlist part, i.e. don't include the first 80
dwords), so pass the right size.

v2: Use the new macros to prevent abusive overuse of the old ones (Chris).
Reported-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-2-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-2-chris@chris-wilson.co.uk

Not only the context image consist of two parts (the PPHWSP, and the
logical context state), but we also allocate a header at the start of
for sharing data with GuC. Thus every lrc looks like this:

  | [guc]          | [hwsp] [logical state] |
  |<- our header ->|<- context image      ->|

So far, we have oversimplified whenever we use each of these parts of the
context, just because the GuC header happens to be in page 0, and the
(PP)HWSP is in page 1. But this had led to using the same define for more
than one meaning (as a page index in the lrc and as 1 page).

This patch adds defines for the GuC shared page, the PPHWSP page and the
start of the logical state. It also updated the places where the old
define was being used. Since we are not changing the size (or format) of
the context, there are no functional changes.

v2: Use PPHWSP index for hws again.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/20170712193032.27080-1-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-1-chris@chris-wilson.co.uk

As realised by commit 9e3d6223 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x).
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913105154.2910-2-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

As realised by commit 9e3d6223 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x). This catches a
couple of instances in the display code using (u64)x * (u32)y.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170913105154.2910-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The sgt iterators cause an

drivers/gpu/drm/i915/i915_gpu_error.c:846 i915_error_object_create() warn: statement has no effect 7

everywhere they are used. If we change the code slightly, we can achieve
the same increment without altering the output or raising a warning.

   text	   data	    bss	    dec	    hex	filename
1267906	  20587	   3168	1291661	 13b58d	before
1267906	  20587	   3168	1291661	 13b58d	after
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/20170913105754.4423-1-chris@chris-wilson.co.uk

Spare some comments and other small style changes.
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505252197-27696-3-git-send-email-oscar.mateo@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We never used it in i915 and it's going to be removed
in newer GuC firmwares anyway.
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505252197-27696-2-git-send-email-oscar.mateo@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The default values for the default scheduling policy come from the
GuC firmware itself. Transform the magic numbers into defines.
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505252197-27696-1-git-send-email-oscar.mateo@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>