Skip to content

L
linux
Switch branch/tag
  1. 10 Dec, 2015 1 commit
  3. 09 Dec, 2015 6 commits
  5. 08 Dec, 2015 9 commits
  7. 07 Dec, 2015 6 commits
  9. 04 Dec, 2015 9 commits
  11. 03 Dec, 2015 9 commits
    • Maarten Lankhorst's avatar
      drm/i915: Handle cdclk limits on broadwell. · 63ba534e
      Maarten Lankhorst authored 
      As the comment indicates this can only fail gracefully when
called from compute_config. Fortunately this is now what's happening,
so the fixme can be removed and the DRM_ERROR downgraded.

Link: http://patchwork.freedesktop.org/patch/msgid/1448360945-5723-3-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      63ba534e
    • Alex Goins's avatar
      i915: wait for fence in prepare_plane_fb · 3c28ff22
      Alex Goins authored 
      In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive
fence

v2: First commit
v3: Remove object_name_lock acquire
    Move wait from intel_atomic_commit() to intel_prepare_plane_fb()
v4: Wait only on exclusive fences, interruptible with no timeout
v5: Style tweaks to more closely match rest of file
v6: Properly handle interrupted waits
v7: No change
v8: No change

Link: https://patchwork.kernel.org/patch/7704181/Signed-off-by: default avatarAlex Goins <agoins@nvidia.com>
Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      3c28ff22
    • Alex Goins's avatar
      i915: wait for fence in mmio_flip_work_func · fd8e058a
      Alex Goins authored 
      If a buffer is backed by dmabuf, wait on its reservation object's exclusive
fence before flipping.

v2: First commit
v3: Remove object_name_lock acquire
v4: Move wait ahead of mark_page_flip_active
    Use crtc->primary->fb to get GEM object instead of pending_flip_obj
    use_mmio_flip() return true when exclusive fence is attached
    Wait only on exclusive fences, interruptible with no timeout
v5: Move wait from do_mmio_flip to mmio_flip_work_func
    Style tweaks to more closely match rest of file
v6: Change back to unintteruptible wait to match __i915_wait_request due to
    inability to properly handle interrupted wait.
    Warn on error code from waiting.
v7: No change
v8: Test for !reservation_object_signaled_rcu(test_all=FALSE) instead of
    obj->base.dma_buf->resv->fence_excl

Link: https://patchwork.kernel.org/patch/7704181/Signed-off-by: default avatarAlex Goins <agoins@nvidia.com>
Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      fd8e058a
    • Nick Hoath's avatar
      drm/i915: Extend LRC pinning to cover GPU context writeback · 6d65ba94
      Nick Hoath authored 
      Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
This fixes an issue with GuC submission where the GPU might not
have finished writing back the context before it is unpinned. This
results in a GPU hang.

v2: Moved the new pin to cover GuC submission (Alex Dai)
    Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
    context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
    already have a request pending on it (Alex Dai)
    Rename unsaved to dirty to avoid double negatives (Dave Gordon)
    Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
    Split out per engine cleanup from context_free as it
    was getting unwieldy
    Corrected locking (Dave Gordon)
v6: Removed some bikeshedding (Mika Kuoppala)
    Added explanation of the GuC hang that this fixes (Daniel Vetter)
v7: Removed extra per request pinning from ring reset code (Alex Dai)
    Added forced ring unpin/clean in error case in context free (Alex Dai)
Signed-off-by: default avatarNick Hoath <nicholas.hoath@intel.com>
Issue: VIZ-4277
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: default avatarAlex Dai <yu.dai@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6d65ba94
    • Alex Dai's avatar
      drm/i915/guc: Clean up locks in GuC · 5a843307
      Alex Dai authored 
      For now, remove the spinlocks that protected the GuC's
statistics block and work queue; they are only accessed
by code that already holds the global struct_mutex, and
so are redundant (until the big struct_mutex rewrite!).

The specific problem that the spinlocks caused was that
if the work queue was full, the driver would try to
spinwait for one jiffy, but with interrupts disabled the
jiffy count would not advance, leading to a system hang.
The issue was found using test case igt/gem_close_race.

The new version will usleep() instead, still holding
the struct_mutex but without any spinlocks.

v4: Reorganize commit message (Dave Gordon)
v3: Remove unnecessary whitespace churn
v2: Clean up wq_lock too
v1: Clean up host2guc lock as well
Signed-off-by: default avatarAlex Dai <yu.dai@intel.com>
Reviewed-by: default avatarDave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449104189-27591-1-git-send-email-yu.dai@intel.comSigned-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5a843307
    • Paulo Zanoni's avatar
      drm/i915: only recompress FBC after flushing a drawing operation · ee7d6cfa
      Paulo Zanoni authored 
      There's no need to stop and restart FBC, which is quite expensive as
we have to revalidate the CRTC state. After flushing a drawing
operation we know the CRTC state hasn't changed, so a nuke
(recompress) should be fine.

v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order changes.
v4: Rewrite commit message (Chris).
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
      ee7d6cfa
    • Paulo Zanoni's avatar
      drm/i915: get rid of FBC {,de}activation messages · 820bcabb
      Paulo Zanoni authored 
      When running Cinnamon I see way too many pairs of these messages: many
per second. Get rid of them as they're just telling us FBC is working
as expected. We already have the messages for enable/disable, so we
don't really need messages for activation/deactivation.

v2: Rebase after changing the patch order.
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
      820bcabb
    • Paulo Zanoni's avatar
      drm/i915: kill fbc.uncompressed_size · 559d9135
      Paulo Zanoni authored 
      Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.

v2: Use drm_mm_node_allocated() (Chris).
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
      559d9135
    • Paulo Zanoni's avatar
      drm/i915: use a single intel_fbc_work struct · 128d7356
      Paulo Zanoni authored 
      This was already on my TODO list, and was requested both by Chris and
Ville, for different reasons. The advantages are avoiding a frequent
malloc/free pair, and the locality of having the work structure
embedded in dev_priv. The maximum used memory is also smaller since
previously we could have multiple allocated intel_fbc_work structs at
the same time, and now we'll always have a single one - the one
embedded on dev_priv. Of course, we're now using a little more memory
on the cases where there's nothing scheduled.

The biggest challenge here is to keep everything synchronized the way
it was before.

Currently, when we try to activate FBC, we allocate a new
intel_fbc_work structure. Then later when we conclude we must delay
the FBC activation a little more, we allocate a new intel_fbc_work
struct, and then adjust dev_priv->fbc.fbc_work to point to the new
struct. So when the old work runs - at intel_fbc_work_fn() - it will
check that dev_priv->fbc.fbc_work points to something else, so it does
nothing. Everything is also protected by fbc.lock.

Just cancelling the old delayed work doesn't work because we might
just cancel it after the work function already started to run, but
while it is still waiting to grab fbc.lock. That's why we use the
"dev_priv->fbc.fbc_work == work" check described in the paragraph
above.

So now that we have a single work struct we have to introduce a new
way to synchronize everything. So we're making the work function a
normal work instead of a delayed work, and it will be responsible for
sleeping the appropriate amount of time itself. This way, after it
wakes up it can grab the lock, ask "were we delayed or cancelled?" and
then go back to sleep, enable FBC or give up.

v2:
  - Spelling fixes.
  - Rebase after changing the patch order.
  - Fix ms/jiffies confusion.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
      128d7356
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7