• J
    drm/i915: Reserve ring buffer space for i915_add_request() commands · 29b1b415
    John Harrison 提交于
    It is a bad idea for i915_add_request() to fail. The work will already have been
    send to the ring and will be processed, but there will not be any tracking or
    management of that work.
    
    The only way the add request call can fail is if it can't write its epilogue
    commands to the ring (cache flushing, seqno updates, interrupt signalling). The
    reasons for that are mostly down to running out of ring buffer space and the
    problems associated with trying to get some more. This patch prevents that
    situation from happening in the first place.
    
    When a request is created, it marks sufficient space as reserved for the
    epilogue commands. Thus guaranteeing that by the time the epilogue is written,
    there will be plenty of space for it. Note that a ring_begin() call is required
    to actually reserve the space (and do any potential waiting). However, that is
    not currently done at request creation time. This is because the ring_begin()
    code can allocate a request. Hence calling begin() from the request allocation
    code would lead to infinite recursion! Later patches in this series remove the
    need for begin() to do the allocate. At that point, it becomes safe for the
    allocate to call begin() and really reserve the space.
    
    Until then, there is a potential for insufficient space to be available at the
    point of calling i915_add_request(). However, that would only be in the case
    where the request was created and immediately submitted without ever calling
    ring_begin() and adding any work to that request. Which should never happen. And
    even if it does, and if that request happens to fall down the tiny window of
    opportunity for failing due to being out of ring space then does it really
    matter because the request wasn't doing anything in the first place?
    
    v2: Updated the 'reserved space too small' warning to include the offending
    sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
    re-initialisation of tracking state after a buffer wrap to keep the sanity
    checks accurate.
    
    v3: Incremented the reserved size to accommodate Ironlake (after finally
    managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
    
    v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
    
    For: VIZ-5115
    CC: Tomas Elf <tomas.elf@intel.com>
    Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    29b1b415
intel_ringbuffer.h 16.8 KB