Atm we can only check the connector state after a dpms call - while
doing modeset with the copy&pasted crtc helper code things are too
ill-defined for proper checking. But the idea is very much to call
this check from the modeset code, too.

v2: Fix dpms check and don't presume that if the hw isn't on that it
must not be linked up with an encoder (it could simply be switched off
with the dpms state).
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... instead of resetting a few things and hoping that this will work
out.

To properly disable the output pipelines at the initial modeset after
resume or boot up we need to have an accurate picture of which outputs
are enabled and connected to which crtcs. Otherwise we risk disabling
things at the wrong time, which can lead to hangs (or at least royally
confused panels), both requiring a walk to the reset button to fix.

Hence read out the hw state with the freshly introduce get_hw_state
functions and then sanitize it afterwards.

For a full modeset readout (which would allow us to avoid the initial
modeset at boot up) a few things are still missing:
- Reading out the mode from the pipe, especially the dotclock
  computation is quite some fun.
- Reading out the parameters for the stolen memory framebuffer and
  wrapping it up.
- Reading out the pch pll connections - luckily the disable code
  simply bails out if the crtc doesn't have a pch pll attached (even
  for configurations that would need one).

This patch here turned up tons of smelly stuff around resume: We
restore tons of register in seemingly random way (well, not quite, but
we're not too careful either), which leaves the hw in a rather
ill-defined state: E.g. the port registers are sometimes
unconditionally restore (lvds, crt), leaving us with an active
encoder/connector but no active pipe connected to it. Luckily the hw
state sanitizer detects this madness and fixes things up a bit.

v2: When checking whether an encoder with active connectors has a crtc
wire up to it, check for both the crtc _and_ it's active state.

v3:
- Extract intel_sanitize_encoder.
- Manually disable active encoders without an active pipe.

v4: Correclty fix up the pipe<->plane mapping on machines where we
switch pipes/planes. Noticed by Chris Wilson, who also provided the
fixup.

v5: Spelling fix in a comment, noticed by Paulo Zanoni
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It is all glorious if we try really hard to only enable/disable an
entire display pipe to ensure that everyting happens in the right
order. But if we don't know the output configuration when the driver
takes over, this will all be for vain because we'll make the hw angry
right on the first modeset - we don't know what outputs/ports are
enabled and hence have to disable everything in a rather ad-hoc way.

Hence we need to be able to read out the current hw state, so that we
can properly tear down the current hw state on the first modeset.
Obviously this is also a nice preparation for the fastboot work, where
we try to avoid the modeset on driver load if it matches what the hw
is currently using.

Furthermore we'll be using these functions to cross-check the actual
hw state with what we think it should be, to ensure that the modeset
state machine actually works as advertised.

This patch only contains the interface definitions and a little helper
for the simple case where we have a 1:1 encoder to connector mapping.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is the first tiny step towards cross-checking the entire modeset
state machine with WARNs. A crtc can only be enabled when it's
actually in use, i.e. crtc->active imlies crtc->enabled.

Unfortunately we can't (yet) check this when disabling the crtc,
because the crtc helpers are a bit slopy with updating state and
unconditionally update crtc->enabled before changing the hw state.

Fixing that requires quite some more work.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of going through the crtc helper function tables.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new infrastructure we're doing this when enabling/disabling
the entire display pipe.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- We don't have the ->get_crtc callback.
- Call intel_encoder->disable directly.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Together with the static helper functions drm_crtc_prepare_encoders
and drm_encoder_disable (which will be simplified in the next patch,
but for now are 1:1 copies). Again, no changes beside new names for
these functions.

Also call our new set_mode instead of the crtc helper one now in all
the places we've done so far.

v2: Call the function just intel_set_mode to better differentia it
from intel_crtc_mode_set which really only does the ->mode_set step of
the entire modeset sequence on one crtc. Whereas this function does
the global change.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also kill the error-path, we have a fixed connector->encoder mapping.

Unfortunately we can't rip out all the ->best_encoder callbacks, these
are all still used by the fb_helper. Neat helper layering violation there.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And drop the check, we always have it.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And the following static functions required by it:
drm_encoder_crtc_ok, drm_crtc_helper_disable

No changes safe for the s/drm/intel prefix change.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We no longer need them. And now that all encoders are converted, we
can finally move the cpt modeset check to the right place - at the end
of the crtc_enable function.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All encoders are now converted so there's no need for these checks any
more.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Yeah, big patch but I couldn't come up with a neat idea of how to
split it up further, that wouldn't break dpms on cloned configs
somehow. But the changes in dvo/sdvo/crt are all pretty much
orthonogal, so it's not too bad a patch.

These are the only encoders that support cloning, which requires a few
special changes compared to the previous patches.
- Compute the desired state of the display pipe by walking all
  connected encoders and checking whether any has active connectors.
  To make this clearer, drop the old mode parameter to the crtc dpms
  function and rename it to intel_crtc_update_dpms.
- There's the curious case of intel_crtc->dpms_mode. With the previous
  patches to remove the overlay pipe A code and to rework the load
  detect pipe code, the big users are gone. We still keep it to avoid
  enabling the pipe twice, but we duplicate this logic with
  crtc->active, too. Still, leave this for now and just push a fake
  dpms mode into it that reflects the state of the display pipe.

Changes in the encoder dpms functions:
- We clamp the dpms state to the supported range right away. This is
  escpecially important for the VGA outputs, where only older hw
  supports the intermediate states. This (and the crt->adpa_reg patch)
  allows us to unify the crt dpms code again between all variants
  (gmch, vlv and pch).
- We only enable/disable the output for dvo/sdvo and leave the encoder
  running. The encoder will be disabled/enabled when we switch the
  state of the entire output pipeline (which will happen right away
  for non-cloned setups). This way the duplication is reduced and
  strange interaction when disabling output ports at the wrong time
  avoided.

The dpms code for all three types of connectors contains a bit of
duplicated logic, but I think keeping these special cases separate is
simpler: CRT is the only one that hanldes intermediate dpms state
(which requires extra logic to enable/disable things in the right
order), and introducing some abstraction just to share the code
between dvo and sdvo smells like overkill. We can do that once someone
bothers to implement cloning for the more modern outputs. But I doubt
that this will ever happen.

v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've picked hdmi as the first encoder to convert because it's rather
simple:
- no cloning possible
- no differences between prepare/commit and dpms off/on switching.

A few changes are required to do so:
- Split up the dpms code into an enable/disable function and wire it
  up with the intel encoder.
- Noop out the existing encoder prepare/commit functions used by the
  crtc helper - our crtc enable/disable code now calls back into the
  encoder enable/disable code at the right spot.
- Create new helper functions to handle dpms changes.
- Add intel_encoder->connectors_active to better track dpms state. Atm
  this is unused, but it will be useful to correctly disable the
  entire display pipe for cloned configurations. Also note that for
  now this is only useful in the dpms code - thanks to the crtc
  helper's dpms confusion across a modeset operation we can't (yet)
  rely on this having a sensible value in all circumstances.
- Rip out the encoder helper dpms callback, if this is still getting
  called somewhere we have a bug. The slight issue with that is that
  the crtc helper abuses dpms off to disable unused functions. Hence
  we also need to implement a default encoder disable function to do
  just that with the new encoder->disable callback.
- Note that we drop the cpt modeset verification in the commit
  callback, too. The right place to do this would be in the crtc's
  enable function, _after_ all the encoders are set up. But because
  not all encoders are converted yet, we can't do that. Hence disable
  this check temporarily as a minor concession to bisectability.

v2: Squash the dpms mode to only the supported values -
connector->dpms is for internal tracking only, we can hence avoid
needless state-changes a bit whithout causing harm.

v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just prep work, not yet put to some use.

Note that because we're still using the crtc helper to switch modes
(and their complicated way to do partial modesets), we need to call
the encoder's disable function unconditionally.

But once this is cleaned up we shouldn't call the encoder's disable
function unconditionally any more, because then we know that we'll
only call it if the encoder is actually enabled. Also note that we
then need to be careful about which crtc we're filtering the encoder
list on: We want to filter on the crtc of the _current_ mode, not the
one we're about to set up.

For the enabling side we need to do the same trick. And again, we
should be able to simplify this quite a bit when things have settled
into place.

Also note that this simply does not take cloning into account, so dpms
needs to be handled specially for the few outputs where we even bother
with it.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just impendance matching with the the crtc helper stuff.

... and somehow the design of this all ended up in this commit here,
too ;-)

The big plan is that this new set of crtc display_funcs take full
responsibility of modeset operations for the entire display output
pipeline (by calling down into object-specific callbacks and
functions). The platform-specific callbacks simply know best what the
proper order is.

This has the drawback that we can't do minimal change-overs any more
if a modeset just disables one encoder in a cloned configuration
(because we will only expose a disable/enable action that takes
down/sets up the entire crtc including all encoders). Imo that's the
only sane way to do it though:
- The use-case for this is pretty minimal, even when presenting (at
  least sane people) should use a dual-screen output so that you can
  see your notes on your panel. Clone mode is imo BS.
- With all the clone mode constrains, shared resources, and special
  ordering requirements (which differ even on the same platform
  sometimes for different outputs) there's no way we'd get this right
  for all cases. Especially since this is a under-used feature.
- And to top it off: On haswell even dp link re-training requires us
  to take down the entire display pipe - otherwise the chip dies.

So the only sane way is to do a full modeset on every crtc where the
output config changes in any way.

To support global modeset (i.e. set the configuration for all crtcs at
once) we'd then add one more function to allocate global and shared
objects in the best ways (e.g. fdi links, pch plls, ...). The crtc
functions would then simply use the pre-allocated stuff (and shouldn't
be able to fail, ever). We could even do all the object pinning in
there (and maybe try to defragment the global gtt if we fail)!
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because that's what we're essentially calling. This is the first step
in untangling the crtc_helper induced dpms handling mess we have - at
the crtc level we only have 2 states and the magic is just in
selecting which one (and atm there isn't even much magic, but on
recent platforms where not even the crt output has more than 2 states
we could do better).
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.

V2: Also add the number of pipes emitted (Chris Wilson)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use _PIPE macro to get correct register definition for IBX/CPT, discard
old variable "i" way.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Added the DIP_PORT_SEL #define from a preceeding patch in the
series that needs more work.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.

Also switch to intel_crtc for the enable function.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since it's redundant - we can get the attached encoder in the
functions themselves.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A few things need adjustement:
- Change the dpms state by calling the dpms connector function and
  not some crtc helper internal callbacks. Otherwise this will break
  once we switch to our own dpms handling.
- Instead of tracking and restoring intel_crtc->dpms_mode use the
  connector's dpms variable - the former relies on the dpms compuation
  rules used by the crtc helper. And it would break when the encoder
  is cloned and the other output has a different dpms state. But luckily
  no one is crazy enough for that.
- Properly clear the connector -> encoder -> crtc linking, even when
  failing (note that the crtc helper removes the encoder -> crtc link
  in disabled_unused_functions for us).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For some odd reason we've missed i830 and a i855 variant. Also
kill the two now redundant i830 entries.

v2: Don't add the missing 855 id to the pipe A quirk list, we seem to
lack justification for it.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.

This bug was indroduced by

commit 1519b995
Author: Keith Packard <keithp@keithp.com>
Date:   Sat Aug 6 10:35:34 2011 -0700

    drm/i915: Fix PCH port pipe select in CPT disable paths

The reachable tag for this commit is v3.1-rc1-3-g1519b995Signed-off-by: NAnhua Xu <anhua.xu@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has originally been introduced to not oversubscribe the dp links
in

commit 885a5fb5
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Tue Jan 12 05:38:31 2010 +0800

    drm/i915: fix pixel color depth setting on eDP

Since then we've fixed up the dp link bandwidth calculation code and
should now automatically fall back to 6bpc dithering. So this is
unnecessary.

Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.
Reported-by: NBenoit Gschwind <gschwind@gnu-log.net>
Cc: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Francois Rigaut <frigaut@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Tested-by: NBenoit Gschwind <gschwind@gnu-log.net>
Tested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

--

Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel

  - intel_encoder->type is INTEL_OUTPUT_SOMETHING
  - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING

Here we're using intel_encoder, so compare the oranges against
oranges. While at it, rename the variable to "intel_encoder" so we
keep our naming standards used everywhere.

Luckily this was not a bug because both DRM_MODE_ENCODER_DAC and
INTEL_OUTPUT_ANALOG are defined as 1. This is the only case where the
drm definition matches the intel definition.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way it's easier so see what belongs together, and what is used
by the ilk ips code. Also add some comments that explain the locking.

Note that (cur|min|max)_delay need to be duplicated, because
they're also used by the ips code.

v2: Missed one place that the dev_priv->ips change caught ...
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should not hit this under any sane conditions, but still, this does not
looks right.

CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: stable@vger.kernel.org
Reported-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Reviewed-by: NChris Wlison <chris@chris-wilson.co.uk>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We believe to have squashed all issues around the gen6+ rps interrupt
generation and why the gpu sometimes got stuck. With that cleared up,
there's no user left for the sanitize_pm infrastructure, so let's just
rip it out.

Note that 'intel_reg_write 0xa014 0x13070000' is the w/a if we find
ourselves stuck again.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As suggested by Daniel, rip out the independent timers for device and
crtc busyness and integrate the manual powermanagement of the display
engine into the GEM core and its request tracking. The benefits are that
the code is a lot smaller, fewer moving parts and should fit more neatly
into the overall activity tracking of the driver.

v2: Complete overhaul and removal of the racy timers and workers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops.
It is in the state of "works for me".
Includes now proper DPMS support. Includes switching between resolutions -
from 640x480 to 1024x768.
Currently assumes that the native display resolution is 1024x768.

The ns2501 seems to be rather critical - if the output PLL is not
running, the chip doesn't seem to be clocked and then doesn't react
on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO
is active before submitting any i2c messages to it. This is
probably to be reviewed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902Signed-off-by: NThomas Richter <thor@math.tu-berlin.de>
[danvet: fixup whitespace fail.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed for Haswell, but already has its uses here.

This patch started as a small patch written patch by Shobhit Kumar,
but it has changed so much that none of its original lines remain.

Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of having a giant if cascade to figure this out according to
the passed-in register. We could do quite a bit more cleaning up and
all by using the port at more places, but I think this should be part
of a bigger rework to introduce a struct intel_digital_port which
would keep track of all these things. I guess this will be part of
some haswell-DP-induced refactoring.

For now this rips out the big cascade, which is what annoyed me so
much.

v2: Add port variable name back for the func decl (I've tried to trick
myself below the 80 char limit).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Intel hw only has one MUX for encoders, so outputs are either not
cloneable or all in the same group of cloneable outputs. This neatly
simplifies the code and allows us to ditch some ugly if cascades in
the dp and hdmi init code (well, we need these if cascades for other
stuff still, but that can be taken care of in follow-up patches).

Note that this changes two things:
- dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is
  gen3+, so no problem. Note that the old code had a bug and didn't
  allow cloning crt with dvo (but only the other way round).
- sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't
  work, but the only reason I've found is that you can't use the
  panel-fitter (used for lvds upscaling) with anything else. But we
  don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is
  a) rather confusing b) mostly as a guideline to implementors (i.e.
  explicitly stating what is already implicit from the spec, without
  always going into the details of why). So I think we can ignore this
  - worst case we'll get a bug report from a user with with sdvo-lvds
  and sdvo-tmds and have to add that special case back in.

Because sdvo lvds is a bit special explain in comments why sdvo LVDS
outputs can be cloned, but native LVDS and eDP can't be cloned - we
use the panel fitter for the later, but not for sdvo.

Note that this also uncoditionally initializes the panel_vdd work used
by eDP. Trying to be clever doesn't buy us anything (but strange bugs)
and this way we can kill the is_edp check.

v2: Incorporate review from Paulo
- Add in a missing space.
- Pimp comment message to address his concerns.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Laurent Pinchart missed this when sending in is giant constify patch:

commit e811f5ae
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Tue Jul 17 17:56:50 2012 +0200

    drm: Make the .mode_fixup() operations mode argument a const pointer

Acked-by; Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we take the struct_mutex lock to access the command-stream, there is
a possibility that we may need to wait for a GPU hang and so should make
the lock both interruptible and error-checking.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50069Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>