Chris Wilson [Thu, 12 Oct 2017 12:57:24 +0000 (13:57 +0100)]
drm/i915: Fix eviction when the GGTT is idle but full
In the full-ppgtt world, we can fill the GGTT full of context objects.
These context objects are currently implicitly tracked by the requests
that pin them i.e. they are only unpinned when the request is completed
and retired, but we do not have the link from the vma to the request
(anymore). In order to unpin those contexts, we have to issue another
request and wait upon the switch to the kernel context.
The bug during eviction was that we assumed that a full GGTT meant we
would have requests on the GGTT timeline, and so we missed situations
where those requests where merely in flight (and when even they have not
yet been submitted to hw yet). The fix employed here is to change the
already-is-idle test to no look at the execution timeline, but count the
outstanding requests and then check that we have switched to the kernel
context. Erring on the side of overkill here just means that we stall a
little longer than may be strictly required, but we only expect to hit
this path in extreme corner cases where returning an erroneous error is
worse than the delay.
v2: Logical inversion when swapping over branches.
Ville Syrjälä [Thu, 12 Oct 2017 13:02:01 +0000 (16:02 +0300)]
drm/i915: Start tracking PSR state in crtc state
Add the minimal amount of PSR tracking into the crtc state. This allows
precomputing the possibility of using PSR correctly, and it means we can
safely call the psr enable/disable functions for any DP endcoder.
As a nice bonus we get rid of some more crtc->config usage, which we
want to kill off eventually.
v2: Fix 'goto unlock' fail in intel_psr_enable() (Jani)
Check intel_dp_is_edp() in is_edp_psr() (Jani)
Chris Wilson [Wed, 11 Oct 2017 14:18:57 +0000 (15:18 +0100)]
drm/i915/userptr: Drop struct_mutex before cleanup
Purely to silence lockdep, as we know that no bo can exist at this time
and so the inversion is impossible. Nevertheless, lockdep currently
warns on unload:
[ 137.522565] WARNING: possible circular locking dependency detected
[ 137.522568] 4.14.0-rc4-CI-CI_DRM_3209+ #1 Tainted: G U
[ 137.522570] ------------------------------------------------------
[ 137.522572] drv_module_relo/1532 is trying to acquire lock:
[ 137.522574] ("i915-userptr-acquire"){+.+.}, at: [<ffffffff8109a831>] flush_workqueue+0x91/0x540
[ 137.522581]
but task is already holding lock:
[ 137.522583] (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
[ 137.522605]
which lock already depends on the new lock.
Jani Nikula [Mon, 9 Oct 2017 09:29:58 +0000 (12:29 +0300)]
drm/i915/dp: centralize max source rate conditions more
Turn intel_dp_source_supports_hbr2() into a simple helper to query the
pre-filled source rates array, and move the conditions about which
platforms support which rates to the single point of truth in
intel_dp_set_source_rates().
This also reduces the code paths you have to think about in the source
rates initialization in intel_dp_set_source_rates(), making it easier to
grasp.
Ville Syrjälä [Mon, 9 Oct 2017 16:19:51 +0000 (19:19 +0300)]
drm/i915: Allow PCH platforms fall back to BIOS LVDS mode
With intel_encoder_current_mode() using the normal state readout code it
actually works on PCH platforms as well. So let's nuke the PCH check from
intel_lvds_init(). I suppose there aren't any machines that actually
need this, but at least we get to eliminate a few lines of code, and one
FIXME.
Ville Syrjälä [Mon, 9 Oct 2017 16:19:50 +0000 (19:19 +0300)]
drm/i915: Reuse normal state readout for LVDS/DVO fixed mode
Reuse the normal state readout code to get the fixed mode for LVDS/DVO
encoders. This removes some partially duplicated state readout code
from LVDS/DVO encoders. The duplicated code wasn't actually even
populating the negative h/vsync flags, leading to possible state checker
complaints. The normal readout code populates that stuff fully.
Daniel Vetter [Wed, 11 Oct 2017 09:10:19 +0000 (11:10 +0200)]
drm/i915: Use rcu instead of stop_machine in set_wedged
stop_machine is not really a locking primitive we should use, except
when the hw folks tell us the hw is broken and that's the only way to
work around it.
This patch tries to address the locking abuse of stop_machine() from
drm/i915: Stop the machine as we install the wedged submit_request handler
Chris said parts of the reasons for going with stop_machine() was that
it's no overhead for the fast-path. But these callbacks use irqsave
spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
To stay as close as possible to the stop_machine semantics we first
update all the submit function pointers to the nop handler, then call
synchronize_rcu() to make sure no new requests can be submitted. This
should give us exactly the huge barrier we want.
I pondered whether we should annotate engine->submit_request as __rcu
and use rcu_assign_pointer and rcu_dereference on it. But the reason
behind those is to make sure the compiler/cpu barriers are there for
when you have an actual data structure you point at, to make sure all
the writes are seen correctly on the read side. But we just have a
function pointer, and .text isn't changed, so no need for these
barriers and hence no need for annotations.
Unfortunately there's a complication with the call to
intel_engine_init_global_seqno:
- Without stop_machine we must hold the corresponding spinlock.
- Without stop_machine we must ensure that all requests are marked as
having failed with dma_fence_set_error() before we call it. That
means we need to split the nop request submission into two phases,
both synchronized with rcu:
1. Only stop submitting the requests to hw and mark them as failed.
2. After all pending requests in the scheduler/ring are suitably
marked up as failed and we can force complete them all, also force
complete by calling intel_engine_init_global_seqno().
This should fix the followwing lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc3-CI-CI_DRM_3179+ #1 Tainted: G U
------------------------------------------------------
kworker/3:4/562 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8113d4bc>] stop_machine+0x1c/0x40
but task is already holding lock:
(&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
v2: Have 1 global synchronize_rcu() barrier across all engines, and
improve commit message.
v3: We need to protect the seqno update with the timeline spinlock (in
set_wedged) to avoid racing with other updates of the seqno, like we
already do in nop_submit_request (Chris).
v4: Use two-phase sequence to plug the race Chris spotted where we can
complete requests before they're marked up with -EIO.
v5: Review from Chris:
- simplify nop_submit_request.
- Add comment to rcu_read_lock section.
- Align comments with the new style.
v6: Remove unused variable to appease CI.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102886
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103096 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171011091019.1425-1-daniel.vetter@ffwll.ch
drm/i915: Create generic functions to control RC6, RPS
Prepared generic functions intel_enable_rc6, intel_disable_rc6,
intel_enable_rps and intel_disable_rps functions to setup RC6/RPS
based on platforms.
v2: Make intel_enable/disable_rc6/rps static. (Chris)
v3: Added lockdep_assert_held(dev_priv->pcu_lock) in new generic
functions. (Chris)
Removed WARN_ON(&dev_priv->pcu_lock) from lower level functions as generic
function now has lockdep_assert. Rebase.
drm/i915: Rename intel_enable_rc6 to intel_rc6_enabled
This function gives the status of RC6, whether disabled or if
enabled then which state. intel_enable_rc6 will be used for
enabling RC6 in the next patch.
drm/i915: Name structure in dev_priv that contains RPS/RC6 state as "gt_pm"
Prepared substructure rps for RPS related state. autoenable_work is
used for RC6 too hence it is defined outside rps structure. As we do
this lot many functions are refactored to use intel_rps *rps to access
rps related members. Hence renamed intel_rps_client pointer variables
to rps_client in various functions.
v2: Rebase.
v3: s/pm/gt_pm (Chris)
Refactored access to rps structure by declaring struct intel_rps * in
many functions.
drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lock
In order to separate GT PM related functionality into new structure
we are updating rps structure. hw_lock in it is used for display
related PCU communication too hence move it to dev_priv.
This patch separates RC6 and RPS enabling for BDW.
RC6/RPS Disabling are handled through gen6 functions.
PM Programming guide recommends a sequence within forcewakes to
configure RC6, RPS and ring frequencies in sequence. With this
patch the order is still maintained.
v2: Update sequence numbers in RC6 programming and comment about
intent of reset_rps during gen8_enable_rps. (Radoslaw)
Matthew Auld [Tue, 10 Oct 2017 13:30:30 +0000 (14:30 +0100)]
drm/i915/selftests: ditch the kernel context
There's really no good reason to be using the kernel context for the
huge-page livetests. Also with the introduction of commit bef27bdb6cfb
("drm/i915: Assert we do not try to expand VMA for hugepage inside GGTT")
we start hitting the bug on in the selftests, since the kernel context
will always return true for i915_vma_is_ggtt(), so now seems like the
opportune time to instead create our own context.
Fixes: 4049866f0913 ("drm/i915/selftests: huge page tests") Fixes: bef27bdb6cfb ("drm/i915: Assert we do not try to expand VMA for hugepage inside GGTT") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010133030.12112-1-matthew.auld@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Tue, 10 Oct 2017 11:10:05 +0000 (12:10 +0100)]
drm/i915: Silently fallback to 4k scratch
If we fail to allocate a 64k hugepage for scratch, we try again with a
normal 4k page (with some loss of efficiency at runtime). As we handle
this gracefully, we do not need a noisy allocation failure warning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010111005.13625-1-chris@chris-wilson.co.uk Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Daniel Vetter [Tue, 10 Oct 2017 09:18:16 +0000 (11:18 +0200)]
drm/i915: Increase atomic update vblank evasion time with lockdep
All our mmio writes take forever with lockdep due to the constant
lock acquire&dropping we do. Ville has some patches to only acquire
the mmio spinlocks once instead for every single mmio, but those
aren't ready yet.
As an interim solution just extend our budget slightly when lockdep is
enabled, to avoid the rare and sporadic noise in CI.
v2: I forgot to add the FIXME comment ...
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103169
References: https://bugs.freedesktop.org/show_bug.cgi?id=103124
References: https://bugs.freedesktop.org/show_bug.cgi?id=102403
References: https://bugs.freedesktop.org/show_bug.cgi?id=103020
References: https://bugs.freedesktop.org/show_bug.cgi?id=103019
References: https://bugs.freedesktop.org/show_bug.cgi?id=102723
References: https://bugs.freedesktop.org/show_bug.cgi?id=102544
References: https://bugs.freedesktop.org/show_bug.cgi?id=103180 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171010091816.26898-1-daniel.vetter@ffwll.ch
Mika Kuoppala [Tue, 10 Oct 2017 11:48:57 +0000 (14:48 +0300)]
drm/i915: Use execlists_num_ports instead of size of array
There is function to tell how many ports we have, so use it.
We still have direct relationship with array size and port count,
so no harm was done.
Fixes: 76e70087d360 ("drm/i915: Make execlist port count variable") Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010114857.13108-1-mika.kuoppala@intel.com
Daniel Vetter [Mon, 9 Oct 2017 16:44:00 +0000 (18:44 +0200)]
drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock
4.14-rc1 gained the fancy new cross-release support in lockdep, which
seems to have uncovered a few more rules about what is allowed and
isn't.
This one here seems to indicate that allocating a work-queue while
holding mmap_sem is a no-go, so let's try to preallocate it.
Of course another way to break this chain would be somewhere in the
cpu hotplug code, since this isn't the only trace we're finding now
which goes through msr_create_device.
Full lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc1-CI-CI_DRM_3118+ #1 Tainted: G U
------------------------------------------------------
prime_mmap/1551 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8109dbb7>] apply_workqueue_attrs+0x17/0x50
but task is already holding lock:
(&dev_priv->mm_lock){+.+.}, at: [<ffffffffa01a7b2a>] i915_gem_userptr_init__mmu_notifier+0x14a/0x270 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
Note that this also has the minor benefit of slightly reducing the
critical section where we hold mmap_sem.
v2: Set ret correctly when we raced with another thread.
v3: Use Chris' diff. Attach the right lockdep splat.
v4: Repaint in Tvrtko's colors (aka don't report ENOMEM if we race and
some other thread managed to not also get an ENOMEM and successfully
install the mmu notifier. Note that the kernel guarantees that small
allocations succeed, so this never actually happens).
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Sasha Levin <alexander.levin@verizon.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Tejun Heo <tj@kernel.org>
References: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3180/shard-hsw3/igt@prime_mmap@test_userptr.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102939 Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171009164401.16035-1-daniel.vetter@ffwll.ch
Jani Nikula [Thu, 28 Sep 2017 08:22:03 +0000 (11:22 +0300)]
drm/i915/bios: parse SDVO device mapping from pre-parsed child devices
We parse and store the child devices in
parse_general_definitions(). There is no need to parse the VBT block
again for SDVO device mapping. Do the same as we do in
parse_ddi_ports().
We no longer have access to child device size at this stage, but we also
don't need to worry about reading past the child device anymore. Instead
of a child device size check, do a mild optimization by limiting the
parsing to gens 3 through 7.
Jani Nikula [Thu, 28 Sep 2017 08:21:59 +0000 (11:21 +0300)]
drm/i915/bios: don't initialize fields based on vbt version
In theory, these might clobber information for older VBT versions.
We might have to store the BDB version for later parsing, but currently
all code accessing these fields will only use them on newer platforms
with new enough BDB versions.
Jani Nikula [Thu, 28 Sep 2017 08:21:57 +0000 (11:21 +0300)]
drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel
While technically CHV isn't DDI, we do look at the VBT based DDI port
info for HDMI DDC pin and DP AUX channel. (We call these "alternate",
but they're really just something that aren't platform defaults.)
In commit e4ab73a13291 ("drm/i915: Respect alternate_ddc_pin for all DDI
ports") Ville writes, "IIRC there may be CHV system that might actually
need this."
I'm not sure why there couldn't be even more platforms that need this,
but start conservative, and parse the info for CHV in addition to DDI.
Paulo Zanoni [Thu, 5 Oct 2017 21:38:42 +0000 (18:38 -0300)]
drm/i915: avoid division by zero on cnl_calc_wrpll_link
If for some unexpected reason the registers all read zero it's better
to WARN and return instead of dividing by zero and completely freezing
the machine.
I don't expect this to happen in the wild with the current code, but I
accidentally triggered the division by zero while doing some debugging
in an unusual environment.
Matthew Auld [Mon, 9 Oct 2017 11:00:24 +0000 (12:00 +0100)]
drm/i915: s/sg_mask/sg_page_sizes/
It's a little unclear what the sg_mask actually is, so prefer the more
meaningful name of sg_page_sizes.
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171009110024.29114-1-matthew.auld@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Mon, 9 Oct 2017 08:44:01 +0000 (09:44 +0100)]
drm/i915: Early rejection of mappable GGTT pin attempts for large bo
Currently, we reject attempting to pin a large bo into the mappable
aperture, but only after trying to create the vma. Under debug kernels,
repeatedly creating and freeing that vma for an oversized bo consumes
one-third of the runtime for pwrite/pread tests as it is spent on
kmalloc/kfree tracking. If we move the rejection to before creating that
vma, we lose some accuracy of checking against the fence_size as opposed
to object size, though the fence can never be smaller than the object.
Note that the vma creation itself will reject an attempt to create a vma
larger than the GTT so we can remove one redundant test.
Chris Wilson [Mon, 9 Oct 2017 08:44:00 +0000 (09:44 +0100)]
drm/i915: Avoid evicting user fault mappable vma for pread/pwrite
Both pread/pwrite GTT paths provide a fast fallback in case we cannot
map the whole object at a time. Currently, we use the fallback for very
large objects and for active objects that would require remapping, but
we can also add active fault mappable objects to the list that we want
to avoid evicting. The rationale is that such fault mappable objects are
in active use and to evict requires tearing down the CPU PTE and forcing
a page fault on the next access; more costly, and intefers with other
processes, than our per-page GTT fallback.
Chris Wilson [Mon, 9 Oct 2017 08:43:59 +0000 (09:43 +0100)]
drm/i915: Try a minimal attempt to insert the whole object for relocations
As we have a lightweight fallback to insert a single page into the
aperture, try to avoid any heavier evictions when attempting to insert
the entire object.
Chris Wilson [Mon, 9 Oct 2017 08:43:58 +0000 (09:43 +0100)]
drm/i915: Check PIN_NONFAULT overlaps in evict_for_node
If the caller says that he doesn't want to evict any other faulting
vma, honour that flag. The logic was used in evict_something, but not
the more specific evict_for_node, now being used as a preliminary probe
since commit 606fec956c0e ("drm/i915: Prefer random replacement before
eviction search").
Fixes: 606fec956c0e ("drm/i915: Prefer random replacement before eviction search") Fixes: 821188778b9b ("drm/i915: Choose not to evict faultable objects from the GGTT")
References: https://bugs.freedesktop.org/show_bug.cgi?id=102490 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171009084401.29090-4-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Mon, 9 Oct 2017 08:43:57 +0000 (09:43 +0100)]
drm/i915: Track user GTT faulting per-vma
We don't wish to refault the entire object (other vma) when unbinding
one partial vma. To do this track which vma have been faulted into the
user's address space.
v2: Use a local vma_offset to tidy up a multiline unmap_mapping_range().
Chris Wilson [Mon, 9 Oct 2017 08:43:56 +0000 (09:43 +0100)]
drm/i915: Consolidate get_fence with pin_fence
Following the pattern now used for obj->mm.pages, use just pin_fence and
unpin_fence to control access to the fence registers. I.e. instead of
calling get_fence(); pin_fence(), we now just need to call pin_fence().
This will make it easier to reduce the locking requirements around
fence registers.
Chris Wilson [Mon, 9 Oct 2017 08:43:55 +0000 (09:43 +0100)]
drm/i915: Pin fence for iomap
Acquire the fence register for the iomap in i915_vma_pin_iomap() on
behalf of the caller.
We probably want for the caller to specify whether the fence should be
pinned for their usage, but at the moment all callers do want the
associated fence, or none, so take it on their behalf.
Chris Wilson [Mon, 9 Oct 2017 11:03:01 +0000 (12:03 +0100)]
drm/i915: Provide an assert for when we expect forcewake to be held
Add assert_forcewakes_active() (the complementary function to
assert_forcewakes_inactive) that documents the requirement of a
function for its callers to be holding the forcewake ref (i.e. the
function is part of a sequence over which RC6 must be prevented).
One such example is during ringbuffer reset, where RC6 must be held
across the whole reinitialisation sequence.
v2: Include debug information in the WARN so we know which fw domain is
missing.
Chris Wilson [Mon, 9 Oct 2017 11:03:00 +0000 (12:03 +0100)]
drm/i915/selftests: Hold the rpm wakeref for the reset tests
The lowlevel reset functions expect the caller to be holding the rpm
wakeref for the device access across the reset. We were not explicitly
doing this in the sefltest, so for simplicity acquire the wakeref for
the duration of all subtests.
Chris Wilson [Mon, 9 Oct 2017 11:02:59 +0000 (12:02 +0100)]
drm/i915: Hold forcewake for the duration of reset+restart
Resetting the engine requires us to hold the forcewake wakeref to
prevent RC6 trying to happen in the middle of the reset sequence. The
consequence of an unwanted RC6 event in the middle is that random state
is then saved to the powercontext and restored later, which may
overwrite the mmio state we need to preserve (e.g. PD_DIR_BASE in the
legacy ringbuffer reset_ring_common()).
This was noticed in the live_hangcheck selftests when Haswell would
sporadically fail to restart during igt_reset_queue().
Chris Wilson [Mon, 9 Oct 2017 11:02:57 +0000 (12:02 +0100)]
drm/i915: Make i915_engine_info pretty printer to standalone
We can use drm_printer to hide the differences between printk and
seq_printf, and so make the i915_engine_info pretty printer able to be
called from different contexts and not just debugfs. For instance, I
want to use the pretty printer to debug kselftests.
Chris Wilson [Mon, 9 Oct 2017 09:20:19 +0000 (10:20 +0100)]
drm/i915: Assert we do not try to expand VMA for hugepage inside GGTT
We only apply the hugepage PD redirection inside the ppGTT, so during
i915_vma_insert() we want to exclude the GGTT from the additional
alignment constraints (thereby avoiding the extra GTT pressure from
fragmentation). Add an assert to document that intention alongside the
comment.
v2: After discussion with Matthew, make it a blanket GGTT ban
(previously we allowed the expansion for appgtt, and so indirectly
ggtt). There are issues we need to fix before allowing the current
appgtt to be used with hugepages, and if we do, we probably want more
care over when to expand/align, as the mappable aperture inside the ggtt
is precious.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171009092019.20747-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ville Syrjälä [Fri, 1 Apr 2016 15:37:25 +0000 (18:37 +0300)]
drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
intel_crtc->config->cpu_transcoder isn't yet filled out when
intel_crtc_mode_get() gets called during output probing, so we should
not use it there. Instead intel_crtc_mode_get() figures out the correct
transcoder on its own, and that's what we should use.
If the BIOS boots LVDS on pipe B, intel_crtc_mode_get() would actually
end up reading the timings from pipe A instead (since PIPE_A==0),
which clearly isn't what we want.
It looks to me like this may have been broken by
commit eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder")
as that one removed the early initialization of cpu_transcoder from
intel_crtc_init().
Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Rob Kramer <rob@solution-space.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Rob Kramer <rob@solution-space.com> Fixes: eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder")
References: https://lists.freedesktop.org/archives/dri-devel/2016-April/104142.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1459525046-19425-1-git-send-email-ville.syrjala@linux.intel.com
Matthew Auld [Fri, 6 Oct 2017 22:18:25 +0000 (23:18 +0100)]
drm/i915: add support for 64K scratch page
Before we can fully enable 64K pages, we need to first support a 64K
scratch page if we intend to support the case where we have object sizes
< 2M, since any scratch PTE must also point to a 64K region. Without
this our 64K usage is limited to objects which completely fill the
page-table, and therefore don't need any scratch.
Matthew Auld [Fri, 6 Oct 2017 22:18:21 +0000 (23:18 +0100)]
drm/i915: align 64K objects to 2M
We can't mix 64K and 4K pte's in the same page-table, so for now we
align 64K objects to 2M to avoid any potential mixing. This is
potentially wasteful but in reality shouldn't be too bad since this only
applies to the virtual address space of a 48b PPGTT.
Matthew Auld [Fri, 6 Oct 2017 22:18:20 +0000 (23:18 +0100)]
drm/i915: align the vma start to the largest gtt page size
For the 48b PPGTT try to align the vma start address to the required
page size boundary to guarantee we use said page size in the gtt. If we
are dealing with multiple page sizes, we can't guarantee anything and
just align to the largest. For soft pinning and objects which need to be
tightly packed into the lower 32bits we don't force any alignment.
v2: various improvements suggested by Chris
v3: use set_pages and better placement of page_sizes
Matthew Auld [Fri, 6 Oct 2017 22:18:19 +0000 (23:18 +0100)]
drm/i915: introduce vm set_pages/clear_pages
Move the setting/clearing of the vma->pages to a vm operation. Doing so
neatens things up a little, but more importantly gives us a sane place
to also set/clear the vma->pages_sizes, which we introduce later in
preparation for supporting huge-pages.
v2: remove redundant vma->pages check
v3: GEM_BUG_ON(vma->pages) following i915_vma_remove
Matthew Auld [Fri, 6 Oct 2017 22:18:18 +0000 (23:18 +0100)]
drm/i915: introduce page_size members
In preparation for supporting huge gtt pages for the ppgtt, we introduce
page size members for gem objects. We fill in the page sizes by
scanning the sg table.
v2: pass the sg_mask to set_pages
v3: calculate the sg_mask inline with populating the sg_table where
possible, and pass to set_pages along with the pages.
Matthew Auld [Fri, 6 Oct 2017 22:18:17 +0000 (23:18 +0100)]
drm/i915: push set_pages down to the callers
Each backend is now responsible for calling __i915_gem_object_set_pages
upon successfully gathering its backing storage. This eliminates the
inconsistency between the async and sync paths, which stands out even
more when we start throwing around an sg_mask in a later patch.
Matthew Auld [Fri, 6 Oct 2017 22:18:16 +0000 (23:18 +0100)]
drm/i915: introduce page_sizes field to dev_info
In preparation for huge gtt pages expose page_sizes as part of the
device info, to indicate the page sizes supported by the HW. Currently
only 4K is supported.
Matthew Auld [Fri, 6 Oct 2017 22:18:14 +0000 (23:18 +0100)]
drm/i915: introduce simple gemfs
Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
moves us away from the shmemfs shm_mnt, and gives us the much needed
flexibility to do things like set our own mount options, namely huge=
which should allow us to enable the use of transparent-huge-pages for
our shmem backed objects.
v2: various improvements suggested by Joonas
v3: move gemfs instance to i915.mm and simplify now that we have
file_setup_with_mnt
v4: fallback to tmpfs shm_mnt upon failure to setup gemfs
Matthew Auld [Fri, 6 Oct 2017 22:18:13 +0000 (23:18 +0100)]
mm/shmem: introduce shmem_file_setup_with_mnt
We are planning to use our own tmpfs mnt in i915 in place of the
shm_mnt, such that we can control the mount options, in particular
huge=, which we require to support huge-gtt-pages. So rather than roll
our own version of __shmem_file_setup, it would be preferred if we could
just give shmem our mnt, and let it do the rest.
Chris Wilson [Thu, 5 Oct 2017 19:10:05 +0000 (20:10 +0100)]
drm/i915/execlists: Add a comment for the extra MI_ARB_ENABLE
Michel Thierry noticed that we were applying WaDisableCtxRestoreArbitration
even to gen9, which does not require the w/a. The rationale is that we
need to enable MI arbitration for execlists to work, and to be safe we
do that before every batch (in addition to every context switch into the
batch). Since this is not clear from the single line comment suggesting
the MI_ARB_ENABLE is solely for the w/a, add a little more detail.
Chris Wilson [Fri, 6 Oct 2017 11:56:17 +0000 (12:56 +0100)]
drm/i915: Order two completing nop_submit_request
If two nop's (requests in-flight following a wedged device) complete at
the same time, the global_seqno value written to the HWSP is undefined
as the two threads are not serialized.
v2: Use irqsafe spinlock. We expect the callback may be called from
inside another irq spinlock, so we can't unconditionally restore irqs.
Chris Wilson [Mon, 2 Oct 2017 10:04:16 +0000 (11:04 +0100)]
drm/i915: Silence compiler warning for hsw_power_well_enable()
Not all compilers are able to determine that pg is guarded by wait_fuses
and so may think that pg is used uninitialized.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171002100416.25865-1-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
Chris Wilson [Fri, 6 Oct 2017 10:40:38 +0000 (11:40 +0100)]
drm/i915: Try harder to finish the idle-worker
If a worker requeues itself, it may switch to a different kworker pool,
which flush_work() considers as complete. To be strict, we then need to
keep flushing the work until it is no longer pending.
Joonas Lahtinen [Fri, 6 Oct 2017 08:49:40 +0000 (11:49 +0300)]
drm/i915: Unify uC variable types to avoid flooding checkpatch.pl
With the code motion mostly done, convert all the uC code away
from uint??_t at once (only a couple dozen variables), so that
reading the checkpatch.pl output should actually pinpoint if
a new uint??_t was accidentally introduced.
v2: - Include intel_uc_fw.h too (Sagar)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171006084940.15910-1-joonas.lahtinen@linux.intel.com
drm/i915: Use crtc_state_is_legacy_gamma in intel_color_check
crtc_state_is_legacy_gamma also checks for CTM, which was missing from
intel_color_check. By using the same condition for commit and check
we reduce the chance of mismatches.
This was spotted by KASAN while trying to rework kms_color igt test.
projects / mirror_ubuntu-bionic-kernel.git / log