Some MG PLL registers have fields that need to be preserved at their HW
default or BIOS programmed values. So make sure we preserve them.

v2:
- Add comment to icl_mg_pll_write() explaining the need for register
  masks. (Vandita)
- Fix patchwork checkpatch warning.

v3:
- Rebase on drm-tip.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v1)
Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180619164115.7835-1-imre.deak@intel.com

Atm we're zeroing out fields in MG_PLL_BIAS and MG_PLL_TDC_COLDST_BIAS
if refclk is 38.4MHz, whereas the spec tells us to preserve them.
Although the calculated values mostly match the register defaults even
for the 38.4MHz case, there are some differences wrt. what BIOS
programs (I noticed at least differences in the MG_PLL_BIAS/IREFTRIM and
MG_PLL_BIAS/BIASCAL_EN fields). In the lack of further info on how to
program these fields, just do what the spec says and preserve the BIOS
state.

v2:
- Preserve the BIOS programmed reg fields instead of programming them.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v1)
Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615143911.31082-1-imre.deak@intel.com

This became dead code with commit 309bd8ed ("drm/i915: Reinstate
GMBUS and AUX interrupts on gen4/g4x").

v2: Move comment about HW behavior to where decision is made to enable
MSI (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523180435.18042-1-lucas.demarchi@intel.com

To aide debugging spurious EINVALs, include a debug message every time
we emit one from execbuf.

References: https://bugs.freedesktop.org/show_bug.cgi?id=106744Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621080150.8110-1-chris@chris-wilson.co.uk

We only need to apply the BIAS for self-relocations into the batchbuffer
iff the execobject has any relocations.

This suppresses some warnings we may get with a full gtt (so the batch
object has wound up at 0 from a previous invocation), but doesn't fix
the underlying problem of how we tried to move a pinned batch vma (how
we have a pinned user vma outside of execbuf, I do not know, though this
being on an aliasing ppgtt means it could be a spurious pinning via the
global gtt). One step at a time...

References: https://bugs.freedesktop.org/show_bug.cgi?id=106744#c1
Testcase: igt/gem_exec_gttfill # byt (sporadic)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621073205.26701-1-chris@chris-wilson.co.uk

The guc submission backends expects to only be run from (at least)
softirq context, but during our intel_engine_is_idle() check we would
call into the tasklet to make sure it was flushed. As this could occur
from process context, occasionally we would be caught out using a
wait_for_atomic() not from an atomic context:

[   59.939091] WARN_ON_ONCE((1) && !(preempt_count() != 0))
[   59.939142] WARNING: CPU: 1 PID: 2901 at drivers/gpu/drm/i915/intel_guc_submission.c:615 guc_submission_tasklet+0x784/0xa90 [i915]
[   59.939143] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers
[   59.939164] CPU: 1 PID: 2901 Comm: gem_exec_schedu Tainted: G     U  W         4.18.0-rc1-g93475d62c730-drmtip_67+ #1
[   59.939165] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3610 03/29/2018
[   59.939188] RIP: 0010:guc_submission_tasklet+0x784/0xa90 [i915]
[   59.939189] Code: fc ff ff 80 3d 2f 87 11 00 00 0f 85 80 fb ff ff 48 c7 c6 f8 49 40 c0 48 c7 c7 80 41 3e c0 c6 05 14 87 11 00 01 e8 2c ea d6 d3 <0f> 0b e9 5f fb ff ff 8b 46 38 89 cf 31 c7 83 e7 c0 75 08 39 c1 0f
[   59.939253] RSP: 0018:ffffaafe08a03c10 EFLAGS: 00010286
[   59.939255] RAX: 0000000000000000 RBX: ffff8f9112c246f0 RCX: 0000000000000001
[   59.939256] RDX: 0000000080000001 RSI: ffffffff95086d8e RDI: 00000000ffffffff
[   59.939257] RBP: ffff8f9112c24680 R08: 000000009517be77 R09: 0000000000000000
[   59.939258] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f9112c24700
[   59.939259] R13: ffff8f9112c24700 R14: 0000000000000000 R15: ffff8f9112c242a8
[   59.939260] FS:  00007fc2cc7e5980(0000) GS:ffff8f9136c40000(0000) knlGS:0000000000000000
[   59.939261] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   59.939262] CR2: 00007fc2cc815040 CR3: 000000021f10e003 CR4: 00000000003606e0
[   59.939263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   59.939264] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   59.939265] Call Trace:
[   59.939288]  ? intel_engine_is_idle+0x64/0x160 [i915]
[   59.939323]  ? intel_engine_dump+0x638/0x890 [i915]
[   59.939327]  ? seq_printf+0x49/0x70
[   59.939353]  ? i915_engine_info+0xc8/0x100 [i915]
[   59.939356]  ? drm_get_color_range_name+0x20/0x20
[   59.939361]  ? seq_read+0xf1/0x470
[   59.939365]  ? trace_hardirqs_on_caller+0xe0/0x1b0
[   59.939370]  ? full_proxy_read+0x51/0x80
[   59.939389]  ? __vfs_read+0x31/0x170
[   59.939395]  ? do_sys_open+0x13b/0x240
[   59.939398]  ? rcu_read_lock_sched_held+0x6f/0x80
[   59.939401]  ? vfs_read+0x9e/0x140
[   59.939404]  ? ksys_read+0x50/0xc0
[   59.939409]  ? do_syscall_64+0x55/0x190
[   59.939412]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   59.939420] irq event stamp: 552834
[   59.939422] hardirqs last  enabled at (552833): [<ffffffff940fc74c>] console_unlock+0x3fc/0x600
[   59.939425] hardirqs last disabled at (552834): [<ffffffff94a0111c>] error_entry+0x7c/0x100
[   59.939451] softirqs last  enabled at (552614): [<ffffffffc02e0f53>] i915_request_add+0x2e3/0x7b0 [i915]
[   59.939470] softirqs last disabled at (552604): [<ffffffffc02e0ecb>] i915_request_add+0x25b/0x7b0 [i915]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106977
Fixes: dd0cf235 ("drm/i915: Speed up idle detection by kicking the tasklets")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620135929.23956-1-chris@chris-wilson.co.uk

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Starting Icelake silicon supports 10-bpc hdmi to support certain
media workloads. Currently hdmi supports 8 and 12 bpc. Plumbed
in support for 10 bit hdmi.

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-18-paulo.r.zanoni@intel.com

Currently for the psr_table->tp2_tp3_wakeup_time case 3 there appears
to be a copy-paste error from the previous switch statement where
dev_priv->vbt.psr.tp1_wakeup_time_us is being assigned and I believe
it should be dev_priv->vbt.psr.tp2_tp3_wakeup_time_us that should be
assigned instead.

Detected by CoverityScan, CID#1470105 ("Copy-paste error")

Fixes: 77312ae8 ("drm/i915/psr: vbt change for psr")
Signed-off-by: NColin Ian King <colin.king@canonical.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/20180620132543.28092-1-colin.king@canonical.com

commit 5422b37c ("drm/i915/psr: Kill delays when activating psr
back.") removed the call to cancel a scheduled psr_work from
psr_disable() and instead added an early return in the work function. But,
if the scheduled work item is executed after psr_enable(), we end up
printing warnings as PSR is already enabled and active. So, put the
cancel_work call back in psr_disable().

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Fixes: 5422b37c ("drm/i915/psr: Kill delays when activating psr back.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106948Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618220207.2778-1-dhinakaran.pandiyan@intel.com

Along the early error path for igt_switch_to_kernel_context we may try
to dereference an invalid error pointer. Instead, return early rather
than dump the GEM trace since we haven't yet emitted anything of
interest.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 09a4c02e ("drm/i915: Look for an active kernel context before switching")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620112441.13085-1-chris@chris-wilson.co.uk

gvt-next-2018-06-19

- fine-grained per vgpu locking (Colin)
- fine-grained vgpu scheduler locking (Colin)
- deliver windows guest cursor hotspot info (Tina)
- GVT-g BXT support (Colin)
- other misc and checker fixes (Chris, Xinyun)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180619090043.ly6gquafbmxuus6h@zhen-hp.sh.intel.com

The hooks aren't supposed to modify the ELD, so use const pointer. As a
drive-by fix, use drm_eld_size() to log ELD size.
Suggested-by: NVille Syrjala <ville.syrjala@linux.intel.com>
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/20180619124437.10982-1-jani.nikula@intel.com

The PCH transcoder registers are only 12 bits wide for the hdisplay
and hblank_start values. On HSW/BDW the CPU side registers are 13
bits wide. intel_mode_valid() only checks against the higher limit
(since we don't know where the mode is to be used), so an extra
check is required against the FDI limits.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-3-ville.syrjala@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

Validate that all display timings fit within the number of bits
we have in the transcoder timing registers.

The limits are:
hsw+:
 4k: vdisplay, vblank_start
 8k: everything else
gen3+:
 4k: h/vdisplay, h/vblank_start
 8k: everything else
gen2:
 2k: h/vdisplay, h/vblank_start
 4k: everything else

Also document the fact that the mode_config.max_width/height limits
refer to just the max framebuffer dimensions we support. Which may
be larger than the max hdisplay/vdisplay.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-2-ville.syrjala@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

No point in having this extra indireciton for the cursor max size.
So drop the defines and just write out the raw numbers. Makes it
easier to see what's going on.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-1-ville.syrjala@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>

Use the '[PROP:id:name]' format I introduced for the core in the driver
debug messages as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adds new psrwake options defined in the below table.
Platform	PSR wake options vbt version
KBL/CFL/WHL	All(205+)
BXT		Uses old interpretation.
CNL/ICL+	All(205+)
GLK		All(205+)
SKL		All PV releases (Check for 205+ might help but cannot be foolproof)

We will continue with newer interpretation for SKL from 205.

v2: Jani
    Keep the bdb version check.
v3:
    Apply newer version for skl from 205+(DK).
    Add (version check && platform list) (Jani).
    Add bdb version for each platform in commit message(DK).

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Puthikorn Voravootivat <puthik@chromium.org>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ashutosh D Shukla <ashutosh.d.shukla@intel.com>
Cc: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1529302326-3567-1-git-send-email-vathsala.nagaraju@intel.com

This function has been unused since commit 5ed0bdf2 ("drm: i915:
Use nsec based interfaces"). Let's remove the definition as well now
to help get rid of all uses of 'timespec'.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618153855.2126048-1-arnd@arndb.de

This patch enables hotplug interrupts for DP over TBT output on TC
ports. The TBT interrupts are enabled and handled irrespective of the
actual output type which could be DP Alternate, DP over TBT, native DP
or native HDMI.

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-3-paulo.r.zanoni@intel.com

The hotplug interrupts for the ports can be routed to either North
Display or South Display depending on the output mode. DP Alternate or
DP over TBT outputs will have hotplug interrupts routed to the North
Display while interrupts for legacy modes will be routed to the South
Display in PCH. This patch adds hotplug interrupt handling support for
DP Alternate mode.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[Paulo: coding style changes]
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-2-paulo.r.zanoni@intel.com

The Graphics System Event(GSE) interrupt bit has a new location in the
GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only
DE_MISC interrupt that was enabled, with this change we don't enable/handle
any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out
the register change.

v2: from DK
raw_reg_[read/write], branch prediction hint and drop platform check (Mika)

v3: From DK
Early re-enable of master interrupt (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[Paulo: bikesheds and rebases]
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-1-paulo.r.zanoni@intel.com

While I don't see any issue with the way these macros are being called
today, let's protect them against operator precedence issues before
they happen.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612235654.7914-4-paulo.r.zanoni@intel.com

Since I'm touching the file I might as well fix this class of errors
since they are just a few. Also drive-by fix the styling of the
VLV_TURBO_SOC_OVERRIDE definitions instead of just the spaces before
the tabs.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612235654.7914-3-paulo.r.zanoni@intel.com

Because OCD.

Now seriously, commit 1aa920ea ("drm/i915: add register macro
definition style guide") has finally established a coding standard to
be followed by the rest of the file, and I've been trying to request
everybody to adhere to that since then. The problem is that when
someone adds a new line to a register that has the wrong style, these
people generally propagate the wrong style and I have to keep asking
them to drive-by fix the whole register, which is not something I like
to do and also creates extra work for them. Or I can ignore the
propagation of the wrong coding style and feel anxious about it. On
top of that, we now have our CI happily reminding us about these
problems, which makes everything worse.

So IMHO the best way to proceed is to fix the spacing issues in the
file once and for all. Contributors will stop propagating the bad
style when adding new bits to registers that already have bad style,
we will stop asking them to redo their patches and the CI emails will
become more relevant by having less semi-false errors.

Yes, there will be some pain involved for backporters, but at least
spacing issues like that are easy to spot and fix in the patch files.

This patch was generated by:

../../../../scripts/checkpatch.pl -f --strict --types SPACING \
	--fix-inplace i915_reg.h

I manually checked the output and everything seems sane.

v2: Single conflict around the addition of DP_TP_CTL_LINK_TRAIN_PAT4.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618180943.894-1-paulo.r.zanoni@intel.com

Expand the Maud/Naud table according to DP 1.4 spec to include entries for
810 MHz clock. This is required for audio to work with HBR3.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180607192013.25872-1-radhakrishna.sripada@intel.com

Amber Lake uses the same gen graphics as Kaby Lake, including a id
that were previously marked as reserved on Kaby Lake, but that
now is moved to AML page.

So, let's just move it to AML macro that will feed into KBL macro
just to keep it better organized to make easier future code review
but it will be handled as a KBL.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614233720.30517-2-jose.souza@intel.com

Whiskey Lake uses the same gen graphics as Coffe Lake, including some
ids that were previously marked as reserved on Coffe Lake, but that
now are moved to WHL page.

So, let's just move them to WHL macros that will feed into CFL macro
just to keep it better organized to make easier future code review
but it will be handled as a CFL.

v2:
Fixing GT level of some ids

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@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/20180614233720.30517-1-jose.souza@intel.com

Having the w/a registers as an open-coded table leaves a trap for the
unwary; it would be easy to miss incrementing the LRI counter when
adding a new register to the list. Instead, pull the list of registers
into a table, so that we only need add new registers to that table
rather than try and remember important side-effects of earlier chunks of
GPU instructions.
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618094150.30895-1-chris@chris-wilson.co.uk

Since we trigger 10,000s of hangs and resets during selftesting, we emit
many, many thousands of lines of useless debug messages. Reduce the
frequency by only logging a change in state of a guilty context.

Fixes: 14921f3c ("drm/i915: Fix context ban and hang accounting for client")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618073135.10849-1-chris@chris-wilson.co.uk

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/1e132575785d9b615208eb60ee5e388df5991172.1528794959.git.jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/808b06e1f0a95a4ee892553abf11fdbc30025571.1528794959.git.jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/e68c3f16738eb3ab9f276d797f20326ed6d15848.1528794959.git.jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.

v2: fix checkpatch warning on indentation
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/20180612095621.21101-1-jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/4af5f30fc9665d1bed1eed09e7f749737749d739.1528794959.git.jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/d8b79de3d52e1fcaeabf3abfbb2ed99c4397ff2b.1528794959.git.jani.nikula@intel.com

We have fairly mixed uintN_t vs. uN usage throughout the driver, but try
to stick to kernel types at least where it's more prevalent.
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/ed5de29c280797b20eb625d52592dcbba8326684.1528794959.git.jani.nikula@intel.com

commit b2209e62 ("drm/i915/execlists: Reset the CSB head tracking on
reset/sanitization") and commit 1288786b ("drm/i915: Move GEM sanitize
from resume_early to resume") show the conflicting requirements on the
code. We must reset the GPU before trashing live state on a fast resume
(hibernation debug, or error paths), but we must only reset our state
tracking iff the GPU is reset (or power cycled). This is tricky if we
are disabling GPU reset to simulate broken hardware; we reset our state
tracking but the GPU is left intact and recovers from its stale state.

v2: Again without the assertion for forcewake, no longer required since
commit b3ee09a4 ("drm/i915/ringbuffer: Fix context restore upon reset")
as the contexts are reset from the CS ensuring everything is powered up.

Fixes: b2209e62 ("drm/i915/execlists: Reset the CSB head tracking on reset/sanitization")
Fixes: 1288786b ("drm/i915: Move GEM sanitize from resume_early to resume")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616202534.18767-1-chris@chris-wilson.co.uk

The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.

There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue.  These registers are
unfortunately not part of the logical context (even the power context),
and so we must reload them every time we start executing in a context.

Bugzilla: https://bugs.freedesktop.org/103047Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org

Some bits from the flags2 field are going to be used in the next
patches, so replace the whole-byte definition with the actual bits and
document their versions.

This patch is based on a patch by Animesh Manna.

Cc: Animesh Manna <animesh.manna@intel.com>
Credits-to: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614221018.19044-2-paulo.r.zanoni@intel.com