osé Roberto de Souza [Wed, 25 Apr 2018 21:23:31 +0000 (14:23 -0700)]
drm/i915/psr: Prevent PSR exit when a non-pipe related register is written
Any write in any display register was causing HW to exit PSR,
masking it to allow more power savings. Writes to pipe related
registers will still cause HW to exit PSR.
This is already masked for PSR2.
It also do not break the Display WA #0884, writes to CURSURFLIVE
are still causing hardware to exit PSR. This was tested in CNL machine
by triggering a write to CURSURFLIVE when a debugfs was read by user.
Bspec: 7721 and 8042
v4: Checked that it do not breaks WA #0884 and added this information
to the commit message.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-1-jose.souza@intel.com
Chris Wilson [Wed, 11 Apr 2018 12:03:46 +0000 (13:03 +0100)]
drm/i915/selftests: Wait for idle between idle resets as well
Even though we weren't injecting guilty requests to be reset, we could
still fall over the issue of resetting the same request too fast -- where
the GPU refuses to start again. (Although it is interesting to note that
reloading the driver is sufficient, suggesting that we could recover if
we delayed the setup after reset?) Continue to paper over the problem by
adding a small delay by waiting for the engine to idle between tests,
and ensure that the engines are idle before starting the idle tests.
v2: Replace single instance of 50 with a magic macro.
References:
028666793a02 ("drm/i915/selftests: Avoid repeatedly harming the same innocent context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
Jani Nikula [Thu, 26 Apr 2018 08:25:30 +0000 (11:25 +0300)]
drm/i915/dp: fix compliance test adjustments
Abstract compliance test adjustments to a single function. Also make the
bpc adjustments affect the limits, actually forcing the bpc. Seems like
directly changing the pipe_bpp in the past could not have been
effective.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ef61e76003ab7719c82810b742f3fb5765c0e14c.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:29 +0000 (11:25 +0300)]
drm/i915/dp: abstract link config selection
For now, there's just the one link config selection, optimizing for slow
and wide link. No functional changes.
Keep the debug logging in the caller, to avoid duplication later on if
alternative link confing selection gets added.
v2: Improved commit message
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/64848b76bf90d6ceecd7ec6b5add28531e0b1a41.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:28 +0000 (11:25 +0300)]
drm/i915/dp: group link config limits in a struct
Also use same min/max model for bpp, and adjust debug logging while at
it.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/72f78c7ae0cd1810798bd94cbf5e574c78da83f8.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:27 +0000 (11:25 +0300)]
drm/i915/dp: move eDP VBT bpp clamping code to intel_dp_compute_bpp()
Keep related things together. No functional changes.
v2: Fix a typo in patch subject, fix a checkpatch alignment warning.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f24d44547a586a0e342f24e69ab4d576a2474891.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:26 +0000 (11:25 +0300)]
drm/i915/dp: abstract dp link config computation from the rest
Abstract a new intel_dp_compute_link_config() from
intel_dp_compute_config(), with the parts related to link configuration,
i.e. bpp, link rate, and lane count selection. No functional changes.
v2: Fix a checkpatch warn about spacing.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/80f99a625633f87f44d38d487ba3b32ff9a26b07.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:25 +0000 (11:25 +0300)]
drm/i915/dp: move link_bw and rate_select debugging where used
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be
able to debug log the link_bw and rate_select parameters; we don't use
the parameters here for anything else. We call intel_dp_compute_rate()
again during link training where we actually need and use the
parameters.
Move the debug logging of link_bw and rate_select to
intel_dp_link_training_clock_recovery(), and clean up the extra
intel_dp_compute_rate() call and extra clutter from the already
overcrowded intel_dp_compute_config().
v2: Rewrote commit message (Rodrigo, Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c5cf6a179e2d244eceb6bb80a792765d9efbee4f.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 08:25:24 +0000 (11:25 +0300)]
drm/i915/dp: remove stale comment about bw constants
We haven't used the DP bw constants here for a while. No functional
changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1dc7763cdc70c7f64c0a01f76f218d9ac0717227.1524730974.git.jani.nikula@intel.com
Jani Nikula [Thu, 26 Apr 2018 11:35:21 +0000 (14:35 +0300)]
drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.
v2: don't change device info dump (Chris)
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426113521.28417-1-jani.nikula@intel.com
Chris Wilson [Thu, 26 Apr 2018 10:32:19 +0000 (11:32 +0100)]
drm/i915: Compile out engine debug for release
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive paths.
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/20180426103219.22181-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Thu, 26 Apr 2018 07:47:16 +0000 (08:47 +0100)]
drm/i915: Use seqlock in engine stats
We can convert engine stats from a spinlock to seqlock to ensure interrupt
processing is never even a tiny bit delayed by parallel readers.
There is a smidgen bit more cost on the write lock side, and an extremely
unlikely chance that readers will have to retry a few times in face of
heavy interrupt load. But it should be extremely unlikely given how
lightweight read side section is compared to the interrupt processing
side, and also compared to the rest of the code paths which can lead into
it. Furthermore, writer is the ones doing the real, latency sensitive
work, while readers are only informative.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426074716.7352-1-tvrtko.ursulin@linux.intel.com
Oscar Mateo [Tue, 24 Apr 2018 21:39:55 +0000 (14:39 -0700)]
drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11
Interrupt handling in Gen11 is quite different from previous platforms.
v2: Rebased (Michel)
v3: Rebased with wiggle
v4: Rebased, remove TODO warning correctly (Daniele)
v5: Rebased, made gen11_gtiir const while at it (Michel)
v6: Rebased
v7: Adapt to the style currently in upstream
Suggested-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1524605995-22324-1-git-send-email-oscar.mateo@intel.com
Chris Wilson [Wed, 25 Apr 2018 14:23:34 +0000 (15:23 +0100)]
drm/i915: Remove obsolete min/max freq setters from debugfs
A more complete, and more importantly stable, interface for controlling
the RPS frequency range is available in sysfs, obsoleting the unstable
debugfs.
It's presence seems to trick people into using it, forgetting it is not
ABI.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106237
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425142334.27113-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 25 Apr 2018 12:37:18 +0000 (13:37 +0100)]
drm/i915: Use memset64() to align the ring with MI_NOOP
When filling the ring to align the emit pointer to the next cacheline,
use memset64() rather than open-coding it. As we know that we always
have an even number of dwords, we can replace the dword loop with the
qword equivalent.
v2: s/0/MI_NOOP<<32 | MI_NOOP/
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/20180425123718.16366-1-chris@chris-wilson.co.uk
Lyude Paul [Wed, 11 Apr 2018 23:42:40 +0000 (19:42 -0400)]
drm/atomic: Print debug message on atomic check failure
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411234302.2896-2-lyude@redhat.com
Chris Wilson [Tue, 24 Apr 2018 14:29:45 +0000 (15:29 +0100)]
drm/i915/breadcrumbs: Keep the fake irq armed across reset
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting an engine.
It also allows us to react better to the user poking around debugfs for
testing missed irqs.
v2: Tighten the order of del_timer_sync as the fake_irq timer
may trigger the hangcheck timer, and so we should cancel it first and
then cancel the hangcheck (Mika)
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/20180424142945.6787-1-chris@chris-wilson.co.uk
Gustavo A. R. Silva [Tue, 24 Apr 2018 13:15:45 +0000 (08:15 -0500)]
drm/i915/selftests: Fix uninitialized variable
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
Addresses-Coverity-ID:
1468362 ("Uninitialized scalar variable")
Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.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/20180424131545.GA4053@embeddedor.com
José Roberto de Souza [Wed, 18 Apr 2018 23:41:58 +0000 (16:41 -0700)]
drm/i915/fbdev: Enable late fbdev initial configuration
If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN). Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.
So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.
This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.
This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/
Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17
Tested-by: Ian Pilcher <arequipeno@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
Chris Wilson [Tue, 24 Apr 2018 11:52:36 +0000 (12:52 +0100)]
drm/i915: Skip printing global offsets for per-engine scratch pages
Knowing the offset of the per-engine scratch/HWS page during boot is not
very informative, so remove the DRM_DEBUG.
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/20180424115236.2022-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 24 Apr 2018 08:16:00 +0000 (09:16 +0100)]
drm/i915: Don't dump umpteen thousand requests
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most often comparing the first/last
in the queue is enough to identify problems in the scheduling.
We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common
debug scenarios, but for the moment if we can avoiding spending more
than a few seconds dumping the GPU state that will avoid a nasty
livelock (where hangcheck spends so long dumping the state, it fires
again and starts to dump the state again in parallel, ad infinitum).
v2: Remember to print last not the stale rq iter after the loop.
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/20180424081600.27544-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 24 Apr 2018 01:08:39 +0000 (02:08 +0100)]
drm/i915: Build request info on stack before printk
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete line in a single call to printk.
Fixes: b7268c5eed0a ("drm/i915: Pack params to engine->schedule() into a struct")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424010839.22860-1-chris@chris-wilson.co.uk
Mika Kuoppala [Mon, 23 Apr 2018 11:37:54 +0000 (14:37 +0300)]
drm/i915: Add compiler barrier to wait_for
We need to be careful to not let compiler evaluate
the expiration and the operation on it's terms.
Document and enforce that COND will be evaluated
before checking timeout expiration.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-2-mika.kuoppala@linux.intel.com
Mika Kuoppala [Mon, 23 Apr 2018 11:37:53 +0000 (14:37 +0300)]
drm/i915: Use ktime on wait_for
We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.
We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.
v2: added bugzilla entry (Imre), added stable (Chris)
Reported-by: Imre Deak <imre.deak@intel.com>
References: https://lkml.org/lkml/2018/4/18/798 [1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
Matt Atwood [Mon, 23 Apr 2018 22:28:03 +0000 (15:28 -0700)]
drm/i915/kbl: Add KBL GT2 sku
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1524522483-19987-1-git-send-email-matthew.s.atwood@intel.com
Jani Nikula [Mon, 23 Apr 2018 10:17:26 +0000 (13:17 +0300)]
Merge tag 'gvt-next-2018-04-23' of https://github.com/intel/gvt-linux into drm-intel-next-queued
- Minor condition check improvment (Gustavo A. R. Silva)
- Non-priviliged batch buffer scan (Yan Zhao)
- Scheduling optimizations (Zhipeng Gong)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5dafba29-b2bd-6b94-630e-db5c009da7e3@intel.com
Gustavo A. R. Silva [Thu, 22 Mar 2018 17:27:54 +0000 (12:27 -0500)]
drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID:
1466154 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Gustavo A. R. Silva [Thu, 22 Mar 2018 18:21:54 +0000 (13:21 -0500)]
drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
The checks are misleading and not required [1].
[1] https://lkml.org/lkml/2018/3/19/1792
Addresses-Coverity-ID:
1466017
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Zhao Yan [Wed, 4 Apr 2018 05:57:09 +0000 (13:57 +0800)]
drm/i915/gvt: scan non-privileged batch buffer for debug purpose
For perfomance purpose, scanning of non-privileged batch buffer is turned
off by default. But for debugging purpose, it can be turned on via debugfs.
After scanning, we submit the original non-privileged batch buffer into
hardware, so that the scanning is only a peeking window of guest submitted
commands and will not affect the execution results.
v4:
- refine debugfs print format&content (zhenyu wang)
- print engine id instread of engine name to prevent potential memory leak
in debugfs warning message. (zhenyu wang)
v3:
- change vgpu->scan_nonprivbb from type bool to u32, so it is able to
selectively turn on/off scanning of non-privileged batch buffer on engine
level. e.g.
if vgpu->scan_nonprivbb=3, then it will scan non-privileged batch buffer
on engine 0 and 1.
- in debugfs interface to set vgpu->scan_nonprivbb, print warning message
to warn user and explicitly tell state change in kernel log (zhenyu wang)
v2:
- rebase
- update comments for start_gma_offset (henry)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Zhipeng Gong [Wed, 4 Apr 2018 00:43:53 +0000 (08:43 +0800)]
drm/i915/gvt: Update time slice more frequently
When there is only one vGPU in GVT-g and it submits workloads
continuously, it will not be scheduled out, vgpu_update_timeslice
is not called and its sched_in_time is not updated in a long time,
which can be several seconds or longer.
Once GVT-g pauses to submit workload for this vGPU due to heavy
host CPU workload, this vGPU get scheduled out and
vgpu_update_timeslice is called, its left_ts will be subtract
by a big value from sched_out_time - sched_in_time.
When GVT-g is going to submit workload for this vGPU again,
it will not be scheduled in until gvt_balance_timeslice reaches
stage 0 and reset its left_ts, which introduces several
hunderand milliseconds latency.
This patch updates time slice in every ms to update sched_in_time
timely.
v2: revise commit message
v3: use more concise expr. (Zhenyu)
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Min He <min.he@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Zhipeng Gong [Wed, 4 Apr 2018 00:43:52 +0000 (08:43 +0800)]
drm/i915/gvt: Use real time to do timer check
intel_gvt_schedule check timer through a counter and is supposed
to wake up to increase the counter every ms.
In a system with heavy workload, gvt_service_thread can not get
a chance to run right after wake up and will be delayed several
milliseconds. As a result, one hundred counter interval means
several hundred milliseconds in real time.
This patch use real time instead of counter to do timer check.
v2: remove static variable. (Zhenyu)
v3: correct expire_time update. (Zhenyu)
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Min He <min.he@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Hans de Goede [Fri, 20 Apr 2018 09:59:33 +0000 (11:59 +0200)]
drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit
d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing (see note below).
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
Some notes about the mapping of the BIOS framebuffer:
v1 led to some discussion if the assumption of the intel_display.c code
that the firmware framebuffer is a linear mapping of the stolen memory
starting at offset 0 is still correct, because that would mean that the
GOP does not implement the WaSkipStolenMemoryFirstPage workaround.
To verify this the following code was added at the end of
i915_gem_object_create_stolen_for_preallocated() :
pr_err("first ggtt entry before bind: 0x%016llx\n",
readq(dev_priv->ggtt.gsm));
ret = i915_vma_bind(vma,
HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE,
PIN_UPDATE);
pr_err("i915_vma_bind ret %d\n", ret);
pr_err("first ggtt entry after bind: 0x%016llx\n",
readq(dev_priv->ggtt.gsm));
Which prints the mapping of the first page, then does a vma_bind() to
force update the mapping with our linear view of the framebuffer and
then prints the mapping of the first page again.
On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints:
[ 1.651141] first ggtt entry before bind: 0x0000000078c00001
[ 1.651151] i915_vma_bind ret 0
[ 1.651152] first ggtt entry after bind: 0x0000000078c00083
And "sudo cat /proc/iomem | grep Stolen" gives:
78c00000-
88bfffff : Graphics Stolen Memory
There are no visual changes with this patch (BIOS vendor logo still
stays in place when we inherit the BIOS framebuffer), so the vma_bind()
does not impact which memory is being scanned out.
The address of the first ggtt entry matches with the start of stolen
and the i915_vma_bind call only changes the first gtt entry's flags,
or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly
matches what we would expect based on gen8_pte_encode()'s behavior.
So it seems that the GOP indeed does NOT implement the wa and the i915's
code assuming a linear mapping at the start of stolen for the BIOS fb
still holds true for gen8+.
I've also tested this on a Cherry Trail based device (a GPD Win)
with identical results (the flags are 0x1b after the vma_bind
on CHT, which matches with I915_CACHE_NONE).
Changed in v2: No code changes, extended the commit message with the
verification that the intel_display.c BIOS framebuffer mapping is still
correct.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180420095933.16442-1-hdegoede@redhat.com
Dhinakaran Pandiyan [Tue, 3 Apr 2018 21:24:20 +0000 (14:24 -0700)]
drm/i915/psr: Timestamps for PSR entry and exit interrupts.
Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
PSR entry.
v2: Removed seqlock (Ville)
Removed erroneous warning in irq loop (Chris)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-4-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Thu, 5 Apr 2018 01:37:17 +0000 (18:37 -0700)]
drm/i915/psr: Control PSR interrupts via debugfs
Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.
User can make such a request with
echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug
There are no locks to serialize PSR debug enabling from
irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
called only during module initialization/resume and IGT subtests
aren't expected to modify PSR debug at those times, we should be safe.
v2: Unroll loops (Ville)
Avoid resetting error mask bits.
v3: Unmask interrupts in postinstall() if debug was still enabled.
Avoid RMW (Ville)
v4: Avoid extra IMR write introduced in the previous version.(Jose)
Style changes, renames (Jose).
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405013717.24254-1-dhinakaran.pandiyan@intel.com
Ville Syrjälä [Tue, 3 Apr 2018 21:24:18 +0000 (14:24 -0700)]
drm/i915: Enable edp psr error interrupts on bdw+
Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on
any transcoder in theory, though the we don't currenty enable PSR except
on the EDP transcoder.
v2: From DK
* Rebased on drm-tip
v3: Switched author to Ville based on IRC discussion.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-2-dhinakaran.pandiyan@intel.com
Daniel Vetter [Thu, 5 Apr 2018 22:00:23 +0000 (15:00 -0700)]
drm/i915: Enable edp psr error interrupts on hsw
The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.
Somewhat confusing the the moved register offset on bdw is only for
the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
on bdw.
v2: Fixes from Ville.
v3: From DK
* Rebased on drm-tip
* Removed BDW IIR bit definition, looks like an unintentional change that
should be in the following patch.
v4: From DK
* Don't mask REG_WRITE.
References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405220023.9449-1-dhinakaran.pandiyan@intel.com
Daniel Vetter [Tue, 17 Apr 2018 10:02:25 +0000 (12:02 +0200)]
drm/i915: Remove skl dc6 enable/disable functions
One is outright unused, other can be made static.
Drive-by cleanup while accidentally reading dc code.
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417100225.12286-1-daniel.vetter@ffwll.ch
Imre Deak [Thu, 19 Apr 2018 15:51:09 +0000 (18:51 +0300)]
drm/i915: Enable display WA#1183 from its correct spot
The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.
I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.
Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
Ville Syrjälä [Fri, 16 Mar 2018 18:36:25 +0000 (20:36 +0200)]
drm/i915: Protect PIPE_CONF_CHECK macros with do {} while(0)
Make the PIPE_CONF_CHECK macros a bit more robust by wrapping them
in do {} while(0). Avoids funky sirprises when you try put an 'else'
after a PIPE_CONF_CHECK invocation...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316183625.16316-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Jani Nikula [Thu, 19 Apr 2018 08:59:39 +0000 (11:59 +0300)]
drm/i915/dsi: improve dphy param limits logging
Move the limit checks near the calculations for each field, and actually
log the values that exceed limits.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419085940.21505-1-jani.nikula@intel.com
Abhay Kumar [Wed, 18 Apr 2018 10:37:07 +0000 (13:37 +0300)]
drm/i915/audio: set minimum CD clock to twice the BCLK
In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.
Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.
The proper fix would be to increase CDCLK dynamically from the audio
component hooks.
v2:
- Address comment (Jani)
- New design approach
v3: - Typo fix on top of v1
v4 by Jani: rewrite commit message, add comment in code
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Cc: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
Chris Wilson [Wed, 18 Apr 2018 18:40:52 +0000 (19:40 +0100)]
drm/i915: Pack params to engine->schedule() into a struct
Today we only want to pass along the priority to engine->schedule(), but
in the future we want to have much more control over the various aspects
of the GPU during a context's execution, for example controlling the
frequency allowed. As we need an ever growing number of parameters for
scheduling, move those into a struct for convenience.
v2: Move the anonymous struct into its own function for legibility and
ye olde gcc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-3-chris@chris-wilson.co.uk
Chris Wilson [Wed, 18 Apr 2018 18:40:51 +0000 (19:40 +0100)]
drm/i915: Rename priotree to sched
Having moved the priotree struct into i915_scheduler.h, identify it as
the scheduling element and rebrand into i915_sched. This becomes more
useful as we start attaching more information we require to propagate
through the scheduler.
v2: Use i915_sched_node for future distinctiveness
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 18 Apr 2018 18:40:50 +0000 (19:40 +0100)]
drm/i915: Move the priotree struct to its own headers
Over time the priotree has grown from a sorted list to a more
complicated structure for propagating constraints along the dependency
chain to try and resolve priority inversion. Start to segregate this
information from the rest of the request/fence tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-1-chris@chris-wilson.co.uk
Gaurav K Singh [Tue, 17 Apr 2018 18:22:18 +0000 (23:52 +0530)]
drm/i915/audio: Fix audio detection issue on GLK
On Geminilake, sometimes audio card is not getting
detected after reboot. This is a spurious issue happening on
Geminilake. HW codec and HD audio controller link was going
out of sync for which there was a fix in i915 driver but
was not getting invoked for GLK. Extending this fix to GLK as well.
Tested by Du,Wenkai on GLK board.
Bspec: 21829
v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
Cc: <stable@vger.kernel.org> # b651bd2a3ae3 ("drm/i915/audio: Fix audio enumeration issue on BXT")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Abhay Kumar <abhay.Kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
Oscar Mateo [Mon, 16 Apr 2018 21:57:01 +0000 (14:57 -0700)]
drm/i915/selftests: Handle a potential failure of intel_ring_begin
Silence smatch over:
drivers/gpu/drm/i915/selftests/intel_workarounds.c:58 read_nonprivs() error: 'cs' dereferencing possible ERR_PTR()
by handling a potential (but unlikely) failure of intel_ring_begin.
Fixes: f4ecfbfc32ed ("drm/i915: Check whitelist registers across resets")
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/1523915821-30624-1-git-send-email-oscar.mateo@intel.com
Chris Wilson [Sat, 14 Apr 2018 09:12:33 +0000 (10:12 +0100)]
drm/i915: Call i915_perf_fini() on init_hw error unwind
We have to cleanup after i915_perf_init(), even on the error path, as it
passes a pointer into the module to the sysfs core. If we fail to
unregister the sysctl table, we leave a dangling pointer which then may
explode anytime later.
Fixes: 9f9b2792b6d3 ("drm/i915/perf: reuse timestamp frequency from device info")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 14 Apr 2018 12:27:54 +0000 (13:27 +0100)]
drm/i915: Check whitelist registers across resets
Add a selftest to ensure that we restore the whitelisted registers after
rewrite the registers everytime they might be scrubbed, e.g. module
load, reset and resume. For the other volatile workaround registers, we
export their presence via debugfs and check in igt/gem_workarounds.
However, we don't export the whitelist and rather than do so, let's test
them directly in the kernel.
The test we use is to read the registers back from the CS (this helps us
be sure that the registers will be valid for MI_LRI etc). In order to
generate the expected list, we split intel_whitelist_workarounds_emit
into two phases, the first to build the list and the second to apply.
Inside the test, we only build the list and then check that list against
the hw.
v2: Filter out pre-gen8 as they do not have RING_NONPRIV.
v3: Drop unused engine parameter, no plans to use it now or future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414122754.569-1-chris@chris-wilson.co.uk
Piorkowski, Piotr [Fri, 13 Apr 2018 08:52:45 +0000 (10:52 +0200)]
drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter
It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter
where we are passing GT type and Core family values.
Let's stop/remove setup of this parameter and remove related
definitions.
v2: (this time without squashed HAX)
- New title and description
- Remove also GUC_CORE_FAMILY_* definitions (Michel)
v3:
- The removed define GUC_CTL_DEVICE_INFO has been restored (Michel)
- Updated description (Sagar)
v4: rebase
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: John A Spotswood <john.a.spotswood@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180413085245.57206-1-piotr.piorkowski@intel.com
Jani Nikula [Fri, 13 Apr 2018 09:20:58 +0000 (12:20 +0300)]
drm/i915: Update DRIVER_DATE to
20180413
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Mika Kuoppala [Thu, 12 Apr 2018 14:58:02 +0000 (17:58 +0300)]
drm/i915/cnl: Use mmio access to context status buffer
Evidence indicates that Cannonlake HWSP is not coherent
as it should. Revert to using mmio access for now.
Testcase: igt/gem_ctx_switch
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180412145802.23313-1-mika.kuoppala@linux.intel.com
Jani Nikula [Wed, 11 Apr 2018 13:15:19 +0000 (16:15 +0300)]
drm/i915/bios: reduce the scope of some local variables in parse_ddi_port()
No functional changes.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-2-jani.nikula@intel.com
Jani Nikula [Wed, 11 Apr 2018 13:15:18 +0000 (16:15 +0300)]
drm/i915/bios: filter out invalid DDC pins from VBT child devices
The VBT contains the DDC pin to use for specific ports. Alas, sometimes
the field appears to contain bogus data, and while we check for it later
on in intel_gmbus_get_adapter() we fail to check the returned NULL on
errors. Oops results.
The simplest approach seems to be to catch and ignore the bogus DDC pins
already at the VBT parsing phase, reverting to fixed per port default
pins. This doesn't guarantee display working, but at least it prevents
the oops. And we continue to be fuzzed by VBT.
One affected machine is Dell Latitude 5590 where a BIOS upgrade added
invalid DDC pins.
Typical backtrace:
[ 35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
[ 35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
[ 35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[ 35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted
4.16.0-rc7.x64-g1cda370ffded #1
[ 35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[ 35.461450] Workqueue: events_unbound async_run_entry_fn
[ 35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
[ 35.461467] RSP: 0018:
ffff9b4e43d47c40 EFLAGS:
00010286
[ 35.461469] RAX:
0000000000000000 RBX:
ffff98f90639f800 RCX:
ffffffffae051960
[ 35.461471] RDX:
0000000000000001 RSI:
0000000000000092 RDI:
0000000000000246
[ 35.461472] RBP:
ffff98f905410000 R08:
0000004d062a83f6 R09:
00000000000003bd
[ 35.461474] R10:
0000000000000031 R11:
ffffffffad4eda58 R12:
ffff98f905410000
[ 35.461475] R13:
ffff98f9064c1000 R14:
ffff9b4e43d47cf0 R15:
ffff98f905410000
[ 35.461477] FS:
0000000000000000(0000) GS:
ffff98f92e580000(0000) knlGS:
0000000000000000
[ 35.461479] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 35.461481] CR2:
00007f5682359008 CR3:
00000001b700c005 CR4:
00000000003606e0
[ 35.461483] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 35.461484] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 35.461486] Call Trace:
[ 35.461501] intel_hdmi_set_edid+0x37/0x27f [i915]
[ 35.461515] intel_hdmi_detect+0x7c/0x97 [i915]
[ 35.461518] drm_helper_probe_single_connector_modes+0xe1/0x6c0
[ 35.461521] drm_setup_crtcs+0x129/0xa6a
[ 35.461523] ? __switch_to_asm+0x34/0x70
[ 35.461525] ? __switch_to_asm+0x34/0x70
[ 35.461527] ? __switch_to_asm+0x40/0x70
[ 35.461528] ? __switch_to_asm+0x34/0x70
[ 35.461529] ? __switch_to_asm+0x40/0x70
[ 35.461531] ? __switch_to_asm+0x34/0x70
[ 35.461532] ? __switch_to_asm+0x40/0x70
[ 35.461534] ? __switch_to_asm+0x34/0x70
[ 35.461536] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[ 35.461538] ? __switch_to_asm+0x40/0x70
[ 35.461541] ? _cond_resched+0x10/0x33
[ 35.461557] intel_fbdev_initial_config+0xf/0x1c [i915]
[ 35.461560] async_run_entry_fn+0x2e/0xf5
[ 35.461563] process_one_work+0x15b/0x364
[ 35.461565] worker_thread+0x2c/0x3a0
[ 35.461567] ? process_one_work+0x364/0x364
[ 35.461568] kthread+0x10c/0x122
[ 35.461570] ? _kthread_create_on_node+0x5d/0x5d
[ 35.461572] ret_from_fork+0x35/0x40
[ 35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
[ 35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
[ 35.461606] ---[ end trace
4fe1e63e2dd93373 ]---
[ 35.461609] BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
[ 35.461613] IP: i2c_transfer+0x4/0x86
[ 35.461614] PGD 0 P4D 0
[ 35.461616] Oops: 0000 [#1] SMP PTI
[ 35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[ 35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G W
4.16.0-rc7.x64-g1cda370ffded #1
[ 35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[ 35.461628] Workqueue: events_unbound async_run_entry_fn
[ 35.461630] RIP: 0010:i2c_transfer+0x4/0x86
[ 35.461631] RSP: 0018:
ffff9b4e43d47b30 EFLAGS:
00010246
[ 35.461633] RAX:
ffff9b4e43d47b6e RBX:
0000000000000005 RCX:
0000000000000001
[ 35.461635] RDX:
0000000000000002 RSI:
ffff9b4e43d47b80 RDI:
0000000000000000
[ 35.461636] RBP:
ffff9b4e43d47bd8 R08:
0000004d062a83f6 R09:
00000000000003bd
[ 35.461638] R10:
0000000000000031 R11:
ffffffffad4eda58 R12:
0000000000000002
[ 35.461639] R13:
0000000000000001 R14:
ffff9b4e43d47b6f R15:
ffff9b4e43d47c07
[ 35.461641] FS:
0000000000000000(0000) GS:
ffff98f92e580000(0000) knlGS:
0000000000000000
[ 35.461643] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 35.461645] CR2:
0000000000000010 CR3:
00000001b700c005 CR4:
00000000003606e0
[ 35.461646] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 35.461647] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 35.461649] Call Trace:
[ 35.461652] drm_do_probe_ddc_edid+0xb3/0x128
[ 35.461654] drm_get_edid+0xe5/0x38d
[ 35.461669] intel_hdmi_set_edid+0x45/0x27f [i915]
[ 35.461684] intel_hdmi_detect+0x7c/0x97 [i915]
[ 35.461687] drm_helper_probe_single_connector_modes+0xe1/0x6c0
[ 35.461689] drm_setup_crtcs+0x129/0xa6a
[ 35.461691] ? __switch_to_asm+0x34/0x70
[ 35.461693] ? __switch_to_asm+0x34/0x70
[ 35.461694] ? __switch_to_asm+0x40/0x70
[ 35.461696] ? __switch_to_asm+0x34/0x70
[ 35.461697] ? __switch_to_asm+0x40/0x70
[ 35.461698] ? __switch_to_asm+0x34/0x70
[ 35.461700] ? __switch_to_asm+0x40/0x70
[ 35.461701] ? __switch_to_asm+0x34/0x70
[ 35.461703] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[ 35.461705] ? __switch_to_asm+0x40/0x70
[ 35.461707] ? _cond_resched+0x10/0x33
[ 35.461724] intel_fbdev_initial_config+0xf/0x1c [i915]
[ 35.461727] async_run_entry_fn+0x2e/0xf5
[ 35.461729] process_one_work+0x15b/0x364
[ 35.461731] worker_thread+0x2c/0x3a0
[ 35.461733] ? process_one_work+0x364/0x364
[ 35.461734] kthread+0x10c/0x122
[ 35.461736] ? _kthread_create_on_node+0x5d/0x5d
[ 35.461738] ret_from_fork+0x35/0x40
[ 35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
[ 35.461756] RIP: i2c_transfer+0x4/0x86 RSP:
ffff9b4e43d47b30
[ 35.461757] CR2:
0000000000000010
[ 35.461759] ---[ end trace
4fe1e63e2dd93374 ]---
Based on a patch by Fei Li.
v2: s/reverting/sticking/ (Chris)
Cc: stable@vger.kernel.org
Cc: Fei Li <fei.li@intel.com>
Co-developed-by: Fei Li <fei.li@intel.com>
Reported-by: Pavel Nakonechnyi <zorg1331@gmail.com>
Reported-and-tested-by: Seweryn Kokot <sewkokot@gmail.com>
Reported-and-tested-by: Laszlo Valko <valko@linux.karinthy.hu>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-1-jani.nikula@intel.com
Oscar Mateo [Tue, 10 Apr 2018 16:12:47 +0000 (09:12 -0700)]
drm/i915: Split out functions for different kinds of workarounds
There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.
v2:
- Add multiple MISSING_CASE
- Rebased
v3:
- Rename mmio_workarounds to gt_workarounds (Chris, Mika)
- Create empty placeholders for BDW and CHV GT WAs
- Rebased
v4: Rebased
v5:
- Rebased
- FORCE_TO_NONPRIV register exists since BDW, so make a path
for it to achieve universality, even if empty (Chris)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: appease checkpatch]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-2-git-send-email-oscar.mateo@intel.com
Oscar Mateo [Tue, 10 Apr 2018 16:12:46 +0000 (09:12 -0700)]
drm/i915: Move a bunch of workaround-related code to its own file
This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.
v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
- Rebased
- New license header
v5:
- Rebased
- Added some organisational notes to the file (Chris)
v6: Include DOC section in the documentation build (Jani)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: appease checkpatch, mostly]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-1-git-send-email-oscar.mateo@intel.com
Chris Wilson [Wed, 11 Apr 2018 10:39:29 +0000 (11:39 +0100)]
drm/i915/execlists: Set queue priority from secondary port
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more
important than the current queue, we will rerun the submission tasklet
to evaluate the need for preemption. However, we only want to preempt if
we need to jump ahead of a currently executing request in ELSP. The
second reason for running the submission tasklet is amalgamate requests
into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
(Though repeatedly amalgamating requests into the active context and
triggering many lite-restore is off question gain, the goal really is to
put a context into ELSP[1] to cover the interrupt.) So if instead of
looking at the head of the queue, we look at the context in ELSP[1] we
can answer both of the questions more accurately -- we don't need to
rerun the submission tasklet unless our new request is important enough
to feed into, at least, ELSP[1].
v2: Add some comments from the discussion with Tvrtko.
v3: More commentary to cross-reference queue_request()
References:
f6322eddaff7 ("drm/i915/preemption: Allow preemption between submission ports")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411103929.27374-1-chris@chris-wilson.co.uk
Jani Nikula [Tue, 10 Apr 2018 09:12:48 +0000 (12:12 +0300)]
drm/i915/bios: remove duplicated code
Apparently caused by a merge fail at some point. Due to the nature of
the duplicated block, the second one will have no effect, and there's no
need to backport.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410091248.1454-1-jani.nikula@intel.com
Tvrtko Ursulin [Tue, 10 Apr 2018 11:27:04 +0000 (12:27 +0100)]
drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state, and if not, the best we can do is return the last known
RC6 value.
Without this check we can calculate the estimated value based on un-
initialized or inappropriate internal state, which can result in over-
estimation, or in any case incorrect value being returned.
v2:
* Re-arrange the code a bit to avoid second unlock and return branch.
(Chris Wilson)
v3:
* Insert some strategic blank lines and improve commit msg.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410112704.24462-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Tue, 10 Apr 2018 11:14:17 +0000 (12:14 +0100)]
drm/i915/guc: Replace %phn with %ph
%phn is not a valid specifier, and the trailing 'n' is being eaten by
the format-specifier and defaulting to the ' ' separator. Avoid angering
smatch by using the unknown specifier, and use the default we expect.
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' cannot be followed by 'n'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410111417.27563-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 10 Apr 2018 13:33:54 +0000 (14:33 +0100)]
drm/i915: Don't fiddle with rps/rc6 across GPU reset
Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop
forcibly reloading the registers.
Ville suggested this many moons ago, I said at that time that sanitizing
was no harm and meant that our bookkeeping was kept consistent with the
HW. However, in a forthcoming series, we want to split rps/rc6 GT
powermanagement and one of the key simplifications is the control of
when we enable it. Performing a crude sanitize in the middle of
i915_gem_reset() is then a huge wart.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410133354.13425-1-chris@chris-wilson.co.uk
Maarten Lankhorst [Wed, 28 Mar 2018 10:05:26 +0000 (12:05 +0200)]
drm/i915: Add debugfs file to clear FIFO underruns.
Adding a i915_fifo_underrun_reset debugfs file will make it possible
for IGT tests to clear FIFO underrun fallout at the start of each
subtest, and make re-enable FBC so tests always have maximum exposure
to features used by IGT. FIFO underruns and FBC bugs will no longer
hide when an earlier subtests disables both.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=105685
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681
Link: https://patchwork.freedesktop.org/patch/msgid/20180328100526.36467-1-maarten.lankhorst@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
[mlankhorst: Reset FBC reason if underrun had occurred. (vivijim)]
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Thu, 5 Apr 2018 11:49:15 +0000 (12:49 +0100)]
drm/i915/psr: Chase psr.enabled only under the psr.lock
Inside the psr work function, we want to wait for PSR to idle first and
wish to do so without blocking the normal modeset path, so we do so
without holding the PSR lock. However, we first have to find which pipe
PSR was enabled on, which requires chasing into the PSR struct and
requires locking to prevent intel_psr_disable() from concurrently
setting our pointer to NULL.
Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.0+
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405114915.29609-1-chris@chris-wilson.co.uk
Imre Deak [Mon, 9 Apr 2018 12:27:16 +0000 (15:27 +0300)]
drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout
On GLK sporadic timeouts occur during PHY0 enabling. Based on logs it looks
like they happen sometime after a system suspend/resume cycle, with the
same power well enabling succeeding both before and after the failed
one and no other problems observed. The current timeout in the code is
not actually specified by BSpec, so let's try to increase that until a
BSpec update.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409122716.4055-1-imre.deak@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Maarten Lankhorst [Mon, 9 Apr 2018 12:46:55 +0000 (14:46 +0200)]
drm/i915: Remove last references to drm_atomic_get_existing* macros
All the references to get_existing_state can be converted to
get_new_state or get_old_state, which means that i915 is now
get_existing_state free.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409124656.39886-3-maarten.lankhorst@linux.intel.com
[mlankhorst: Fix alignment in prepare_plane_fb. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Maarten Lankhorst [Mon, 9 Apr 2018 12:46:54 +0000 (14:46 +0200)]
drm/i915: Remove get_existing_crtc_state
get_existing_crtc_state is currently unused, get rid of it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409124656.39886-2-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Maarten Lankhorst [Mon, 9 Apr 2018 12:46:53 +0000 (14:46 +0200)]
drm/i915: Change use get_new_plane_state instead of existing plane state
The get_existing macros are deprecated and should be replaced by
get_old/new_state for clarity.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409124656.39886-1-maarten.lankhorst@linux.intel.com
[mlankhorst: Remove useless warn. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tvrtko Ursulin [Fri, 6 Apr 2018 12:35:14 +0000 (13:35 +0100)]
drm/i915/execlists: Log fence context & seqno throughout GEM_TRACE
Include fence context and seqno in low level tracing so it is easier to
follow flows of individual requests when things go bad.
Also added tracing on the reset side of things.
v2:
Chris Wilson:
* Standardize global_seqno and seqno as global.
* Include current hws seqno in execlists_cancel_port_requests.
v3:
* Fix port printk format for all builds.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v2
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406123514.5809-1-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Fri, 6 Apr 2018 11:44:07 +0000 (12:44 +0100)]
drm/i915: Enclose for_each_engine_masked macro arguments in parentheses
Enclose for_each_engine_masked macro arguments in parentheses.
v2:
* Fixup whitespace to satisfy checkpatch.
* Likewise reformat to 80 chars.
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/20180406114407.25360-1-tvrtko.ursulin@linux.intel.com
Chandra Konduru [Mon, 9 Apr 2018 03:41:13 +0000 (09:11 +0530)]
drm/i915: Upscale scaler max scale for NV12
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series
v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Rebased (me)
v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.
v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.
v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.
v14: Addressed review comments from Maarten
Just add a check for NV12 min src height in
skl_update_scaler and retain the remaining checks
as is. Added Reviewed By from Juha-Pekka Heikkila.
v15: Rebased the series.
v16: Changed fb height restriction to be >= 16 as per
Bspec. Earlier it was > 16.
v17: Adding src width and height to be mult of 4 restriction
to avoid pipe fifo underruns for NV12.
Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-15-git-send-email-vidya.srinivas@intel.com
Chandra Konduru [Mon, 9 Apr 2018 03:41:12 +0000 (09:11 +0530)]
drm/i915: Update format_is_yuv() to include NV12
This patch adds NV12 to format_is_yuv() function
for sprite planes.
v2:
-Use intel_ prefix for format_is_yuv (Ville)
v3: Rebased (me)
v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.
v11: Rebased the patch. format_is_yuv has already
been renamed to intel_format_is_yuv in the color
patch series which is already merged. This function
which was previously static has already been made
non-static. So this patch after rebase just adds
NV12 to intel_format_is_yuv function.
v12: Added reviewed by from Juha-Pekka Heikkila
v13/v14/v15: Rebased the series
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-14-git-send-email-vidya.srinivas@intel.com
Chandra Konduru [Mon, 9 Apr 2018 03:41:11 +0000 (09:11 +0530)]
drm/i915: Set scaler mode for NV12
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3: Rebased (me)
v4: Rebased (me)
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.
v9: Rebased (me)
v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.
v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.
v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr
v14: Added reviewed by from Juha-Pekka Heikkila
v15: Rebased the series
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-13-git-send-email-vidya.srinivas@intel.com
Vidya Srinivas [Mon, 9 Apr 2018 03:41:10 +0000 (09:11 +0530)]
drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.
v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h
v3: Adding Reviewed By from Shashank Sharma
v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-12-git-send-email-vidya.srinivas@intel.com
Vidya Srinivas [Mon, 9 Apr 2018 03:41:09 +0000 (09:11 +0530)]
drm/i915: Display WA 827
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.
v2: Addressed review comments from Maarten and
Juha-Pekka Heikkila. Added reviewed by from
Juha-Pekka Heikkila.
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-11-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:08 +0000 (09:11 +0530)]
drm/i915/skl: split skl_compute_ddb function
This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.
v2: Added reviewed by tag from Shashank Sharma
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
v5: Fixed checkpatch error. Changed *changed = true
to (*changed) = true;
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-10-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:07 +0000 (09:11 +0530)]
drm/i915/skl+: nv12 workaround disable WM level 1-7
Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.
v2: Addressed review comments by Maarten.
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-9-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:06 +0000 (09:11 +0530)]
drm/i915/skl+: make sure higher latency level has higher wm value
DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.
v2: Changed plane_num to plane_id in skl_compute_wm_levels
v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"
v4: Added reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-8-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:05 +0000 (09:11 +0530)]
drm/i915/skl+: pass skl_wm_level struct to wm compute func
This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.
v2: Addressed review comments by Shashank Sharma
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-7-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:04 +0000 (09:11 +0530)]
drm/i915/skl+: NV12 related changes for WM
NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.
v2: Addressed review comments from Shashank Sharma.
v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-6-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:03 +0000 (09:11 +0530)]
drm/i915/skl+: support verification of DDB HW state for NV12
For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.
v2: Addressed review comments by Maarten.
v3: Addressed review comments by Shashank Sharma.
v4: Adding reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-5-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:02 +0000 (09:11 +0530)]
drm/i915/skl+: add NV12 in skl_format_to_fourcc
Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.
v2: Added reviewed by tag from Mika Kahola
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-4-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:01 +0000 (09:11 +0530)]
drm/i915/skl+: refactor WM calculation for NV12
Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.
v2: Addressed review comments by Maarten
v3: Rebased and addressed review comments by Maarten
v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-3-git-send-email-vidya.srinivas@intel.com
Mahesh Kumar [Mon, 9 Apr 2018 03:41:00 +0000 (09:11 +0530)]
drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.
s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe
Changes since V1:
- also change name of skl_copy_wm_for_pipe
v2: Added reviewed by from Juha-Pekka Heikkila
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-2-git-send-email-vidya.srinivas@intel.com
Lyude Paul [Sat, 7 Apr 2018 01:10:53 +0000 (21:10 -0400)]
drm/i915/dp: Send DPCD ON for MST before phy_up
When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought this might be an issue with us accidentally shutting
off the aux block when putting the sink into D3, but since the DP spec
mandates that sinks must wake up within 1ms while we have 100ms to
respond to an ESI irq, this didn't really add up. Turns out that the
problem is more subtle then that:
It turns out that the timeout is from us not enabling DPMS on the MST
hub before actually trying to initiate sideband communications. This
would cause the first sideband communication (power_up_phy()), to start
timing out because the sink wasn't ready to respond. Afterwards, we
would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
intel_ddi_pre_enable_dp(), which would actually result in waking up the
sink so that sideband requests would work again.
Since DPMS is what lets us actually bring the hub up into a state where
sideband communications become functional again, we just need to make
sure to enable DPMS on the display before attempting to perform sideband
communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send
DPMS on when we're enabling the first sink - dhnkrn
Changes since v3:
- Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
Chris Wilson [Fri, 6 Apr 2018 22:03:54 +0000 (23:03 +0100)]
drm/i915: Pass the set of guilty engines to i915_reset()
Currently, we rely on inspecting the hangcheck state from within the
i915_reset() routines to determine which engines were guilty of the
hang. This is problematic for cases where we want to run
i915_handle_error() and call i915_reset() independently of hangcheck.
Instead of relying on the indirect parameter passing, turn it into an
explicit parameter providing the set of stalled engines which then are
treated as guilty until proven innocent.
While we are removing the implicit stalled parameter, also make the
reason into an explicit parameter to i915_reset(). We still need a
back-channel for i915_handle_error() to hand over the task to the locked
waiter, but let's keep that its own channel rather than incriminate
another.
This leaves stalled/seqno as being private to hangcheck, with no more
nefarious snooping by reset, be it whole-device or per-engine. \o/
The only real issue now is that this makes it crystal clear that we
don't actually do any testing of hangcheck per se in
drv_selftest/live_hangcheck, merely of resets!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 6 Apr 2018 22:03:53 +0000 (23:03 +0100)]
drm/i915: Treat i915_reset_engine() as guilty until proven innocent
If we are resetting just one engine, we know it has stalled. So we can
pass the stalled parameter directly to i915_gem_reset_engine(), which
alleviates the necessity to poke at the generic engine->hangcheck.stalled
magic variable, leaving that under control of hangcheck as its name
implies. Other than simplifying by removing the indirect parameter along
this path, this allows us to introduce new reset mechanisms that run
independently of hangcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 6 Apr 2018 15:51:44 +0000 (16:51 +0100)]
drm/i915: Split out parking from the idle worker for reuse
We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.
v2: Just skip if already parked; makes it more forgiving to use by
future callers.
v3: Extract mark_busy, rename it to i915_gem_unpark and place it next to
i915_gem_park so that we can evaluate it for symmetry more easily.
Calling GEM from inside i915_request looks to be a bit of a layering
violation, for the moment I am imaging them as being notify_cb.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> #v1
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406155144.27791-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 6 Apr 2018 10:09:50 +0000 (11:09 +0100)]
drm/i915/selftests: Rename wait_for_hang() to wait_until_running()
Tvrtko mentioned that wait_for_hang() was confusing as it does not
actually wait for the aforementioned hang, just until the request is
running and we are *ready* to inject a hang. A quick
s/wait_for_hang/wait_until_running/ removes that confusion without
having to rethink the naming scheme, immediately at least.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
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>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406100950.19033-1-chris@chris-wilson.co.uk
Oscar Mateo [Thu, 5 Apr 2018 14:00:52 +0000 (17:00 +0300)]
drm/i915/icl: Enable RC6 and RPS in Gen11
AFAICT, once the new interrupt is in place, the rest should behave the
same as Gen10.
v2: Update ring frequencies (Sagar)
v3: Rebase.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-5-mika.kuoppala@linux.intel.com
Oscar Mateo [Fri, 6 Apr 2018 09:32:37 +0000 (12:32 +0300)]
drm/i915/icl: Deal with GT INT DW correctly
BSpec says:
"Second level interrupt events are stored in the GT INT DW. GT INT DW is
a double buffered structure. A snapshot of events is taken when SW reads
GT INT DW. From the time of read to the time of SW completely clearing
GT INT DW (to indicate end of service), all incoming interrupts are logged
in a secondary storage structure. this guarantees that the record of
interrupts SW is servicing will not change while under service".
We read GT INT DW in several places now:
- The IRQ handler (banks 0 and 1) where, hopefully, it is completely
cleared (operation now covered with the irq lock).
- The 'reset' interrupts functions for RPS and GuC logs, where we clear
the bit we are interested in and leave the others for the normal
interrupt handler.
- The 'enable' interrupts functions for RPS and GuC logs, as a measure
of precaution. Here we could relax a bit and don't check GT INT DW
at all or, if we do, at least we should clear the offending bit
(which is what this patch does).
Note that, if every bit is cleared on reading GT INT DW, the register
won't be locked. Also note that, according to the BSpec, GT INT DW
cannot be cleared without first servicing the Selector & Shared IIR
registers.
v2:
- Remove some code duplication (Tvrtko)
- Make sure GT_INTR_DW are protected by the irq spinlock, since it's a
global resource (Tvrtko)
v3: Optimize the spinlock (Tvrtko)
v4: Rebase.
v5:
- take spinlock on outer scope to please sparse (Mika)
- use raw_reg accessors (Mika)
v6: omit the continue in looping banks (Michel)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v4)
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406093237.14548-1-mika.kuoppala@linux.intel.com
Oscar Mateo [Thu, 5 Apr 2018 14:00:50 +0000 (17:00 +0300)]
drm/i915/icl: Handle RPS interrupts correctly for Gen11
Using the new hierarchical interrupt infrastructure.
v2: Rebase
v3: Rebase
v4: use class/instance handler (Mika)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-3-mika.kuoppala@linux.intel.com
Mika Kuoppala [Fri, 6 Apr 2018 09:31:45 +0000 (12:31 +0300)]
drm/i915/icl: Use hw engine class, instance to find irq handler
Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.
v3: rebase on top of rps intr
use correct class / instance limits (Michel)
v4: split engine/other handling
v5: empty iir is not err (Daniele, Michel)
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406093145.14389-1-mika.kuoppala@linux.intel.com
Michel Thierry [Thu, 5 Apr 2018 14:00:48 +0000 (17:00 +0300)]
drm/i915/icl: Add reset control register changes
The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.
v2: Use shift-left instead of BIT macro to match the file style (Paulo).
v3: Reuse gen8_reset_engines (Daniele).
v4: Do not call intel_uncore_forcewake_reset after reset, we may be
using the forcewake to read protected registers elsewhere and those
results may be clobbered by the concurrent dropping of forcewake.
bspec: 19212
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@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/20180405140052.10682-1-mika.kuoppala@linux.intel.com
Kevin Rogovin [Fri, 6 Apr 2018 08:05:57 +0000 (11:05 +0300)]
drm/i915: Describe the bottom of stack in processing a batchbuffer
Now that "DOC: User command execution" of i915_gem_execbuffer.c is included
in the i915.rst, it is benecifial (for new developers) to read what happens
at the bottom of the driver stack (in terms of bytes written to be read
by the GPU) when processing a user-space batchbuffer.
v5:
Typo correction of lacking double tick.
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
[Joonas: correcting the patch title]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-4-git-send-email-kevin.rogovin@intel.com
Kevin Rogovin [Fri, 6 Apr 2018 08:05:56 +0000 (11:05 +0300)]
drm/i915: Add link to documentation in i915_gem_execbuffer.c
Add the documentation of "DOC: User command execution" of
i915_gem_execbuffer.c into a new section in i915.rst.
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
[Joonas: correcting the patch title]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-3-git-send-email-kevin.rogovin@intel.com
Kevin Rogovin [Fri, 6 Apr 2018 08:05:55 +0000 (11:05 +0300)]
drm/i915: Narration overview on GEM
Add a narration to i915.rst about Intel GEN GPU's: engines,
driver context and relocation. Also do minor reorder to improve
narration.
v5:
More type fixes.
Flow bullet list so lines are not too long.
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
[Joonas: correcting the patch title]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-2-git-send-email-kevin.rogovin@intel.com
Chris Wilson [Fri, 30 Mar 2018 13:18:01 +0000 (14:18 +0100)]
drm/i915/selftests: Avoid repeatedly harming the same innocent context
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrumb. This is really only a problem for the selftest as
normally there is a large interlude between resets (hangcheck), or we
focus on resetting just one engine and so avoid repeatedly resetting
innocents.
Something to try would be a preempt-to-idle to quiesce the engine before
reset, so that innocent contexts would be spared the reset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330131801.18327-1-chris@chris-wilson.co.uk
Gaurav K Singh [Thu, 5 Apr 2018 16:42:24 +0000 (22:12 +0530)]
drm/i915/audio: Fix audio enumeration issue on BXT
On Apollolake, with stress test warm reboot, audio card was not getting
enumerated after reboot. This was a spurious issue happening on
Apollolake. HW codec and HD audio controller link was going out of sync
for which there was a fix in i915 driver but was not getting invoked for
BXT. Extending this fix to BXT as well.
Tested on apollolake chromebook by stress test warm reboot with 2500
iterations.
Bspec: 21829
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522946544-11524-1-git-send-email-gaurav.k.singh@intel.com
Radhakrishna Sripada [Wed, 4 Apr 2018 22:59:57 +0000 (15:59 -0700)]
drm/i915: Fix memory leak in intel_hdcp auth
Static code analysis tool reported memory leak in
intel_hdcp_auth_downstream. Fixing the memory leak.
v2: Rebase, move free to a cleanup label(Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180404225957.7457-1-radhakrishna.sripada@intel.com
Chris Wilson [Thu, 5 Apr 2018 12:37:14 +0000 (13:37 +0100)]
drm/i915: Only call finish_reset after a prepare_reset
If we skip the intel_prepare_reset(), we should also skip the
intel_display_reset(). If we we use a flag set by intel_prepare_reset()
then we do not have to second guess based on external user controlled
state whether or not the prepare was called before deciding to finish
it after the reset. igt/gem_eio is one such example that may tweak
i915.reset faster than the code is expecting, leading to
[ 190.233528] =====================================
[ 190.233534] WARNING: bad unlock balance detected!
[ 190.233540]
4.16.0-rc7-g335ef9849310-drmtip_10+ #1 Tainted: G U
[ 190.233547] -------------------------------------
[ 190.233553] gem_eio/1348 is trying to release lock (crtc_ww_class_acquire) at:
[ 190.233569] [<
ffffffff895c7810>] drm_modeset_acquire_fini+0x0/0x60
[ 190.233575] but there are no more locks to release!
[ 190.233580]
other info that might help us debug this:
[ 190.233588] 3 locks held by gem_eio/1348:
[ 190.233592] #0: (&f->f_pos_lock){+.+.}, at: [<
00000000ab90c784>] __fdget_pos+0x3a/0x50
[ 190.233607] #1: (sb_writers#11){.+.+}, at: [<
00000000e1529265>] vfs_write+0x188/0x1a0
[ 190.233622] #2: (&attr->mutex){+.+.}, at: [<
0000000011f40afe>] simple_attr_write+0x36/0xd0
[ 190.233635]
stack backtrace:
[ 190.233644] CPU: 0 PID: 1348 Comm: gem_eio Tainted: G U
4.16.0-rc7-g335ef9849310-drmtip_10+ #1
[ 190.233655] Hardware name: Dell Inc. OptiPlex GX280 /0G8310, BIOS A04 02/09/2005
[ 190.233664] Call Trace:
[ 190.233674] dump_stack+0x67/0x95
[ 190.233682] ? drm_modeset_backoff+0x1b0/0x1b0
[ 190.233690] print_unlock_imbalance_bug+0xd2/0xe0
[ 190.233698] ? drm_modeset_backoff+0x1b0/0x1b0
[ 190.233704] lock_release+0x23e/0x300
[ 190.233712] drm_modeset_acquire_fini+0x16/0x60
[ 190.233835] intel_finish_reset+0x72/0x160 [i915]
[ 190.233894] i915_reset_device+0x1e9/0x240 [i915]
[ 190.233953] ? __intel_get_crtc_scanline+0x1c0/0x1c0 [i915]
[ 190.233962] ? work_on_cpu_safe+0x50/0x50
[ 190.234020] i915_handle_error+0x1f2/0x470 [i915]
[ 190.234031] ? __might_fault+0x39/0x90
[ 190.234037] ? __might_fault+0x39/0x90
[ 190.234099] i915_wedged_set+0x7f/0xc0 [i915]
[ 190.234107] simple_attr_write+0xb0/0xd0
[ 190.234117] full_proxy_write+0x51/0x80
[ 190.234125] __vfs_write+0x21/0x140
[ 190.234133] ? rcu_read_lock_sched_held+0x6f/0x80
[ 190.234140] ? rcu_sync_lockdep_assert+0x29/0x50
[ 190.234147] ? __sb_start_write+0x152/0x1f0
[ 190.234152] ? __sb_start_write+0x168/0x1f0
[ 190.234159] vfs_write+0xbd/0x1a0
[ 190.234166] SyS_write+0x40/0xa0
[ 190.234173] ? do_syscall_64+0x19/0x1b0
[ 190.234180] do_syscall_64+0x6b/0x1b0
[ 190.234188] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 190.234196] RIP: 0033:0x7f84c1b392b7
[ 190.234201] RSP: 002b:
00007f84b6755b00 EFLAGS:
00000293 ORIG_RAX:
0000000000000001
[ 190.234211] RAX:
ffffffffffffffda RBX:
0000000000000046 RCX:
00007f84c1b392b7
[ 190.234218] RDX:
0000000000000002 RSI:
000055ec20abc8d6 RDI:
0000000000000046
[ 190.234225] RBP:
000055ec20abc8d6 R08:
0000000000000000 R09:
0000000000000000
[ 190.234231] R10:
0000000000000000 R11:
0000000000000293 R12:
0000000000000002
[ 190.234238] R13:
0000000000000000 R14:
00007f84b0000b20 R15:
000055ec20ce4eb8
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405123714.3638-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 4 Apr 2018 09:33:29 +0000 (10:33 +0100)]
drm/i915/selftests: Add basic sanitychecks for execlists
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180404093329.5383-1-chris@chris-wilson.co.uk
projects / openwrt / staging / blogic.git / log