drm/i915/execlists: Pull submit after dequeue under timeline lock

In the next patch, we will begin processing the CSB from inside the
submission path (underneath an irqsoff section, and even from inside
interrupt handlers). This means that updating the execlists->port[] will
no longer be serialised by the tasklet but needs to be locked by the
engine->timeline.lock instead. Pull dequeue and submit under the same
lock for protection. (An alternate future plan is to keep the in/out
arrays separate for concurrent processing and reduced lock coverage.)

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/20180628201211.13837-2-chris@chris-wilson.co.uk

drm/i915: Drop posting reads to flush master interrupts

We do not need to do a posting read of our uncached mmio write to
re-enable the master interrupt lines after handling an interrupt, so
don't. This saves us a slow UC read before we can process the interrupt,
most noticeable in execlists where any stalls imposes extra latency on
GPU command execution.

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

drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init

We're fetching GuC/HuC firmwares directly from uc level during
init_early stage but this breaks guc/huc struct isolation and
also strict SW-only initialization rule for init_early. Move fw
fetching to init phase and do it separately per guc/huc struct.

v2: don't forget to move wopcm_init - Michele
v3: fetch in init_misc phase - Michal

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

drm/i915/guc: Use intel_guc_init_misc to hide GuC internals

We will add more init steps to misc phase and there is no need
to expose them separately for use in uc_init_misc function.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628141522.62788-1-michal.wajdeczko@intel.com

drm/i915: Only signal from interrupt when requested

Avoid calling dma_fence_signal() from inside the interrupt if we haven't
enabled signaling on the request.

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/20180627201304.15817-4-chris@chris-wilson.co.uk

drm/i915: Move the irq_counter inside the spinlock

Rather than have multiple locked instructions inside the notify_ring()
irq handler, move them inside the spinlock and reduce their intrinsic
locking.

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/20180627201304.15817-3-chris@chris-wilson.co.uk

drm/i915: Only trigger missed-seqno checking next to boundary

If we have more interrupts pending (because we know there are more
breadcrumb signals before the completion), then we do not need to
trigger an irq_seqno_barrier or even wakeup the task on this interrupt
as there will be another. To allow some margin of error (we are trying
to work around incoherent seqno after all), we wakeup the breadcrumb
before the target as well as on the target.

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/20180627201304.15817-2-chris@chris-wilson.co.uk

drm/i915: Reduce spinlock hold time during notify_ring() interrupt

By taking advantage of the RCU protection of the task struct, we can find
the appropriate signaler under the spinlock and then release the spinlock
before waking the task and signaling the fence.

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/20180627201304.15817-1-chris@chris-wilson.co.uk

drm/i915: Show vma allocator stack when in doubt

At the moment, gem_exec_gttfill fails with a sporadic EBUSY due to us
wanting to unbind a pinned batch. Let's dump who first bound that vma to
see if that helps us identify who still unexpectedly has it pinned.

v2: We cannot allocate inside the printer (as it may be on an fs-reclaim
path), so hope for the best and build the string on the stack
v3: stack depth of 16 routinely overflows a 512 character string, limit
it to 12 to avoid unsightly truncation.

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/20180628132206.8329-1-chris@chris-wilson.co.uk

drm/i915: Replace drm_dev_unref with drm_dev_put

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618110154.30462-6-tdz@users.sourceforge.net

drm/i915: Replace drm_gem_object_unreference_unlocked with put function

This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618110154.30462-5-tdz@users.sourceforge.net

drm/i915: Replace __drm_gem_object_unreference with __drm_gem_object_put

This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618110154.30462-4-tdz@users.sourceforge.net

drm/i915: Replace drm_gem_object_{un/reference} with {put,get} functions

This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618110154.30462-3-tdz@users.sourceforge.net

drm/i915: Replace drm_connector_{un/reference} with put,get functions

This patch unifies the naming of DRM functions for reference counting
of struct drm_connector. The resulting code is more aligned with the
rest of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618110154.30462-2-tdz@users.sourceforge.net

drm/i915/icp: Add Interrupt Support

This patch addresses Interrupts from south display engine (SDE).

ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
Introduce these registers and their intended values.

Introduce icp_irq_handler().

The icp_irq_postinstall() takes care of
enabling all PCH interrupt sources, to unmask
them as needed with SDEIMR, as is done
done by ibx_irq_pre_postinstall() for earlier platforms.
We do not need to explicitly call the ibx_irq_pre_postinstall().

Also, while changing these,
s/CPT/PPT/CPT-CNP comment.

v2:
- remove redundant register defines.(Lucas)
- Change register names to be more consistent with
previous platforms (Lucas)

v3:
-Reorder bit defines to a more appropriate location.
 Change the comments. Confirm in the commit message that
 icp_irq_postinstall() need not go to
 ibx_irq_pre_postinstall() and ibx_irq_postinstall()
 as in earlier platforms. (Paulo)

Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
[Paulo: coding style bikesheds and rebases].
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1530046343-30649-1-git-send-email-anusha.srivatsa@intel.com

drm/i915: Wait for engines to idle before retiring

In the next^W forthcoming patch, we will start to defer retiring the
request from the engine list if it is still active on the submission
backend. To preserve the semantics that after wait-for-idle completes
the system is idle and fully retired, we need to therefore wait for the
backends to idle before calling i915_retire_requests().

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/20180627115334.16282-1-chris@chris-wilson.co.uk

drm/i915/icl: Add power well support

Add the definition for ICL power wells and their mapping to power
domains. On ICL there are 3 power well control registers, we'll select
the correct one based on higher bits of the power well ID. The offset
for the control and status flags within this register is based on the
lower bits of the ID as on older platforms.

As the DC state programming is also the same as on old platforms we can
reuse the corresponding helpers. For this we mark here the DC-off power
well as shared among multiple platforms.

Other than the above the delta between old platforms and ICL:
- Pipe C has its own power well, so we can save some additional power in the
  pipe A+B and (non-eDP) pipe A configurations.
- Power wells for port E/F DDI/AUX IO and Thunderbolt 1-4 AUX IO

v2:
- Rebase on drm-tip after prep patch for this was merged there as
  requested by Paulo.
- Actually add the new AUX and DDI power well control regs (Rakshmi)

v3:
- Fix power well register names in code comments
- Add TBT AUX->power well 3 dependency

v4:
- Rebase

v5:
- Detach AUX power wells from the INIT power domain. These power wells
  can only be enabled in a TC/TBT connected state and otherwise not
  needed during driver initialization.

v6:
- Use _MMIO_PORT(...) instead _MMIO(_PICK(...)) (Paulo)
  Fix checkpatch warnings.

Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com> (v1)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626142232.22361-1-imre.deak@intel.com

drm/i915/psr: Enable CRC check in the static frame on the sink side

Sink can be configured to calculate the CRC over the static frame and
compare with the CRC calculated and transmited in the VSC SDP by
source, if there is a mismatch sink will do a short pulse in HPD
and set DP_PSR_LINK_CRC_ERROR in DP_PSR_ERROR_STATUS.

Spec: 7723

v6:
andling DP_PSR_LINK_CRC_ERROR here and remove "bdw+" from commit
message

v4:
patch moved to after 'drm/i915/psr: Avoid PSR exit max time timeout'
to avoid touch in 2 patches EDP_PSR_DEBUG.

v3:
disabling PSR instead of exiting on error

Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626201644.21932-5-jose.souza@intel.com

drm/i915/psr: Avoid PSR exit max time timeout

Specification requires that max time should be masked from bdw and
forward but it can be also safely enabled to hsw.
This will make PSR exits more deterministic and only when really
needed. If this was used to fix a issue in some panel than can
only self-refresh for a few seconds, that panel will interrupt
and assert one of the PSR errors handled in:
'drm/i915/psr: Handle PSR RFB storage error' and
'drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink'

Spec: 21664

v4:
patch moved to before 'drm/i915/psr/bdw+: Enable CRC check in the
static frame on the sink side' to avoid touch in 2 patches
EDP_PSR_DEBUG.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626201644.21932-4-jose.souza@intel.com

drm/i915/psr: Handle PSR errors

Sink will interrupt source when it have any PSR error.
DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR is a PSR2 but already
handling it here.
The only missing error to be handled is DP_PSR_LINK_CRC_ERROR that
will be taken in care in a futher patch.

v6:
not handling DP_PSR_LINK_CRC_ERROR here

v5:
handling all PSR errors here, so the commit message and
comment have changed

v3:
disabling PSR instead of exiting on error

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626201644.21932-3-jose.souza@intel.com

drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

eDP spec states that sink device will do a short pulse in HPD
line when there is a PSR/PSR2 error that needs to be handled by
source, this is handling the first and most simples error:
DP_PSR_SINK_INTERNAL_ERROR.

Here taking the safest approach and disabling PSR(at least until
the next modeset), to avoid multiple rendering issues due to
bad pannels.

v5:
added lockdep_assert in psr_disable and renamed psr_disable()
to intel_psr_disable_locked()

v4:
Using CAN_PSR instead of HAS_PSR in intel_psr_short_pulse

v3:
disabling PSR instead of exiting on error

Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626201644.21932-2-jose.souza@intel.com

drm/i915/psr: Remove intel_crtc_state parameter from disable_source()

It was only used in VLV/CHV so after the removal of the PSR support
for those platforms it is not necessary any more.

v7: Rebased

Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626201644.21932-1-jose.souza@intel.com

drm/i915/psr: Warn for erroneous enabling of both PSR1 and PSR2.

Depending whether PSR1 or PSR2 was configured, we print a warning if the
corresponding control mmio indicated PSR was erroneously enabled. As
Chris pointed out, it makes more sense to check for both the mmio's
since we expect neither PSR1 nor PSR2 to be enabled when psr_activate() is
called.

v2: Read PSR2 control register only on supported platforms (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626090522.17682-1-dhinakaran.pandiyan@intel.com

drm/i915/psr: Fix race in intel_psr_work()

Commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr
back.") switched from delayed work to the plain variant and while doing so
removed the check for work_busy() before scheduling a PSR activation.
This appears to cause consecutive executions of psr_activate() in this
scenario - after a worker picks up the PSR work item for execution and
before the work function can acquire the PSR mutex, a psr_flush() can
get hold of the mutex and schedule another PSR work. Without a psr_exit()
between the two psr_activate() calls, warning messages get printed.
Further, since we drop the mutex in the midst of psr_work() to wait for
PSR to idle, another work item can also get scheduled. Fix this by
returning if PSR was already active.

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

drm/i915/psr: Kill useless function pointers.

At some point we introduced the function pointers
on PSR code to help with VLV/CHV separation logic
because it had a different HW implementation from PSR.

Since all converged to HSW PSR and we dropped the
VLV/CHV support, let's also kill the useless function
pointers and leave the code cleaner.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626052536.15137-1-rodrigo.vivi@intel.com

drm/i915/ddi: Get AUX power domain for DP main link too

So far we got an AUX power domain reference only for the duration of DP
AUX transfers. However, the following suggests that we also need these
for main link functionality:
- The specification doesn't state whether it's needed or not for main
  link functionality, but suggests that these power wells need to be
  enabled already during display core initialization (Sequences to
  Initialize Display).
- For PSR we need to keep the AUX power well enabled.
- On ICL combo PHY ports (non-TC) the AUX power well is needed for
  link training too: while the port is enabled with a DP link training
  test pattern trying to toggle the AUX power well will time out.
- On ICL MG PHY ports (TC) the AUX power well is needed also for main
  link functionality (both in DP and HDMI modes).
- Windows enables these power wells both for main and AUX lane
  functionality.

Based on the above take an AUX power reference for main link
functionality too. This makes a difference only on GEN10+ (GLK+)
platforms, where we have separate port specific AUX power wells.

For PSR we still need to distinguish between port A and the other
ports, since on port A DC states must stay enabled for main link
functionality, but DC states must be disabled for driver initiated
AUX transfers. So re-use the corresponding helper from intel_psr.c.

Since we take now a reference for main link functionality on all DP
ports we can forgo taking the separate power ref for PSR functionality.

v2:
- Make sure DC states stay enabled when taking the ref on port A.
  (Ville)

v3: (Ville)
- Fix comment about logic for encoders without a crtc state and
  add FIXME note for a simplification to avoid calling get_power_domains
  in such cases.
- Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Clarified code comments in intel_ddi_main_link_aux_domain() and
 intel_ddi_get_power_domains() (Imre)]
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621184449.26634-1-imre.deak@intel.com

drm/i915: Context objects can never be active when freed

Due to how we only release the pining on the context state on
retirement and never track activity on the context vma itself, the
object can never be active at the point of release. Replace the
conditional transfer of ownership onto an active-reference with an
assert that the object is idle.

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/20180625100604.22598-2-chris@chris-wilson.co.uk

drm/i915/execlists: Check for ce->state before destroy

As we may cancel the ce->state allocation during context pinning (but
crucially after we mark ce as operational), that means we may be asked
to destroy a nonexistent ce->state. Given the choice in handing a
complex error path on pinning, and just ignoring the lack of state in
destroy, choice the latter for simplicity.

Reported-by: Zhao Yakui <yakui.zhao@intel.com>
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/20180625100604.22598-1-chris@chris-wilson.co.uk

drm/i915: Defer modeset cleanup to a secondary task

If we avoid cleaning up the old state immediately in
intel_atomic_commit_tail() and defer it to a second task, we can avoid
taking heavily contended locks when the caller is ready to procede.
Subsequent modesets will wait for the cleanup operation (either directly
via the ordered modeset wq or indirectly through the atomic helperr)
which keeps the number of inflight cleanup tasks in check.

As an example, during reset an immediate modeset is performed to disable
the displays before the HW is reset, which must avoid struct_mutex to
avoid recursion. Moving the cleanup to a separate task, defers acquiring
the struct_mutex to after the GPU is running again, allowing it to
complete. Even in a few patches time (optimist!) when we no longer
require struct_mutex to unpin the framebuffers, it will still be good
practice to minimise the number of contention points along reset. The
mutex dependency still exists (as one modeset flushes the other), but in
the short term it resolves the deadlock for simple reset cases.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101600
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180623103951.23889-1-chris@chris-wilson.co.uk
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming

In the guc_ctl_debug_flags, the ads struct is programmed only
when USES_GUC_SUBMISSION is satisfied. But, this has to be
programmed for all suspend/resume cases.
Remove the condition and program the ads struct for
both huc loading and guc submission.

This issue was noticed when CI threw errors for enable_guc=2
(load huc; disable submission)

v2:
- Change commit title.
- Correct the shifts. (Daniele)

Credits to: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Spotswood <john.a.spotswood@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: John Spotswood <john.a.spotswood@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1529691543-28606-1-git-send-email-anusha.srivatsa@intel.com

drm/i915: Enable hw workaround to bypass alpha

Alpha blending with alpha 0 and 0xff passes through
alpha math and rounding logic causing differences
compared to fully transparent or opaque plane,resulting
in CRC mismatch.
This WA on icl and above enables hardware to bypass alpha
math and rounding for per pixel alpha values of 00 and 0xff

v2: Fix patchwork checkpatch warnings.

Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1529594036-25036-1-git-send-email-vandita.kulkarni@intel.com

drm/i915/icl: Do read-modify-write as needed during MG PLL programming

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: Imre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v1)
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180619164115.7835-1-imre.deak@intel.com

drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz

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: Imre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v1)
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615143911.31082-1-imre.deak@intel.com

drm/i915: remove check for aux irq

This became dead code with commit 309bd8ed464f ("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: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523180435.18042-1-lucas.demarchi@intel.com

drm/i915: Redefine EINVAL for debugging

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=106744
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621080150.8110-1-chris@chris-wilson.co.uk

drm/i915: Ignore applying the self-relocation BIAS if no relocations

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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621073205.26701-1-chris@chris-wilson.co.uk

drm/i915: Disable bh around call to tasklet

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: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the tasklets")
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: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620135929.23956-1-chris@chris-wilson.co.uk

drm/i915: Update DRIVER_DATE to 20180620

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

drm/i915/icl: Add 10-bit support for hdmi

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-18-paulo.r.zanoni@intel.com

drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us

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: 77312ae8f071 ("drm/i915/psr: vbt change for psr")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620132543.28092-1-colin.king@canonical.com

drm/i915/psr: Fix warning in intel_psr_activate()

commit 5422b37c907e ("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: 5422b37c907e ("drm/i915/psr: Kill delays when activating psr back.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106948
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618220207.2778-1-dhinakaran.pandiyan@intel.com

drm/i915/selftests: Avoid ERR_PTR dereference

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: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 09a4c02e58c1 ("drm/i915: Look for an active kernel context before switching")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620112441.13085-1-chris@chris-wilson.co.uk

Merge tag 'gvt-next-2018-06-19' of https://github.com/intel/gvt-linux into drm-intel-next-queued

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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180619090043.ly6gquafbmxuus6h@zhen-hp.sh.intel.com

drm/i915/audio: constify ELD pointers

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: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180619124437.10982-1-jani.nikula@intel.com

drm/i915: Enforce max hdisplay/hblank_start limits on HSW/BDW FDI

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-3-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

drm/i915: Check timings against hardware maximums

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-2-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

drm/i915: Nuke the cursor size defines

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615174406.12258-1-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

drm/i915: Print prop name/id when rejecting it

Use the '[PROP:id:name]' format I introduced for the core in the driver
debug messages as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/psr: Adds psrwake options for all platforms

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: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1529302326-3567-1-git-send-email-vathsala.nagaraju@intel.com

i915: remove timespec_to_jiffies_timeout

This function has been unused since commit 5ed0bdf21a85 ("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: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618153855.2126048-1-arnd@arndb.de

drm/i915/icl: Handle hotplug interrupts for DP over TBT

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: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-3-paulo.r.zanoni@intel.com

drm/i915/icl: Support for TC North Display interrupts

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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[Paulo: coding style changes]
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-2-paulo.r.zanoni@intel.com

drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC

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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[Paulo: bikesheds and rebases]
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-1-paulo.r.zanoni@intel.com

drm/i915/i915_reg.h: fix the checkpatch MACRO_ARG_PRECEDENCE issues

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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612235654.7914-4-paulo.r.zanoni@intel.com

drm/i915/i915_reg.h: fix the checkpatch SPACE_BEFORE_TAB issues

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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612235654.7914-3-paulo.r.zanoni@intel.com

drm/i915/i915_reg.h: fix the checkpatch SPACING issues

Because OCD.

Now seriously, commit 1aa920ea0e85 ("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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618180943.894-1-paulo.r.zanoni@intel.com

drm/i915/audio: Add 810 MHz clock entries to dp_aud_n_m table

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: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180607192013.25872-1-radhakrishna.sripada@intel.com

drm/i915/aml: Introducing Amber Lake platform

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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614233720.30517-2-jose.souza@intel.com

drm/i915/whl: Introducing Whiskey Lake platform

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: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614233720.30517-1-jose.souza@intel.com

drm/i915/execlists: Pull the w/a LRI emission into a helper

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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180618094150.30895-1-chris@chris-wilson.co.uk

drm/i915: Only show debug for state changes when banning

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

drm/i915/lspcon: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e132575785d9b615208eb60ee5e388df5991172.1528794959.git.jani.nikula@intel.com

drm/i915/audio: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/808b06e1f0a95a4ee892553abf11fdbc30025571.1528794959.git.jani.nikula@intel.com

drm/i915/backlight: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e68c3f16738eb3ab9f276d797f20326ed6d15848.1528794959.git.jani.nikula@intel.com

drm/i915/dvo: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612095621.21101-1-jani.nikula@intel.com

drm/i915/uncore: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4af5f30fc9665d1bed1eed09e7f749737749d739.1528794959.git.jani.nikula@intel.com

drm/i915/hdmi: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d8b79de3d52e1fcaeabf3abfbb2ed99c4397ff2b.1528794959.git.jani.nikula@intel.com

drm/i915/vbt: switch to kernel unsigned int types

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed5de29c280797b20eb625d52592dcbba8326684.1528794959.git.jani.nikula@intel.com

drm/i915: Fix fallout of fake reset along resume

commit b2209e62a450 ("drm/i915/execlists: Reset the CSB head tracking on
reset/sanitization") and commit 1288786b18f7 ("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 b3ee09a4de33 ("drm/i915/ringbuffer: Fix context restore upon reset")
as the contexts are reset from the CS ensuring everything is powered up.

Fixes: b2209e62a450 ("drm/i915/execlists: Reset the CSB head tracking on reset/sanitization")
Fixes: 1288786b18f7 ("drm/i915: Move GEM sanitize from resume_early to resume")
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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180616202534.18767-1-chris@chris-wilson.co.uk

drm/i915: Enable provoking vertex fix on Gen9 systems.

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/103047
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org

drm/i915/icl: update VBT's child_device_config flags2 field

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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614221018.19044-2-paulo.r.zanoni@intel.com

drm/i915/icl: implement DVFS for ICL

ICL DVFS is almost the same as CNL, except for the CDCLK/DDICLK
table. Implement it just like CNL does.

References: commit 48469eced282 ("drm/i915: Use cdclk_state->voltage
 on CNL")
References: commit 53e9bf5e8159 ("drm/i915: Adjust system agent
 voltage on CNL if required by DDI ports")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614221018.19044-1-paulo.r.zanoni@intel.com

drm/i915: s/IS_G4X && !IS_GM45/IS_G45/

We have IS_G45 these days. Let's use it instead of the
'IS_G4X && !IS_GM45' construct.

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

drm/i915/execlists: Reset the CSB head tracking on reset/sanitization

We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are expecting to read from entry
0, hence we reset our head tracking back to the entry before (the last
entry in the ring).

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/20180615093137.14270-2-chris@chris-wilson.co.uk

drm/i915: Be irqsafe inside reset

As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all times. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.

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/20180615093137.14270-1-chris@chris-wilson.co.uk

drm/i915: Fix context ban and hang accounting for client

If client is smart or lucky enough to create a new context
after each hang, our context banning mechanism will never
catch up, and as a result of that it will be saved from
client banning. This can result in a never ending streak of
gpu hangs caused by bad or malicious client, preventing
access from other legit gpu clients.

Fix this by always incrementing per client ban score if
it hangs in short successions regardless of context ban
scoring. The exception are non bannable contexts. They remain
detached from client ban scoring mechanism.

v2: xchg timestamp, tidyup (Chris)
v3: comment, bannable & banned together (Chris)

Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615104429.31477-1-mika.kuoppala@linux.intel.com

drm/i915: Keep the ctx workarounds tightly packed

For each platform, we have a few registers that are rewritten with
different values -- they are not part of a sequence, just different parts
of a masked register set at different times (e.g. platform and gen
workarounds). Consolidate these into a single register write to keep the
table compact, important since we are running of room in the current
fixed sized buffer.

While adjusting the construction of the wa table, make it non fatal so
that the driver still loads but keeping the warning and extra details
for inspection.

Inspecting the changes for a Kabylake system,
Before:
Address val mask read
0x07014 0x20002000 0x00002000 0x00002100
0x0E194 0x01000100 0x00000100 0x00000114
0x0E4F0 0x81008100 0x00008100 0xFFFF8120
0x0E184 0x00200020 0x00000020 0x00000022
0x0E194 0x00140014 0x00000014 0x00000114
0x07004 0x00420042 0x00000042 0x000029C2
0x0E188 0x00080000 0x00000008 0x00008030
0x07300 0x80208020 0x00008020 0x00008830
0x07300 0x00100010 0x00000010 0x00008830
0x0E184 0x00020002 0x00000002 0x00000022
0x0E180 0x20002000 0x00002000 0x00002000
0x02580 0x00010000 0x00000001 0x00000004
0x02580 0x00060004 0x00000006 0x00000004
0x07014 0x01000100 0x00000100 0x00002100
0x0E100 0x00100010 0x00000010 0x00008050

After:
Address val mask read
0x02580 0x00070004 0x00000007 0x00000004
0x07004 0x00420042 0x00000042 0x000029C2
0x07014 0x21002100 0x00002100 0x00002100
0x07300 0x80308030 0x00008030 0x00008830
0x0E100 0x00100010 0x00000010 0x00008050
0x0E180 0x20002000 0x00002000 0x00002000
0x0E184 0x00220022 0x00000022 0x00000022
0x0E188 0x00080000 0x00000008 0x00008030
0x0E194 0x01140114 0x00000114 0x00000114
0x0E4F0 0x81008100 0x00008100 0xFFFF8120

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615120207.13952-1-chris@chris-wilson.co.uk

drm/i915/dp: Add support for HBR3 and TPS4 during link training

DP spec 1.4 supports training pattern set 4 (TPS4) for HBR3 link
rate. This will be used in link training's channel equalization
phase if supported by both source and sink.
This patch adds the helpers to check if HBR3 is supported and uses
TPS4 in training pattern selection during link training.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611222655.5696-2-paulo.r.zanoni@intel.com

drm/i915/icl: Add allowed DP rates for Icelake

For ICL, on Combo PHY the allowed max rates are:
 - HBR3 8.1 eDP (DDIA)
 - HBR2 5.4 DisplayPort (DDIB)
and for MG PHY/TC DDI Ports allowed DP rates are:
 - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
 - DP on legacy connector - DDIC/D/E/F)

v2 (from Paulo): Remove misleading comment (Ville).

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
[Paulo: bikeshed to keep future platforms on "else", v2.]
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611222655.5696-1-paulo.r.zanoni@intel.com

drm/i915/icl: start adding the TBT pll

This commit just adds the register addresses and the basic skeleton of
the code. The next commits will expand on more specific functions.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-15-paulo.r.zanoni@intel.com

drm/i915/icl: unconditionally init DDI for every port

On ICP, port present straps (from SFUSE_STRAP PCH register) are no
longer supported. Software should determine the presence through BIOS
VBT, hotplug or other mechanisms.

v2: Improve commit message (Lucas).

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-14-paulo.r.zanoni@intel.com

drm/i915/icl: add icelake_get_ddi_pll()

Implement the hardware state readout code.

Thanks to Animesh Manna for spotting this problem.

Cc: Animesh Manna <animesh.manna@intel.com>
Credits-to: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-11-paulo.r.zanoni@intel.com

drm/i915/gtt: Reduce a pair of runtime asserts

We can stop asserting using WARN_ON as given sufficient CI coverage, we
can rely on using GEM_BUG_ON() to catch problems before merging.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614184218.1606-2-chris@chris-wilson.co.uk

drm/i915/gtt: Cache the PTE encoding of the scratch page

As the most frequent PTE encoding is for the scratch page, cache it upon
creation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614184218.1606-1-chris@chris-wilson.co.uk

drm/i915/gtt: Free unused page tables on unbind the context

As we cannot reliably change used page tables while the context is
active, the earliest opportunity we have to recover excess pages is when
the context becomes idle. So whenever we unbind the context (it must be
idle, and indeed being evicted) free the unused ptes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614134315.5900-2-chris@chris-wilson.co.uk

drm/i915/gtt: Lazily allocate page directories for gen7

As we were only supporting aliasing_ppgtt on gen7 for some time, we
saved a few checks by preallocating the page directories on creation.
However, since we need 2MiB of page directories for each ppgtt, to
support arbitrary numbers of user contexts, we need to be more prudent
in our allocations, and defer the page allocation until it is used. We
don't recover unused pages yet as we found that doing so on the fly
(i.e. altering TLB entries) would confuse the GPU.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614134315.5900-1-chris@chris-wilson.co.uk

drm/i915: Declare the driver wedged if hangcheck makes no progress

Hangcheck is our back up in case the GPU or the driver gets stuck. It
detects when the GPU is not making any progress and issues a GPU reset.
However, if the driver is failing to make any progress, we can get
ourselves into a situation where we continually try resetting the GPU to
no avail. Employ a second timeout such that if we continue to see the
same seqno (the stalled engine has made no progress at all) over the
course of several hangchecks, declare the driver wedged and attempt to
start afresh.

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

drm/i915/execlists: Push the tasklet kick after reset to reset_finish

In the unlikely case where we have failed to keep submitting to the GPU,
we end up with the ELSP queue empty but a pending queue of requests.
Here, we skip the per-engine reset as there is no guilty request, but in
doing so we also skip the engine restart leaving ourselves with a
permanently hung engine. A quick way to recover is by moving the tasklet
kick to execlists_reset_finish() (from init_hw). We still emit the error
on hanging, so the error is not lost but we should be able to recover.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180604073441.6737-2-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915/selftests: Initialise request to silence a compiler

With an old (4.7.3 on 32bit) gcc, it emits a warning for

In file included from drivers/gpu/drm/i915/i915_request.c:1425:0:
drivers/gpu/drm/i915/selftests/i915_request.c: In function ‘live_nop_request’:
drivers/gpu/drm/i915/selftests/i915_request.c:380:21: error: ‘request’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

Silence it by just setting it to NULL on initialisation.

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

drm/i915: Turn off g4x DP port in .post_disable()

While Bspec doesn't list a specific sequence for turning off the DP port
on g4x we are getting an underrun if the port is disabled in the
.disable() hook. Looks like the pipe stops when the port stops, and by
that time the plane disable may not have completed yet. Also the plane(s)
seem to end up in some wonky state when this happens as they also signal
another underrun immediately after we turn them back on during the next
enable sequence.

We could add a vblank wait in .disable() to avoid wedging the planes,
but I assume we're still tripping up the pipe in some way. So it seems
better to me to just follow the ILK+ sequence and turn off the DP port
in .post_disable() instead. This sequence doesn't seem to suffer from
this problem. Could be it was always the intended sequence for DP and
the gen4 bspec was just never updated to include it.

Originally we used the bad sequence even on ilk+, but I changed that
in commit 08aff3fe26ae ("drm/i915: Move DP port disable to post_disable
for pch platforms") as it was causing issues on those platforms as well.
I left out g4x then only because I didn't have the hardware to test it.
Now that I do it's fairly clear that the ilk+ sequence is also the
right choice for g4x.

v2: Fix whitespace fail (Jani)
    Mention the ilk+ commit (Jani)

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Disallow interlaced modes on g4x DP outputs

Looks like interlaced DP output doesn't work on g4x either. Not all
that surprising considering we already established that interlaced
DP output is busted on VLV/CHV.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-1-ville.syrjala@linux.intel.com

drm/i915: Fix PIPESTAT irq ack on i965/g4x

On i965/g4x IIR is edge triggered. So in order for IIR to notice that
there is still a pending interrupt we have to force and edge in ISR.
For the ISR/IIR pipe event bits we can do that by temporarily
clearing all the PIPESTAT enable bits when we ack the status bits.
This will force the ISR pipe event bit low, and it can then go back
high when we restore the PIPESTAT enable bits.

This avoids the following race:
1. stat = read(PIPESTAT)
2. an enabled PIPESTAT status bit goes high
3. write(PIPESTAT, enable|stat);
4. write(IIR, PIPE_EVENT)

The end result is IIR==0 and ISR!=0. This can lead to nasty
vblank wait/flip_done timeouts if another interrupt source
doesn't trick us into looking at the PIPESTAT status bits despite
the IIR PIPE_EVENT bit being low.

Before i965 IIR was level triggered so this problem can't actually
happen there. And curiously VLV/CHV went back to the level triggered
scheme as well. But for simplicity we'll use the same i965/g4x
compatible code for all platforms.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/ddi: Removed unused var from hsw_write_infoframe()

Cc: Vandita Kulkarni <vandita.kulkarni@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/20180613170710.15080-6-imre.deak@intel.com

drm/i915/ddi: Set HDMI infoframes with pipe clocks enabled

On ICL for setting the HDMI infoframe the pipe clock needs to be
enabled, otherwise accessing the VIDEO_DIP_CTL register will hang the
machine.

Cc: Vandita Kulkarni <vandita.kulkarni@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/20180613170710.15080-5-imre.deak@intel.com

drm/i915/ddi: Check transcoder instead of port when setting HDMI infoframe

The only requirement by BSpec for setting the HDMI infoframes is on DDI
platforms to do that before enabling the HDMI transcoder function, see
VIDEO_DIP_CTL bit 16. Accordingly check for the transcoder function
disabled state instead of the port's disabled state on DDI platforms.
This is needed by the next patch as it will set the infoframe during
crtc disabling where the port is still enabled.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@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/20180613170710.15080-4-imre.deak@intel.com

drm/i915/ddi: Push pipe clock enabling to encoders

On ICL the pipe clock needs to be enabled before setting the HDMI
infoframe, but these steps are in the reverse order atm. Move the pipe
clock enabling to the encoders, so reordering of the two steps can be
done in a clean way.

No functional change.

v2:
- Rebased on drm-tip.

Cc: Vandita Kulkarni <vandita.kulkarni@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/20180613172746.18525-1-imre.deak@intel.com

drm/i915/ddi: s/crtc->config/old_crtc_state in haswell_crtc_disable()

crtc->config points to the old crtc state at the point
display.crtc_disable() is called, so use the more descriptive pointer
instead.

v2:
- Convert one remaining instance of the ptr in the function. (Ville)

Cc: Vandita Kulkarni <vandita.kulkarni@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/20180613170710.15080-2-imre.deak@intel.com

drm/i915/psr: Kill delays when activating psr back.

The immediate enabling was actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.

Now that we removed VLV/CHV out of the picture completely
we can safely remove any delays.

Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a477d
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.

v2:(DK): Remove unnecessary WARN_ONs and make some other
         VLV | CHV more readable.
v3: Do it regardless the timer rework.
v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
v5: Kill remaining items and fully rework activation functions.
v6: Rebase on top of VLV/CHV clean-up and keep the reactivation
    on a regular non-delayed work to avoid extra delays on exit
    calls and allow us to add few more safety checks before
    real activation.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613192600.3955-1-rodrigo.vivi@intel.com

drm/i915/gtt: Only keep gen6 page directories pinned while active

In order to be able to evict the gen6 ppgtt, we have to unpin it at some
point. We can simply use our context activity tracking to know when the
ppgtt is no longer in use by hardware, and so only keep it pinned while
being used a request.

For the kernel_context (and thus aliasing_ppgtt), it remains pinned at
all times, as the kernel_context itself is pinned at all times.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614094103.18025-5-chris@chris-wilson.co.uk

drm/i915: Show CCID in engine dumps

For debugging context issues, knowing what context the GPU is
loading/using is helpful.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614094103.18025-4-chris@chris-wilson.co.uk