Arun Siluvery [Mon, 4 Apr 2016 17:50:56 +0000 (18:50 +0100)]
drm/i915/guc: reset GuC and retry on firmware load failure
Due to timing issues in the HW, some of the status bits required for GuC
authentication occasionally don't get set; when that happens, the GuC
cannot be initialized and we will be left with a wedged GPU. The W/A
suggested is to perform a soft reset of the GuC and attempt to reload
the F/W again for few times before giving up.
As the failure is dependent on timing, tests performed by triggering
manual full gpu reset (i915_wedged) showed that we could sometimes hit
this after several thousand iterations, but sometimes tests ran even
longer without any issues. Reset and reload mechanism proved helpful
when we indeed hit f/w load failure, so it is better to include this
to improve driver stability.
This change implements the following WAs,
WaEnableuKernelHeaderValidFix:skl,bxt
WaEnableGuCBootHashCheckNotSet:skl,bxt
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Tue, 5 Apr 2016 09:22:25 +0000 (10:22 +0100)]
drm/i915/shrinker: Refactor common uninterruptible locking
Both the oom and vmap notifier callbacks have a loop to acquire the
struct_mutex and set the device as uninterruptible, within a certain
time. Refactor the common code into a pair of functions.
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459848145-24042-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Mon, 4 Apr 2016 13:46:43 +0000 (14:46 +0100)]
drm/i915/shrinker: Hook up vmap allocation failure notifier
If the core runs out of vmap address space, it will call a notifier in
case any driver can reap some of its vmaps. As i915.ko is possibily
holding onto vmap address space that could be recovered, hook into the
notifier chain and try and reap objects holding onto vmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Roman Pen <r.peniaev@gmail.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459777603-23618-4-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Mon, 4 Apr 2016 13:46:42 +0000 (14:46 +0100)]
mm/vmap: Add a notifier for when we run out of vmap address space
vmaps are temporary kernel mappings that may be of long duration.
Reusing a vmap on an object is preferrable for a driver as the cost of
setting up the vmap can otherwise dominate the operation on the object.
However, the vmap address space is rather limited on 32bit systems and
so we add a notification for vmap pressure in order for the driver to
release any cached vmappings.
The interface is styled after the oom-notifier where the callees are
passed a pointer to an unsigned long counter for them to indicate if they
have freed any space.
v2: Guard the blocking notifier call with gfpflags_allow_blocking()
v3: Correct typo in forward declaration and move to head of file
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Roman Peniaev <r.peniaev@gmail.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Andrew Morton <akpm@linux-foundation.org> # for inclusion via DRM
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459777603-23618-3-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Mon, 4 Apr 2016 13:46:41 +0000 (14:46 +0100)]
drm/i915/shrinker: Account for unshrinkable unbound pages
Since we only attempt to purge an object if can_release_pages() report
true, we should also only add it to the count of potential recoverable
pages when can_release_pages() is true.
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: Akash Goel <akash.goel@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459777603-23618-2-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Jani Nikula [Fri, 18 Mar 2016 11:11:15 +0000 (13:11 +0200)]
drm/i915/chv: add more IOSF port definitions
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/65d58c578adecc205a741102329bc9c9f6eb79cf.1458299160.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 11:11:10 +0000 (13:11 +0200)]
drm/i915/dsi: add support for DSI sequence block v2 gpio element
In sequence block v2, and only in v2, the gpio source (i.e. IOSF port)
is specified separately.
v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/87152feec8f921dc82502af1b29c0956b0d360bb.1458299160.git.jani.nikula@intel.com
Tvrtko Ursulin [Mon, 4 Apr 2016 11:11:56 +0000 (12:11 +0100)]
drm/i915: Move execlists irq handler to a bottom half
Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.
Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
multi-second periods of complete non-interactivty. That can
look for example like this:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
Modules linked in: [redacted for brevity]
CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183
Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1
Workqueue: i915 gen6_pm_rps_work [i915]
task:
ffff8800aae88000 ti:
ffff8800aae90000 task.ti:
ffff8800aae90000
RIP: 0010:[<
ffffffff8104a3c2>] [<
ffffffff8104a3c2>] __do_softirq+0x72/0x1d0
RSP: 0000:
ffff88014f403f38 EFLAGS:
00000206
RAX:
ffff8800aae94000 RBX:
0000000000000000 RCX:
00000000000006e0
RDX:
0000000000000020 RSI:
0000000004208060 RDI:
0000000000215d80
RBP:
ffff88014f403f80 R08:
0000000b1b42c180 R09:
0000000000000022
R10:
0000000000000004 R11:
00000000ffffffff R12:
000000000000a030
R13:
0000000000000082 R14:
ffff8800aa4d0080 R15:
0000000000000082
FS:
0000000000000000(0000) GS:
ffff88014f400000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007fa53b90c000 CR3:
0000000001a0a000 CR4:
00000000001406f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Stack:
042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a
0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080
0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8
Call Trace:
<IRQ>
[<
ffffffff8104a716>] irq_exit+0x86/0x90
[<
ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50
[<
ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90
<EOI>
[<
ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915]
[<
ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20
[<
ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915]
[<
ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0
[<
ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915]
[<
ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915]
[<
ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915]
[<
ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915]
[<
ffffffff81063852>] ? finish_task_switch+0x72/0x1c0
[<
ffffffff8105ab29>] process_one_work+0x139/0x350
[<
ffffffff8105b186>] worker_thread+0x126/0x490
[<
ffffffff8105b060>] ? rescuer_thread+0x320/0x320
[<
ffffffff8105fa64>] kthread+0xc4/0xe0
[<
ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170
[<
ffffffff814f351f>] ret_from_fork+0x3f/0x70
[<
ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170
I could not explain, or find a code path, which would explain
a +20 second lockup, but from some instrumentation it was
apparent the interrupts off proportion of time was between
10-25% under heavy load which is quite bad.
When a interrupt "cliff" is reached, which was >~320k irq/s on
my machine, the whole system goes into a terrible state of the
above described multi-second lockups.
By moving the GT interrupt handling to a tasklet in a most
simple way, the problem above disappears completely.
Testing the effect on sytem-wide latencies using
igt/gem_syslatency shows the following before this patch:
gem_syslatency: cycles=
1532739, latency mean=416531.829us max=2499237us
gem_syslatency: cycles=
1839434, latency mean=
1458099.157us max=4998944us
gem_syslatency: cycles=
1432570, latency mean=2688.451us max=1201185us
gem_syslatency: cycles=
1533543, latency mean=416520.499us max=2498886us
This shows that the unrelated process is experiencing huge
delays in its wake-up latency. After the patch the results
look like this:
gem_syslatency: cycles=808907, latency mean=53.133us max=1640us
gem_syslatency: cycles=862154, latency mean=62.778us max=2117us
gem_syslatency: cycles=856039, latency mean=58.079us max=2123us
gem_syslatency: cycles=841683, latency mean=56.914us max=1667us
Showing a huge improvement in the unrelated process wake-up
latency. It also shows an approximate halving in the number
of total empty batches submitted during the test. This may
not be worrying since the test puts the driver under
a very unrealistic load with ncpu threads doing empty batch
submission to all GPU engines each.
Another benefit compared to the hard-irq handling is that now
work on all engines can be dispatched in parallel since we can
have up to number of CPUs active tasklets. (While previously
a single hard-irq would serially dispatch on one engine after
another.)
More interesting scenario with regards to throughput is
"gem_latency -n 100" which shows 25% better throughput and
CPU usage, and 14% better dispatch latencies.
I did not find any gains or regressions with Synmark2 or
GLbench under light testing. More benchmarking is certainly
required.
v2:
* execlists_lock should be taken as spin_lock_bh when
queuing work from userspace now. (Chris Wilson)
* uncore.lock must be taken with spin_lock_irq when
submitting requests since that now runs from either
softirq or process context.
v3:
* Expanded commit message with more testing data;
* converted missed locking sites to _bh;
* added execlist_lock comment. (Chris Wilson)
v4:
* Mention dispatch parallelism in commit. (Chris Wilson)
* Do not hold uncore.lock over MMIO reads since the block
is already serialised per-engine via the tasklet itself.
(Chris Wilson)
* intel_lrc_irq_handler should be static. (Chris Wilson)
* Cancel/sync the tasklet on GPU reset. (Chris Wilson)
* Document and WARN that tasklet cannot be active/pending
on engine cleanup. (Chris Wilson/Imre Deak)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Testcase: igt/gem_exec_nop/all
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1459768316-6670-1-git-send-email-tvrtko.ursulin@linux.intel.com
Chris Wilson [Sun, 3 Apr 2016 20:59:14 +0000 (21:59 +0100)]
drm/i915/ddi: Silence compiler warning for unknown output type
Silences
src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized]
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1459717154-27607-1-git-send-email-chris@chris-wilson.co.uk
Chris Wilson [Sun, 3 Apr 2016 13:14:21 +0000 (14:14 +0100)]
drm/i915: Show PCI power state under debugfs/i915_runtime_pm_status
As the current PCI power state is an essential feature of runtime pm,
include it in the debugfs/i915_runtime_pm_status.
v2: Use pci_power_name()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-2-git-send-email-chris@chris-wilson.co.uk
Chris Wilson [Sun, 3 Apr 2016 13:14:20 +0000 (14:14 +0100)]
drm/i915: Add struct_mutex locking for debugs/i915_gem_framebuffer
Since describe_obj() looks at state guarded by the struct_mutex, we need
to be holding it.
[ 580.201054] drv_suspend: starting subtest debugfs-reader
[ 580.239652] ------------[ cut here ]------------
[ 580.239696] WARNING: CPU: 0 PID: 920 at include/linux/list_check.h:25 describe_obj+0x419/0x440()
[ 580.239725] CPU: 0 PID: 920 Comm: cat Not tainted 4.5.0-rc6+ #835
[ 580.239745] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 580.239767]
0000000000000000 ffff88027554fcf8 ffffffff812c1135 0000000000000000
[ 580.239815]
ffffffff8193dc42 ffff88027554fd30 ffffffff8107419d ffff880071727c00
[ 580.239858]
ffff8802757d8000 ffffffff818f693c ffffffff818f693c ffff8802757b9048
[ 580.239896] Call Trace:
[ 580.239917] [<
ffffffff812c1135>] dump_stack+0x67/0x92
[ 580.239939] [<
ffffffff8107419d>] warn_slowpath_common+0x7d/0xb0
[ 580.239959] [<
ffffffff810742ba>] warn_slowpath_null+0x1a/0x20
[ 580.239981] [<
ffffffff813ce579>] describe_obj+0x419/0x440
[ 580.240006] [<
ffffffff813ced22>] i915_gem_framebuffer_info+0xa2/0x100
[ 580.240033] [<
ffffffff811a9286>] seq_read+0xe6/0x3b0
[ 580.240059] [<
ffffffff81182288>] __vfs_read+0x28/0xd0
[ 580.240085] [<
ffffffff81173378>] ? SyS_fadvise64+0x228/0x2c0
[ 580.240112] [<
ffffffff811823b2>] vfs_read+0x82/0x110
[ 580.240137] [<
ffffffff811827d9>] SyS_read+0x49/0xa0
[ 580.240162] [<
ffffffff815bac57>] entry_SYSCALL_64_fastpath+0x12/0x6b
[ 580.240187] ---[ end trace
3e2cbf34576c9878 ]---
[ 580.281900] ------------[ cut here ]------------
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-1-git-send-email-chris@chris-wilson.co.uk
Ville Syrjälä [Mon, 21 Mar 2016 14:43:22 +0000 (14:43 +0000)]
drm/i915: Fix plane init failure paths
Deal with errors from drm_universal_plane_init() in primary and cursor
plane init paths (sprites were already covered). Also make the code
neater by using goto for error handling.
v2: Rebased due to drm_universal_plane_init() 'name' parameter
v3: Another rebase due to s/""/NULL/
v4: Rebased on drm-nightly (Matthew Auld)
v5: Fix email address (Matthew Auld)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458571402-32749-1-git-send-email-matthew.auld@intel.com
Ville Syrjälä [Tue, 15 Mar 2016 14:39:59 +0000 (16:39 +0200)]
drm/i915: Remove the "three times for luck" trick from vlv_enable_pll()
VLV DPLL is somewhat sane and doesn't run on luck.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-7-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 15 Mar 2016 14:39:58 +0000 (16:39 +0200)]
drm/i915: assert_panel_unlocked() in chv_enable_pll()
Supposedly the power sequencer still locks out the DPLL registers on
CHV, so let's issue a warning if it's still locked when enabling the
DPLL.
Also drop the redundant IS_MOBILE() check for VLV when we check the same
thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-6-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 15 Mar 2016 14:39:57 +0000 (16:39 +0200)]
drm/i915: Add a local pipe variable to vlv_enable_pll()
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local
pipe variable. Also makes it look more like the corresponding CHV code.
While at is change the CHV code to enum pipe from int,
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 15 Mar 2016 14:39:56 +0000 (16:39 +0200)]
drm/i915: Implement WaPixelRepeatModeFixForC0:chv
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.
Fortunately the pixel repeat propagation appears to be a oneshot
operation, so once the value has been written we can clear the
chicken bits. So it is still possible to drive pipe B and C with
different pixel multipliers simultaneosly.
Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
for this to work. But since we keep that bit always set in all
DPLLs there's no problem.
This of course means we can't reliably read out the pixel multiplier
for pipes B and C. That would make the state checker unhappy, so I
added shadow copies of those registers in to dev_priv. The other
option would have been to skip pixel multiplier, dpll_md an dotclock
checks entirely on CHV, but that feels like a serious loss of cross
checking, so just pretending that we have working DPLL MD registers
seemed better. Obviously with the shadow copies we can't detect if
the pixel multiplier was properly configured, nor can we take over
its state from the BIOS, but hopefully people won't have displays
that would be limitd to such crappy modes.
There is one strange flicker still remaining. It's visible on
pipe C/HDMID when HDMIB is enabled while driven by pipe B.
It doesn't occur if pipe A drives HDMIB, nor is there any glitch
on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
with HDMIC so not sure if it happens there too. So I'm not sure
if it's somehow tied in with this strange linkage between pipe B
and C. Sadly I was unable to find an enable sequence that would
avoid the glitch, but at least it's not fatal ie. the output
recovers afterwards.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 15 Mar 2016 14:39:55 +0000 (16:39 +0200)]
drm/i915: Make {vlv,chv}_{disable,update}_pll() more similar
The VLV and CHV DPLL disable and update are almost identical in
how the DPLL/DPLL_MD registers need to be set up. But the code
looks more different than it really is. Try to bring them into
line.
Note that we now leave the refclock always enabled for both
DPLLs in the dual channel PHY. But that's perfectly fine since
it's the same clock, and we anyway already do that when turning
the disp2d power well on.
v2: s/chv_update_pll/chv_compute_dpll/
v3: Add a note that we leave refclocks enabled for both DPLLs (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 15 Mar 2016 14:39:54 +0000 (16:39 +0200)]
drm/i915: Throw out BUGs from DPLL/PCH functions
These BUGs don't serve any purpose IMO. Throw them out.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 1 Mar 2016 14:16:23 +0000 (16:16 +0200)]
drm/i915: Disable FDI RX before DDI_BUF_CTL
Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
FDI RX disable both as step 13 and step 18 in the sequence. But I dug
up an old BUN mail from Art that moved the FDI RX disable to happen
before DDI_BUF_CTL disable. That BUN did not renumber the steps and just
added a note:
"Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."
The BUN described the symptoms of the fixed issue as:
"PCH display underflow and a black screen on the analog CRT port that
happened after a FDI re-train"
I suppose later someone tried to renumber the steps to match, but forgot
to remove the FDI RX disable from its old position in the sequence.
They also forgot to update the note describing what should be done in
case of an FDI training failure. Currently it says:
"To retry FDI training, follow the Disable Sequence steps to Disable FDI,
but skip the steps related to clocks and PLLs (16, 19, and 20), ..."
It should really say "17, 20, and 21" with the current sequence because
those are the steps that deal with PLLs and whatnot, after step 13 became
FDI RX disable. And had the step 18 FDI RX disable been removed, as I
suspect it should have, the note should actually say "17, 19, and 20".
So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable,
as that would appear to be the correct order based on the BUN.
Note that Art has since unconfused the spec, and so this patch should
now match the steps listed in the spec.
v2: Add a note that the spec is now correct
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456841783-4779-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Joonas Lahtinen [Fri, 1 Apr 2016 11:41:01 +0000 (14:41 +0300)]
Revert "drm/i915: Fix races on fbdev"
This reverts commit
a7442b93cf32c1e1ddb721a26cd1f92302e2a222.
With the patch applied SNB, IVB and ILK are experiencing hard machine
hangs. Original patch was to fix "just" kernel panics so it's not a good
trade-off.
Proper fix for the panic is on the way, lets revert until then.
Fixes: a7442b93cf32 ("drm/i915: Fix races on fbdev")
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Lukas Wunner <lukas@wunner.de>
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459510861-29035-1-git-send-email-joonas.lahtinen@linux.intel.com
Jani Nikula [Fri, 18 Mar 2016 11:11:09 +0000 (13:11 +0200)]
drm/i915/dsi: refer to gpio index instead of gpio to avoid confusion
The DSI sequence blocks contain gpio index references, not actual gpio
numbers. No functional changes.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/4a54778e56b507e8a0bd635ba02ed2a4734b00ac.1458299160.git.jani.nikula@intel.com
Jani Nikula [Fri, 1 Apr 2016 07:44:41 +0000 (10:44 +0300)]
drm/i915: use for_each_port_masked in bxt phy init for clarity
Make it easier to see which ports are configured for each phy. No
functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459496681-398-1-git-send-email-jani.nikula@intel.com
Vandana Kannan [Thu, 31 Mar 2016 17:45:54 +0000 (23:15 +0530)]
drm/i915: BXT DDI PHY sequence BUN
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.
v2: [Ville] use wait_for_us instead of the atomic call.
v3: [Jani/Imre] read register only once
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reported-by: Philippe Lecluse <Philippe.Lecluse@intel.com>
Cc: Deak, Imre <imre.deak@intel.com>
Cc: Nikula, Jani <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459446354-19012-1-git-send-email-vandana.kannan@intel.com
Shubhangi Shrivastava [Wed, 30 Mar 2016 12:35:26 +0000 (18:05 +0530)]
drm/i915: force full detect on sink count change
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
return immediately if perform_full_detect is set(Siva)
v3: changed method of determining full detection from using
pointer to return code (Siva)
v4: changed comments to indicate meaning of return value of
intel_dp_short_pulse and explain the use of return value
from intel_dp_get_dpcd in intel_dp_short_pulse (Ander)
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-5-git-send-email-shubhangi.shrivastava@intel.com
Shubhangi Shrivastava [Wed, 30 Mar 2016 12:35:25 +0000 (18:05 +0530)]
drm/i915: Read sink_count dpcd always
Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.
SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.
Here is a table of possible values and scenarios
sink_count downstream_port
present
0 0 no display is attached
0 1 dongle is connected without display
1 0 display connected directly
1 1 display connected through dongle
v2: Storing value of intel_dp->sink_count that is ready
for consumption. (Ander)
Squashing two commits into one. (Ander)
v3: Added comment to explain the need of early return when
sink count is 0. (Ander)
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com
Shubhangi Shrivastava [Wed, 30 Mar 2016 12:35:24 +0000 (18:05 +0530)]
drm/i915: Reorganizing intel_dp_check_link_status
When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and handle all logic for
short pulse handling while intel_dp_check_link_status()
will retain its original purpose of only doing link
status related work.
intel_dp_short_pulse: All existing code other than
link status read and link training upon error status.
intel_dp_check_link_status:
The link status should be read on short pulse
irrespective of panel being enabled or not so
intel_dp_get_link_status() performs dpcd read first
then based on crtc active / enabled it will
perform the link training.
This is because short pulse is a generic interrupt
which should always be handled, because it may mean:
1. Hotplug/unplug of MST panel
2. Hotplug/unplug of dongle
3. Link status change for other DP panels
v2: Added WARN_ON to intel_dp_check_link_status()
Removed a call to intel_dp_get_link_status() (Ander)
v3: Changed commit message to explain need of link status
being read before performing encoder checks (Daniel)
v4: Changed commit message to explain need of reading
link status on short pulse (Ander)
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis alignment]
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-3-git-send-email-shubhangi.shrivastava@intel.com
Shubhangi Shrivastava [Wed, 30 Mar 2016 12:35:23 +0000 (18:05 +0530)]
drm/i915: Cleaning up intel_dp_hpd_pulse
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD operations
in one single function and make intel_dp_detect
use existing values instead of repeating same steps.
v2: Pulled in a hunk from last patch of the series to
this patch. (Ander)
v3: Added MST hotplug handling. (Ander)
v4: Added a flag to check if detect is performed to
prevent multiple detects on hotplug. (Ander)
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis aligment]
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-2-git-send-email-shubhangi.shrivastava@intel.com
Shubhangi Shrivastava [Wed, 30 Mar 2016 12:35:22 +0000 (18:05 +0530)]
drm/i915: Splitting intel_dp_detect
intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note that the behavior of intel_dp_detect() is changed to
report connected or disconnected depending on whether the
EDID is available or not.
This change will be required by further patches in the series
to avoid performing duplicated DPCD operations on hotplug.
v2: Moved a hunk to next patch of the series.
Moved intel_dp_unset_edid to out. (Ander)
v3: Rephrased commit message and intel_dp_unset_dp() is called
within intel_dp_set_dp() to free the previous EDID. (Ander)
v4: Added overriding of status to disconnected for MST. (Ander)
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis alignment]
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-1-git-send-email-shubhangi.shrivastava@intel.com
Joonas Lahtinen [Wed, 30 Mar 2016 13:57:10 +0000 (16:57 +0300)]
drm/i915: Refer to GGTT {,VM} consistently
Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt",
"vm" or indirectly through other variables like "dev_priv->ggtt.base"
to avoid confusion with the i915_ggtt object itself and PPGTT VMs.
Refer to the GGTT as "ggtt" instead of indirectly through chaining.
As a bonus gets rid of the long-standing i915_obj_to_ggtt vs.
i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt!
v2:
- Added some more after grepping sources with Chris
v3:
- Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm
(Chris)
v4:
- Convert all dev_priv->ggtt->foo accesses to ggtt->foo.
v5:
- Make patch checker happy
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Maarten Lankhorst [Wed, 30 Mar 2016 15:16:36 +0000 (17:16 +0200)]
drm/i915: Update color management during vblank evasion.
Without this a vblank may occur between updating color management
and planes, which should be prevented.
intel_color_set_csc was called in update pipe config because the
handover from hardware may not have any csc set, which resulted
in a black screen. Because of this also update color management
during fastset.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459350996-4957-4-git-send-email-maarten.lankhorst@linux.intel.com
[mlankhorst: Remove comment in response to review feedback.]
Maarten Lankhorst [Wed, 30 Mar 2016 15:16:35 +0000 (17:16 +0200)]
drm/i915: Do not check crtc_state->active in intel_color_load_luts.
This is already tested by its callers.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459350996-4957-3-git-send-email-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Wed, 30 Mar 2016 15:16:34 +0000 (17:16 +0200)]
drm/i915: Pass crtc_state to color management functions.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459350996-4957-2-git-send-email-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Wed, 23 Mar 2016 13:51:12 +0000 (14:51 +0100)]
drm/i915: Add locking to pll updates, v3.
With async modesets this is no longer protected with connection_mutex,
so ensure that each pll has its own lock. The pll configuration state
is still protected; it's only the pll updates that need locking against
concurrency.
Changes since v1:
- Rebased.
- Fix locking to protect all accesses. (Durgadoss)
Changes since v2:
- Make the dpll_lock global to protect concurrent updates to the
same register, for example DPLL_CTRL1 on skl. (Ander)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56F29F50.1090708@linux.intel.com
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Daniel Vetter [Wed, 30 Mar 2016 09:34:36 +0000 (11:34 +0200)]
drm/i915: Remove PIPE_CONF_CHECK_I_ALT
And move the comment to the right macro. This was mixed up in
commit
cfb23ed622d040619abb91e625fcba74d356b8a8
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Jul 14 12:17:40 2015 +0200
drm/i915: Allow fuzzy matching in pipe_config_compare, v2
v2: Rebase.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330476-32453-1-git-send-email-daniel.vetter@ffwll.ch
Rodrigo Vivi [Wed, 30 Mar 2016 14:58:01 +0000 (07:58 -0700)]
drm/i915/kbl: Remove preliminary_hw_support protection from KBL.
We now have KBL machines running in our CI systems and with no
blocking issues that could cause a full hangs or blank screens.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459349881-951-1-git-send-email-rodrigo.vivi@intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Mon, 14 Mar 2016 09:01:57 +0000 (09:01 +0000)]
drm/i915: Exit cherryview_irq_handler() after one pass
This effectively reverts
commit
8e5fd599eb219f1054e39b40d18b217af669eea9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 9 13:28:50 2014 +0300
drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed
as under continuous execlists load we can saturate the IRQ handler,
destablising the tsc clock and triggering the NMI watchdog to declare a hung
CPU.
[ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
[ 552.756080] clocksource: 'refined-jiffies' wd_now:
10003b480 wd_last:
10003b28c mask:
ffffffff
[ 552.756091] clocksource: 'tsc' cs_now:
d55d31aa50 cs_last:
d17446166c mask:
ffffffffffffffff
[ 552.756210] clocksource: Switched to clocksource refined-jiffies
[ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18
[ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 575.217915]
0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000
[ 575.217935]
0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000
[ 575.217951]
ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e
[ 575.217967] Call Trace:
[ 575.217973] <NMI> [<
ffffffff81288c6d>] dump_stack+0x4f/0x72
[ 575.217994] [<
ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160
[ 575.218003] [<
ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0
[ 575.218016] [<
ffffffff811154c4>] perf_event_overflow+0x14/0x20
[ 575.218028] [<
ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460
[ 575.218042] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218052] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218064] [<
ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50
[ 575.218075] [<
ffffffff81007540>] nmi_handle+0x60/0x130
[ 575.218086] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218096] [<
ffffffff810079c0>] do_nmi+0x140/0x470
[ 575.218108] [<
ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e
[ 575.218119] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218129] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218139] [<
ffffffff814a8aae>] ? poll_idle+0x3e/0x70
[ 575.218148] <<EOE>> [<
ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0
[ 575.218164] [<
ffffffff814a8587>] cpuidle_enter+0x17/0x20
[ 575.218175] [<
ffffffff810aaa3a>] call_cpuidle+0x2a/0x40
[ 575.218185] [<
ffffffff810aade3>] cpu_startup_entry+0x273/0x330
[ 575.218196] [<
ffffffff81033a1e>] start_secondary+0x10e/0x130
However, not servicing all available IIR within the handler does hurt the
throughput of pathological nop execbuf by about 20%, with a similar effect
upon the dispatch latency of a series of execbuf.
v2: use do {} while(0) for a smaller patch, and easier to revert again
I have reasonable confidence that we do not miss GT interrupts (as
execlists provides a stress case with a failure mechanism easily
detected by igt), however I have less confidence about all the other
sources of interrupts and worry that may lose a display hotplug
interrupt, for example.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467
Testcase: igt/gem_exec_nop/basic # requires NMI watchdog
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Antti Koskipää <antti.koskipaa@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk
Chris Wilson [Thu, 24 Mar 2016 14:31:47 +0000 (14:31 +0000)]
drm/i915: Rename __force_wake_get to __force_wake_auto
__force_wake_get() only acquires a temporary wakeref on forcewake that is
automatically released when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get() for __force_wake_get()
and to my shame thought I found a bug in unbalanced wake_count handling.
I claim that if the function had been called __force_wake_auto() instead
I would not have embarrassed myself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458829907-26596-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Joonas Lahtinen [Thu, 24 Mar 2016 14:47:46 +0000 (16:47 +0200)]
drm/i915: Rename GGTT init functions
Rename and document the GGTT init functions to give a better
idea of the context where they are called from.
i915_gem_gtt_init => i915_ggtt_init_hw
i915_gem_init_global_gtt => i915_gem_init_ggtt
i915_global_gtt_cleanup => i915_ggtt_cleanup_hw
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458830866-12578-1-git-send-email-joonas.lahtinen@linux.intel.com
Matthew Auld [Thu, 24 Mar 2016 15:54:20 +0000 (15:54 +0000)]
drm/i915: BUG_ON when ggtt_view is NULL
Lets BUG_ON and don't bother with a WARN and returning an error, so we can
remove the need to pollute the code with error handling, after all it is
a programmer error to provide NULL view. Also while we're here remove
redundant NULL ggtt_view check.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834860-7898-1-git-send-email-matthew.auld@intel.com
Bjørn Mork [Wed, 30 Mar 2016 09:08:33 +0000 (11:08 +0200)]
drm/i915: fix deadlock on lid open
commit
e2c8b8701e2d moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:
=============================================
[ INFO: possible recursive locking detected ]
4.6.0-rc1 #385 Not tainted
---------------------------------------------
kworker/0:3/88 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<
ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
but task is already holding lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<
ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&dev->mode_config.mutex);
lock(&dev->mode_config.mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by kworker/0:3/88:
#0: ("kacpi_notify"){++++.+}, at: [<
ffffffff81068dfc>] process_one_work+0x14a/0x50b
#1: ((&dpc->work)#2){+.+.+.}, at: [<
ffffffff81068dfc>] process_one_work+0x14a/0x50b
#2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<
ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
#3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<
ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
#4: (&dev->mode_config.mutex){+.+.+.}, at: [<
ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
#5: (crtc_ww_class_acquire){+.+.+.}, at: [<
ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
#6: (crtc_ww_class_mutex){+.+.+.}, at: [<
ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]
stack backtrace:
CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
Workqueue: kacpi_notify acpi_os_execute_deferred
0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
Call Trace:
[<
ffffffff8124af06>] dump_stack+0x67/0x90
[<
ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
[<
ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
[<
ffffffff8108fae2>] lock_acquire+0x137/0x1cb
[<
ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
[<
ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<
ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
[<
ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<
ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<
ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<
ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
[<
ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<
ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<
ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<
ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
[<
ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
[<
ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
[<
ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
[<
ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
[<
ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
[<
ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
[<
ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
[<
ffffffff812b07df>] acpi_device_notify+0x19/0x1b
[<
ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
[<
ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
[<
ffffffff81068f17>] process_one_work+0x265/0x50b
[<
ffffffff810696f5>] worker_thread+0x1fc/0x2dd
[<
ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<
ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<
ffffffff8106e2d6>] kthread+0xe0/0xe8
[<
ffffffff8107bc47>] ? local_clock+0x19/0x22
[<
ffffffff81484f42>] ret_from_fork+0x22/0x40
[<
ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
Daniel Vetter [Wed, 30 Mar 2016 07:33:11 +0000 (09:33 +0200)]
drm/i915: Update DRIVER_DATE to
20160330
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Lyude [Fri, 11 Mar 2016 15:57:01 +0000 (10:57 -0500)]
drm/i915: Call intel_dp_mst_resume() before resuming displays
Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.
This order was originally changed in
commit
e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.
CC: stable@vger.kernel.org
Signed-off-by: Lyude <cpaul@redhat.com>
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Lukas Wunner [Wed, 9 Mar 2016 11:52:53 +0000 (12:52 +0100)]
drm/i915: Fix races on fbdev
The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.
We might likewise receive hotplug events before we've had a chance to
fully set up the fbdev.
Fix by waiting for the asynchronous thread to finish.
v2:
An async_synchronize_full() was also added to intel_fbdev_set_suspend()
in v1 which turned out to be entirely gratuitous. It caused a deadlock
on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
for CI support) and was unnecessary since a device is never suspended
until its ->probe callback (and all asynchronous tasks it scheduled)
have finished. See dpm_prepare(), which calls wait_for_device_probe(),
which calls async_synchronize_full().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind <gustav.fagerlind@gmail.com>
Reported-by: "Li, Weinan Z" <weinan.z.li@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org
Jani Nikula [Thu, 24 Mar 2016 15:50:23 +0000 (17:50 +0200)]
drm/i915: remove unused dev_priv->render_reclock_avail
Set from VBT, but never used. Good riddance.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-5-git-send-email-jani.nikula@intel.com
Jani Nikula [Thu, 24 Mar 2016 15:50:22 +0000 (17:50 +0200)]
drm/i915: move sdvo mappings to vbt data
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-4-git-send-email-jani.nikula@intel.com
Jani Nikula [Thu, 24 Mar 2016 15:50:21 +0000 (17:50 +0200)]
drm/i915: move edp low vswing config to vbt data
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-3-git-send-email-jani.nikula@intel.com
Jani Nikula [Thu, 24 Mar 2016 15:50:20 +0000 (17:50 +0200)]
drm/i915: use a substruct in vbt data for edp
Housekeeping, similar to psr, backlight, and dsi. No functional changes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-2-git-send-email-jani.nikula@intel.com
Dave Gordon [Thu, 24 Mar 2016 11:20:38 +0000 (11:20 +0000)]
drm/i915: replace for_each_engine()
Having provided for_each_engine_id() for cases where the third (id)
argument is useful, we can now replace all the remaining instances with
a simpler version that takes only two parameters. In many cases, this
also allows the elimination of the local variable used in the iterator
(usually 'i').
v2:
s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson]
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458757194-17783-2-git-send-email-david.s.gordon@intel.com
Dave Gordon [Wed, 23 Mar 2016 18:19:53 +0000 (18:19 +0000)]
drm/i915: introduce for_each_engine_id()
Equivalent to the existing for_each_engine() macro, this will replace
the latter wherever the third argument *is* actually wanted (in most
places, it is not used). The third argument is renamed to emphasise
that it is an engine id (type enum intel_engine_id). All the callers of
the macro that actually need the third argument are updated to use this
version, and the argument (generally 'i') is also updated to be 'id'.
Other callers (where the third argument is unused) are untouched for
now; they will be updated in the next patch.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Thu, 24 Mar 2016 10:41:40 +0000 (12:41 +0200)]
drm/i915/bxt: Fix DSI HW state readout
Currently the machine hangs during booting while accessing the
BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
experimentation I found that the hang is caused by the DSI PLL being
disabled, or it being enabled but with an incorrect divider
configuration. Enabling the PLL got rid of the boot problem, so fix
this by checking the PLL enabled state/configuration before attempting
to read out the HW state.
The DSI_PLL_ENABLE register is in the always-on power well, while the
BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
transcoder power domain, but what we really need is just a runtime PM
reference, which is provided by any power domain.
Ville also found this dependency specified in BSpec, so I added a
reference to that too.
v2:
- Make sure we hold a power reference while accessing the PLL registers.
v3: (Jani)
- Simplify check in bxt_get_dsi_transcoder_state()
- Add comment explaining why we check for valid dividers in
bxt_dsi_pll_is_enabled()
CC: Shashank Sharma <shashank.sharma@intel.com>
CC: Uma Shankar <uma.shankar@intel.com>
CC: Jani Nikula <jani.nikula@intel.com>
Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458816100-31269-1-git-send-email-imre.deak@intel.com
Maarten Lankhorst [Wed, 23 Mar 2016 13:33:28 +0000 (14:33 +0100)]
drm/i915: Remove vblank wait from hsw_enable_ips, v2.
intel_post_plane_update did an extra vblank wait that's no longer needed when enabling ips.
Changes since v1:
- Add comment explaining why vblank wait is performed. (Paulo)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/56F29B28.5070804@linux.intel.com
Chris Wilson [Fri, 20 Nov 2015 10:27:18 +0000 (10:27 +0000)]
drm/i915: Tidy aliasing_gtt_bind_vma()
In commit
0a878716265e9af9f697264dc2e858fcc060d833
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 15 14:23:01 2015 +0200
drm/i915: restore ggtt double-bind avoidance
we wrote the ggtt_bind_vma() observing a number of cleanups we could do
over the template of aliasing_gtt_bind_vma(). Now let's apply the
cleanups we made there back to the original. The essence is to avoid
redundant variables and assignements, and by doing so make the code
easier to read.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448015238-24639-1-git-send-email-chris@chris-wilson.co.uk
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:16 +0000 (18:00 +0200)]
drm/i915: Split PNV version of crtc_compute_clock()
Split a pnv_crtc_compute_clock(), so the differences between platforms
become more obvious.
With this, there are no more users of intel_limit() or the ->find_dpll()
hook, so get rid of them.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-16-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:15 +0000 (18:00 +0200)]
drm/i915: Split g4x_crtc_compute_clock()
Split a G4X specific version from i9xx_crtc_compute_clock(). With this
the differences between platforms become more obvious.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-15-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Tue, 22 Mar 2016 13:35:23 +0000 (15:35 +0200)]
drm/i915: Split i8xx_crtc_compute_clock()
Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this
there is no need for i9xx_get_refclk() anymore, and the differences
between platforms become more obvious.
v2: Use i8xx as prefix instead of gen2. (Ville and Daniel)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458653723-17951-1-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:13 +0000 (18:00 +0200)]
drm/i915: Split CHV and VLV specific crtc_compute_clock() hooks
In order for VLV and CHV to use i9xx_crtc_compute_clocks(), a number
of if ladders is necessary: one for setting the find_dpll() hook, one
for choosing the limits struct, one for choosing the right compute dpll
function and one for initializing the crtc_compute_clock() hook.
By extracting a platform specific implementation for each platform, the
number of if-ladders is reduced to one.
While at it also clean up bxt_find_best_dpll() which depends on some of
the CHV code.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-13-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:12 +0000 (18:00 +0200)]
drm/i915: Merge ironlake_compute_clocks() and ironlake_crtc_compute_clock()
Merge ironlake_compute_clocks() into ironlake_crtc_compute_clock() so
the clock computation logic is all in one place. The resulting function
is still quite simple. Follow up patches will make the similar code for
GMCH platforms look similar.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-12-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:11 +0000 (18:00 +0200)]
drm/i915: Move fp divisor calculation into ironlake_compute_dpll()
Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and
move the lower level details of setting crtc_state->dpll_hw_state into
the _compute_dpll() function.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-11-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:10 +0000 (18:00 +0200)]
drm/i915: Pass crtc_state->dpll directly to ->find_dpll()
When calculating clocks, just pass a pointer to crtc_state->dpll
directly to the find_dpll() hook. Back when this was introduced in
commit
f47709a9502f3 ("drm/i915: create pipe_config->dpll for clock
state") there was no staged crtc config or atomic crtc state, so it was
possible to overwrite the current configuration on error. That hasn't
been the case for a while now, so finally make it "disappear".
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-10-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:09 +0000 (18:00 +0200)]
drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case
None of the code in ironlake_crtc_compute_clock() is relevant for CPU
eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off}
from the DP code and that doesn't depend on the crtc_state->dpll values,
so just return early in that case.
v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-9-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:08 +0000 (18:00 +0200)]
drm/i915: Remove PCH type checks from ironlake_crtc_compute_clock()
The checks were added in commit
5dc5298bb3e5 ("drm/i915: add proper
CPU/PCH checks to crtc_mode_set functions") in a time when there was
doubts on what PCHs would be supported by HSW. There are similar checks
for PCH type in intel_detect_pch() and the function pointers are
initialized based on platform/pch information, so the removed WARN can't
ever be reached.
v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-8-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:07 +0000 (18:00 +0200)]
drm/i915: Don't calculate a new clock in ILK+ code if it is already set
Remove the clock calculation from ironlake_crtc_compute_clock() when the
encoder compute_config() already set one. The value was just thrown away
in that case.
Note that the previously set clock is not validated against the limits
anymore. That is ok since the fixed clocks from DP and SDVO are within
the supported range, so the call to ironlake_compute_clocks() would
never fail in that case.
v2: Add note about not checking fixed clocks agains limits. (Maarten)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-7-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:06 +0000 (18:00 +0200)]
drm/i915: Simplify ironlake reduced clock logic a bit
Check has_reduced_clock only once when setting dpll_hw_state, making the
code slightly more readable.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-6-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:05 +0000 (18:00 +0200)]
drm/i915: Call g4x_find_best_dpll() directly from ILK+ code
The call to dev_priv->display.find_dpll() is already in platform
specific code, so avoid the extra detour.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-5-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:04 +0000 (18:00 +0200)]
drm/i915: Fold intel_ironlake_limit() into clock computation function
The function intel_ironlake_limit() is only called by the crtc compute
clock path. By merging it into ironlake_compute_clocks(), the code gets
clearer, since there's no more if-ladders to follow.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-4-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:03 +0000 (18:00 +0200)]
drm/i915: Merge ironlake_get_refclk() into its only caller
A previous patch made ironlake_get_refclk() very simple, so merge
it into its only caller.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-3-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Mon, 21 Mar 2016 16:00:02 +0000 (18:00 +0200)]
drm/i915: Remove checks for cloned config with LVDS in dpll code
LVDS is not cloneable, so the check is unnecessary. Removing it makes
the code neater.
v2: Remove checks from GMCH code too, not only ILK+. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-2-git-send-email-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Tue, 22 Mar 2016 08:11:24 +0000 (10:11 +0200)]
drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only
The wait for other gens was added in commit
564ed191f5d8 ("drm/i915:
gmch: fix stuck primary plane due to memory self-refresh mode") since
that's necessary when disabling cxsr. However, cxsr disabling was later
moved to intel_pre_disable_primary() in commit
87d4300a7dbc ("drm/i915:
Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use
it there.") and that function got its own vblank wait for cxsr in commit
262cd2e154c2 ("drm/i915: CHV DDR DVFS support and another watermark
rewrite"). So remove the extra vblank wait from i9xx_crtc_distable().
Cc: Kalyan Kondapally <kalyan.kondapally@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458634284-6080-1-git-send-email-ander.conselvan.de.oliveira@intel.com
Mika Kuoppala [Wed, 23 Mar 2016 08:31:46 +0000 (10:31 +0200)]
drm/i915: Fix use after free when printing load failure
Commit
d15d7538c6d2 ("drm/i915: Tune down init error message due
to failure injection") added i915_load_error message to failure
path on device initialization. The message is printed
after the device is freed. And as the message printing helper
uses the device structure, this leads to use after free.
Spotted by Kasan.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/1458721906-10625-1-git-send-email-mika.kuoppala@intel.com
Shashank Sharma [Tue, 22 Mar 2016 10:01:50 +0000 (12:01 +0200)]
drm/i915/bxt: Initialize MIPI DSI for BXT
This patch contains following changes:
1. Add BXT MIPI display address base.
2. Call dsi_init from display_setup function.
v2: Rebased on latest nightly branch
v3 by Jani: init dsi after ddi
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458640910-5338-1-git-send-email-jani.nikula@intel.com
Imre Deak [Mon, 21 Mar 2016 15:08:57 +0000 (17:08 +0200)]
drm/i915: Make __i915_printk debug output behave the same as DRM_DEBUG_DRIVER
Joonas and Daniel remarked that our debugging output should stay compatible
with the core DRM's debug facility. The recently added __i915_printk() would
output debug messages even if debugging is completely disabled via the
drm.debug option. To fix this make __i915_printk behave the same as
DRM_DEBUG_DRIVER in this case.
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458572937-21712-1-git-send-email-imre.deak@intel.com
Matt Roper [Fri, 4 Mar 2016 23:59:39 +0000 (15:59 -0800)]
drm/i915: Wait until after wm optimization to drop runtime PM reference
At the end of an atomic commit, we currently wait for vblanks to
complete, call put() on the various runtime PM references, and then try
to optimize our watermarks (on platforms that need two-step watermark
programming). This can lead to watermark registers being programmed
while the power well is powered down. We need to wait until after
watermark optimization is complete before dropping our runtime power
references.
Note that in the future the watermark optimization is probably going to
move to an asynchronous workqueue task that happens at some arbitrary
point after vblank. When we make that change, we'll no longer
necessarily be operating under the power reference held here, so we'll
need to wrap the watermark register programmin in a call to
intel_runtime_pm_get_if_in_use() or similar.
Cc: arun.siluvery@linux.intel.com
Cc: ville.syrjala@linux.intel.com
Cc: maarten.lankhorst@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94349
Fixes: ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming (v11)")
Signed-off-by: Matt Roper <matthew.d.roper@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/1457135979-23727-1-git-send-email-matthew.d.roper@intel.com
arun.siluvery@linux.intel.com [Fri, 18 Mar 2016 20:07:55 +0000 (20:07 +0000)]
drm/i915/tdr: Prepare error handler to accept mask of hung engines
In preparation for engine reset, the wedged argument of i915_handle_error()
is extended to reflect as a mask of engines that are hung. This is further
passed down to error state capture functions which are also updated.
Engine reset recovery mechanism uses this mask and schedules recovery work
for those particular engines.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331676-567-3-git-send-email-arun.siluvery@linux.intel.com
Tomas Elf [Mon, 21 Mar 2016 16:26:59 +0000 (16:26 +0000)]
drm/i915/tdr: Initialize hangcheck struct for each engine
Initialize hangcheck struct during driver load. Since we do the same after
recovering from a reset, this is extracted into a helper function.
v2: remove redundant hangcheck init during load as this is done when
engines are initialized (Chris)
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458577619-12006-1-git-send-email-arun.siluvery@linux.intel.com
Lionel Landwerlin [Wed, 16 Mar 2016 10:57:17 +0000 (10:57 +0000)]
drm/i915: Implement color management on chv
Patch based on a previous series by Shashank Sharma.
v2: Update contributors
v3: Refactor degamma/gamma LUTs load into a single function
v4: Remove unused variable
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-5-git-send-email-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Wed, 16 Mar 2016 10:57:16 +0000 (10:57 +0000)]
drm/i915: Implement color management on bdw/skl/bxt/kbl
Patch based on a previous series by Shashank Sharma.
v2: Do not read GAMMA_MODE register to figure what mode we're in
v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
Add documentation on how the Broadcast RGB property is affected by CTM
v4: Update contributors
v5: Refactor degamma/gamma LUTs load into a single function
v6: Fix missing intel_crtc variable (bisect issue)
v7: Fix & simplify limited range matrix multiplication (Matt Roper's
comment)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acknowledged-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-4-git-send-email-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Wed, 16 Mar 2016 10:57:15 +0000 (10:57 +0000)]
drm/i915: Do not read GAMMA_MODE register
Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.
v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).
v4: Mask GAMMA_MODE register with interesting bits when reading
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-3-git-send-email-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Wed, 16 Mar 2016 10:57:14 +0000 (10:57 +0000)]
drm/i915: Extract out gamma table and CSC to their own file
The moves a couple of functions programming the gamma LUT and CSC
units into their own file.
On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).
The CSC unit is only available from Haswell on.
We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.
v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1458125837-2576-2-git-send-email-lionel.g.landwerlin@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:44 +0000 (17:05 +0200)]
drm/i915/bxt: allow dsi on any pipe
BXT isn't as limited as BYT and CHT regarding DSI pipes and ports.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/0375f1e237092d0ae3f39ecfc5702024918acbfd.1458313400.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:43 +0000 (17:05 +0200)]
drm/i915/dsi: use the BIT macro for clarity
No functional changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/9115c0a80ad57075700e006db965dd31cc4358fc.1458313400.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:42 +0000 (17:05 +0200)]
drm/i915/bxt: add dsi transcoders
The BXT display connections have DSI transcoders A and C that can be
muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI
transcoders.
The "normal" transcoders A, B and C are not used with BXT DSI, so care
must be taken to avoid accessing those registers with DSI transcoders in
the hardware state readout, modeset, and generally everywhere.
v2: addressing comments by Ville:
- rename the dsi get config function to hsw_get_dsi_transcoder_state
- rebase onto the higher level split of pipe/transcoder functions
- use more has_dsi_encoder as we can now because of the above,
with no need to look at the transcoder so much
- rename IS_DSI_TRANSCODER to transcoder_is_dsi
- use the above a bit more instead of comparing to < TRANSCODER_EDP
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/299740536b7941e31b2744f3ce34f7afe936a771.1458313400.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:41 +0000 (17:05 +0200)]
drm/i915: abstract get config for cpu transcoder
Makes it neater to add the same for DSI transcoder. No functional
changes.
v2: rename to hsw_get_transcoder_state and add a comment about grabbing
power reference (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/c473a73d69dcd61584419d85ff7908a8717b0594.1458313400.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:40 +0000 (17:05 +0200)]
drm/i915: split set pipeconf to pipeconf, pipemisc, pipe_gamma
Prep work for DSI transcoders. No functional changes.
v2: call split functions at a higher level (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/981252d5d5f82d009d73e1b2ae93d9ab7bee8de8.1458313400.git.jani.nikula@intel.com
Jani Nikula [Fri, 18 Mar 2016 15:05:39 +0000 (17:05 +0200)]
drm/i915: split get/set pipe timings to timings and src size
Prep work for DSI transcoders. No functional changes.
v2: call split functions at a higher level (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8d67a05eb869a7b0c4ee17c2d3b0b029de34851c.1458313400.git.jani.nikula@intel.com
Jesse Barnes [Wed, 16 Mar 2016 20:31:30 +0000 (13:31 -0700)]
drm/i915: add another virtual PCH bridge for passthrough support
Some configs use the P2X type but some use a P3X type PCH, so add that
to the detect_pch function so things work correctly.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458160290-16710-1-git-send-email-jbarnes@virtuousgeek.org
Jordan Justen [Mon, 7 Mar 2016 07:30:30 +0000 (23:30 -0800)]
drm/i915: Bump command parser version for new whitelisted registers
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457335830-30923-6-git-send-email-jordan.l.justen@intel.com
Jordan Justen [Mon, 7 Mar 2016 07:30:29 +0000 (23:30 -0800)]
drm/i915: Add Haswell CS GPR registers to whitelist
This is needed for the Mesa Vulkan driver on Haswell.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457335830-30923-5-git-send-email-jordan.l.justen@intel.com
Jordan Justen [Mon, 7 Mar 2016 07:30:28 +0000 (23:30 -0800)]
drm/i915: Move Haswell registers to separate whitelist table
Now that we can whitelist registers only on Haswell, move HSW_SCRATCH1
and HSW_ROW_CHICKEN3 into a separate Haswell only table.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457335830-30923-4-git-send-email-jordan.l.justen@intel.com
Jordan Justen [Mon, 7 Mar 2016 07:30:27 +0000 (23:30 -0800)]
drm/i915: Use an array of register tables in command parser
For Haswell, we will want another table of registers while retaining
the large common table of whitelisted registers shared by all gen7
devices.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
[danvet: Pipe patch through sed -e 's/\<ring\>/engine/g' to make it
apply.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jordan Justen [Mon, 7 Mar 2016 07:30:26 +0000 (23:30 -0800)]
drm/i915: Add TIMESTAMP to register whitelist
This is needed for the Mesa Vulkan driver on Haswell.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457335830-30923-2-git-send-email-jordan.l.justen@intel.com
Imre Deak [Fri, 18 Mar 2016 08:46:10 +0000 (10:46 +0200)]
drm/i915: Tune down init error message due to failure injection
Atm, in case failure injection forces an error the subsequent "*ERROR*
failed to init modeset" error message will make automated tests (CI)
report this event as a breakage even though the event is expected. To
fix this print the error message with debug log level in this case.
While at it print the error message for any init failure and change it
to
"""
Device initialization failed (errno)
Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
against DRM/Intel providing the dmesg log by booting with drm.debug=0xf
"""
and export a helper printing error messages using this same format.
A follow-up patch will convert all uses of DRM_ERROR reporting a user
facing problem to use this new helper instead.
v2:
- Include the problematic error message in the commit log, add a
request to file an fdo bug to the message (Chris)
v3:
- Include the new error message too in the commit log, make the
fdo link more precise and print part of the message with info log
level (Chris)
v4: (Chris)
- Use dev_printk instead of DRM_ERROR/INFO and use NOTICE instead of
INFO loglevel
- Export a helper for printing user facing error messages
v5:
- Keep the DRM_ERROR message prefix used by piglit-igt/CI to filter
relevant dmesg lines
- Use dev_notice(), instead of dev_printk(KERN_NOTICE,...)
v6:
- Print the fdo bug link only once (Chris)
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458290770-15480-1-git-send-email-imre.deak@intel.com
Chris Wilson [Fri, 18 Mar 2016 08:42:59 +0000 (10:42 +0200)]
drm/i915: Codify our assumption that the Global GTT is <= 4GiB
Throughout the code base, we use u32 for offsets into the global GTT. If
we ever see any hardware with a larger GGTT, then we run the real risk
of silent corruption. So test for our assumption up front so that we
have a nice reminder should the time come when it fails.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
[Rebased and changed 1ull -> 1ULL, cut 80 char line]
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458290579-27783-1-git-send-email-joonas.lahtinen@linux.intel.com
Joonas Lahtinen [Fri, 18 Mar 2016 08:42:58 +0000 (10:42 +0200)]
drm/i915/gtt: Clean up GGTT probing code
Use less pointers with the probing code, making it much less confusing
to read.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Joonas Lahtinen [Fri, 18 Mar 2016 08:42:57 +0000 (10:42 +0200)]
drm/i915: Rename dev_priv->gtt to dev_priv->ggtt
Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt
to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt.
Fix a couple of whitespace problems while at it.
v2:
- Fix a typo in commit message.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Joonas Lahtinen [Fri, 18 Mar 2016 08:42:56 +0000 (10:42 +0200)]
drm/i915/gtt: Reference mappable_end variable from pointer
Reference variable value from pointer, not assumed pointer destination.
Since:
commit
c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu Jun 25 18:35:05 2015 +0300
drm/i915/gtt: Allow >= 4GB sizes for vm.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Tim Gore [Wed, 16 Mar 2016 16:13:46 +0000 (16:13 +0000)]
drm/i915/gen9: add WaClearFlowControlGpgpuContextSave
This allows writes to EU flow control registers. Together
with SIP code from the user-mode driver this resolves a
hang seen in some pre-emption scenarios. Note that this
patch is just the kernel mode part of this workaround.
v2. Oops, add FLOW_CONTROL_ENABLE macro to i915_reg.h.
Signed-off-by: Tim Gore <tim.gore@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458144826-17269-1-git-send-email-tim.gore@intel.com
Tvrtko Ursulin [Thu, 17 Mar 2016 12:59:46 +0000 (12:59 +0000)]
drm/i915: Move CSB MMIO reads out of the execlists lock
By reading the CSB (slow MMIO accesses) into a temporary local
buffer we can decrease the duration of holding the execlist
lock.
Main advantage is that during heavy batch buffer submission we
reduce the execlist lock contention, which should decrease the
latency and CPU usage between the submitting userspace process
and interrupt handling.
Downside is that we need to grab and relase the forcewake twice,
but as the below numbers will show this is completely hidden
by the primary gains.
Testing with "gem_latency -n 100" (submit batch buffers with a
hundred nops each) shows more than doubling of the throughput
and more than halving of the dispatch latency, overall latency
and CPU time spend in the submitting process.
Submitting empty batches ("gem_latency -n 0") does not seem
significantly affected by this change with throughput and CPU
time improving by half a percent, and overall latency worsening
by the same amount.
Above tests were done in a hundred runs on a big core Broadwell.
v2:
* Overflow protection to local CSB buffer.
* Use closer dev_priv in execlists_submit_requests. (Chris Wilson)
v3: Rebase.
v4: Added commend about irq needed to be disabled in
execlists_submit_request. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilsno <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458219586-20452-1-git-send-email-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Thu, 17 Mar 2016 13:04:10 +0000 (13:04 +0000)]
drm/i915: Use shorter route to dev_private where possible
Where we have a request we can use req->i915 directly instead
of going through the engine and device. Coccinelle script:
@@
function f;
identifier r;
@@
f(..., struct drm_i915_gem_request *r, ...)
{
...
- engine->dev->dev_private
+ r->i915
...
}
@@
struct drm_i915_gem_request *req;
@@
(
req->
- engine->dev->dev_private
+ i915
)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1458219850-21007-1-git-send-email-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Thu, 17 Mar 2016 13:04:09 +0000 (13:04 +0000)]
drm/i915: Remove unused variable in i915_gem_request_add_to_client
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Wed, 16 Mar 2016 11:39:08 +0000 (13:39 +0200)]
drm/i915: Add fault injection support
Add support for forcing an error at selected places in the driver. As an
example add 4 options to fail during driver loading.
Requested by Chris.
v2:
- Add fault point for modeset initialization
- Print debug message when injecting an error
v3:
- Rename inject_fault to inject_load_failure, rename the related macros
and helper accordingly (Chris)
- Use a counter instead of a mask to identify the failure point (Daniel)
- Mark the module option as _unsafe and keep i915_params ordered (Joonas)
v4:
- Rebase on latest -nightly
v5:
- Use DRM_INFO instead of DRM_DEBUG_DRIVER, making it clearer in CI reports
that a following error message is expected (IRC r-b from Chris on v5)
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
projects / openwrt / staging / blogic.git / log