Colin Xu [Mon, 9 Jul 2018 01:28:18 +0000 (09:28 +0800)]
drm/i915/gvt: Handle EDP_PSR_IMR and EDP_PSR_IIR for BXT.
BXT supports EDP. However since GVT-g only simulate DP monitor
to guest and handles EDP_PSR_IMR and EDP_PSR_IIR as default MMIO
r/w. If guest r/w these IMR/IIR, GVT-g won't simulate the real
HW behavior and below warning is printed:
--------
Interrupt register 0x64838 is not zero: 0xffffffff
WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:161
gen3_assert_iir_is_zero+0x34/0xa0
Call Trace:
gen8_de_irq_postinstall+0xad/0x330
gen8_irq_postinstall+0x23/0x80
drm_irq_install+0xb5/0x130
i915_driver_load+0xafd/0xf70
--------
Since GVT-g won't simulate EDP to guest, always set EDP_PSR_IMR
and EDP_PSR_IIR IMR/IIR to 0.
Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:44 +0000 (10:35 +0800)]
drm/i915/gvt: Handle special sequence on PDE IPS bit
If the guest update the 64K gtt entry before changing IPS bit of PDE, we
need to re-shadow the whole page table. Because we have ignored all
updates to unused entries.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:43 +0000 (10:35 +0800)]
drm/i915/gvt: Add 2M huge gtt support
This add 2M huge gtt support for GVTg. Unlike 64K gtt entry, we can
shadow 2M guest entry with real huge gtt. But before that, we have to
check memory physical continuous, alignment and if it is supported on
the host. We can get all supported page sizes from
intel_device_info.page_sizes.
Finally we must split the 2M page into smaller pages if we cannot
satisfy guest Huge Page.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:42 +0000 (10:35 +0800)]
drm/i915/kvmgt: Support setting dma map for huge pages
To support huge gtt, we need to support huge pages in kvmgt first.
This patch adds a 'size' param to the intel_gvt_mpt::dma_map_guest_page
API and implements it in kvmgt.
v2: rebase.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:41 +0000 (10:35 +0800)]
drm/i915/gvt: Add 64K huge gtt support
Finally, this add the first huge gtt support for GVTg - 64K pages. Since
64K page and 4K page cannot be mixed on the same page table, so we always
split a 64K entry into small 4K page. And when unshadow guest 64K entry,
we need ensure all the shadowed entries in shadow page table also get
cleared.
For page table which has 64K gtt entry, only PTE#0, PTE#16, PTE#32, ...
PTE#496 are used. Unused PTEs update should be ignored.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:39 +0000 (10:35 +0800)]
drm/i915/gvt: Split ppgtt_alloc_spt into two parts
We need a interface to allocate a pure shadow page which doesn't have
a guest page associated with. Such shadow page is used to shadow 2M
huge gtt entry.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Changbin Du [Tue, 15 May 2018 02:35:33 +0000 (10:35 +0800)]
drm/i915/gvt: Add new 64K entry type
Add a new entry type GTT_TYPE_PPGTT_PTE_64K_ENTRY. 64K entry is very
different from 2M/1G entry. 64K entry is controlled by IPS bit in upper
PDE. To leverage the current logic, I take IPS bit as 'PSE' for PTE
level. Which means, 64K entries can also processed by get_pse_type().
v2: Make it bisectable.
Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Colin Xu [Mon, 11 Jun 2018 07:39:40 +0000 (15:39 +0800)]
drm/i915: Enable KVMGT for BXT.
Enable KVMGT for BXT.
is_supported_device() acting as the gatekeeper of GVT-g init.
If all supported platforms share the same configurations for some
specific feature, platform check will rely on this check only.
Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Colin Xu [Mon, 11 Jun 2018 07:39:37 +0000 (15:39 +0800)]
drm/i915/gvt: Enable virtual display support for BXT.
Virtual monitor on BXT start from port B.
Unlike SKL/KBL, digital display port connectivity is detected via
GEN8_DE_PORT_ISR so emulate monitor state change by setting it.
Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Chris Wilson [Wed, 6 Jun 2018 14:41:53 +0000 (15:41 +0100)]
drm/i915: Mark i915.inject_load_failure as being hit
When we reach the magic value and do inject a fault into our module load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load isn't actually aborted and the module (and
parameters) are left lingering. igt can then inspect the parameter on its
synchronous completion of modprobe to see if the fault injection was
successful, and will keeping on injecting new faults until the module
succeeds in loading having surpassed the number of fault points.
Chris Wilson [Tue, 5 Jun 2018 15:37:58 +0000 (16:37 +0100)]
drm/i915/gtt: Rename i915_hw_ppgtt base member
In the near future, I want to subclass gen6_hw_ppgtt as it contains a
few specialised members and I wish to add more. To avoid the ugliness of
using ppgtt->base.base, rename the i915_hw_ppgtt base member
(i915_address_space) as vm, which is our common shorthand for an
i915_address_space local.
Chris Wilson [Tue, 5 Jun 2018 16:06:23 +0000 (17:06 +0100)]
drm/i915/error: Fixup inactive/active counting
The inactive counter was over the active list, and vice versa.
Fortuitously this should not cause a problem in practice as they shared
the same array and clamped the number of entries they would write.
drm/i915/guc: Don't leak stage descriptor pool on init failure
In case of failure during GuC clients creation, we forget to
cleanup earlier pool allocation. Use proper teardown to fix that.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@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/20180605120547.16468-1-michal.wajdeczko@intel.com
Tvrtko Ursulin [Tue, 5 Jun 2018 14:02:53 +0000 (15:02 +0100)]
drm/i915/pmu: Do not assume fixed hrtimer period
As Chris has discovered on his Ivybridge, and later automated test runs
have confirmed, on most of our platforms hrtimer faced with heavy GPU load
can occasionally become sufficiently imprecise to affect PMU sampling
calculations.
This means we cannot assume sampling frequency is what we asked for, but
we need to measure the interval ourselves.
This patch is similar to Chris' original proposal for per-engine counters,
but instead of introducing a new set to work around the problem with
frequency sampling, it swaps around the way internal frequency accounting
is done. Instead of accumulating current frequency and dividing by
sampling frequency on readout, it accumulates frequency scaled by each
period.
v2:
* Typo in commit message, comment on period calculation and USEC_PER_SEC.
(Chris Wilson)
Chris Wilson [Tue, 5 Jun 2018 08:28:56 +0000 (09:28 +0100)]
drm/i915/gtt: Teach restore-gtt to walk the ggtt vma list not the object list
In preparation, for having non-vma objects stored inside the ggtt, to
handle restoration of the GGTT following resume, we need to walk over
the ggtt address space rebinding vma, as opposed to walking over bound
objects looking for ggtt entries.
v2: Skip objects only bound for the aliasing_ppgtt
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> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20180605082856.19221-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 5 Jun 2018 08:53:48 +0000 (09:53 +0100)]
drm/i915/ringbuffer: Make context pin/unpin symmetric
Currently, we have a special routine for pinning the context state at
the start of activity tracking, but lack the complementary unpin
routine. Create it to to ease later patches that want to do partial
teardown on error, and, not least, to improve the readability of the
code.
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180605085348.3018-1-chris@chris-wilson.co.uk
Changbin Du [Tue, 8 May 2018 09:07:05 +0000 (17:07 +0800)]
drm/i915: Add new vGPU cap info bit VGT_CAPS_HUGE_GTT
This adds a new vGPU cap info bit VGT_CAPS_HUGE_GTT, which is to detect
whether the host supports shadowing of huge gtt pages. If host does
support it, remove the page sizes restriction for vGPU.
Mahesh Kumar [Thu, 17 May 2018 13:26:26 +0000 (18:56 +0530)]
drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw
Do not update number of enabled dbuf slices in dev_priv struct until we
actually enable/disable dbuf slice in hw. This is leading to never
updating dbuf slices and resulting in DBuf slice mismatch warning.
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches exactly the hw_id stored into the context descriptor.
When using GuC submission we have an issue of a non matching hw_id
because GuC uses bit 20 of the hw_id to signal proxy submission. This
change introduces a mask to compare only the relevant bits.
On ICL the context descriptor format has changed and we failed to
address this. On top of using a mask we also need to shift the bits
properly.
v2: Reuse lrc_desc rather than recomputing part of it (Chris/Michel)
v3: Always pin the context we're filtering with (Chris)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252
BSpec: 1237
Testcase: igt/perf/gen8-unprivileged-single-ctx-counters Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180602112946.30803-3-lionel.g.landwerlin@intel.com Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org
drm/i915: drop one bit on the hw_id when using guc
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate 1048576+ contexts to hit this issue. Still, we should avoid allocating
the hw_id on that bit and restriction to bits [0:19] (i.e 20bits
instead of 21).
v2: Leave the max hw_id computation in i915_gem_context.c (Michel)
Chris Wilson [Mon, 4 Jun 2018 13:15:52 +0000 (14:15 +0100)]
drm/i915/gtt: Remove obsolete switch_mm hooks for gen8+
As the ppgtt for execlists is tightly coupled to the executing context,
and not switch separately, we no longer use the ppgtt->switch_mm hooks
on gen8+. Remove them.
References: 79e6770cb1f5 ("drm/i915: Remove obsolete ringbuffer emission for gen8+") 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> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180604131552.29370-1-chris@chris-wilson.co.uk
Manasi Navare [Wed, 23 May 2018 22:44:44 +0000 (15:44 -0700)]
drm/i915/icl: Get DDI clock for ICL based on PLLs.
PLLs are the source clocks for the DDIs so in order
to determine the ddi clock we need to check the PLL
configuration.
This gets a little tricky for ICL since there is
no register bit that maps directly to the link clock.
So this patch creates a separate function in intel_dpll_mgr.c
to obtain the write array PLL Params and compares the set
pll_params with the table to get the corresponding link
clock.
v2:
- Fix the encoder type check (DK).
- Improve our error checking, return a sane value (Mika, Paulo).
- Fix table entries (Paulo).
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Paulo: implement v2] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180523224444.19017-1-paulo.r.zanoni@intel.com
Manasi Navare [Fri, 25 May 2018 19:03:52 +0000 (12:03 -0700)]
drm/i915/icl: Add register definition for DFLEXDPMLE
DFLEXDPMLE register is required to tell the FIA hardware which
main links of DP are enabled on TCC Connectors. FIA uses this
information to program PHY to Controller signal mapping.
This register is applicable in both TC connector's Alternate mode
as well as DP connector mode.
v2:
* Remove _ICL prefix since the reg is first introduced
in ICL (Paulo)
* s/ICL/icl in commit message (Lucas)
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@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/1527275032-4555-1-git-send-email-manasi.d.navare@intel.com
Paulo Zanoni [Tue, 22 May 2018 00:25:37 +0000 (17:25 -0700)]
drm/i915/icl: introduce tc_port
Add and enum for TC ports and auxiliary functions to handle them.
Icelake brings a lot of registers and other things that only apply to
the TC ports and are indexed starting from 0, so having an enum for
tc_ports that starts at 0 really helps the indexing.
This patch is based on previous patches written by Dhinakaran Pandiyan
and Mahesh Kumar.
Chris Wilson [Fri, 1 Jun 2018 14:41:25 +0000 (15:41 +0100)]
drm/i915: Apply the full CPU domain markup before freezing
Let's not take any chances by using a shortcut to mark the objects as in
the CPU domain upon freezing (all pages will be written to disk and so
on restore all objects will start from the CPU domain). Currently, we
simply mark the objects as being in the CPU domain, bypassing the
flushes. Let's call the full domain transfer function so that we have
less special case code (and symmetry with the suspend path) even though
it will be mostly redundant.
Chris Wilson [Fri, 1 Jun 2018 14:41:24 +0000 (15:41 +0100)]
drm/i915: Flush all writes before suspend
As we have already suspended the device, this should be a no-op except
for marking that all writes are indeed complete. The downside is that
we then have to walk all the lists of objects for what should be a no-op
(in some cases they will be mmio read to ensure the GGTT writes are
indeed flushed, and clflushes to ensure that cpu writes are in memory).
It seems prudent and the safer course for us to ensure all writes are
flushed to memory before suspend.
Set up the SKL+ scaler initial phase registers correctly. Otherwise
we start fetching the data from the center of the first pixel instead
of the top-left corner, which obviously then leads to right/bottom edges
replicating data excessively as the data runs out half a pixel too soon.
Ville Syrjälä [Tue, 30 Jan 2018 20:38:05 +0000 (22:38 +0200)]
drm/i915: Disable trickle feed for SNB/IVB cursors
We disable trickle feed whenever possible, except for the cursors
on SNB/IVB. Let's try disabling it there too if for no other reason
than consistency.
Ville Syrjälä [Wed, 31 Jan 2018 14:37:09 +0000 (16:37 +0200)]
drm/i915: Clean up cursor defines
Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865
cursor defines consistently, and move the pipe CSC enable bit next
to the other non-845/865 cursor defines.
v2: Take care of gvt uses as well
v3: Another gvt use popped up
Ville Syrjälä [Tue, 30 Jan 2018 20:38:03 +0000 (22:38 +0200)]
drm/i915: Have plane->get_hw_state() return the current pipe
Like we do for encoder let's make the plane->get_hw_state() return
the pipe to which the plane is currently attached. We don't currently
allow planes to move between the pipes, but perhaps one day we will.
In either case this makes the code more uniform and perhaps makes
intel_plane_mapping_ok() slightly more clear.
Note that for i965 and g4x planes A and B still have pipe select bits
but they're hardwired to pipe A and B respectively. This means we can
safely interpret those bits just like on gen2/3. This allows the
same readout code work for plane C (which can still be assigned
to eiter pipe on i965) should we ever expose it.
g4x no longer allows moving the cursor planes between the pipes,
but the pipe select bits can still be set in the register. Thus
we have to ignore those bits. OTOH i965 still allows the cursors
to move between pipes thus we have to trust the bits there.
Chris Wilson [Fri, 1 Jun 2018 09:35:50 +0000 (10:35 +0100)]
drm/i915/gtt: Don't restore the non-existent PDE for GGTT
On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we
switch on full-ppgtt, there is then one address space with no PDE, the
GGTT. Currently under aliasing-ppgtt, the GGTT address space does have
an associated ppgtt and so the restore works just fine. We would have a
similar problem if we tried disabling aliasing-ppgtt
(i915.enable_ppgtt=0). So skip the empty ppgtt, as being non-existent it
doesn't need restoring.
On hsw and older, we do not need to allocate the ppgtt on the fly and so
ppgtt->allocate_va_range() is NULL. Fixup ppgtt_bind_vma not to call it,
in that case!
Chris Wilson [Fri, 1 Jun 2018 09:40:02 +0000 (10:40 +0100)]
drm/i915: Check intel_contexts to avoid one extra pointer chase
As we store the intel_context on the request (rq->hw_context), we can
simply compare that against the local intel_context for the
i915->kernel_context rather than using the rq->gem_context.
Chris Wilson [Thu, 31 May 2018 08:22:46 +0000 (09:22 +0100)]
drm/i915: Only sanitize GEM from late suspend
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset to its defaults. A simple way around this is to skip the
sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late.
Chris Wilson [Thu, 31 May 2018 08:22:45 +0000 (09:22 +0100)]
drm/i915: After reset on sanitization, reset the engine backends
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
Chris Wilson [Thu, 31 May 2018 08:22:44 +0000 (09:22 +0100)]
drm/i915: "Race-to-idle" after switching to the kernel context
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is also used to enforce
a barrier before changing OA properties, and when evicting active
rendering from the global GTT. All cases where we do want to
race-to-idle.
v2: Limit the boosting to only the switch before suspend.
v3: Limit it to the wait-for-idle on suspend.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: David Weinehall <david.weinehall@linux.intel.com> #v1 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 31 May 2018 08:22:43 +0000 (09:22 +0100)]
drm/i915: Switch to kernel context before idling at runtime
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through the slow and irregular retire work handler.
Michal Wajdeczko [Mon, 28 May 2018 17:16:18 +0000 (17:16 +0000)]
drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
those events are now handled by intel_guc_to_host_event_handler_mmio().
We should not try to read it on MMIO action error as 1) we may be using
different set of registers for GuC MMIO communication, and 2) GuC may
use CTB mechanism for sending events to host.
While here, upgrade error message to DRM_ERROR.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20180528171618.10436-1-michal.wajdeczko@intel.com
drm/i915: Call intel_opregion_notify_encoder in intel_sanitize_encoder, v2.
Normally this is called on a modeset, but the call is missing when
we inherit the mode from the BIOS, so make sure it's called somewhere
in hardware readout.
Changes since v1:
- Unconditionally call intel_opregion_notify_encoder. (Ville)
Chris Wilson [Tue, 29 May 2018 13:29:18 +0000 (14:29 +0100)]
drm/i915: Remove stale asserts from i915_gem_find_active_request()
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.
The second assert removed (that request->engine == engine) remains
valid, but is now more rigorously checked during retirement.
Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to standalone") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180529132922.6831-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
drm/i915/psr: Set idle frame count based on sink synchronization latency
DPCD 2009h "Synchronization latency in sink" has bits that tell us the
maximum number of frames sink can take to resynchronize to source timing
when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
number of frames following PSR exit that the Source device needs to
wait for PSR entry."
We currently use this value only to setup the number frames to wait before
PSR2 selective update. But, based on the above description it makes more
sense to use this to configure idle frames for both PSR1 and and PSR2. This
will ensure we wait the required number of frames before
activation whether it is PSR1 or PSR2.
The minimum number of idle frames remains 6, while allowing sink
synchronization latency and VBT to increase this value.
This also solves the flip-flop between sink and source frames that I
noticed on my Thinkpad X260 during PSR exit. This specific panel has a
value of 8h, which according to the spec means the "Source device must
wait for more than eight active frames after PSR exit before initiating PSR
entry. (In this case, should be provided by the panel supplier.)" VBT
however has a value of 0.
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose 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> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525033047.7596-1-dhinakaran.pandiyan@intel.com
Oscar Mateo [Fri, 25 May 2018 22:05:29 +0000 (15:05 -0700)]
drm/i915/icl: WaDisableImprovedTdlClkGating
Revert to the legacy implementation.
v2: GEN7_ROW_CHICKEN2 is masked
v3:
- Rebased
- Renamed to Wa_2006611047
- A0 and B0 only
v4:
- Add spaces around '<<' (and fix the surrounding code as well)
- Mark the WA as pre-prod
v5: Rebased on top of the WA refactoring
v6: Added References (Mika)
v7: Fixed in B0
Michal Wajdeczko [Fri, 25 May 2018 12:18:58 +0000 (12:18 +0000)]
drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
v4: rebased
v5: rebased, pulled out from the series
Ville Syrjälä [Thu, 24 May 2018 19:04:06 +0000 (22:04 +0300)]
drm/i915: Simplify ilk-ivb underrun suppression
Let's suppress the underruns around every modeset sequence instead
of trying to avoid it. Planes are disabled at this point anyway so
we don't really gain anything from keeping the underrun reporting
enabled. Also for PCH ports we already suppress all underruns here
anyway so trying avoid it for the CPU eDP doesn't seem all that
important.
Maybe this gets rid of some lingering spurious underruns?
Ville Syrjälä [Fri, 18 May 2018 15:01:38 +0000 (18:01 +0300)]
drm/i915: Consult VBT "LVDS config" bits to determine whether internal LVDS is present
VBT seems to have some bits to tell us whether the internal LVDS port
has something hooked up. In theory one might expect the VBT to not have
a child device for the LVDS port if there's no panel hooked up, but
in practice many VBTs still add the child device. The "LVDS config" bits
seem more reliable though, so let's check those.
So far we've used the "LVDS config" bits to check for eDP support on
ILK+, and disable the internal LVDS when the value is 3. That value
is actually documented as "Both internal LVDS and SDVO LVDS", but in
practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's
keep that interpretation, but for pre-ILK we will consider the value
3 to also indicate the presence of the internal LVDS.
Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an
effort to reduce that let's toss in a WARN when the DMI match and VBT
both tell us that the internal LVDS is not present. The hope is that
people will report a bug, and then we can just nuke the corresponding
entry from the DMI quirk list. Credits to Jani for this idea.
v2: Split the basic int_lvds_support thing to a separate patch (Jani)
v3: Rebase
v4: Limit this to VBT version >= 134
Ville Syrjälä [Thu, 24 May 2018 19:04:05 +0000 (22:04 +0300)]
drm/i915: Try to suppress more spurious PCH underruns on ILK-IVB
My ILK seems to generate a spurious PCH underrun with most interlaced
HDMI modes. Add a second vblank wait to avoid it.
We have seen some spurious PCH underruns still in CI as well, some
of which seem to be progressive DP. The logs also point towards some
spurious underrins with progressive HDMI on SNB. While I don't have
a solid explanation for those let's try to kill all the birds with one
stone and always do the double wait.
Ville Syrjälä [Wed, 23 May 2018 14:57:18 +0000 (17:57 +0300)]
drm/i915: Initialize panel_pipe to INVALID_PIPE
We can always figure out which pipe is affected by the panel power
sequencer lockout mechanism. So no need for the pipe A fallback
anymore. The only case we may have to worry about is an invalid
port select in the power sequencer, but INVALID_PIPE is just fine
in that case. We'll get the WARN about the bogus pps port select
anyway.
Chris Wilson [Fri, 25 May 2018 09:26:29 +0000 (10:26 +0100)]
drm/i915: Prepare GEM for suspend earlier
In order to prepare the GPU for sleeping, we may want to submit commands
to it. This is a complicated process that may even require some swapping
in from shmemfs, if the GPU was in the wrong state. As such, we need to
do this preparation step synchronously before the rest of the system has
started to turn off (e.g. swapin fails if scsi is suspended).
Fortunately, we are provided with a such a hook, pm_ops.prepare().
v4: Ville pointed out that in some circumstances (such as switching off
the overlay) the display code may issue a GPU request. This is
unexpected, and will result in us going to sleep with us believing the
GPU is still awake (though all user work has been saved). Add a comment
to remind our future selves of what trouble brews.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Testcase: igt/drv_suspend after igt/gem_tiled_swapping Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180525092629.1456-1-chris@chris-wilson.co.uk Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Chris Wilson [Tue, 22 May 2018 10:19:37 +0000 (11:19 +0100)]
drm/i915/execlists: Wait for ELSP submission on restart
After a reset, we will ensure that there is at least one request
submitted to HW to ensure that a context is loaded for powersaving.
Let's wait for this submission via a tasklet to complete before we drop
our forcewake, ensuring the system is ready for rc6 before we let it
possibly sleep.
where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.
v2: Only clear the bit on restarting the ring, as we want to be sure the
STOP_RING bit is kept if reset fails on wedging.
v3: Spot when the ring state doesn't make sense when re-initialising the
engine and dump it to the logs so that we don't have to wait for an
error later and try to guess what happened earlier.
v4: Prepare to print all the unexpected state, not just the first.
Chris Wilson [Thu, 24 May 2018 08:11:35 +0000 (09:11 +0100)]
drm/i915: Look for an active kernel context before switching
We were not very carefully checking to see if an older request on the
engine was an earlier switch-to-kernel-context before deciding to emit a
new switch. The end result would be that we could get into a permanent
loop of trying to emit a new request to perform the switch simply to
flush the existing switch.
What we need is a means of tracking the completion of each timeline
versus the kernel context, that is to detect if a more recent request
has been submitted that would result in a switch away from the kernel
context. To realise this, we need only to look in our syncmap on the
kernel context and check that we have synchronized against all active
rings.
v2: Since all ringbuffer clients currently share the same timeline, we do
have to use the gem_context to distinguish clients.
As a bonus, include all the tracing used to debug the death inside
suspend.
v3: Test, test, test. Construct a selftest to exercise and assert the
expected behaviour that multiple switch-to-contexts do not emit
redundant requests.
Reported-by: Mika Kuoppala <mika.kuoppala@intel.com> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524081135.15278-1-chris@chris-wilson.co.uk
While touching the code around this, I noticed that absence of ALPM
capability does not stop us from enabling PSR2. But, the spec
unambiguously states that ALPM is required for PSR2 and so does this
commit that introduced this code
drm/i915/psr: enable ALPM for psr2
As per edp1.4 spec , alpm is required for psr2 operation as it's
used for all psr2 main link power down management and alpm enable
bit must be set for psr2 operation.
Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-6-dhinakaran.pandiyan@intel.com
drm/i915/psr: Fall back to max. synchronization latency if DPCD read fails
Noticed that we assume the best case of 0 latency when the DPCD read
fails, reasonable pessimism is safer.
eDP spec does say that if latency is greater than 8, the panel
supplier needs to provide it. I didn't see anything specific in the VBT
for this, so let's go with 8 frames as a fallback.