Commit Graph

753309 Commits

Author SHA1 Message Date
Ville Syrjälä
ea80a661fe drm/i915: Try to suppress more spurious PCH underruns on ILK-IVB
My ILK seems to generate a spurious PCH underrun with most interlaced
HDMI modes. Add a second vblank wait to avoid it.

We have seen some spurious PCH underruns still in CI as well, some
of which seem to be progressive DP. The logs also point towards some
spurious underrins with progressive HDMI on SNB. While I don't have
a solid explanation for those let's try to kill all the birds with one
stone and always do the double wait.

Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524190406.2973-1-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-05-25 18:00:26 +03:00
Ville Syrjälä
10ed55e4d9 drm/i915: Initialize panel_pipe to INVALID_PIPE
We can always figure out which pipe is affected by the panel power
sequencer lockout mechanism. So no need for the pipe A fallback
anymore. The only case we may have to worry about is an invalid
port select in the power sequencer, but INVALID_PIPE is just fine
in that case. We'll get the WARN about the bogus pps port select
anyway.

Cc: Jani Nikula <jani.nikula@intel.com>
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523145718.22932-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-25 18:00:26 +03:00
Chris Wilson
73b66f8731 drm/i915: Prepare GEM for suspend earlier
In order to prepare the GPU for sleeping, we may want to submit commands
to it. This is a complicated process that may even require some swapping
in from shmemfs, if the GPU was in the wrong state. As such, we need to
do this preparation step synchronously before the rest of the system has
started to turn off (e.g. swapin fails if scsi is suspended).
Fortunately, we are provided with a such a hook, pm_ops.prepare().

v2: Compile cleanup
v3: Fewer asserts, fewer problems?

v4: Ville pointed out that in some circumstances (such as switching off
the overlay) the display code may issue a GPU request. This is
unexpected, and will result in us going to sleep with us believing the
GPU is still awake (though all user work has been saved). Add a comment
to remind our future selves of what trouble brews.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Testcase: igt/drv_suspend after igt/gem_tiled_swapping
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525092629.1456-1-chris@chris-wilson.co.uk
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2018-05-25 14:52:20 +01:00
Chris Wilson
fe25f30483 drm/i915/execlists: Wait for ELSP submission on restart
After a reset, we will ensure that there is at least one request
submitted to HW to ensure that a context is loaded for powersaving.
Let's wait for this submission via a tasklet to complete before we drop
our forcewake, ensuring the system is ready for rc6 before we let it
possibly sleep.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522101937.7738-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2018-05-25 13:39:49 +01:00
Chris Wilson
9a4dc80399 drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like

<7>[  239.094840] i915_gem_set_wedged rcs0
<7>[  239.094843] i915_gem_set_wedged 	current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms]
<7>[  239.094846] i915_gem_set_wedged 	Reset count: 6239 (global 1)
<7>[  239.094848] i915_gem_set_wedged 	Requests:
<7>[  239.095052] i915_gem_set_wedged 		first  19a99 [e8c:5f] prio=1024 @ 5159ms: (null)
<7>[  239.095056] i915_gem_set_wedged 		last   19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1
<7>[  239.095059] i915_gem_set_wedged 		active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null)
<7>[  239.095062] i915_gem_set_wedged 		[head 0220, postfix 0280, tail 02a8, batch 0xffffffff_ffffffff]
<7>[  239.100050] i915_gem_set_wedged 		ring->start:  0x00283000
<7>[  239.100053] i915_gem_set_wedged 		ring->head:   0x000001f8
<7>[  239.100055] i915_gem_set_wedged 		ring->tail:   0x000002a8
<7>[  239.100057] i915_gem_set_wedged 		ring->emit:   0x000002a8
<7>[  239.100059] i915_gem_set_wedged 		ring->space:  0x00000f10
<7>[  239.100085] i915_gem_set_wedged 	RING_START: 0x00283000
<7>[  239.100088] i915_gem_set_wedged 	RING_HEAD:  0x00000260
<7>[  239.100091] i915_gem_set_wedged 	RING_TAIL:  0x000002a8
<7>[  239.100094] i915_gem_set_wedged 	RING_CTL:   0x00000001
<7>[  239.100097] i915_gem_set_wedged 	RING_MODE:  0x00000300 [idle]
<7>[  239.100100] i915_gem_set_wedged 	RING_IMR: fffffefe
<7>[  239.100104] i915_gem_set_wedged 	ACTHD:  0x00000000_0000609c
<7>[  239.100108] i915_gem_set_wedged 	BBADDR: 0x00000000_0000609d
<7>[  239.100111] i915_gem_set_wedged 	DMA_FADDR: 0x00000000_00283260
<7>[  239.100114] i915_gem_set_wedged 	IPEIR: 0x00000000
<7>[  239.100117] i915_gem_set_wedged 	IPEHR: 0x02800000
<7>[  239.100120] i915_gem_set_wedged 	Execlist status: 0x00044052 00000002
<7>[  239.100124] i915_gem_set_wedged 	Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[  239.100128] i915_gem_set_wedged 		ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[  239.100132] i915_gem_set_wedged 		ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[  239.100135] i915_gem_set_wedged 		HW active? 0x5
<7>[  239.100250] i915_gem_set_wedged 		E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[  239.100338] i915_gem_set_wedged 		E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[  239.100340] i915_gem_set_wedged 		Queue priority: 139
<7>[  239.100343] i915_gem_set_wedged 		Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8
<7>[  239.100346] i915_gem_set_wedged 		Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2
<7>[  239.100349] i915_gem_set_wedged 		Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3
<7>[  239.100352] i915_gem_set_wedged 		Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2
<7>[  239.100356] i915_gem_set_wedged 		Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4
<7>[  239.100362] i915_gem_set_wedged 	drv_selftest [5894] waiting for 19a99

where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.

v2: Only clear the bit on restarting the ring, as we want to be sure the
STOP_RING bit is kept if reset fails on wedging.
v3: Spot when the ring state doesn't make sense when re-initialising the
engine and dump it to the logs so that we don't have to wait for an
error later and try to guess what happened earlier.
v4: Prepare to print all the unexpected state, not just the first.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518100933.2239-1-chris@chris-wilson.co.uk
2018-05-25 09:51:49 +01:00
Tvrtko Ursulin
8359768c5c drm/i915: Forward declare struct intel_context
This is to avoid an error with structure declared in parameter list if the
include ordering changes.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524150621.17332-2-tvrtko.ursulin@linux.intel.com
2018-05-25 08:21:19 +01:00
Tvrtko Ursulin
c5d1f5562e drm/i915: Include i915_scheduler.h from i915_gem_context.h
struct i915_gem_context embeds struct i915_sched_attr so needs to include
the respective header.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524150621.17332-1-tvrtko.ursulin@linux.intel.com
2018-05-25 08:21:19 +01:00
Chris Wilson
09a4c02e58 drm/i915: Look for an active kernel context before switching
We were not very carefully checking to see if an older request on the
engine was an earlier switch-to-kernel-context before deciding to emit a
new switch. The end result would be that we could get into a permanent
loop of trying to emit a new request to perform the switch simply to
flush the existing switch.

What we need is a means of tracking the completion of each timeline
versus the kernel context, that is to detect if a more recent request
has been submitted that would result in a switch away from the kernel
context. To realise this, we need only to look in our syncmap on the
kernel context and check that we have synchronized against all active
rings.

v2: Since all ringbuffer clients currently share the same timeline, we do
have to use the gem_context to distinguish clients.

As a bonus, include all the tracing used to debug the death inside
suspend.

v3: Test, test, test. Construct a selftest to exercise and assert the
expected behaviour that multiple switch-to-contexts do not emit
redundant requests.

Reported-by: Mika Kuoppala <mika.kuoppala@intel.com>
Fixes: a89d1f921c ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524081135.15278-1-chris@chris-wilson.co.uk
2018-05-24 15:51:45 +01:00
Dhinakaran Pandiyan
97c9de66ca drm/i915/psr: Fix ALPM cap check for PSR2
While touching the code around this, I noticed that absence of ALPM
capability does not stop us from enabling PSR2. But, the spec
unambiguously states that ALPM is required for PSR2 and so does this
commit that introduced this code

drm/i915/psr: enable ALPM for psr2

    As per edp1.4 spec , alpm is required for psr2 operation as it's
    used for all psr2  main link power down management and alpm enable
    bit must be set for psr2 operation.

Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Tarun Vyas <tarun.vyas@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-6-dhinakaran.pandiyan@intel.com
2018-05-24 16:34:23 +03:00
Dhinakaran Pandiyan
264ff016cf drm/i915/psr: Fall back to max. synchronization latency if DPCD read fails
Noticed that we assume the best case of 0 latency when the DPCD read
fails, reasonable pessimism is safer.

eDP spec does say that if latency is greater than 8, the panel
supplier needs to provide it. I didn't see anything specific in the VBT
for this, so let's go with 8 frames as a fallback.

Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-5-dhinakaran.pandiyan@intel.com
2018-05-24 16:33:35 +03:00
Dhinakaran Pandiyan
1e8b251ebc drm/i915/psr: Avoid unnecessary DPCD read of DP_PSR_CAPS
intel_dp->psr_dpcd already has the required values.

Cc: Jose Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Tarun Vyas <tarun.vyas@intel.com>
Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-4-dhinakaran.pandiyan@intel.com
2018-05-24 16:31:54 +03:00
Dhinakaran Pandiyan
84bb2916a6 drm/i915/psr: Check for SET_POWER_CAPABLE bit at PSR init time.
By moving the check from psr_compute_config() to psr_init_dpcd(), we get
to set the dev_priv->psr.sink_support flag only when the panel is
capable of changing power state. An additional benefit is that the check
will be performed only at init time instead of every atomic_check.

This should change the psr_basic IGT failures on HSW to skips.

v2: Return early when SET_POWER_CAPABLE bit is 0 (Jose)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106217
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106346
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-2-dhinakaran.pandiyan@intel.com
2018-05-24 16:15:14 +03:00
Dhinakaran Pandiyan
8cf6da7ef7 drm/i915/psr: Avoid DPCD reads when panel does not support PSR
Ville noticed that we are unncessarily reading DPCD's after knowing
panel did not support PSR. Looks like this check that was present
earlier got removed unintentionally, let's put it back.

While we do this, add the PSR version number in the debug print.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Tarun Vyas <tarun.vyas@intel.com>
Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-1-dhinakaran.pandiyan@intel.com
2018-05-24 16:15:00 +03:00
Dhinakaran Pandiyan
ce3508fd2a drm/i915/psr: Nuke PSR support for VLV and CHV
PSR hardware and hence the driver code for VLV and CHV deviates a lot from
their DDI counterparts. While the feature has been disabled for a long time
now, retaining support for these platforms is a maintenance burden. There
have been multiple refactoring commits to just keep the existing code for
these platforms in line with the rest. There are known issues that need to
be fixed to enable PSR on these platforms, and there is no PSR capable
platform in CI to ensure the code does not break again if we get around to
fixing the existing issues. On account of all these reasons, let's nuke
this code for now and bring it back if a need arises in the future.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511230059.19387-1-dhinakaran.pandiyan@intel.com
2018-05-24 16:05:19 +03:00
Vathsala Nagaraju
77312ae8f0 drm/i915/psr: vbt change for psr
For psr block #9, the vbt description has moved to options [0-3] for
TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
structure. Since spec does not  mention from which VBT version this
change was added to vbt.bsf file, we cannot depend on bdb->version check
to change for all the platforms.

There is RCR inplace for GOP team to  provide the version number
to make generic change. Since Kabylake with bdb version 209 is having this
change, limiting this change to gen9_bc and version 209+ to unblock google.

Tested on skl(bdb version 203,without options) and
kabylake(bdb version 209,212) having new options.

bspec 20131

v2: (Jani and Rodrigo)
    move the 165 version check to intel_bios.c
v3: Jani
    Move the abstraction to intel_bios.
v4: Jani
    Rename tp*_wakeup_time to have "us" suffix.
    For values outside range[0-3],default to max 2500us.
    Old decimal value was wake up time in multiples of 100us.
v5: Jani and Rodrigo
    Handle option 2 in default condition.
    Print oustide range value.
    For negetive values default to 2500us.
v6: Jani
    Handle default first and then fall through for case 2.
v7: Rodrigo
    Apply this change for IS_GEN9_BC and vbt version > 209
v8: Puthik
    Add new function vbt_psr_to_us.
v9: Jani
    Change to v7 version as it's more readable.
    DK
    add comment /*fall through*/ after case2.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Puthikorn Voravootivat <puthik@chromium.org>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526981243-2745-1-git-send-email-vathsala.nagaraju@intel.com
2018-05-24 16:03:49 +03:00
Yunwei Zhang
fe864b76c2 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
 - use fls instead of find_last_bit (Chris)
 - use is_power_of_2() instead of counting bit set (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Move local variable into scope where they are used (Ursulin)
 - use a new local variable to reduce long line of code (Ursulin)
v6:
 - Some coding style and use more local variables for clearer
   logic (Ursulin)

Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683285-24861-1-git-send-email-yunwei.zhang@intel.com
2018-05-24 12:52:53 +03:00
Yunwei Zhang
d78fa508f0 drm/i915/icl: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Icelake as
well.

References: HSD#1405586840, BSID#0575

v2:
 - GEN11 mask is different from its predecessors. (Oscar)
 - Better separate GEN10 and GEN11. (Oscar)

Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683232-24753-1-git-send-email-yunwei.zhang@intel.com
2018-05-24 12:52:52 +03:00
Yunwei Zhang
1e40d4aea5 drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
 - use fls() instead of find_last_bit() (Chris)
 - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Change the ordered of passing arguments and etc. (Ursulin)
v7:
 - Moved WA explanation Comments(Oscar)
 - Rebased.
v8:
 - Renamed sanitize_mcr to calculate_s_ss_select. (Oscar)
 - calculate s/ss selector instead of whole mcr. (Oscar)
v9:
 - Updated function name (Oscar)
 - Remove redundant variables (Oscar)
v10:
 - Separate pre-GEN10 and GEN11 mask. (Oscar)

Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683197-24656-1-git-send-email-yunwei.zhang@intel.com
2018-05-24 12:52:51 +03:00
José Roberto de Souza
c894d63c6b drm/i915/icl: Disable pipe CSC and gamma in cursor plane
'Pipe CSC enable' bit is more than just deprecated in ICL+, it was
disabled in commit 077ef1f09c ("drm/i915/icl: Don't set pipe
CSC/Gamma in PLANE_COLOR_CTL") for primary and sprite planes as it was
causing those planes to be rendered as always black but it was not
disabled in cursor plane, also causing it to be rendered as black.

As mentioned in the commit referenced above, this is a workaround
too and the CSC and gamma per plane values needs to be setup before
enable CSC and gamma again.

BSpec: 4278 and 7635

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518201547.15793-1-jose.souza@intel.com
2018-05-23 10:26:51 -07:00
Chris Wilson
4a774ee35c drm/i915/selftests: Pin the mock kernel context
The driver assumes that the kernel context is pinned and always
available for use from any process or atomic context. Make it so for
selftesting as well!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523142346.27953-1-chris@chris-wilson.co.uk
2018-05-23 17:48:46 +01:00
Ville Syrjälä
f0d2b758e0 drm/i915: WARN if power sequencer is not connected to the LVDS port on pre-ilk
We don't support using the power sequencer with other ports besides LVDS
on pre-ilk platforms. WARN if someone has mistakenly connected the power
sequencer to the wrong port.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23 17:23:07 +03:00
Ville Syrjälä
4c23dea48b drm/i915: Implement the missing bits of assert_panel_unlocked()
Add the missing eDP port handling into assert_panel_unlocked(). We now
have intel_dp_port_enabled() which makes this trivial.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23 17:23:07 +03:00
Ville Syrjälä
05bf51d3b5 drm/i915: Allow eDP on port C in theory
The power sequencer has bits to allow DP C to be used for eDP.
Currently we assume this will never happen, but I guess it could
theoretically be a thing. Make the code do the right thing in that
case, and toss in a MISSING_CASE() for any other port.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23 17:23:07 +03:00
Ville Syrjälä
59b74c497a drm/i915: Clean up DP pipe select bits
Clean up the DP pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state(),
the port state asserts, and the VLV power sequencer code.

v2: Return PIPE_A for cpt/ppt when the port isn't selected by
    any transcoder. Returning INVALID_PIPE explodes *somewhere*
    on some machines (can't immediately see where though). This
    now matches the old behaviour.
v3: Order the defines shift,mask,value (Jani)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23 17:23:07 +03:00
Ville Syrjälä
5a0b385e1c drm/i915: Nuke intel_trans_dp_port_sel()
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic
drivers. Let's throw out intel_trans_dp_port_sel() and replace it
with intel_get_crtc_new_encoder() which looks the atomic state instead.

Since we now have to call intel_get_crtc_new_encoder() during the commit
phase we'll need to plumb in the top level atomic state. The
crtc_state->state pointers are no longer valid at that point.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23 17:23:07 +03:00
Ville Syrjälä
f67dc6d886 drm/i915: Parametrize TRANS_DP_PORT_SEL
Parametrize the TRANS_DP_PORT_SEL macros.

v2: WARN for bogus ports (Jani)
    Order the defines mask,value (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-2-ville.syrjala@linux.intel.com
2018-05-23 17:23:07 +03:00
Ville Syrjälä
f606bc6d9d drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi code
The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it
elsewhere where we have some users left.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-1-ville.syrjala@linux.intel.com
2018-05-23 17:23:07 +03:00
Chris Wilson
a33b1dc8a7 drm/i915/query: nospec expects no more than an unsigned long
nospec quite reasonably asserts that it will never be used with an index
larger than unsigned long (that being the largest possibly index into an
C array). However, our ubi uses the convention of u64 for any large
integer, running afoul of the assertion on 32b. Reduce our index to an
unsigned long, checking for type overflow first.

  drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
  include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)

Reported-by: kbuild-all@01.org
Fixes: 84b510e22d ("drm/i915/query: Protect tainted function pointer lookup")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522121018.15199-1-chris@chris-wilson.co.uk
2018-05-22 16:55:57 +01:00
Ville Syrjälä
59462a00cc drm/i915: Eliminate the unused dev_priv->vbt.lvds_vbt
dev_priv->vbt.lvds_vbt is set but never actually used. Kill it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508124136.10969-3-ville.syrjala@linux.intel.com
2018-05-22 15:52:35 +03:00
Ville Syrjälä
5255e2f8d1 drm/i915: Replace vbt edp.support with int_lvds_support
Replace dev_priv->vbt.edp.support with
dev_priv->vbt.int_lvds_support. We'll want to extend its
use beyond the LVDS vs. eDP case in the future.

v2: Nuke the edp.support from parse_edp() (Jani)
    Only clear int_lvds_support for gen5+ to preserve
    the current behaviour (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508140814.20105-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-22 15:50:40 +03:00
Chris Wilson
1abb70f595 drm/i915/gtt: Allow pagedirectory allocations to fail
As we handle the allocation failure of the page directory and tables by
propagating the failure back to userspace, allow it to fail if direct
reclaim is unable to satisfy the request (i.e. disable the oomkiller).
The premise being that if we are unable to allocate a single page for
the pagetable, we will not be able to handle the multitude of pages
required for the gfx operation and we should back off to allow the
system to recover.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106609
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522083643.29601-1-chris@chris-wilson.co.uk
2018-05-22 10:56:46 +01:00
Chris Wilson
84b510e22d drm/i915/query: Protect tainted function pointer lookup
Smatch identifies i915_query_ioctl() as being a potential victim of
Spectre due to its use of a tainted user index into a function pointer
array. Use array_index_nospec() to defang the user index before using it
to lookup the function pointer.

Fixes: a446ae2c6e ("drm/i915: add query uAPI")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521210530.26008-1-chris@chris-wilson.co.uk
2018-05-22 10:47:07 +01:00
Jani Nikula
d93fa1b47b Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
This reverts commit dc911f5bd8.

Per the report, no matter what display mode you select with xrandr, the
i915 driver will always select the alternate fixed mode. For the
reporter this means that the display will always run at 40Hz which is
quite annoying. This may be due to the mode comparison.

But there are some other potential issues. The choice of alt_fixed_mode
seems dubious. It's the first non-preferred mode, but there are no
guarantees that the only difference would be refresh rate. Similarly,
there may be more than one preferred mode in the probed modes list, and
the commit changes the preferred mode selection to choose the last one
on the list instead of the first.

(Note that the probed modes list is the raw, unfiltered, unsorted list
of modes from drm_add_edid_modes(), not the pretty result after a
drm_helper_probe_single_connector_modes() call.)

Finally, we already have eerily similar code in place to find the
downclock mode for DRRS that seems like could be reused here.

Back to the drawing board.

Note: This is a hand-crafted revert due to conflicts. If it fails to
backport, please just try reverting the original commit directly.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469
Reported-by: Rune Petersen <rune@megahurts.dk>
Reported-by: Mark Spencer <n7u4722r35@ynzlx.anonbox.net>
Fixes: dc911f5bd8 ("drm/i915/edp: Allow alternate fixed mode for eDP if available.")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nikula@intel.com
2018-05-22 12:36:05 +03:00
Daniel Stone
a268bcd764 drm/i915: Move GEM BO inside drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.

v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-2-daniels@collabora.com
2018-05-22 09:44:04 +01:00
Daniel Stone
a5ff7a45c9 drm/i915: Use intel_fb_obj() everywhere
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-1-daniels@collabora.com
2018-05-22 09:44:02 +01:00
Zhenyu Wang
6bb2a2af8b drm/i915/gvt: Fix crash after request->hw_context change
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.

v2: Move request alloc earlier as already try to track shadow status
depending on request state, which also facilitate to use request->hw_context
for target engine context reference.

Fixes: 1fc44d9b1a ("drm/i915: Store a pointer to intel_context in i915_request")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521081752.31056-1-zhenyuw@linux.intel.com
2018-05-21 10:55:30 +01:00
Chris Wilson
39d3cc03e9 drm/i915/selftests: Wait longer for the old active request
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active timeouts are the same, it is hard to distinguish
which caused the timeout. Bump the active thread timeouts to 5s,
compared to the 1s timeout for the hang, so that we preferentially
report the hang timing out, while hopefully ensuring that we do at least
wake up the hang thread first before declaring the background active
timeout.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517142442.16979-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2018-05-19 12:50:59 +01:00
Chris Wilson
2399a4a6f5 drm/i915: Allow init_breadcrumbs to be used from irq context
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518090212.5349-3-chris@chris-wilson.co.uk
2018-05-19 12:50:58 +01:00
Chris Wilson
fe0c493538 drm/i915/execlists: Handle copying default context state for atomic reset
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an atomic context. The atomic
context prevents us from pinning the object or from peeking into the
shmemfs backing store (all may sleep), so we choose to pin the
default_state into memory when the engine becomes active. This
compromise allows us to swap out the default state when idle, when
required.

References: 5692251c25 ("drm/i915/lrc: Scrub the GPU state of the guilty hanging request")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518090212.5349-2-chris@chris-wilson.co.uk
2018-05-19 12:50:58 +01:00
Chris Wilson
d6d12ec081 drm/i915: Make intel_engine_dump irqsafe
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518090212.5349-1-chris@chris-wilson.co.uk
2018-05-19 12:50:57 +01:00
Chris Wilson
dd0cf235d8 drm/i915: Speed up idle detection by kicking the tasklets
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!

Thus we can speed up idle detection by bypassing ksoftirqd in these
cases and flush our tasklet to confirm if we are indeed still waiting
for the ELSP to drain.

v2: Put the execlists.first check back; it is required for handling
reset!

References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506171328.30034-1-chris@chris-wilson.co.uk
2018-05-19 12:50:57 +01:00
Chris Wilson
e578a570dc drm/i915/lvds: Move acpi lid notification registration to registration phase
Delay registering ourselves with the acpi lid notification mechanism
until we are registering the connectors after initialisation is
complete. This prevents a possibility of trying to handle the lid
notification before we are ready with the danger of chasing
uninitialised function pointers.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
 IP:           (null)
 PGD 0 P4D 0
 Oops: 0010 [#1] PREEMPT SMP PTI
 Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod ehci_pci
  ehci_hcd usbcore usb_common i8042 serio
 CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1
 Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012
 RIP: 0010:          (null)
 RSP: 0018:ffffaf4580c33a18 EFLAGS: 00010287
 RAX: 0000000000000000 RBX: ffff947533558000 RCX: 000000000000003e
 RDX: ffffffffc0aa80c0 RSI: ffffaf4580c33a3c RDI: ffff947534e4c000
 RBP: ffff947533558338 R08: ffff947534598930 R09: ffffffffc0a928b1
 R10: ffffd8f181d5fd40 R11: 0000000000000000 R12: ffffffffc0a928b1
 R13: ffff947533558368 R14: ffffffffc0a928a9 R15: ffff947534e4c000
 FS:  00007f3dc4ddb940(0000) GS:ffff947539280000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 000000006e214000 CR4: 00000000000406e0
 Call Trace:
  ?  intel_modeset_setup_hw_state+0x385/0xf60 [i915]
  ? __intel_display_resume+0x1e/0xc0 [i915]
  ? intel_display_resume+0xcc/0x120 [i915]
  ? intel_lid_notify+0xbc/0xc0 [i915]
  ? notifier_call_chain+0x47/0x70
  ? blocking_notifier_call_chain+0x3e/0x60
  ? acpi_lid_notify_state+0x8f/0x1d0
  ? acpi_lid_update_state+0x49/0x70
  ? acpi_lid_input_open+0x60/0x90
  ? input_open_device+0x5d/0xa0
  ? evdev_open+0x1ba/0x1e0 [evdev]
  ? chrdev_open+0xa3/0x1b0
  ? cdev_put.part.0+0x20/0x20
  ? do_dentry_open+0x14c/0x300
  ? path_openat+0x30c/0x1240
  ? current_time+0x16/0x60
  ? do_filp_open+0x93/0x100
  ? __check_object_size+0xfb/0x180
  ? do_sys_open+0x186/0x210
  ? do_syscall_64+0x74/0x190
  ?  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
 Code:  Bad RIP value.
 RIP:           (null) RSP: ffffaf4580c33a18
 CR2: 0000000000000000

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559
Fixes: c1c7af6089 ("drm/i915: force mode set at lid open time")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518074840.16194-1-chris@chris-wilson.co.uk
Cc: stable@vger.kernel.org
2018-05-19 12:50:56 +01:00
Ville Syrjälä
45101e939e drm/i915: Rename the remaining gen4 references to g4x in the DP code
i965 does not have native DP. Let's rename the remaining gen4 references
in the DP code to g4x.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-18 17:23:40 +03:00
Ville Syrjälä
4d82c2b5f0 drm/i915: Rename SNB/IVB CPU eDP signal level funcs
To make the intent more clear, let's rename the signal level funcs for
the SNB/IVB CPU eDP.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-18 17:23:40 +03:00
Ville Syrjälä
b752e99582 drm/i915: Check for IVB instead of gen7 when we think about IVB CPU eDP
Almost all of the GEN7 checks in the DP code are actually looking for
IVB. HSW doesn't even take these codepaths, and VLV is excluded on
account of not having port A. So let's change the checks to IS_IVB to
make the code less confusing.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-3-ville.syrjala@linux.intel.com
2018-05-18 17:23:40 +03:00
Ville Syrjälä
4718a365cf drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+
All DDI platforms support the full set of preemph settings for each
supported vswing, so let's use the same code for them. We'll also move
the code into intel_ddi.c so that it sits closer to the actual buf trans
tables.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-18 17:23:40 +03:00
Ville Syrjälä
a393e96495 drm/i915: Use intel_ddi_dp_voltage_max() for HSW/BDW too
Use intel_ddi_dp_voltage_max() for HSW/BDW too instead of letting these
fall through the if ladder in a weird way. This function will look at
the actual buf trans tables we have for HSW/BDW to determine the max
vswing level.

It looks to me like the current code leads HSW port A down the IVB port
A path, HSW port B+ and BDW fall through to the very end. Both cases do
result in the correct max vswing level 2, but it's very hard to see that
from the code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-18 17:23:40 +03:00
Ondrej Zary
7f7105f99b drm/i915: Disable LVDS on Radiant P845
Radiant P845 does not have LVDS, only VGA.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org
2018-05-18 17:23:40 +03:00
Chris Wilson
867985d4a4 drm/i915: Pull the context->pin_count dec into the common intel_context_unpin
As all backends implement the same pin_count mechanism and do a
dec-and-test as their first step, pull that into the common
intel_context_unpin(). This also pulls into the caller, eliminating the
indirect call in the usual steady state case. The intel_context_pin()
side is a little more complicated as it combines the lookup/alloc as
well as pinning the state, and so is left for a later date.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-4-chris@chris-wilson.co.uk
2018-05-18 09:35:28 +01:00
Chris Wilson
1fc44d9b1a drm/i915: Store a pointer to intel_context in i915_request
To ease the frequent and ugly pointer dance of
&request->gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.

v2: Set mock_context->ops so we don't crash and burn in selftests.
    Cleanups from Tvrtko.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-3-chris@chris-wilson.co.uk
2018-05-18 09:35:22 +01:00