drm/i915: Refactor wm calculations

All platforms until SKL compute their watermarks essentially
using the same method1/small buffer and method2/large buffer
formulas. Most just open code it in slightly different ways.
Let's pull it all into common helpers. This makes it a little
easier to spot the actual differences.

While at it try to add some docs explainign what the formulas
are trying to do.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-11-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Refactor the g4x TLB miss w/a to a helper

Pull the g4x TLB miss w/a calculation into a small helper.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-10-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Fix the g4x watermark TLB miss workaround

The g4x watermark TLB miss workaround requires that we bump up the
watermark by the difference between 8 full lines and the FIFO size.
Unfortunately the way we compute it at the moment ignores the size
of the pixels. The code also used the primary plane width as the
cursor width when computing the TLB miss w/a for the cursor.
Let's fix both problems.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-9-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Fix cursor 'cpp' in watermark calculatins for old platforms

The watermark code for the old platforms (g4x and older) uses the
primary plane cpp when computing cursor watermarks. To keep the fix
simple let's just hardcode cpp=4 for the cursor on those platforms
since that's all we support.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-8-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Document CxSR

Add some documentation explaining what CxSR actually is.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-7-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Make vlv/chv watermark debug print less cryptic

The magic numbers 0,1,2 aren't all that interesting for users perhaps.
Since we know what these watermark levels mean for VLV/CHV let's print
their names.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-6-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Rename bunch of vlv_ watermark structures to g4x_

We'll be wanting to share some of these watermark structures on g4x,
so let's rename them to have a g4x_ prefix instead of vlv_.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-5-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: s/vlv_num_wm_levels/intel_wm_num_levels/

Rename the VLV/CHV max_level->num_levels helper to have an intel_
prefix since it's not VLV/CHV specific and I'll want to use it on
other platforms as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-4-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Drop the debug message from vlv_get_fifo_size()

Seeing the display FIFO sizes at driver load time doesn't really provide
anything useful for us, so let's just drop the debug message. One can
always use eg. intel_watermarks to dump out the hardware settings prior
to loading the driver.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-3-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: s/vlv_plane_wm_compute/vlv_raw_plane_wm_compute/ etc.

Rename some of the vlv wm functions to reflect the fact that they
operate on the "raw" watermarks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/lvds: Remove magic from PLL programming

This looks like a left-over from enabling work. The spec defines
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow
this in the programming.

v2:
- Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED.
  (Ville)

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: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-7-git-send-email-imre.deak@intel.com

drm/i915: Sanitize stolen memory size calculation

On GEN8+ (not counting CHV) the calculation can in theory result in an
incorrect sign extension with all upper bits set. In practice this is
unlikely to happen since it would require 4GB of stolen memory set
aside. For consistency still prevent the sign extension explicitly
everywhere.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-6-git-send-email-imre.deak@intel.com

drm/i915: Check error return when converting pipe to connector

An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.

v2:
- Fall back to a reasonable default instead of bailing out in case of
  error. (Jani)
v3:
- Fix s/PIPE_INVALID/INVALID_PIPE/ typo. (Jani)
v4:
- Fix bogus bracing around WARN() condition. (Ville)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-5-git-send-email-imre.deak@intel.com

drm/i915: Check error return when setting DMA mask

Even though an error from these functions isn't fatal we still want to
have a diagnostic message about it.

v2:
- Don't do assignments in if statements. (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-4-git-send-email-imre.deak@intel.com

drm/i915/sdvo: Check error return from intel_sdvo_get_value()

The current code assumes that 'enhancements' won't change in case of an
error, but this isn't guaranteed. Fix things by treating any error as a
lack of the given capability.

v2:
- Remove the now redundant init of enhancements. (Ville)

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: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-3-git-send-email-imre.deak@intel.com

drm/i915/dp: Check error return during DPCD capability queries

The assumptions of these users of drm_dp_dpcd_readb() is that the passed
in output buffer won't change in case of error, but this isn't
guaranteed. Fix this by treating any error as the lack of the given
capability.

In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
buffer uninitialized even with the above assumption.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-2-git-send-email-imre.deak@intel.com

drm/i915/vlv: Fix port B PLL opamp initialization

The current code looks like a typo, the specification calls for setting
bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly.

I'm not aware of the typo causing a real problem, so the fix is only for
consistency.

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: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-1-git-send-email-imre.deak@intel.com

drm/i915: Show dmc debug registers on Kabylake

The assumption is that the registers offsets are
identical as with skl. Also all the published
kbl firmwares support the debug registers. So
let kbl show the debug counts.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100975
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494324322-28193-1-git-send-email-mika.kuoppala@intel.com

drm/i915: Move uncore definitions into a separate header

In order to allow use of e.g. forcewake_domains in a other feature headers
included from the top of i915_drv.h, move all uncore related definitions
into their own header.

v2: move __mask_next_bit macro to utils header (Mika)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: use memdup_user_nul

Use memdup_user_nul() helper instead of open-coding to simplify the
code.

Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/6baf3aa45d0b5e0fd016b508bac905ebf8443aac.1493779294.git.geliangtang@gmail.com

drm/i915: Fix rawclk readout for g4x

Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.

Sadly the docs are now in bit heaven, so the fix will have to be based
on empirical evidence. Using another elk machine I was able to frob
the FSB frequency from the BIOS and see how it affects the CLKCFG
register. The machine seesm to use a frequency of 266 MHz by default,
and fortunately it still boot even with the 50% CPU overclock that
we get when we bump the FSB up to 400 MHz.

It turns out the actual FSB frequency and the register have no real
link whatsoever. The register value is based on some straps or something,
but fortunately those too can be configured from the BIOS on this board,
although it doesn't seem to respect the settings 100%. In the end I was
able to derive the following relationship:

BIOS FSB / strap | CLKCFG
-------------------------
200              | 0x2
266              | 0x0
333              | 0x4
400              | 0x4

So only the 200 and 400 MHz cases actually match how we're currently
decoding that register. But as the comment next to some of the defines
says, we have been just guessing anyway.

So let's fix things up so that at least the 266 MHz case will work
correctly as that is actually the setting used by both the buggy
machine and my test machine.

The fact that 333 and 400 MHz BIOS settings result in the same register
value is a little disappointing, as that means we can't tell them apart.
However, according to the gmch datasheet for both elk and ctg 400 Mhz is
not even a supported FSB frequency, so I'm going to make the assumption
that we should decode it as 333 MHz instead.

Cc: stable@vger.kernel.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170504181530.6908-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>

drm/i915: Micro-optimise hotpath through intel_ring_begin()

Typically, there is space available within the ring and if not we have
to wait (by definition a slow path). Rearrange the code to reduce the
number of branches and stack size for the hotpath, accomodating a slight
growth for the wait.

v2: Fix the new assert that packets are not larger than the actual ring.
v3: Make the parameters unsigned as well to make usage.

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

drm/i915: Report the ring->space from intel_ring_update_space()

Some callers immediately want to know the current ring->space after
calling intel_ring_update_space(), which we can freely provide via the
return parameter.

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

drm/i915: Avoid the branch in computing intel_ring_space()

Exploit the power-of-two ring size to compute the space across the
wraparound using a mask rather than a if. Convert to unsigned integers
so the operation is well defined.

References: https://bugs.freedesktop.org/show_bug.cgi?id=99671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170504130846.4807-1-chris@chris-wilson.co.uk

drm/i915: Use engine->context_pin() to report the intel_ring

Since unifying ringbuffer/execlist submission to use
engine->pin_context, we ensure that the intel_ring is available before
we start constructing the request. We can therefore move the assignment
of the request->ring to the central i915_gem_request_alloc() and not
require it in every engine->request_alloc() callback. Another small step
towards simplification (of the core, but at a cost of handling error
pointers in less important callers of engine->pin_context).

v2: Rearrange a few branches to reduce impact of PTR_ERR() on gcc's code
generation.

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

drm/i915: Implement dma_buf_ops->kmap

Since kmap allows us to block we can pin the pages and use our normal
page lookup routine making the implementation simple, or as some might
say quick and dirty.

Testcase: igt/drv_selftest/dmabuf
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170503202517.16797-1-chris@chris-wilson.co.uk

Merge tag 'tags/drm-for-v4.12' into drm-intel-next-queued

Backmerge the main drm-next pull to sync up.

Chris also pointed out that

commit ade0b0c965f59176daddbef9c4717354034f9bce
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Apr 22 09:15:37 2017 +0100

    drm/i915: Confirm the request is still active before adding it to the await

is double-applied in the git merge, so make sure we get this right.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

ALSA: x86: Register multiple PCM devices for the LPE audio card

Now that everything is in place let's register a PCM device for
each port of the display engine. This will make it possible to
actually output audio to multiple displays at the same time. And
it avoids modesets on unrelated displays from clobbering up the
ELD and whatnot for the display currently doing the playback.

v2: Add a PCM per port instead of per pipe
v3: Fix off by one error with port numbers (Pierre-Louis)
    Fix .notify_audio_lpe() prototype (Pierre-Louis)

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-12-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

ALSA: x86: Split snd_intelhad into card and PCM specific structures

To allow multiple PCM devices to be registered for the LPE audio card,
split the private data into card and PCM specific chunks. For now we'll
stick to just one PCM device as before.

v2: Rework to do a pcm device per port instead of per pipe

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-11-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

ALSA: x86: Prepare LPE audio ctls for multiple PCMs

In preparation for register a PCM device for each pipe adjust
link up the ctl elements with the corresponding PCM device.

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-10-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Clean up the LPE audio platform data

Split the LPE audio platform data into a port specific
chunk and device specific chunk. Eventually we'll have
a port specific chunk for each port, but for now we'll
stick to just one.

We'll also get rid of the intel_hdmi_lpe_audio_eld structure
which doesn't seem to have any real reason to exist.

v2: Organize per port instead of per pipe

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-9-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Reorganize intel_lpe_audio_notify() arguments

Shuffle the arguments to intel_lpe_audio_notify() around a bit. Pipe
and port being the most important things, so let's put the first, and
thre rest can come in as is. Also constify the eld argument.

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-8-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Remove hdmi_connected from LPE audio pdata

We can determine that the pipe was shut down from pipe<0, so there's
no point in duplicating that information as 'hdmi_connected'.

v2: Use pipe<0 instead of port<0 as we'll want to do per-port
    PCM devices later
    Initialize pipe to -1 to inidicate inactive initial state

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-7-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Replace tmds_clock_speed and link_rate with just ls_clock

There's no need to distinguish between the DP link rate and HDMI TMDS
clock for the purposes of the LPE audio. Both are actually the same
thing more or less, which is the link symbol clock. So let's just
call the thing ls_clock and simplify the code.

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-6-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Remove the unused pending_notify from LPE platform data

The pending_notify flag in the LPE audio platform data is pointless,
actually unused. So let's kill it off.

v2: Fix typo in patch subject

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-5-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Stop pretending to mask/unmask LPE audio interrupts

vlv_display_irq_postinstall() enables the LPE audio interrupts
regardless of whether the LPE audio irq chip has masked/unmasked
them. Also the irqchip masking/unmasking doesn't consider the state
of the display power well or the device, and hence just leads to
dmesg spew when it tries to access the hardware while it's powered
down.

If the current way works, then we don't need to do anything in the
mask/unmask hooks. If it doesn't work, well, then we'd need to properly
track whether the irqchip has masked/unmasked the interrupts when
we enable display interrupts. And the mask/unmask hooks would need
to check whether display interrupts are even enabled before frobbing
with he registers.

So let's just assume the current way works and neuter the mask/unmask
hooks. Also clean up vlv_display_irq_postinstall() a bit and stop
it from trying to unmask/enable the LPE C interrupt on VLV since it
doesn't exist.

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-4-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown

Clear the notify function pointer in the platform data before we tear
down the driver. Otherwise i915 would end up calling a stale function
pointer and possibly explode.

Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-3-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Fix runtime PM for LPE audio

Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.

Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.

So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.

The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.

Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.

Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.

Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai <tiwai@suse.de>

drm/i915: Switch the global i915.semaphores check to a local predicate

Rather than use a global modparam, we can just check to see if the
engine has semaphores configured upon it.

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

drm/i915: Do not record a successful syncpoint for a dma-await

As we may unwind the requests, even though the request we are awaiting
has a global_seqno that seqno may be revoked during the await and so we
can not reliably use it as a barrier for all future awaits on the same
timeline.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-6-chris@chris-wilson.co.uk

drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]

With the addition of the inter-context intel_time.sync map, having a
very similar sync_seqno[] is confusing. Aide the reader by denoting that
this is a pre-allocated array for storing semaphore sync points wrt to
the global seqno.

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

drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.
v6: Create mock_timeline to tidy selftest writing
v7: s/intel_timeline_sync_get/intel_timeline_sync_is_later/ (Tvrtko)
v8: Prune the stale sync points when we idle.
v9: Include a small benchmark in the kselftests
v10: Separate the idr implementation into its own compartment. (Tvrkto)
v11: Refactor igt_sync kselftests to avoid deep nesting (Tvrkto)
v12: __sync_leaf_idx() to assert that p->height is 0 when checking leaves
v13: kselftests to investigate struct i915_syncmap itself (Tvrtko)
v14: Foray into ascii art graphs
v15: Take into account that the random lookup/insert does 2 prng calls,
not 1, when benchmarking, and use for_each_set_bit() (Tvrtko)
v16: Improved ascii art

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-4-chris@chris-wilson.co.uk

drm/i915: Lift timeline ordering to await_dma_fence

Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests along the same timeline are
explicitly ordered via i915_add_request (along with the dependencies).

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: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-3-chris@chris-wilson.co.uk

drm/i915: Unwrap top level fence-array

By first unwrapping an incoming fence-array into its child fences, we
can simplify the internal branching, and so avoid triggering a potential
bug in the next patch when not squashing the child fences on the same
timeline.

It will also have the advantage of keeping the (top-level) fence arrays
out of any fence/timeline caching since these are unordered timelines
but with a random context id.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-2-chris@chris-wilson.co.uk

drm/i915: Mark up clflushes as belonging to an unordered timeline

2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semantics everywhere.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170503093924.5320-1-chris@chris-wilson.co.uk

drm/i915: Use wait_for_atomic_us when waiting for gt fifo

Replace the handcrafter loop when checking for fifo slots
with atomic wait for. This brings this wait in line with
the other waits on register access. We also get a readable
timeout constraint, so make it to fail after 10ms.

Chris suggested that we should fail silently as the fifo debug
handler, now attached to unclaimed mmio handling, will take care of the
possible errors at later stage.

Note that the decision to wait was changed so that we avoid
allocating the first reserved entry. Nor do we reduce the count
if we fail the wait, removing the possiblity to wrap the
count if the hw fifo returned zero.

v2: remove unclaimed check on timeout (Chris)
v3: use void return (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=100247
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1491493182-31540-1-git-send-email-mika.kuoppala@intel.com

drm/i915: Move the GTFIFODBG to the common mmio dbg framework

Remove the per-mmio checking of the FIFO debug register into the common
conditional mmio debug handling. Based on patch from Chris Wilson.

v2: postpone warn on fifodbg for unclaimed reg debugs

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/guc: Enable send function only after successful init

It is safer to setup valid send function after successful GuC
hardware initialization. In addition we prepare placeholder
where we can setup any alternate GuC communication mechanism.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170502103243.54940-1-michal.wajdeczko@intel.com
[ickle: Fixup ENODEV for an impossible error path]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

Add intel_irq_fini() for placing the deinitialization code,
starting with freeing dev_priv->l3_parity.remap_info[].

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1493366319-18515-1-git-send-email-joonas.lahtinen@linux.intel.com

drm/i915: Update DRIVER_DATE to 20170502

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next

Some nouveau regression fixes.

* 'linux-4.12' of git://github.com/skeggsb/linux:
  drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection
  drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr()
  drm/nouveau/kms: Increase max retries in scanout position queries.
  drm/nouveau/bios/bitP: check that table is long enough for optional pointers
  drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engine

drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection

A missing u64 cast causes a 32-Bit wraparound from
4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected
if card has 4096 Mib per FBP.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr()

The error return code PTR_ERR(mc) is always 0 since mc is
equal to 0 in this error handling case.

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/kms: Increase max retries in scanout position queries.

So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.

Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank  stuff, e.g.,
desktop compositors.

Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.

As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bios/bitP: check that table is long enough for optional pointers

Fixes OOB VBIOS accesses on some boards.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engine

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

Merge tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel into drm-next

drm/i915 and gvt fixes for drm-next/v4.12

* tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Confirm the request is still active before adding it to the await
  drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio
  drm/i915/selftests: Allocate inode/file dynamically
  drm/i915: Fix system hang with EI UP masked on Haswell
  drm/i915: checking for NULL instead of IS_ERR() in mock selftests
  drm/i915: Perform link quality check unconditionally during long pulse
  drm/i915: Fix use after free in lpe_audio_platdev_destroy()
  drm/i915: Use the right mapping_gfp_mask for final shmem allocation
  drm/i915: Make legacy cursor updates more unsynced
  drm/i915: Apply a cond_resched() to the saturated signaler
  drm/i915: Park the signaler before sleeping
  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
  drm/i915/gvt: Fix PTE write flush for taking runtime pm properly
  drm/i915/gvt: remove some debug messages in scheduler timer handler
  drm/i915/gvt: add mmio init for virtual display
  drm/i915/gvt: use directly assignment for structure copying
  drm/i915/gvt: remove redundant ring id check which cause significant CPU misprediction
  drm/i915/gvt: remove redundant platform check for mocs load/restore
  drm/i915/gvt: Align render mmio list to cacheline
  drm/i915/gvt: cleanup some too chatty scheduler message

Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next

trivial patch.

* 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux:
  drm/vmwgfx: Convert macro to octal representation

Merge branch 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld into drm-next

Latest updates on Mali DP, adding support for colour management,
plane scaling and power management.

(these have been in -next for a while).

* 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld:
  drm: mali-dp: use div_u64 for expensive 64-bit divisions
  drm: mali-dp: Check the mclk rate and allow up/down scaling
  drm: mali-dp: Enable image enhancement when scaling
  drm: mali-dp: Add plane upscaling support
  drm/mali-dp: Add core_id file to the sysfs interface
  drm: mali-dp: Add CTM support
  drm: mali-dp: enable gamma support
  drm: mali-dp: add malidp_crtc_state struct
  drm: mali-dp: add custom reset hook for planes
  drm: mali-dp: remove unused variable
  drm: mali-dp: add atomic_print_state for planes
  drm: mali-dp: Enable power management for the device.
  drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.

drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

The sequence in glk_dsi_device_ready() enters ULPS then waits until it is
*not* active to then disable it. The correct sequence according to the
spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is
zero, i.e., ULPS is active, and then disable ULPS.

Fixing the condition gets rid of the following spurious error messages:

[drm:glk_dsi_device_ready [i915]] *ERROR* ULPS is still active

Fixes: 4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
Cc: Deepak M <m.deepak@intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fixes@lists.freedesktop.org>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170428080222.6147-1-ander.conselvan.de.oliveira@intel.com

drm/i915: Capture CCID on ILK

CCID register existed already on ILK according to the PRM (Chris
verified the address to match too).

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1493366019-18380-1-git-send-email-joonas.lahtinen@linux.intel.com

drm/i915: Reset ILK during GEM sanitization

ILK should survive a reset without display corruption.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Eliminate HAS_HW_CONTEXTS

HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
replace it with Gen specific (to be updated in next patches).

HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.

This leads to us being able to get rid of the property completely.

v2:
- Keep the checks at Gen6 for no functional change (Ville)

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Sanitize engine context sizes

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context allocation

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/guc: Fix sleep under spinlock during reset

Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
recent changes annotated the wait for register with might_sleep.

I have fixed it by removing holding of the uncore spinlock over
the call to gen6_hw_domain_reset, since I do not see that is
really needed. But there is always a possibility I am missing
some nasty detail so please double check.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Defer context state allocation for legacy ring submission

Almost from the outset for execlists, we used deferred allocation of the
logical context and rings. Then we ported the infrastructure for pinning
contexts back to legacy, and so now we are able to also implement
deferred allocation for context objects prior to first use on the legacy
submission.

v2: We still need to differentiate between legacy engines, Joonas is
fixing that but I want this first ;) (Joonas)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170427104651.22394-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Rename gen8_(un)request_engine_reset to gen8_reset_engine_start/cancel

As all other functions related to resetting engines are using
reset_engine.

v2: remove _request_ and use start/cancel instead (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-3-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Fix stale comment about I915_RESET_IN_PROGRESS flag

It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF.

Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-2-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm: mali-dp: use div_u64 for expensive 64-bit divisions

On 32-bit machines, we can't divide 64-bit integers:

drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'

This calls the div_u64 function explicitly instead.

Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

drm/i915/glk: Don't allow 12 bpc when htotal is too big

Display workaround #1139 for Geminilake instructs us to restrict HDMI
to 8 bpc when htotal is greater than 5460. Otherwise, the pipe is unable
to generate a proper signal and is left in a state where corruption is
seen with other modes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100440
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170424104718.26448-1-ander.conselvan.de.oliveira@intel.com

drm/i915: Confirm the request is still active before adding it to the await

Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.

In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:

[   60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[   60.044118] Read of size 8 by task gem_exec_fence/530
[   60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G            E   4.11.0-rc7+ #46
[   60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[   60.044290] Call Trace:
[   60.044337]  dump_stack+0x4d/0x6a
[   60.044383]  kasan_object_err+0x21/0x70
[   60.044435]  kasan_report+0x225/0x4e0
[   60.044488]  ? __list_add_valid+0x1d/0xd0
[   60.044534]  ? kasan_kmalloc+0xad/0xe0
[   60.044587]  __asan_load8+0x5e/0x70
[   60.044639]  __list_add_valid+0x1d/0xd0
[   60.044788]  __i915_priotree_add_dependency+0x67/0x130 [i915]
[   60.044895]  i915_gem_request_await_request+0xa8/0x370 [i915]
[   60.044974]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.045049]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.045077]  ? save_stack+0xb1/0xd0
[   60.045105]  ? save_stack_trace+0x1b/0x20
[   60.045132]  ? save_stack+0x46/0xd0
[   60.045158]  ? kasan_kmalloc+0xad/0xe0
[   60.045184]  ? __kmalloc+0xd8/0x670
[   60.045229]  ? drm_ioctl+0x359/0x640 [drm]
[   60.045256]  ? SyS_ioctl+0x41/0x70
[   60.045330]  ? i915_vma_move_to_active+0x540/0x540 [i915]
[   60.045360]  ? tty_insert_flip_string_flags+0xa1/0xf0
[   60.045387]  ? tty_flip_buffer_push+0x63/0x70
[   60.045414]  ? remove_wait_queue+0xa9/0xc0
[   60.045441]  ? kasan_unpoison_shadow+0x35/0x50
[   60.045467]  ? kasan_kmalloc+0xad/0xe0
[   60.045494]  ? kasan_check_write+0x14/0x20
[   60.045568]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.045616]  drm_ioctl+0x359/0x640 [drm]
[   60.045705]  ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[   60.045751]  ? drm_version+0x150/0x150 [drm]
[   60.045778]  ? compat_start_thread+0x60/0x60
[   60.045805]  ? plist_del+0xda/0x1a0
[   60.045833]  do_vfs_ioctl+0x12e/0x910
[   60.045860]  ? ioctl_preallocate+0x130/0x130
[   60.045886]  ? pci_mmcfg_check_reserved+0xc0/0xc0
[   60.045913]  ? vfs_write+0x196/0x240
[   60.045939]  ? __fget_light+0xa7/0xc0
[   60.045965]  SyS_ioctl+0x41/0x70
[   60.045991]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.046017] RIP: 0033:0x7feb2baefc47
[   60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[   60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[   60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[   60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[   60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[   60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[   60.046225] Allocated:
[   60.046246] PID = 530
[   60.046269]  save_stack_trace+0x1b/0x20
[   60.046292]  save_stack+0x46/0xd0
[   60.046318]  kasan_kmalloc+0xad/0xe0
[   60.046343]  kasan_slab_alloc+0x12/0x20
[   60.046368]  kmem_cache_alloc+0xab/0x650
[   60.046445]  i915_gem_request_await_request+0x88/0x370 [i915]
[   60.046559]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.046705]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.046849]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.046936]  drm_ioctl+0x359/0x640 [drm]
[   60.046987]  do_vfs_ioctl+0x12e/0x910
[   60.047038]  SyS_ioctl+0x41/0x70
[   60.047090]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.047139] Freed:
[   60.047179] PID = 530
[   60.047223]  save_stack_trace+0x1b/0x20
[   60.047269]  save_stack+0x46/0xd0
[   60.047317]  kasan_slab_free+0x72/0xc0
[   60.047366]  kmem_cache_free+0x39/0x160
[   60.047512]  i915_gem_request_retire+0x83f/0x930 [i915]
[   60.047657]  i915_gem_request_alloc+0x166/0x600 [i915]
[   60.047799]  i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[   60.047897]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.047942]  drm_ioctl+0x359/0x640 [drm]
[   60.047968]  do_vfs_ioctl+0x12e/0x910
[   60.047993]  SyS_ioctl+0x41/0x70
[   60.048019]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.048044] Memory state around the buggy address:
[   60.048066]  ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048105]  ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[   60.048170]                                ^
[   60.048191]  ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048225]  ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc

Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.

Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
(cherry picked from commit ade0b0c965f59176daddbef9c4717354034f9bce)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio

The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:

[   62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[   62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[   62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[   62.034933] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[   62.034934] Workqueue: pm pm_runtime_work
[   62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[   62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[   62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[   62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[   62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[   62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[   62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[   62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[   62.034945] FS:  0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[   62.034945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[   62.034947] Call Trace:
[   62.034948]  intel_wait_for_register+0x77/0x140 [i915]
[   62.034949]  vlv_suspend_complete+0x23/0x5b0 [i915]
[   62.034950]  intel_runtime_suspend+0x16c/0x2a0 [i915]
[   62.034950]  pci_pm_runtime_suspend+0x50/0x180
[   62.034951]  ? pci_pm_runtime_resume+0xa0/0xa0
[   62.034952]  __rpm_callback+0xc5/0x210
[   62.034953]  rpm_callback+0x1f/0x80
[   62.034953]  ? pci_pm_runtime_resume+0xa0/0xa0
[   62.034954]  rpm_suspend+0x118/0x580
[   62.034955]  pm_runtime_work+0x64/0x90
[   62.034956]  process_one_work+0x1bb/0x3e0
[   62.034956]  worker_thread+0x46/0x4f0
[   62.034957]  ? __schedule+0x18b/0x610
[   62.034958]  kthread+0xff/0x140
[   62.034958]  ? process_one_work+0x3e0/0x3e0
[   62.034959]  ? kthread_create_on_node+

and related hard lockups in CI for byt and bsw.

Note this effectively reverts commits 41ce405e6894 and b27366958869
("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")

v2: Convert bool allow into a u32 mask for clarity and repeat the
comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)

Fixes: 41ce405e6894 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Fixes: b27366958869 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.uk
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
(cherry picked from commit 3dd14c04d77d7d702de5aa7157df4cc9417329f3)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/selftests: Allocate inode/file dynamically

Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.

drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]

Reported-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 2310b3c952c5dc56c2e08f71b907b8e23ab3270d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix system hang with EI UP masked on Haswell

Previously with commit a9c1f90c8e17
("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
to be unmasked for IVB and SNB in order to prevent system hang
with chained batchbuffers.

Our CI was seeing incomplete results with tests that used
chained batches and it was found out that HSW needs to have this
same bit unmasked to reliably survive chained batches.

Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to
prevent system hang with batch chaining.

Testcase: igt/gem_exec_fence/nb-await-default
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 3396a273851c14634b98bb27be37508b06df94f4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: checking for NULL instead of IS_ERR() in mock selftests

i915_gem_request_alloc() uses error pointers.  It never returns NULLs.

Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit be02f7556447a0dee672acb5e462f03377b98ae8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Perform link quality check unconditionally during long pulse

Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.

To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37bb3
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.

v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
    s/apparely/apparently/ in the comment (Chris)

Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
(cherry picked from commit 1a36147bb93921651f7fbd7a6e522da6c349081b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix use after free in lpe_audio_platdev_destroy()

[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G    BU  W       4.10.0+ #451
[31908.547553] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[31908.547682] Call Trace:
[31908.547772]  dump_stack+0x68/0x9f
[31908.547857]  kasan_object_err+0x1c/0x70
[31908.547947]  kasan_report_error+0x1f1/0x4f0
[31908.548038]  ? kfree+0xaa/0x170
[31908.548121]  kasan_report+0x34/0x40
[31908.548211]  ? klist_children_get+0x20/0x30
[31908.548472]  ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.548567]  __asan_load8+0x5e/0x70
[31908.548824]  intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.549080]  intel_audio_deinit+0x28/0x80 [i915]
[31908.549315]  i915_driver_unload+0xe4/0x360 [i915]
[31908.549551]  ? i915_driver_load+0x1d70/0x1d70 [i915]
[31908.549651]  ? trace_hardirqs_on+0xd/0x10
[31908.549885]  i915_pci_remove+0x23/0x30 [i915]
[31908.549978]  pci_device_remove+0x5c/0x100
[31908.550069]  device_release_driver_internal+0x1db/0x2e0
[31908.550165]  driver_detach+0x68/0xc0
[31908.550256]  bus_remove_driver+0x8b/0x150
[31908.550346]  driver_unregister+0x3e/0x60
[31908.550439]  pci_unregister_driver+0x1d/0x110
[31908.550531]  ? find_module_all+0x7a/0xa0
[31908.550791]  i915_exit+0x1a/0x87 [i915]
[31908.550881]  SyS_delete_module+0x264/0x2c0
[31908.550971]  ? free_module+0x430/0x430
[31908.551064]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.551159]  ? trace_hardirqs_on_caller+0x16/0x280
[31908.551256]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[31908.551350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.551440] RIP: 0033:0x7f1d67312ec7
[31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7
[31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8
[31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8
[31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000
[31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860
[31908.552121]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048
[31908.552306] Allocated:
[31908.552377] PID = 3781
[31908.552456]  save_stack_trace+0x16/0x20
[31908.552539]  kasan_kmalloc+0xee/0x190
[31908.552627]  __kmalloc+0xdb/0x1b0
[31908.552713]  platform_device_alloc+0x27/0x90
[31908.552804]  platform_device_register_full+0x36/0x220
[31908.553066]  intel_lpe_audio_init+0x41e/0x570 [i915]
[31908.553320]  intel_audio_init+0xd/0x40 [i915]
[31908.553552]  i915_driver_load+0x13f5/0x1d70 [i915]
[31908.553788]  i915_pci_probe+0x65/0xe0 [i915]
[31908.553881]  pci_device_probe+0xda/0x140
[31908.553969]  driver_probe_device+0x400/0x660
[31908.554058]  __driver_attach+0x11c/0x120
[31908.554147]  bus_for_each_dev+0xe6/0x150
[31908.554237]  driver_attach+0x26/0x30
[31908.554325]  bus_add_driver+0x26b/0x3b0
[31908.554412]  driver_register+0xce/0x190
[31908.554502]  __pci_register_driver+0xaf/0xc0
[31908.554589]  0xffffffffa0550063
[31908.554675]  do_one_initcall+0x8b/0x1e0
[31908.554764]  do_init_module+0x102/0x325
[31908.554852]  load_module+0x3aad/0x45e0
[31908.554944]  SyS_finit_module+0x169/0x1a0
[31908.555033]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.555119] Freed:
[31908.555188] PID = 3781
[31908.555266]  save_stack_trace+0x16/0x20
[31908.555349]  kasan_slab_free+0xb0/0x180
[31908.555436]  kfree+0xaa/0x170
[31908.555520]  platform_device_release+0x76/0x80
[31908.555610]  device_release+0x45/0xe0
[31908.555698]  kobject_put+0x11f/0x260
[31908.555785]  put_device+0x12/0x20
[31908.555871]  platform_device_unregister+0x1b/0x20
[31908.556135]  intel_lpe_audio_teardown+0x5c/0xb0 [i915]
[31908.556390]  intel_audio_deinit+0x28/0x80 [i915]
[31908.556622]  i915_driver_unload+0xe4/0x360 [i915]
[31908.556858]  i915_pci_remove+0x23/0x30 [i915]
[31908.556948]  pci_device_remove+0x5c/0x100
[31908.557037]  device_release_driver_internal+0x1db/0x2e0
[31908.557129]  driver_detach+0x68/0xc0
[31908.557217]  bus_remove_driver+0x8b/0x150
[31908.557304]  driver_unregister+0x3e/0x60
[31908.557394]  pci_unregister_driver+0x1d/0x110
[31908.557653]  i915_exit+0x1a/0x87 [i915]
[31908.557741]  SyS_delete_module+0x264/0x2c0
[31908.557834]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.557919] Memory state around the buggy address:
[31908.558005]  ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558127]  ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558374]                                                     ^
[31908.558467]  ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[31908.558595]  ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
and we need to coordinate a proper fix in platform_device itself.

Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Jerome Anand <jerome.anand@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.uk
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 48ae80741da4b8a26b6df0f765713912bc7cc480)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use the right mapping_gfp_mask for final shmem allocation

Many sightings report the greater prevalence of allocation failures.
This is all due to the incorrect use of mapping_gfp_constraint(), so
remove it in favour of just querying the mapping_gfp_mask() which are
the exact gfp_t we wanted in the first place.

We still do expect a higher chance of reporting ENOMEM, as that is the
intention of using __GFP_NORETRY -- to fail rather than oom after having
reclaimed from our bo caches, and having done a direct|kswapd reclaim
pass.

Reported-by: Jason Ekstrand <jason.ekstrand@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit b268d9fe0f10544f5f7a1b7015e2b97075e6215d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make legacy cursor updates more unsynced

We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up the commit.

Also toss in a FIXME about solving these problems in a nicer
way using the fabled vblank workers.

v2: Also unsync with legacy page flips

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
Cc: Rafael Ristovski <rafael.ristovski@gmail.com>
Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 895203044067af64400cedbc055898bcec98d102)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Apply a cond_resched() to the saturated signaler

If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!

A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are more than sufficient to hog the
CPU, preventing the system from even processing ICMP echo replies.

v2: Tvrtko dug into cond_resched() on x86 and found that it only
depended upon preempt_count and not tif_need_resched() - which means
that we would always call schedule() at that point.

Fixes: c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit a7980a640cbd339aa80f406d1786a275a2c320bc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Park the signaler before sleeping

If the signal to park arrives before we sleep, then we need to check
kthread_should_park() before sleeping to avoid missing the signal.
Otherwise, if the signal arrives whilst we are processing completed
requests, we will reset the current->state back to TASK_INTERRUPTIBLE
and so miss the wakeup.

Fixes: fe3288b5da2c ("drm/i915: Park the breadcrumbs signaler across a GPU reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403105124.8969-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
(cherry picked from commit b1becb88268beb72df6495e35d3d76c138d215bb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Skip waking the signaler when enabling before request submission

If we are enabling the breadcrumbs signaling prior to submitting the
request, we know that we cannot have missed the interrupt and can
therefore skip immediately waking the signaler to check.

This reduces a significant chunk of the __i915_gem_request_submit()
overhead for inter-engine synchronisation, for example in gem_exec_whisper.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170426080659.28771-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Merge tag 'gvt-next-fixes-2017-04-20' of https://github.com/01org/gvt-linux into drm-intel-next-fixes

gvt-next-fixes-2017-04-20

- some code optimization from Changbin
- debug message cleanup after QoS merge
- misc fixes for display mmio init, reset vgpu warning, etc.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Poison the request before emitting commands

If we poison the request before we emit commands, it should be easier to
spot when we execute an uninitialised request.

References: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170423170619.7156-2-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Differentiate between sw write location into ring and last hw read

We need to keep track of the last location we ask the hw to read up to
(RING_TAIL) separately from our last write location into the ring, so
that in the event of a GPU reset we do not tell the HW to proceed into
a partially written request (which can happen if that request is waiting
for an external signal before being executed).

v2: Refactor intel_ring_reset() (Mika)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Testcase: igt/gem_exec_fence/await-hang
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170425130049.26147-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Report request restarts for both execlists/guc

As we now share the execlist_port[] tracking for both execlists/guc, we
can reset the inflight count on both and report which requests are being
restarted.

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

drm/i915: Include interesting seqno in the missed breadcrumb debug

Knowing the neighbouring seqno (current on hw, last submitted to hw)
provide some useful breadcrumbs to the debug log.

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

drm: mali-dp: Check the mclk rate and allow up/down scaling

When downscaling, mclk needs to be sufficiently higher than pxlclk in
order to be able to fetch the higher-resolution data and produce output
pixels. When not scaling, or when upscaling, mclk can be equal to
pxlclk. Since the driver doesn't control mclk, just ensure that the
requirement is satisfied with the current clock rate.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: Enable image enhancement when scaling

Apply image enhacement when we are upscaling by a factor of 2
or more in either direction.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: Add plane upscaling support

Enable the scaling engine for upscaling a single plane using the polyphase
scaler. No image enhancement support or downscaling yet*, and composition
result scaling is not implemented.

* Downscaling a plane requires mclk > pxlclk.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm/mali-dp: Add core_id file to the sysfs interface

Add a core_id file in the driver's sysfs directory,
exposing the hardware CORE ID. This is useful to allow
userspace to discover the hardware version used.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: Add CTM support

All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: enable gamma support

Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.

This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same table of coefficients for
all 3 curves on DP500.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

drm: mali-dp: add malidp_crtc_state struct

Add a custom CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: add custom reset hook for planes

Now that we are using a custom plane state in mali-dp, we need a
bespoke reset that takes into account the larger structure.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
[Updated commit message]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: remove unused variable

The newly introduced function causes a harmless build warning:

drivers/gpu/drm/arm/malidp_planes.c: In function 'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp' [-Werror=unused-variable]

The variable serves no purpose here and can be removed.

Fixes: 242f43b69c61 ("drm: mali-dp: add atomic_print_state for planes")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: add atomic_print_state for planes

Add function to dump the state of the plane.

Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: Enable power management for the device.

Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.

Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm/i915: Confirm the request is still active before adding it to the await

Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.

In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:

[   60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[   60.044118] Read of size 8 by task gem_exec_fence/530
[   60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G            E   4.11.0-rc7+ #46
[   60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[   60.044290] Call Trace:
[   60.044337]  dump_stack+0x4d/0x6a
[   60.044383]  kasan_object_err+0x21/0x70
[   60.044435]  kasan_report+0x225/0x4e0
[   60.044488]  ? __list_add_valid+0x1d/0xd0
[   60.044534]  ? kasan_kmalloc+0xad/0xe0
[   60.044587]  __asan_load8+0x5e/0x70
[   60.044639]  __list_add_valid+0x1d/0xd0
[   60.044788]  __i915_priotree_add_dependency+0x67/0x130 [i915]
[   60.044895]  i915_gem_request_await_request+0xa8/0x370 [i915]
[   60.044974]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.045049]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.045077]  ? save_stack+0xb1/0xd0
[   60.045105]  ? save_stack_trace+0x1b/0x20
[   60.045132]  ? save_stack+0x46/0xd0
[   60.045158]  ? kasan_kmalloc+0xad/0xe0
[   60.045184]  ? __kmalloc+0xd8/0x670
[   60.045229]  ? drm_ioctl+0x359/0x640 [drm]
[   60.045256]  ? SyS_ioctl+0x41/0x70
[   60.045330]  ? i915_vma_move_to_active+0x540/0x540 [i915]
[   60.045360]  ? tty_insert_flip_string_flags+0xa1/0xf0
[   60.045387]  ? tty_flip_buffer_push+0x63/0x70
[   60.045414]  ? remove_wait_queue+0xa9/0xc0
[   60.045441]  ? kasan_unpoison_shadow+0x35/0x50
[   60.045467]  ? kasan_kmalloc+0xad/0xe0
[   60.045494]  ? kasan_check_write+0x14/0x20
[   60.045568]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.045616]  drm_ioctl+0x359/0x640 [drm]
[   60.045705]  ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[   60.045751]  ? drm_version+0x150/0x150 [drm]
[   60.045778]  ? compat_start_thread+0x60/0x60
[   60.045805]  ? plist_del+0xda/0x1a0
[   60.045833]  do_vfs_ioctl+0x12e/0x910
[   60.045860]  ? ioctl_preallocate+0x130/0x130
[   60.045886]  ? pci_mmcfg_check_reserved+0xc0/0xc0
[   60.045913]  ? vfs_write+0x196/0x240
[   60.045939]  ? __fget_light+0xa7/0xc0
[   60.045965]  SyS_ioctl+0x41/0x70
[   60.045991]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.046017] RIP: 0033:0x7feb2baefc47
[   60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[   60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[   60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[   60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[   60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[   60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[   60.046225] Allocated:
[   60.046246] PID = 530
[   60.046269]  save_stack_trace+0x1b/0x20
[   60.046292]  save_stack+0x46/0xd0
[   60.046318]  kasan_kmalloc+0xad/0xe0
[   60.046343]  kasan_slab_alloc+0x12/0x20
[   60.046368]  kmem_cache_alloc+0xab/0x650
[   60.046445]  i915_gem_request_await_request+0x88/0x370 [i915]
[   60.046559]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[   60.046705]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[   60.046849]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.046936]  drm_ioctl+0x359/0x640 [drm]
[   60.046987]  do_vfs_ioctl+0x12e/0x910
[   60.047038]  SyS_ioctl+0x41/0x70
[   60.047090]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.047139] Freed:
[   60.047179] PID = 530
[   60.047223]  save_stack_trace+0x1b/0x20
[   60.047269]  save_stack+0x46/0xd0
[   60.047317]  kasan_slab_free+0x72/0xc0
[   60.047366]  kmem_cache_free+0x39/0x160
[   60.047512]  i915_gem_request_retire+0x83f/0x930 [i915]
[   60.047657]  i915_gem_request_alloc+0x166/0x600 [i915]
[   60.047799]  i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[   60.047897]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[   60.047942]  drm_ioctl+0x359/0x640 [drm]
[   60.047968]  do_vfs_ioctl+0x12e/0x910
[   60.047993]  SyS_ioctl+0x41/0x70
[   60.048019]  entry_SYSCALL_64_fastpath+0x17/0x98
[   60.048044] Memory state around the buggy address:
[   60.048066]  ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048105]  ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[   60.048170]                                ^
[   60.048191]  ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[   60.048225]  ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc

Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.

Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk