1. 22 12月, 2015 4 次提交
  2. 21 12月, 2015 1 次提交
  3. 19 12月, 2015 3 次提交
  4. 17 12月, 2015 6 次提交
  5. 16 12月, 2015 4 次提交
  6. 12 12月, 2015 1 次提交
    • D
      drm/i915: mark GEM object pages dirty when mapped & written by the CPU · 033908ae
      Dave Gordon 提交于
      In various places, a single page of a (regular) GEM object is mapped into
      CPU address space and updated. In each such case, either the page or the
      the object should be marked dirty, to ensure that the modifications are
      not discarded if the object is evicted under memory pressure.
      
      The typical sequence is:
      	va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
      	*(va+offset) = ...
      	kunmap_atomic(va);
      
      Here we introduce i915_gem_object_get_dirty_page(), which performs the
      same operation as i915_gem_object_get_page() but with the side-effect
      of marking the returned page dirty in the pagecache.  This will ensure
      that if the object is subsequently evicted (due to memory pressure),
      the changes are written to backing store rather than discarded.
      
      Note that it works only for regular (shmfs-backed) GEM objects, but (at
      least for now) those are the only ones that are updated in this way --
      the objects in question are contexts and batchbuffers, which are always
      shmfs-backed.
      
      Separate patches deal with the cases where whole objects are (or may
      be) dirtied.
      
      v3: Mark two more pages dirty in the page-boundary-crossing
          cases of the execbuffer relocation code [Chris Wilson]
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      033908ae
  7. 10 12月, 2015 2 次提交
  8. 09 12月, 2015 3 次提交
  9. 05 12月, 2015 2 次提交
  10. 03 12月, 2015 6 次提交
    • N
      drm/i915: Extend LRC pinning to cover GPU context writeback · 6d65ba94
      Nick Hoath 提交于
      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: NNick 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: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6d65ba94
    • P
      drm/i915: kill fbc.uncompressed_size · 559d9135
      Paulo Zanoni 提交于
      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: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/
      559d9135
    • P
      drm/i915: use a single intel_fbc_work struct · 128d7356
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/
      128d7356
    • P
      drm/i915: introduce intel_fbc_{enable,disable} · d029bcad
      Paulo Zanoni 提交于
      The goal is to call FBC enable/disable only once per modeset, while
      activate/deactivate/update will be called multiple times.
      
      The enable() function will be responsible for deciding if a CRTC will
      have FBC on it and then it will "lock" FBC on this CRTC: it won't be
      possible to change FBC's CRTC until disable(). With this, all checks
      and resource acquisition that only need to be done once per modeset
      can be moved from update() to enable(). And then the update(),
      activate() and deactivate() code will also get simpler since they
      won't need to worry about the CRTC being changed.
      
      The disable() function will do the reverse operation of enable(). One
      of its features is that it should only be called while the pipe is
      already off. This guarantees that FBC is stopped and nothing is
      using the CFB.
      
      With this, the activate() and deactivate() functions just start and
      temporarily stop FBC. They are the ones touching the hardware enable
      bit, so HW state reflects dev_priv->crtc.active.
      
      The last function remaining is update(). A lot of times I thought
      about renaming update() to activate() or try_to_activate() since it's
      called when we want to activate FBC. The thing is that update() may
      not only decide to activate FBC, but also deactivate or keep it on the
      same state, so I'll leave this name for now.
      
      Moving code to enable() and disable() will also help in case we decide
      to move FBC to pipe_config or something else later.
      
      The current patch only puts the very basic code on enable() and
      disable(). The next commits will take care of moving more stuff from
      update() to the new functions.
      
      v2:
        - Rebase.
        - Improve commit message (Chris).
      v3: Rebase after changing the patch order.
      v4: Rebase again after upstream changes.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/
      d029bcad
    • P
      drm/i915: introduce is_active/activate/deactivate to the FBC terminology · 0e631adc
      Paulo Zanoni 提交于
      The long term goal is to have enable/disable as the higher level
      functions and activate/deactivate as the lower level functions, just
      like we do for PSR and for the CRTC. This way, we'll run enable and
      disable once per modeset, while update, activate and deactivate will
      be run many times. With this, we can move the checks and code that
      need to run only once per modeset to enable(), making the code simpler
      and possibly a little faster.
      
      This patch is just the first step on the conversion: it starts by
      converting the current low level functions from enable/disable to
      activate/deactivate. This patch by itself has no benefits other than
      making review and rebase easier. Please see the next patches for more
      details on the conversion.
      
      v2:
        - Rebase.
        - Improve commit message (Chris).
      v3: Rebase after changing the patch order.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/
      0e631adc
    • P
      drm/i915: set dev_priv->fbc.crtc before scheduling the enable work · e9c5fd26
      Paulo Zanoni 提交于
      This thing where we need to get the crtc either from the work
      structure or the fbc structure itself is confusing and unnecessary.
      Set fbc.crtc right when scheduling the enable work so we can always
      use it.
      
      The problem is not what gets passed and how to retrieve it. The
      problem is that when we're in the other parts of the code we always
      have to keep in mind that if FBC is already enabled we have to get the
      CRTC from place A, if FBC is scheduled we have to get the CRTC from
      place B, and if it's disabled there's no CRTC. Having a single place
      to retrieve the CRTC from allows us to treat the "is enabled" and "is
      scheduled" cases as the same case, reducing the mistake surface. I
      guess I should add this to the commit message.
      
      Besides the immediate advantages, this is also going to make one of
      the next commits much simpler. And even later, when we introduce
      enable/disable + activate/deactivate, this will be even simpler as
      we'll set the CRTC at enable time. So all the
      activate/deactivate/update code can just look at the single CRTC
      variable regardless of the current state.
      
      v2: Improve commit message (Chris).
      v3: Rebase after changing the patch order.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/
      e9c5fd26
  11. 02 12月, 2015 2 次提交
  12. 27 11月, 2015 3 次提交
  13. 26 11月, 2015 1 次提交
  14. 25 11月, 2015 1 次提交
  15. 23 11月, 2015 1 次提交