Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-6-git-send-email-arkadiusz.hiler@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

send_mutex is used to serialise communication with GuC via
intel_guc_send().

Since functions that utilize it are no longer limited to submission,
initialization should be handled as a part of general setup.

v2: move initialization to *_early()

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-5-git-send-email-arkadiusz.hiler@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

guc_send(), guc_recv() and related functions were introduced in the
i915_guc_submission.c and their scope was limited only to that file.

Those are not submission specific though.
This patch moves moves them to intel_uc.c with intel_ prefix added.

v2: rename intel_guc_log_* functions and clean up intel_guc_send usages

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-4-git-send-email-arkadiusz.hiler@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

To facilitate code reorganization we are renaming everything that
contains guc2host or host2guc.

host2guc_action() and host2guc_action_response() become guc_send()
and guc_recv() respectively.

Other host2guc_*() functions become simply guc_*().

Other entities are renamed basing on context they appear in:
 - HOST2GUC_ACTIONS_&           become INTEL_GUC_ACTION_*
 - HOST2GUC_{INTERRUPT,TRIGGER} become GUC_SEND_{INTERRUPT,TRIGGER}
 - GUC2HOST_STATUS_*            become INTEL_GUC_STATUS_*
 - GUC2HOST_MSG_*               become INTEL_GUC_RECV_MSG_*
 - action_lock                 becomes send_mutex

v2: drop unnecessary backslashes and use BIT() instead of '<<'
v3: shortened enum names and INTEL_GUC_STATUS_*

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-3-git-send-email-arkadiusz.hiler@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

GuC is not the only one micro controller we have.

There are also HuC and DMC.

Making the file more general will help with code organization.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Signed-off-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-2-git-send-email-arkadiusz.hiler@intel.com

The check in __intel_uncore_early_sanitize() to disable decoupled mmio
would disable it for every platform that is not broxton. While that's
not a problem now since only broxton supports that, simply setting
.has_decoupled_mmio in a new platform's device info wouldn't suffice. So
avoid future confusion and change the workaround to only change the
value of has_decoupled_mmio for broxton.

v2: git add compile fix. (Ander)

Cc: Praveen Paneri <praveen.paneri@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479993807-29353-1-git-send-email-ander.conselvan.de.oliveira@intel.com

Pass dev_priv to intel_setup_outputs() and functions called by it, since
those are all intel i915 specific functions. Also, in the majority of
the functions dev_priv is used more often than dev. In the rare cases
where there are a few calls back into drm core, a local dev variable was
added.

v2: Don't convert dev to &dev_priv->drm in intel_dsi_init. (Ville)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479910904-11005-1-git-send-email-ander.conselvan.de.oliveira@intel.com

Add the tracking required to enable debugobjects for fences to improve
error detection in BAT. The debugobject interface lets us track the
lifetime and phases of the fences even while being embedded into larger
structs, i.e. to check they are not used after they have been released.

v2: Don't populate the stubs, debugobjects checks for a NULL pointer and
treats it equivalently.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-4-chris@chris-wilson.co.uk

Currently, we have an active reference for the request until it is
retired. Though it cannot be retired before it has been executed by
hardware, the request may be completed before we have finished
processing the execute fence, i.e. we may continue to process that fence
as we free the request.

Fixes: 5590af3e ("drm/i915: Drive request submission through fence callbacks")
Fixes: 23902e49 ("drm/i915: Split request submit/execute phase into two")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-3-chris@chris-wilson.co.uk

Before we return the request back to the kmem_cache after a failed
i915_gem_request_alloc(), we should assert that it has not been added to
any global state tracking.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-2-chris@chris-wilson.co.uk

While we will check that the request is completed prior to being
retired, by placing an assert that the request is complete at the
entrypoint of the function we can more clearly document the function's
preconditions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-1-chris@chris-wilson.co.uk

Show the last submitted seqno to the engine, not the overall next seqno,
as this is more pertinent information when inspecting the pageflip and
whether the CS or display engine stalled.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124144750.2610-2-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rename i915_gem_timeline member 'next_seqno' into 'seqno' as
the variable is pre-increment. We've already had two bugs due
to the confusing name, second is fixed as follow-up patch.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124144750.2610-1-chris@chris-wilson.co.uk

Some monitors will have noise or even no sound after
applying the patch 6014ac12.

In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need to disable Enable CTS or M Prog bit. This is
the initial setting after HW reset.

Fixes: 6014ac12 ("drm/i915/audio: set proper N/M in modeset")
Signed-off-by: NLibin Yang <libin.yang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478853988-139842-1-git-send-email-libin.yang@intel.com

As i915.enable_cmd_parser is an unsafe option, make it read-only at
runtime. Now that it is constant, we can use the value determined during
initialisation as to whether we need the cmdparser at execbuffer time.

v2: Remove the inline for its single user, it is clear enough (and
shorter) without!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124125851.6615-1-chris@chris-wilson.co.uk

The i915_next_seqno read value is to be the next seqno used by the
kernel. However, in the conversion to atomics ops for gt.next_seqno, in
commit 28176ef4 ("drm/i915: Reserve space in the global seqno during
request allocation"), this was changed from a post-increment to a
pre-increment. This increment was missed from the value reported by
debugfs, so in effect it was reporting the current seqno (last
assigned), not the next seqno.

Fixes: 28176ef4 ("drm/i915: Reserve space in the global seqno during request allocation")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81209Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124094752.19129-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

No sense in keeping the cmd_descriptor and cmd_table structs in
i915_drv.h, now that they are no longer referenced externally.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479942147-9837-1-git-send-email-matthew.auld@intel.com

Doing cmd_header >> 29 to extract our 3-bit client value where we know
cmd_header is a u32 shouldn't then also require the use of a mask. So
remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
there are no longer any users.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479163174-29686-1-git-send-email-matthew.auld@intel.com

i915_hws_info() has not been kept upto date (missing new engines) and so
I consider it to be unused. HWS is included in the error state, which
would be an avenue to retrieving it if required in future (possibly via
i915_engine_info). As it is currently oopsing with an rpm testcase, just
remove it.

Fixes: 3b3f1650 ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98838Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161124093401.18852-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

In all cases we can now obtain the relevant crtc_state/conn_state
from the relevant callbacks, which means all the ->config accesses
can be removed and the code cleaned up.

Changes since v1:
- cstate -> crtc_state
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8b02a6b4-606a-e43a-b357-ad17f491525b@linux.intel.com
[mlankhorst: Reinstate missing comment]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

No need for the extra break statements and whatnot, just return the
error directly. And tighten the scope of the local variables while at
it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
actually touching the hardware, in which case we won't force a modeset
on all the pipes, and thus won't lock any of the other pipes either.
That means a parallel plane update on another pipe could be looking at
a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the
plane configuration is invalid, or potentially reject a valid update.

To overcome this we must protect writes to atomic_cdclk_freq with
all the crtc locks, and thus for reads any single crtc lock will
be sufficient protection.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.

This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.

v2: Drop the dev_cdclk stuff (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: bruno.pagani@ens-lyon.org
Cc: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: NPaul Bolle <pebolle@tiscali.nl>
Tested-by: Joseph Yasi <joe.yasi@gmail.com> (v1)
Cc: stable@vger.kernel.org
Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com

For BXT, there is only one bit that enables/disables dual-link mode
and not different bits depending on which pipe is being used.
Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479767046-3964-1-git-send-email-bob.j.paauwe@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Let's try not to abuse plane->plane for sprites on VLV/CHV and instead
use plane->id. Since out watermark structures aren't entirely plane type
agnostic (for now) and start indexing sprites from 0  we'll add a small
helper to convert between the two bases.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-7-git-send-email-ville.syrjala@linux.intel.com

Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.

v2: Convert assert_sprites_disabled() over as well
v3: Rename the reg macro parameter to 'plane_id' as well (Paulo)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-6-git-send-email-ville.syrjala@linux.intel.com

Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
code with intel_plane->id.

This should make the SKL "primary" and "sprite" code virtually
identical, so the next logical step would likely be dropping one
of the copies.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-5-git-send-email-ville.syrjala@linux.intel.com

Nuke skl_wm_plane_id() and just use the new intel_plane->id.

v2: Convert skl_write_plane_wm() as well
v3: Convert skl_pipe_wm_get_hw_state() correctly
v4: Rebase due to changes in the wm code
    Drop the cursor FIXME from the total data rate calc (Paulo)
    Use the "[PLANE:%d:%s]" format in debug print (Paulo)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lyude <cpaul@redhat.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NLyude <lyude@redhat.com>

Add a mask of which planes are available for each pipe. This doesn't
quite work for old platforms with dynamic plane<->pipe assignment, but
as we don't support that sort of stuff (yet) we can get away with it.

The main use I have for this is the for_each_plane_id_on_crtc() macro
for iterating over all possible planes on the crtc. I suppose we could
not add the mask, and instead iterate by comparing intel_plane->pipe
but then we'd need a local intel_plane variable which is just
unnecessary clutter in some cases. But I'm not hung up on this, so if
people prefer the other option I could be convinced to use it.

v2: Use BIT() in the iterator macro too (Paulo)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-3-git-send-email-ville.syrjala@linux.intel.com

As I told people in [1] we really should not be confusing enum plane
as a per-pipe plane identifier. Looks like that happened nonetheless, so
let's fix it up by splitting the two into two enums.

We'll also want something we just directly pass to various register
offset macros and whatnot on SKL+. So let's make this new thing work for that.
Currently we pass intel_plane->plane for the "sprites" and just a
hardcoded zero for the "primary" planes. We want to get rid of that
hardocoding so that we can share the same code for all planes (apart
from the legacy cursor of course).

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-2-git-send-email-ville.syrjala@linux.intel.com

Someone forgot to make skl_write_{plane,cursor}_wm() static when
removing the prototypes from the header. Sparse isn't pleased.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: e62929b3 ("drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479846113-24745-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NLyude <lyude@redhat.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

It has only one call site from the same file.

v2: Also rename it to alloc_context_obj. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1479898155-21014-1-git-send-email-tvrtko.ursulin@linux.intel.com

Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1479896421-20611-1-git-send-email-tvrtko.ursulin@linux.intel.com

All callers asked for a forced change but the function ignored this
parameter. It doesn't seem to be necessary to force the change in any
case so let's just remove the parameter.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-5-git-send-email-imre.deak@intel.com

Some LSPCON adaptors may return an incorrect LSPCON mode right after
waking from DP Sleep state. This is the case at least for the ParadTech
PS175 adaptor, both when waking because of exiting the DP Sleep to
active state, or due to any other AUX CH transfer. We can determine the
current expected mode based on whether the DPCD area is accessible,
since according to the LSPCON spec this area is only accesible
in PCON mode.

This wait will avoid us trying to change the mode, while the current
expected mode hasn't settled yet and start link training before the
adaptor thinks it's in PCON mode after waking from DP Sleep state.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-4-git-send-email-imre.deak@intel.com

We need to get to LSPCON in the next patch, so factor out the helper for
it. While at it also remove the redundant GEN9 check.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-3-git-send-email-imre.deak@intel.com

Some LSPCON adaptors won't properly wake up in response to an AUX
request after the adaptor was placed to a DP Sink Sleep state (via
writing 0x2 to DP_SET_POWER). Based on the DP 1.4 specification 5.2.5,
the sink may place the AUX CH into a low-power state while in Sleep
state, but should wake it up in response to an AUX request within 1-20ms
(answering with AUX defers while waking it up). As opposed to this at
least the ParadTech PS175 adaptor won't fully wake in response to the
first I2C-over-AUX access and will occasionally ignore the offset in I2C
messages. This can result in accessing the DDC register at offset 0
regardless of the specified offset and the LSPCON detection failing.

To fix this do an initial dummy read from the DPCD area. The PS175 will
defer this access until it's fully woken (taking ~150ms) making sure the
following I2C-over-AUX accesses will work correctly.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=98353Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-2-git-send-email-imre.deak@intel.com

In order to prevent a race between the old callback submitting an
incomplete request and i915_gem_set_wedged() installing its nop handler,
we must ensure that the swap occurs when the machine is idle
(stop_machine).

v2: move context lost from out of BKL.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-4-chris@chris-wilson.co.uk

Since the submit/execute split in commit d55ac5bf ("drm/i915: Defer
transfer onto execution timeline to actual hw submission") the
global seqno advance was deferred until the submit_request callback.
After wedging the GPU, we were installing a nop_submit_request handler
(to avoid waking up the dead hw) but I had missed converting this over
to the new scheme. Under the new scheme, we have to explicitly call
i915_gem_submit_request() from the submit_request handler to mark the
request as on the hardware. If we don't the request is always pending,
and any waiter will continue to wait indefinitely and hangcheck will not
be able to resolve the lockup.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98748
Testcase: igt/gem_eio/in-flight
Fixes: d55ac5bf ("drm/i915: Defer transfer onto execution timeline to actual hw submission")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-3-chris@chris-wilson.co.uk

If the gpu reset fails and the machine is terminally wedged, further
hangchecks achieve nothing but noise. Disable them, with a corollary
that we re-enable hangchecking after a successful GPU reset in case the
user is artificially bringing the machine back to life through the debug
interface.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-2-chris@chris-wilson.co.uk