• T
    drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demand · 7ba717cf
    Thomas Daniel 提交于
    Same as with the context, pinning to GGTT regardless is harmful (it
    badly fragments the GGTT and can even exhaust it).
    
    Unfortunately, this case is also more complex than the previous one
    because we need to map and access the ringbuffer in several places
    along the execbuffer path (and we cannot make do by leaving the
    default ringbuffer pinned, as before). Also, the context object
    itself contains a pointer to the ringbuffer address that we have to
    keep updated if we are going to allow the ringbuffer to move around.
    
    v2: Same as with the context pinning, we cannot really do it during
    an interrupt. Also, pin the default ringbuffers objects regardless
    (makes error capture a lot easier).
    
    v3: Rebased. Take a pin reference of the ringbuffer for each item
    in the execlist request queue because the hardware may still be using
    the ringbuffer after the MI_USER_INTERRUPT to notify the seqno update
    is executed.  The ringbuffer must remain pinned until the context save
    is complete.  No longer pin and unpin ringbuffer in
    populate_lr_context() - this transient address is meaningless and the
    pinning can cause a sleep while atomic.
    
    v4: Moved ringbuffer pin and unpin into the lr_context_pin functions.
    Downgraded pinning check BUG_ONs to WARN_ONs.
    
    v5: Reinstated WARN_ONs for unexpected execlist states.  Removed unused
    variable.
    
    Issue: VIZ-4277
    Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
    Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
    Reviewed-by: NAkash Goel <akash.goels@gmail.com>
    Reviewed-by: Deepak S<deepak.s@linux.intel.com>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    7ba717cf
intel_lrc.c 56.7 KB