Chris Wilson [Sat, 1 Sep 2018 09:24:51 +0000 (10:24 +0100)]
drm/i915: Determine uses-full-ppgtt from context for execbuf
Rather than inspect the global module parameter for whether full-ppgtt
maybe enabled, we can inspect the context directly as to whether it has
its own vm.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180901092451.7233-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 31 Aug 2018 14:36:43 +0000 (15:36 +0100)]
drm/i915: Explicitly mark Global GTT address spaces
So far we have been relying on vm->file pointer being NULL to declare
something GGTT.
This has the unfortunate consequence that the default kernel context is
also declared GGTT and interferes with the following patch which wants to
instantiate VMA's and execute requests against the kernel context.
Change the is_ggtt test to use an explicit flag in struct address_space to
solve this issue.
Note that the bit used is free since there is an alignment hole in the
struct.
v2:
* Mark mock ggtt.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@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/20180831143643.12366-1-tvrtko.ursulin@linux.intel.com
Imre Deak [Fri, 31 Aug 2018 17:47:39 +0000 (20:47 +0300)]
drm/i915/dp_mst: Fix enabling pipe clock for all streams
commit
afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
inadvertently stopped enabling the pipe clock for any DP-MST stream
after the first one. It also rearranged the pipe clock enabling wrt.
initial MST payload allocation step (which may or may not be a
problem, but it's contrary to the spec.).
Fix things by making the above commit truly a non-functional change.
Fixes: afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
Reported-by: Lyude Paul <lyude@redhat.com>
Reported-by: dmummenschanz@web.de
Tested-by: dmummenschanz@web.de
Tested-by: Lyude Paul <lyude@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: dmummenschanz@web.de
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: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180831174739.30387-1-imre.deak@intel.com
Lionel Landwerlin [Mon, 13 Aug 2018 08:02:18 +0000 (09:02 +0100)]
drm/i915/perf: reuse intel_lrc ctx regs macro
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180813080218.28994-3-tvrtko.ursulin@linux.intel.com
Lionel Landwerlin [Mon, 13 Aug 2018 08:02:17 +0000 (09:02 +0100)]
drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180813080218.28994-2-tvrtko.ursulin@linux.intel.com
Jyoti Yadav [Fri, 31 Aug 2018 06:00:23 +0000 (02:00 -0400)]
drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL.
This patch resolves the DMC FW loading issue.
Earlier DMC FW package have only one DMC FW for one stepping. But as such
there is no such restriction from Package side.
For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings.
So while reading the dmc_offset from package header, for 1st stepping
offset used to come 0x0 and was working fine till now.
But for second stepping and other steppings, offset is non zero number
and is in dwords. So we need to convert into bytes to fetch correct DMC
FW from correct place.
v2 : Added check for DMC FW max size for various gen. (Imre Deak)
v3 : Corrected naming convention for various gen. (Imre Deak)
v4 : Initialized max_fw_size to 0
v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak)
v6 : Fixed the typo issues.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jyoti Yadav <jyoti.r.yadav@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1535695223-4648-1-git-send-email-jyoti.r.yadav@intel.com
Chris Wilson [Thu, 30 Aug 2018 13:48:06 +0000 (14:48 +0100)]
drm/i915/selftests: Add a simple exerciser for suspend/hibernate
Although we cannot do a full system-level test of suspend/hibernate from
deep with the kernel selftests, we can exercise the GEM subsystem in
isolation and simulate the external effects (such as losing stolen
contents and trashing the register state).
v2: Don't forget to hold rpm
v3: Suspend the GTT mappings, and more rpm!
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
References:
5ab57c702069 ("drm/i915: Flush logical context image out to memory upon suspend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jakub Bartmiński <jakub.bartminski@intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Jakub Bartmiński <jakub.bartminski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180830134806.21939-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 17 Aug 2018 08:24:05 +0000 (09:24 +0100)]
drm/i915: Keep physical cursors pinned while in use
The optimisation inherent in commit
6a2c4232ece1 ("drm/i915: Make the
physical object coherent with GTT") relies on that once we allocated a
cursor we would have coherent, zero overhead access to the scanout plane
holding the cursor. That is we could then do the very frequent cursor
updates X enjoys with no indirection or kernel involvement. However,
that all hinges on the GGTT mmap of the cursor being pinned and not
require refaulting on each access -- handling such a page fault likely
requires the busy GGTT to be rearranged causing a stall. A very simple
fix is then to handle the physical cursor exactly like other cursors and
keep its vma pinned while active.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107600
References:
6a2c4232ece1 ("drm/i915: Make the physical object coherent with GTT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817082405.755-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 30 Aug 2018 16:10:42 +0000 (17:10 +0100)]
drm/i915/ringbuffer: Delay after invalidating gen6+ xcs
During stress testing of full-ppgtt (on Baytrail at least), we found
that the invalidation around a context/mm switch was insufficient (writes
would go astray). Adding a second MI_FLUSH_DW barrier prevents this, but
it is unclear as to whether this is merely a delaying tactic or if it is
truly serialising with the TLB invalidation. Either way, it is
empirically required.
v2: Avoid the loop for readability;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107715
References: https://bugs.freedesktop.org/show_bug.cgi?id=107759
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180830161042.29193-1-chris@chris-wilson.co.uk
Lionel Landwerlin [Thu, 30 Aug 2018 13:24:24 +0000 (14:24 +0100)]
drm/i915: clear error registers after error capture
We need to clear the register in order to get correct value after the
next potential hang.
v2: Centralize error register clearing in i915_irq.c (Chris)
v3: Don't read gen8 register on < gen6 (Chris)
v4: Don't swap gen8+ & gen6+ code... (Chris)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180830132424.21940-1-lionel.g.landwerlin@intel.com
Joonas Lahtinen [Thu, 30 Aug 2018 14:26:24 +0000 (17:26 +0300)]
drm/i915: Update DRIVER_DATE to
20180830
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Joonas Lahtinen [Thu, 30 Aug 2018 11:29:53 +0000 (14:29 +0300)]
drm/i915: Update DRIVER_DATE to
20180830
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Tue, 28 Aug 2018 15:27:02 +0000 (16:27 +0100)]
drm/i915/execlists: Flush tasklet directly from reset-finish
On finishing the reset, the intention is to restart the GPU before we
relinquish the forcewake taken to handle the reset - the goal being the
GPU reloads a context before it is allowed to sleep. For this purpose,
we used tasklet_flush() which although it accomplished the goal of
restarting the GPU, carried with it a sting in its tail: it cleared the
TASKLET_STATE_SCHED bit. This meant that if another CPU queued a new
request to this engine, we would clear the flag and later attempt to
requeue the tasklet on the local CPU, breaking the per-cpu softirq
lists.
Remove the dangerous tasklet_kill() and just run the tasklet func
directly as we know it is safe to do so (the tasklets are internally
locked to allow mixed usage from direct submission).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828152702.27536-1-chris@chris-wilson.co.uk
Imre Deak [Tue, 28 Aug 2018 12:22:31 +0000 (15:22 +0300)]
drm/i915: Don't check power domains state in intel_power_domains_init_hw()
During power domains initialization we acquire power well references for
power wells in the INIT power domain. The rest of power wells - which
BIOS could have left enabled - we can only acquire references as needed
during display HW readout and so must defer sanitization until then
(also implying that we must always do HW readout to cleanup unused power
wells).
Thus during initialization these latter power wells can have a refcount
of 0 while still being enabled. To avoid the false-positive state
mismatch error this causes remove the check from
intel_power_domains_init_hw() and rely on the state check in
intel_power_domains_enable() which follows the HW readout.
v2:
- Add comment to log and code clarifying how unused power wells get
disabled. (Chris)
Fixes: 6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=107411
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828122231.14336-1-imre.deak@intel.com
Manasi Navare [Fri, 24 Aug 2018 01:48:07 +0000 (18:48 -0700)]
drm/i915/dsc: Fix PPS register definition macros for 2nd VDSC engine
This patch fixes the PPS4 and PPS5 register definition macros that were
resulting into an incorect MMIO address.
Fixes: 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register definitions")
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824014807.14681-1-manasi.d.navare@intel.com
Dhinakaran Pandiyan [Fri, 24 Aug 2018 20:38:56 +0000 (13:38 -0700)]
drm/i915: Do not advertize support for NV12 on ICL yet.
ICL requires two planes for scanning out a NV12 framebuffer. Do
not advertize support for creating NV12 framebuffers until required
plane programming is implemented.
v2: Do not allow adding buffers.
Check inside skl_plane_has_planar (Ville)
Bspec: Plane Planar YUV programming (18566)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824203856.17700-2-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Mon, 27 Aug 2018 22:56:24 +0000 (15:56 -0700)]
drm/i915: Clean up skl_plane_has_planar()
skl_plane_has_planar is hard to read, simplify the logic by checking for
support in the order of platform, pipe and plane.
No change in functionality intended.
v2: Fix logic for primary plane (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827225624.4912-1-dhinakaran.pandiyan@intel.com
Ville Syrjälä [Tue, 28 Aug 2018 14:27:07 +0000 (17:27 +0300)]
drm/i915: Reject compressed Y/Yf with interlaced modes
Y/Yf tiling can't be used with IF-ID. We already reject uncompressed
Y/Yf but we should also reject them when compressed.
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828142707.31583-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
Ville Syrjälä [Tue, 28 Aug 2018 14:27:06 +0000 (17:27 +0300)]
drm/i915: Don't pass plane to .check_plane()
.check_plane() already gets the plane state, so we can dig out the plane
from there if needed. No need in passing it separately.
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828142707.31583-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Tue, 28 Aug 2018 13:37:23 +0000 (16:37 +0300)]
drm/i915: Fix gtt_view asserts
gcc is too smart for us and doesn't evaluate BUILD_BUG_ON()s in
unused static inlines. Collect them up in one static inline and
actually call it to make sure gcc sees it.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828133723.18505-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Rodrigo Vivi [Mon, 27 Aug 2018 22:30:21 +0000 (15:30 -0700)]
drm/i915: Use dp_to_i915 on intel_psr.c
Now that we have a generic caller let's simplify it and
clean up the intel_psr.c code a bit.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827223021.7145-2-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 27 Aug 2018 22:30:20 +0000 (15:30 -0700)]
drm/i915: introduce dp_to_i915() helper
No functional change. But let's get first i915 pointer
directly from intel_dp so we can clean up a lot of code
later.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827223021.7145-1-rodrigo.vivi@intel.com
Daniele Ceraolo Spurio [Mon, 27 Aug 2018 22:36:14 +0000 (15:36 -0700)]
drm/i915/selftests: ring all doorbells in igt_guc_doorbells
We currently verify that all doorbells can be registered with GuC and
HW but don't check that all works as expected after a db ring.
Do a nop ring of all doorbells to make sure we haven't misprogrammed
any WQ or stage descriptor data. This will also help validating
upcoming changes in the db programming flow.
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Katarzyna Dec <katarzyna.dec@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827223614.22789-1-daniele.ceraolospurio@intel.com
Dhinakaran Pandiyan [Fri, 24 Aug 2018 23:08:44 +0000 (16:08 -0700)]
drm/i915/psr: Rewrite comments in intel_psr_wait_for_idle()
Added bspec reference, aligned text and documented the function.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824230844.12428-2-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Fri, 24 Aug 2018 23:08:43 +0000 (16:08 -0700)]
drm/i915/psr: Remove wait_for_idle() for PSR2
CI runs show PSR2 does not go to IDLE with selective update enabled on
all PSR exit triggers. Specifically, logs indicate the hardware enters
"SLEEP Selective Update" and not "IDLE Reset state', like the kernel
expects, when vblank interrupts are enabled. This check was added for PSR1
but incorrectly extended to PSR2, remove the check as it breaks tests
and prints out misleading error messages.
v2: Split out non-code changes (Rodrigo)
Cc: Tarun Vyas <tarun.vyas@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: c43dbcbbcc8c ("drm/i915/psr: Lockless version of psr_wait_for_idle")
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824230844.12428-1-dhinakaran.pandiyan@intel.com
Jan-Marek Glogowski [Sat, 25 Aug 2018 19:10:35 +0000 (15:10 -0400)]
drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit
1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was dropped in commit
c85d200e8321 ("drm/i915: Move SST
DP link retraining into the ->post_hotplug() hook")
Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook")
[Cleaned up commit message, added stable cc]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com
Paulo Zanoni [Mon, 20 Aug 2018 23:31:38 +0000 (16:31 -0700)]
drm/i915: move lookup_power_well() up
There's no need for that forward declaration.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 20 Aug 2018 23:31:37 +0000 (16:31 -0700)]
drm/i915: use for_each_power_well in lookup_power_well()
Use the nice helper function to make the implementation simpler.
v2: Rebase.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-3-paulo.r.zanoni@intel.com
Paulo Zanoni [Mon, 20 Aug 2018 23:31:36 +0000 (16:31 -0700)]
drm/i915: WARN() if we can't lookup_power_well()
None of the current lookup_power_well() callers are actually checking
for NULL return values, they all just use the pointer right away. The
first idea was to replace these theoretical segfaults with a BUG()
since this would at least make our code a little more explicit to the
reader. It was suggested that just converting the BUG() to a WARN()
and returning any power well would probably be better since it would
still keep the system running while at the same time exposing the
driver bug.
We can only hit this NULL/BUG()/WARN() condition if we try to lookup a
power well that isn't defined on a given platform. If that ever
happens, we have to fix our code, making it lookup the correct power
well. Because of this, I don't think it's worth trying to implement
error checking in every caller. Improving our CI system will be a
better use of our time once a bug is found in the wild.
v2: Avoid the BUG() with a WARN() return a random PW (Michal).
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-2-paulo.r.zanoni@intel.com
Paulo Zanoni [Wed, 1 Aug 2018 17:34:41 +0000 (10:34 -0700)]
drm/i915/icl: implement the tc/legacy HPD {dis,}connect flows
Unlike the other ports, TC ports are not available to use as soon as
we get a hotplug. The TC PHYs can be shared between multiple
controllers: display, USB, etc. As a result, handshaking through FIA
is required around connect and disconnect to cleanly transfer
ownership with the controller and set the type-C power state.
This patch implements the flow sequences described by our
specification. We opt to grab ownership of the ports as soon as we get
the hotplugs in order to simplify the interactions and avoid surprises
in the user space side. We may consider changing this in the future,
once we improve our testing capabilities on this area.
v2:
* This unifies the DP and HDMI patches so we can discuss everything
at once so people looking at random single patches can actually
understand the direction.
* I found out the spec was updated a while ago. There's a small
difference in the connect flow and the patch was updated for that.
* Our spec also now gives a good explanation on what is really
happening. As a result, comments were added.
* Add some more comments as requested by Rodrigo (Rodrigo).
v3:
* Downgrade a DRM_ERROR that shouldn't ever happen but we can't act
on in case it does (Chris).
BSpec: 21750, 4250.
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com
Rodrigo Vivi [Thu, 23 Aug 2018 20:51:36 +0000 (13:51 -0700)]
drm/i915: Free write_buf that we allocated with kzalloc.
We use kzalloc to allocate the write_buf that we use for
i2c transfer on hdcp write. But it seems that we are forgetting
to free the memory that is not needed after i2c transfer is
completed.
Reported-by: Brian J Wood <brian.j.wood@intel.com>
Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI")
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180823205136.31310-1-rodrigo.vivi@intel.com
Imre Deak [Wed, 22 Aug 2018 11:26:02 +0000 (14:26 +0300)]
drm/i915: Simplify condition to keep DMC active during S0ix
For S0ix we want to deinit power domains (and so deactivate the DMC
firmware) exactly when the platform supports the DC9 state. To reach
S0ix we need DC9 on these platforms (for which the DMC FW needs to be
deactivated) while to reach S0ix on the rest of the DMC platforms we
need DC6 (which needs the DMC FW to stay active).
Simplify the condition accordingly so it will be automatically
correct for upcoming DC9 platforms like ICL.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/20180822112602.27543-1-imre.deak@intel.com
Dhinakaran Pandiyan [Wed, 22 Aug 2018 01:50:53 +0000 (18:50 -0700)]
drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name -
PLANE_CTL_RENDER_DECOMPRESSION_ENABLE
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Wed, 22 Aug 2018 19:38:27 +0000 (12:38 -0700)]
drm/i915: Add a small wrapper to check for CCS modifiers.
Code looks cleaner with modifiers hidden inside this wrapper.
v2: Remove const qualifier (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180822193827.6341-1-dhinakaran.pandiyan@intel.com
Azhar Shaikh [Wed, 22 Aug 2018 17:23:48 +0000 (10:23 -0700)]
drm/i915/psr: Add PSR mode/revision to debugfs
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
i915_edp_psr_status.
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1534958628-193724-1-git-send-email-azhar.shaikh@intel.com
Ville Syrjälä [Thu, 19 Jul 2018 18:21:57 +0000 (21:21 +0300)]
drm/i915: Fix glk/cnl display w/a #1175
The workaround was supposed to look at the plane destination
coordinates. Currently it's looking at some mixture of src
and dst coordinates that doesn't make sense. Fix it up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719182214.4323-2-ville.syrjala@linux.intel.com
Fixes: 394676f05bee (drm/i915: Add WA for planes ending close to left screen edge)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Dhinakaran Pandiyan [Tue, 21 Aug 2018 22:11:56 +0000 (15:11 -0700)]
drm/i915/psr: Mask PSR irq bits when re-enabling interrupts.
gen8_de_irq_postinstall() wasn't masking the IRQ bit before passing the
debug flag to psr_irq_control(). This check was missed when new debug bits
were defined in 'commit
c44301fce614 ("drm/i915: Allow control of PSR at
runtime through debugfs, v6")'. Instead of ANDing the irq bit in all the
callers, move it to the callee.
v2: Rebased.
Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through
debugfs, v6")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-3-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Tue, 21 Aug 2018 22:11:55 +0000 (15:11 -0700)]
drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
We print the last attempted entry and last exit timestamps only when
IRQ debug is requested. This check was missed when new debug flags were
added in 'commit
c44301fce614 ("drm/i915: Allow control of PSR at
runtime through debugfs, v6")
Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through
debugfs, v6")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-2-dhinakaran.pandiyan@intel.com
Dhinakaran Pandiyan [Tue, 21 Aug 2018 22:11:54 +0000 (15:11 -0700)]
drm/i915/psr: Print PSR_STATUS when PSR idle wait times out.
Knowing the status of the PSR HW state machine is useful for debug,
especially since we are seeing errors with PSR2 in CI.
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-1-dhinakaran.pandiyan@intel.com
Chris Wilson [Tue, 21 Aug 2018 10:11:38 +0000 (11:11 +0100)]
drm/i915: Correct CSB probing for engine state dumper
Since we no longer maintain our read position in the CSB pointers
register, it always returns 0 and not where we last read up to. As a
result the CSB probing in the state dumper starts from 0, either missing
entries or showing stale one.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180821101138.15822-1-chris@chris-wilson.co.uk
Manasi Navare [Fri, 17 Aug 2018 21:52:09 +0000 (14:52 -0700)]
drm/i915/icl: Get DDI clock for ICL for MG PLL and TBT PLL
PLLs are the source clocks for the DDIs so in order to determine the
ddi clock we need to check the PLL configuration.
For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG
PLL the link lock can be obtained from the the PLL divisors based on
the specification.
v2 (from Paulo):
* Make the algorithm look more like what's in the spec, also document
where we differ form the spec and why.
* Make the code a little more consistent with our coding style.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-2-paulo.r.zanoni@intel.com
Manasi Navare [Fri, 17 Aug 2018 21:52:08 +0000 (14:52 -0700)]
drm/i915/icl: Implement HSDIV_RATIO of MG_CLKTOP2_HSCLKCTL_PORT reg as separate divider value defines
The register value of Divider Ratio for high speed divider
(hsdiv_ratio) in MG_CLKTOP2_HSCLKCTL_PORT register is not same as the
actual numerical value of the divider. So this patch implements
separate divider value defines for that field.
icl_mg_pll_find_divisors() can use these defines instead of magic
register values.
The new defines are going to be used in the next patch.
v2 (from Paulo):
* Rebase.
* Make it look a little more like the rest of our code.
v3 (from Paulo):
* Make hsdiv u32 now that it's a bit field (José).
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Suggested-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-1-paulo.r.zanoni@intel.com
Chris Wilson [Fri, 17 Aug 2018 10:02:41 +0000 (11:02 +0100)]
drm/i915/audio: Hook up component bindings even if displays are disabled
If the display has been disabled by modparam, we still want to connect
together the HW bits and bobs with the associated drivers so that we can
continue to manage their runtime power gating.
Fixes: 108109444ff6 ("drm/i915: Check num_pipes before initializing audio component")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Elaine Wang <elaine.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817100241.4628-1-chris@chris-wilson.co.uk
Fredrik Schön [Fri, 17 Aug 2018 20:07:28 +0000 (22:07 +0200)]
drm/i915: Increase LSPCON timeout
100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at boot or screen reconfiguration.
Empirical testing can reproduce the error up to a timeout of 190 ms. Basic
boot and stress testing at 200 ms has not (yet) failed.
Increase timeout to 400 ms to get some margin of error.
Changes from v1:
The initial suggestion of 1000 ms was lowered due to concerns about delaying
valid timeout cases.
Update patch metadata.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=
1570392
Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v4.11+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Fredrik Schön <fredrik.schon@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com
Imre Deak [Thu, 16 Aug 2018 19:34:14 +0000 (22:34 +0300)]
drm/i915: Verify power domains after enabling them
After
commit
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
it makes more sense to check the power domain/well refcounts after
enabling the power domains functionality. Before that it's guaranteed
that most power wells (in the INIT domain) will have a reference held,
so not an interesting state.
While at it also add the check after the init_hw/fini_hw, disable and
suspend/resume steps. Make the test optional on a Kconfig option since
it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg
access for each power well may take up to 20ms.
v2:
- Add the state check to more spots. (Chris)
v3:
- During suspend check the state before deiniting display core.
Afterwards DC states are disabled (and so the dc_off power well is
enabled) even though we don't hold a reference on it.
- Do the test conditionally based on a new Kconfig option. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[Add DRM_I915_DEBUG_RUNTIME_PM to welcome messages]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817145837.26592-1-imre.deak@intel.com
Anusha Srivatsa [Fri, 17 Aug 2018 17:33:30 +0000 (10:33 -0700)]
drm/i915: Do not redefine the has_csr parameter.
Let us reuse the already defined has_csr check and not
redefine it.
The main difference is that in effect this will flip .has_csr to 1
(via GEN9_FEATURES which GEN11_FEATURES pulls in).
Suggested-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=107382
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1534527210-16841-1-git-send-email-anusha.srivatsa@intel.com
Chris Wilson [Wed, 15 Aug 2018 13:58:27 +0000 (14:58 +0100)]
drm/i915/execlists: Include reset depth in traces
Show the reset depth (the tasklet disable count) in the GEM_TRACE to
indicate when we might not expect tasklets to be flushed.
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/20180815135827.25869-1-chris@chris-wilson.co.uk
Lucas De Marchi [Fri, 27 Jul 2018 19:36:47 +0000 (12:36 -0700)]
drm/i915: remove confusing GPIO vs PCH_GPIO
Instead of defining all registers twice, define just a PCH_GPIO_BASE
that has the same address as PCH_GPIO_A and use that to calculate all
the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
the same thing.
v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
macro to return a particular gpio address and move the enum out of
i915_reg.h (suggested by Jani)
v3: Move base offset inside the GPIO() macro so the GMBUS defines don't
actually need to be changed (suggested by Daniel/Ville)
v4: Move definition of i915_gpio to intel_display.h and remove
GMBUS/GPIO handling from gvt since now they have their own
defines.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-3-lucas.demarchi@intel.com
Lucas De Marchi [Fri, 27 Jul 2018 19:36:46 +0000 (12:36 -0700)]
drm/i915/gvt: use its own define for gpio
The definition on i915_reg.h is going to change to depend on
dev_priv->gpio_mmio_base being properly initialized. Define our own
macros since init_generic_mmio_info() is called before than
gpio_mmio_base being set.
Cc: intel-gvt-dev@lists.freedesktop.org
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-2-lucas.demarchi@intel.com
Lucas De Marchi [Fri, 27 Jul 2018 19:36:45 +0000 (12:36 -0700)]
drm/i915: make PCH_GMBUS* definitions private to gvt
This is the only place that they are being used - the others use the
GMBUS* macros that rely on dev_priv being already properly initialized.
Cc: intel-gvt-dev@lists.freedesktop.org
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-1-lucas.demarchi@intel.com
Imre Deak [Thu, 16 Aug 2018 12:37:57 +0000 (15:37 +0300)]
drm/i915: Refactor intel_display_set_init_power() logic
The device global init_power_on flag is somewhat arbitrary and makes
debugging power refcounting problems difficult. Instead arrange things
so that all display power domain get has a corresponding put call. After
this change we have the following sequences:
driver loading:
intel_power_domains_init_hw();
<other init steps>
intel_power_domains_enable();
driver unloading:
intel_power_domains_disable();
<other uninit steps>
intel_power_domains_fini_hw();
system suspend:
intel_power_domains_disable();
<other suspend steps>
intel_power_domains_suspend();
system resume:
intel_power_domains_resume();
<other resume steps>
intel_power_domains_enable();
at other times while the driver is loaded:
intel_display_power_get();
...
intel_display_power_put();
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-2-imre.deak@intel.com
Chris Wilson [Thu, 16 Aug 2018 12:37:56 +0000 (15:37 +0300)]
drm/i915: Introduce intel_runtime_pm_disable to pair intel_runtime_pm_enable
Currently, we cancel the extra wakeref we have for !runtime-pm devices
inside power_wells_fini_hw. However, this is not strictly paired with
the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
be called on errors paths before we even call runtime_pm_enable). Make
the symmetry more explicit and include a check that we do release all of
our rpm wakerefs.
v2: Fixup transfer of ownership back to core whilst keeping our wakeref
count balanced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-1-imre.deak@intel.com
Chris Wilson [Thu, 16 Aug 2018 07:34:46 +0000 (08:34 +0100)]
drm/i915: Stop holding a ref to the ppgtt from each vma
The context owns both the ppgtt and the vma within it, and our activity
tracking on the context ensures that we do not release active ppgtt. As
the context fulfils our obligations for active memory tracking, we can
relinquish the reference from the vma.
This fixes a silly transient refleak from closed vma being kept alive
until the entire system was idle, keeping all vm alive as well.
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/gem_ctx_create/files
Fixes: 3365e2268b6b ("drm/i915: Lazily unbind vma on close")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816073448.19396-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 15 Aug 2018 18:42:51 +0000 (19:42 +0100)]
drm/i915: Remove useless error return from intel_init_mocs_engine()
As the only error is for a programming error in constructing the static
tables describing the register values, replace the error code
propagation with an assert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180815184251.5850-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 15 Aug 2018 20:12:07 +0000 (21:12 +0100)]
drm/i915: Only skip connector output for disable_display
We want to add no connectors, encoders or crtcs if the display is
disabled, but we still need to hook up any existing HW so that we can
power it down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180815201207.2203-1-chris@chris-wilson.co.uk
Imre Deak [Wed, 15 Aug 2018 13:10:38 +0000 (16:10 +0300)]
drm/i915: Fix PM refcounting w/o DMC firmware
The case where the firmware isn't specified for a platform (although
runtime PM works only with DMC on this platform) is the same case where
the firmware is specified but can't be loaded for some reason. Hence we
need to get a display init power domain ref in the first case too to
keep the refcount bookkeeping in balance.
Also convert the related log message to be a debug one, since it's a
valid scenario for a new platform, where we need to have
dev_info->has_csr=1 set, but add support for actually loading the
firmware only later.
v2:
- In addition to the debug log, WARN on non-alpha support platforms,
since then the first case isn't valid scenario. (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180815131038.24446-1-imre.deak@intel.com
Chris Wilson [Tue, 14 Aug 2018 17:18:57 +0000 (18:18 +0100)]
drm/i915: Clear stop-engine for a pardoned reset
If we pardon a per-engine reset, we may leave the STOP_RING bit asserted
in RING_MI_MODE resulting in the engine hanging. Unconditionally clear
it on the per-engine exit path as we know that either we skipped the
reset and so need the cancellation, or the reset was successful and the
cancellation is a no-op, or there was an error and we will follow up
with a full-reset or wedging (both of which will stop the engines again
as required).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107188
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106560
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814171857.24673-1-chris@chris-wilson.co.uk
Chris Wilson [Sun, 12 Aug 2018 22:36:31 +0000 (23:36 +0100)]
drm/i915: Disable runtime-pm using lowlevel functions if !HAS_RC6
If we cannot setup rc6, we cannot let the GPU suspend itself as it
cannot save its state (to a powercontext). As such, we must disable
runtime-pm, but we should do so using the low-level pm-runtime function
which leaves our own debugging functions intact (and continue to detect
errors in our runtime-pm handling should we ever be able to enable rc6).
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/20180812223642.24865-3-chris@chris-wilson.co.uk
Jani Nikula [Tue, 14 Aug 2018 06:00:01 +0000 (09:00 +0300)]
drm/i915: set DP Main Stream Attribute for color range on DDI platforms
Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.
Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit
dae847991a43 ("drm/i915: add
intel_ddi_set_pipe_settings").
Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.
Though not the root cause, the problem was made worse for DDI platforms
with commit
55bc60db5988 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.
After all these years, the fix boils down to flipping one bit.
[Per testing reports, this fixes DP sinks, but not the LSPCON. My
educated guess is that the LSPCON fails to turn the CEA range MSA into
AVI infoframes for HDMI.]
Reported-by: Michał Kopeć <mkopec12@gmail.com>
Reported-by: N. W. <nw9165-3201@yahoo.com>
Reported-by: Nicholas Stommel <nicholas.stommel@gmail.com>
Reported-by: Tom Yan <tom.ty89@gmail.com>
Tested-by: Nicholas Stommel <nicholas.stommel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.9+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
Chris Wilson [Tue, 14 Aug 2018 10:40:56 +0000 (11:40 +0100)]
drm/i915: Kick waiters on resetting legacy rings
This reapplies commit
39f3be162c46 ("drm/i915: Kick waiters on resetting
legacy rings") after the improved gem_eio was run across all machines we
found that gen3 and early gen4 still lost the immediate interrupt
following reset, and the HWSTAM w/a applied to gen6+ is inadequate.
Unlike the later gen, on gen3/4 the principle (and only tests to fail so
far) are the wait vs reset test cases, whereas the reset stress case
works fine (which was the predominantly failing case for gen6+). That is
enough to suggest the underlying issue is sufficiently different to
support the difference in HWSTAM efficacy.
Testcase: igt/gem_eio/wait-10ms
References:
39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
References:
a69ab52b0358 ("drm/i915: Remove extra waiter kick on legacy resets")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@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/20180814104056.27001-1-chris@chris-wilson.co.uk
Chris Wilson [Sun, 12 Aug 2018 22:36:30 +0000 (23:36 +0100)]
drm/i915: Restrict gen6_reset_rps_interrupts to gen6+
Do not call gen6_reset_rps_interrupts() when we know the registers do not
exist.
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/20180812223642.24865-2-chris@chris-wilson.co.uk
Chris Wilson [Sun, 12 Aug 2018 22:36:29 +0000 (23:36 +0100)]
drm/i915: Cleanup gt powerstate from gem
Since the gt powerstate is allocated by i915_gem_init, clean it from
i915_gem_fini for symmetry and to correct the imbalance on error.
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/20180812223642.24865-1-chris@chris-wilson.co.uk
Mika Kuoppala [Mon, 13 Aug 2018 13:01:16 +0000 (16:01 +0300)]
drm/i915: Force reset on unready engine
If engine reports that it is not ready for reset, we
give up. Evidence shows that forcing a per engine reset
on an engine which is not reporting to be ready for reset,
can bring it back into a working order. There is risk that
we corrupt the context image currently executing on that
engine. But that is a risk worth taking as if we unblock
the engine, we prevent a whole device wedging in a case
of full gpu reset.
Reset individual engine even if it reports that it is not
prepared for reset, but only if we aim for full gpu reset
and not on first reset attempt.
v2: force reset only on later attempts, readability (Chris)
v3: simplify with adequate caffeine levels (Chris)
v4: comment about risks and migitations (Chris)
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/20180813130116.7250-1-mika.kuoppala@linux.intel.com
Mika Kuoppala [Fri, 10 Aug 2018 14:00:35 +0000 (17:00 +0300)]
drm/i915: Expose retry count to per gen reset logic
There is a possibility for per gen reset logic to
be more nasty if the softer approach on resetting does
not bear fruit.
Expose retry count to per gen reset logic if it
wants to take such tough measures.
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/20180810140036.24240-1-mika.kuoppala@linux.intel.com
Chris Wilson [Thu, 12 Jul 2018 11:57:29 +0000 (12:57 +0100)]
drm/i915: Bump priority of clean up work
We require that we keep the list of outstanding work short so that we do
not "leak" memory while pageflipping under stress. However that system
stress may delay kernel workers virtually indefinitely, which incurs the
pageflips stall and eventually hit a timeout waiting for the cleanup.
Try to combat CPU starvation of our short-lived cleanup workers by
switching to a high priority workqueue.
Testcase: igt/kms_cursor_legacy/all-pipes-torture-move
References: https://bugs.freedesktop.org/show_bug.cgi?id=107122
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712115729.3506-1-chris@chris-wilson.co.uk
Paulo Zanoni [Thu, 9 Aug 2018 23:58:52 +0000 (16:58 -0700)]
drm/i915/icl: account for context save/restore removed bits
The RS_CTX_ENABLE and CTX_SAVE_INHIBIT bits are not present on ICL
anymore, but we still try to set them and then check them with
GEM_BUG_ON, resulting in a BUG() call. The bug can be reproduced by
igt/drv_selftest/live_hangcheck/others-priority and our CI was able
to catch it.
It is worth noticing that commit
05f0addd9b10 ("drm/i915/icl: Enhanced
execution list support") already tried to avoid the save bits
on ICL, but only inside populate_lr_context().
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Testcase: igt/drv_selftest/live_hangcheck/others-priority
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107399
References:
05f0addd9b10 ("drm/i915/icl: Enhanced execution list support")
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809235852.24516-1-paulo.r.zanoni@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Maarten Lankhorst [Wed, 8 Aug 2018 14:19:11 +0000 (16:19 +0200)]
drm/i915/psr: Add debugfs support to force a downgrade to PSR1 mode.
This will make it easier to test PSR1 on PSR2 capable eDP machines.
Changes since v1:
- Remove I915_PSR_DEBUG_FORCE_PSR2, it did nothing, not sure forcing
PSR2 would even work.
- Handle NULL crtc in intel_psr_set_debugfs_mode. (dhnkrn)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808141911.7647-2-maarten.lankhorst@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Maarten Lankhorst [Thu, 9 Aug 2018 14:21:01 +0000 (16:21 +0200)]
drm/i915: Allow control of PSR at runtime through debugfs, v6
Currently tests modify i915.enable_psr and then do a modeset cycle
to change PSR. We can write a value to i915_edp_psr_debug to force
a certain PSR mode without a modeset.
To retain compatibility with older userspace, we also still allow
the override through the module parameter, and add some tracking
to check whether a debugfs mode is specified.
Changes since v1:
- Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled.
- Fix i915_psr_debugfs_mode to match the writes to debugfs.
- Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify
it and move it to intel_psr.c. This keeps all internals in intel_psr.c
- Perform an interruptible wait for hw completion outside of the psr
lock, instead of being forced to trywait and return -EBUSY.
Changes since v2:
- Rebase on top of intel_psr changes.
Changes since v3:
- Assign psr.dp during init. (dhnkrn)
- Add prepared bool, which should be used instead of relying on psr.dp. (dhnkrn)
- Fix -EDEADLK handling in debugfs. (dhnkrn)
- Clean up waiting for idle in intel_psr_set_debugfs_mode.
- Print PSR mode when trying to enable PSR. (dhnkrn)
- Move changing psr debug setting to i915_edp_psr_debug_set. (dhnkrn)
Changes since v4:
- Return error in _set() function.
- Change flag values to make them easier to remember. (dhnkrn)
- Only assign psr.dp once. (dhnkrn)
- Only set crtc_state->has_psr on the crtc with psr.dp.
- Fix typo. (dhnkrn)
Changes since v5:
- Only wait for PSR idle on the PSR connector correctly. (dhnkrn)
- Reinstate WARN_ON(drrs.dp) in intel_psr_enable. (dhnkrn)
- Remove stray comment. (dhnkrn)
- Be silent in intel_psr_compute_config on wrong connector. (dhnkrn)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809142101.26155-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Chris Wilson [Thu, 9 Aug 2018 06:34:49 +0000 (07:34 +0100)]
drm/i915/selftests: Hold rpm for unparking
The call to i915_gem_unpark() checks that we hold a rpm wakeref before
taking a long term wakeref for i915->gt.awake. We should therefore make
sure we do hold the wakeref when directly calling unpark to disable
the retire worker.
Fixes: 932cac10c8fb ("drm/i915/selftests: Prevent background reaping of active objects")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809063449.4474-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 8 Aug 2018 21:08:42 +0000 (22:08 +0100)]
drm/i915: Restore user forcewake domains across suspend
On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon resume or else our accounting will be
off and we may not acquire the forcewake before we use it. So record
which domains we cleared on suspend and reacquire them early on resume.
v2: Hold the spinlock to appease our sanitychecks
v3: s/fw_domains_user/fw_domains_saved/ to convey intent more clearly
Reported-by: Imre Deak <imre.deak@linux.intel.com>
Fixes: b8473050805f ("drm/i915: Fix forcewake active domain tracking")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808210842.3555-1-chris@chris-wilson.co.uk
Rodrigo Vivi [Fri, 3 Aug 2018 23:27:21 +0000 (16:27 -0700)]
drm/i915/cfl: Add a new CFL PCI ID.
One more CFL ID added to spec.
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180803232721.20038-1-rodrigo.vivi@intel.com
Chris Wilson [Wed, 8 Aug 2018 10:51:01 +0000 (11:51 +0100)]
drm/i915: Remove extra waiter kick on legacy resets
Now with a more efficacious workaround for the lost interrupts after
reset, we can remove the hack of kicking the waiters after reset. The
issue was that the kick only worked for the immediate window after the
reset (those seqno that would complete in the time it took for the
waiter thread to perform its check) but miss any seqno that lacked an
interrupt afterwards.
References:
39f3be162c46 ("drm/i915: Kick waiters on resetting legacy rings")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808105101.913-3-chris@chris-wilson.co.uk
Chris Wilson [Wed, 8 Aug 2018 10:51:00 +0000 (11:51 +0100)]
drm/i915: Unmask user interrupts writes into HWSP on snb/ivb/vlv/hsw
An oddity occurs on Sandybridge, Ivybridge and Haswell (and presumably
Valleyview) in that for the period following the GPU restart after a
reset, there are no GT interrupts received. From Ville's notes, bit 0 in
the HWSTAM corresponds to the render interrupt, and if we unmask it we
do see immediate resumption of GT interrupt delivery (via the master irq
handler) after the reset.
v2: Limit the w/a to the render interrupt from rcs
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107500
Fixes: c5498089463b ("drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode")
References:
d420a50c21ef ("drm/i915: Clean up the HWSTAM mess")
Testcase: igt/gem_eio/reset-stress
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808105101.913-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 8 Aug 2018 10:50:59 +0000 (11:50 +0100)]
drm/i915: Warn if we hit the timeout for wait-for-idle
Hitting the timeout and finding that all engines are actually idle is
indicative of an interrupt delivery problem. This problem is an issue
that we need to fix, so make sure we log it and provide the GEM trace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808105101.913-1-chris@chris-wilson.co.uk
Imre Deak [Mon, 6 Aug 2018 09:58:43 +0000 (12:58 +0300)]
drm/i915/icl: Add missing power gate enums
On ICL there are 5 fused power gates, so add the two missing ones for
clarity.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-11-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:42 +0000 (12:58 +0300)]
drm/i915: Use existing power well IDs where possible
There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum values.
This also fixes a problem on ICL where in assert_can_enable_dc5/9() we
would've failed to look up the PW#2 power well.
v2:
- Keep an ID assigned for the ICL PW#2 power well too. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Added comment about the ICL PW#2 fix to the commit log]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-10-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:41 +0000 (12:58 +0300)]
drm/i915: Make power well ID names more uniform
The format for the ID names is <platform>_DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.
v2:
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-9-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:40 +0000 (12:58 +0300)]
drm/i915: Remove redundant power well IDs
Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting power wells and hopefully won't be needed for any new
power wells in the future. To make maintenance of the power well ID enum
easier, don't require a unique ID for each power well, only if it's
necessary. Remove the IDs becoming redundant this way and assign to all
the corresponding power wells a new DISP_PW_ID_NONE ID.
After the previous two patches the IDs don't need to have a fixed value,
so remove the explicit initializers and adjust the enum's code comment
accordingly.
v2:
- Keep required ID assignments for HSW_DISP_PW_GLOBAL and ICL_DISP_PW_2.
(Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-8-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:39 +0000 (12:58 +0300)]
drm/i915/ddi: Use power well CTL IDX instead of ID
Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.
Also clarify a bit the code comment describing the function and layout
of the control registers.
This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.
v2:
- Clarify platform range tags in code comments. (Paulo)
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:38 +0000 (12:58 +0300)]
drm/i915/vlv: Use power well CTL IDX instead of ID
Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions against the specification more difficult than
necessary. Also the values in the power well ID enum must stay fixed,
making code maintenance of the enum cumbersome.
To solve the above define the control/status flag indices right after
the corresponding registers and use these to derive the control/status
flag values by storing the indices in the i915_power_well_desc struct.
Initializing anonymous union fields require the preceding field in the
struct to be explicitly initialized - even when using named
initializers - and the initialization to be done right before the union
initialization, hence the reordering of the .id fields.
v2:
- Clarify commit log message about anonymous union initializers. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-6-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:37 +0000 (12:58 +0300)]
drm/i915: Constify power well descriptors
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of these objects their corresponding
i915_power_well_desc object.
v2:
- Fix checkpatch warnings about missing param name in fn declaration and
lines over 80 chars. (Paulo)
- Move check for unique IDs to __set_power_wells().
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Fixed checkpatch warn in __set_power_wells()]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:36 +0000 (12:58 +0300)]
drm/i915/vlv: Remove redundant power well ID asserts
The callbacks these asserts are called from are used from a single power
well, so not much point in checking that. The check also requires a unique
power well ID that we would need to keep around only for this purpose.
(A follow-up patch removes power well IDs not needed for direct power
well access).
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-4-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:35 +0000 (12:58 +0300)]
drm/i915: Rename intel_power_domains_fini() to intel_power_domains_fini_hw()
intel_power_domains_fini() rolls back what was done in
intel_power_domains_init_hw(), so rename and move it accordingly. This
allows us adding a cleanup function later for intel_power_domains_init()
in a cleaner way.
No functional change.
v2:
- Fix checkpatch error adding missing param name to function
declaration. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-3-imre.deak@intel.com
Imre Deak [Mon, 6 Aug 2018 09:58:34 +0000 (12:58 +0300)]
drm/i915/icl: Fix power well anonymous union initializers
Similarly to commit
0a445945be6d
("drm/i915: Work around GCC anonymous union initialization bug")
we need to initialize anonymous unions inside extra braces to work
around a GCC4.4 build error.
v2:
- Fix checkpatch errors in commit log. (Paulo)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-2-imre.deak@intel.com
Chris Wilson [Mon, 6 Aug 2018 11:26:05 +0000 (12:26 +0100)]
drm/i915: Pull seqno started checks together
We have a few instances of checking seqno-1 to see if the HW has started
the request. Pull those together under a helper.
v2: Pull the !seqno assertion higher, as given seqno==1 we may indeed
check to see if we have started using seqno==0.
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>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806112605.20725-1-chris@chris-wilson.co.uk
Mahesh Kumar [Wed, 1 Aug 2018 15:11:13 +0000 (20:41 +0530)]
drm/i915/skl: distribute DDB based on panel resolution
We distribute DDB equally among all pipes irrespective of display
buffer requirement of each pipe. This leads to a situation where high
resolution y-tiled display can not be enabled with 2 low resolution
displays.
Main contributing factor for DDB requirement is width of the display.
This patch make changes to distribute ddb based on display width.
So display with higher width will get bigger chunk of DDB.
Changes Since V1:
- pipe_size/ddb_size will not overflow u16 so use appropriate
data-types during computation (Chris)
Changes Since V2:
- avoid redundancy and possible truncation errors (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107113
Cc: raviraj.p.sitaram@intel.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20180801151113.5337-1-mahesh1.kumar@intel.com
Mahesh Kumar [Tue, 31 Jul 2018 14:24:44 +0000 (19:54 +0530)]
drm/i915: ddb_size is of u16 type
ddb_size is u16 so use same return type for intel_get_ddb_size
wrapper.
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20180731142445.30723-2-mahesh1.kumar@intel.com
Chris Wilson [Mon, 6 Aug 2018 14:46:04 +0000 (15:46 +0100)]
drm/i915/selftests: Unconditionally do a chipset flush before emit_bb_start
Experience teaches us over and over again that coherency on Baytrail
requires the odd heavy hammer, and in particular clflush alone is not
enough to guarrantee that writes from the CPU are picked up by the CS.
Do as we do elsewhere and ensure we have an unconditional
i915_gem_chipset_flush() after writing to memory and submitting a batch
to HW.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107499
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806144604.8346-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 6 Aug 2018 14:56:47 +0000 (15:56 +0100)]
drm/i915: Stop dropping irq around resets
A long time ago, we were afraid of handling interrupts and signaling
waiters during a reset, worrying that the confusion in request handling
would interfere with our attempts to process the reset in an orderly
fashion. Since then, we have isolated our irq-driven request handling by
virtue of the engine->timeline.lock and control of kthreads where
required, eliminating the danger of concurrently processing interrupts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806145647.13131-1-chris@chris-wilson.co.uk
Lucas De Marchi [Fri, 3 Aug 2018 23:24:43 +0000 (16:24 -0700)]
drm/i915: kill resource streamer support
After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use RS years ago, but nothing ever landed or shipped
because there was no performance improvement.
This removes it from kernel keeping the uapi defines around for
compatibility.
v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
- don't bother trying to document removed params on uapi header:
applications should know that from the query.
(from Chris)
v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
- reword commit message after Daniele confirmed no performance
regression on his machine
- reword commit message to make clear RS is being removed due to
never been used
v4: - move I915_EXEC_RESOURCE_STREAMER to __I915_EXEC_ILLEGAL_FLAGS so
the check on ioctl() is made much earlier by
i915_gem_check_execbuffer() (suggested by Tvrtko)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180803232443.17193-1-lucas.demarchi@intel.com
Lucas De Marchi [Thu, 19 Jul 2018 17:05:56 +0000 (10:05 -0700)]
drm/i915/icl: move has_resource_streamer to GEN11_FEATURES
Resource streamer has been removed on GEN11 so move it to the FEATURES
macro.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719170557.10729-1-lucas.demarchi@intel.com
Gwan-gyeong Mun [Fri, 3 Aug 2018 16:41:50 +0000 (19:41 +0300)]
drm/i915: Fix typo in i915_drm_resume()
Trivial typo, s/loose/lose/, in i915_drm_resume.
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180803164150.8185-1-gwan-gyeong.mun@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 2 Aug 2018 10:06:30 +0000 (11:06 +0100)]
drm/i915: Clear all residual RPS events on disabling interrupts
Make sure that the RPS IIR is completely clear on disabling so we should
not get any more interrupts after idling. Since the IIR is shared with
the guc, we have to be careful to only clobber RPS events.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 2 Aug 2018 10:06:29 +0000 (11:06 +0100)]
drm/i915: Unconditionally clear the pm/guc GT IIR upon acking
Having stored the IIR for action, we should always clear it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 2 Aug 2018 14:04:16 +0000 (15:04 +0100)]
drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"
The LPE audio is a child device of i915, it is powered up and down
alongside the igfx and presents no independent runtime interface. This
aptly fulfils the description of a "No-Callback" Device, so mark it
thus.
Fixes: 183c00350ccd ("drm/i915: Fix runtime PM for LPE audio")
Testcase: igt/pm_rpm/basic-pci-d3-state
Testcase: igt/pm_rpm/basic-rte
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802140416.6062-1-chris@chris-wilson.co.uk
Paulo Zanoni [Wed, 1 Aug 2018 00:46:14 +0000 (17:46 -0700)]
drm/i915/icl: avoid unclaimed PLANE_NV12_BUF_CFG register
We don't have proper watermark NV12 support on ICL due to differences
in how it should be implemented. In commit
234059da0f33
("drm/i915/icl: NV12 y-plane ddb is not in same plane") we avoided
writing the non-existent PLANE_NV12_BUF_CFG registers but we forgot to
also avoid them on the hardware state readout. While the code is still
not correct, at least now we can avoid unclaimed register error
messages when dealing with RGB formats, which makes CI happier.
Also add some FIXME comments in order to make it even more clear that
there's still work to do.
References: commit
234059da0f33 ("drm/i915/icl: NV12 y-plane ddb is
not in same plane")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801004614.22149-1-paulo.r.zanoni@intel.com
Chris Wilson [Thu, 2 Aug 2018 10:06:28 +0000 (11:06 +0100)]
drm/i915: Drop stray clearing of rps->last_adj
We used to reset last_adj to 0 on crossing a power domain boundary, to
slow down our rate of change. However, commit
60548c554be2 ("drm/i915:
Interactive RPS mode") accidentally caused it to be reset on every
frequency update, nerfing the fast response granted by the slow start
algorithm.
Fixes: 60548c554be2 ("drm/i915: Interactive RPS mode")
Testcase: igt/pm_rps/mix-max-config-loaded
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 30 Jul 2018 16:43:25 +0000 (17:43 +0100)]
drm/i915/execlists: Terminate the context image with BB_END
In the aub trace utility, the context images are terminated with a
MI_BATCH_BUFFER_END; the simulator is reported as complaining otherwise.
Do the same for our protocontext image for completeness, and in passing
apply the magic bit for gen10 to mark the end of the context image.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730164325.12770-1-chris@chris-wilson.co.uk
Mika Kuoppala [Mon, 30 Jul 2018 12:06:36 +0000 (15:06 +0300)]
Revert "drm/i915/icl: WaEnableFloatBlendOptimization"
The register for 0xe420 is unable to hold any value, including
this bit. The documentation is also mixed between having a
register bit for toggle and having a state command setup
for it. Apparently the register toggle is deprecated.
Remove the register toggle as evidence shows it's futile.
The thing remaining is an apology and humble request for
Mesa folks to resurrect their state setup for this as they
were on right track from start.
This reverts commit
0bf059f3532bb39c52d917142206a8554fc2f1c5.
Fixes: 0bf059f3532b ("drm/i915/icl: WaEnableFloatBlendOptimization")
References: HSDES#
1406393558
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@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/20180730120636.26958-1-mika.kuoppala@linux.intel.com
Chris Wilson [Wed, 1 Aug 2018 10:47:21 +0000 (11:47 +0100)]
drm/i95: Mark GGTT as incoherent for gen10+
The evidence suggests that we need to start treating writes via GGTT as
incoherent for gen10+, that is that they are internally buffered and not
immediately visible via a read along a different physical path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107398
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107400
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107435
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801104721.4030-1-chris@chris-wilson.co.uk
projects / openwrt / staging / blogic.git / log