aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_ringbuffer.h
Commit message (Collapse)AuthorAge
...
* drm/i915: use new macros to access the ring start registerDaniel Vetter2010-09-21
| | | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: use new macros to access the ring tail registerDaniel Vetter2010-09-21
| | | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: add relative ring register macrosDaniel Vetter2010-09-21
| | | | | | | | | | | | Documentation explicitly mentions that the ring registers are designed to have the same offsets relative to a base registers. Use this to fight the code beaurocratic in intel_ringbuffer.c. No code changes in this patch, just the new definitions. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/ringbuffer: Implement advance using set_tailChris Wilson2010-09-21
| | | | | | | As noted by Zhenyu, we can now simply replace the existing advance hook by calling the new set_tail function pointer directly. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: add set_tail hook in struct intel_ring_bufferXiang, Haihao2010-09-21
| | | | | | | | | | This is prepared for video codec ring buffer on Sandybridge. It is needed to read/write more than one register to move the tail pointer of the video codec ring on Sandybridge. Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: do not export the instances of struct intel_ring_bufferXiang, Haihao2010-09-21
| | | | | | | | | Introduce intel_init_render_ring_buffer(), intel_init_bsd_ring_buffer for ring initialization. Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Only emit a flush request on the active ring.Chris Wilson2010-09-21
| | | | | | | | When flushing the GPU domains,we emit a flush on *both* rings, even though they share a unified cache. Only emit the flush on the currently active ring. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Remove unused intel_ringbuffer->ring_flagChris Wilson2010-09-14
| | | | | | This can always be re-added should somebody find a use... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: only one interrupt per batchbuffer is not enough!Daniel Vetter2010-09-08
| | | | | | | | | | | | Previously I thought that one interrupt per batchbuffer should be enough. Now tedious benchmarking showed this to be wrong. Therefore track whether any commands have been isssued with a future seqno (like pipelined fencing changes or flushes). If this is the case emit a request before issueing the batchbuffer. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Use a common seqno for all rings.Chris Wilson2010-08-09
| | | | | | | | This will be used by the eviction logic to maintain fairness between the rings. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Inline ringbuffer_emit()Chris Wilson2010-08-09
| | | | | | | | As the function has been reduced to a store plus increment, the body is now smaller than the call so inline it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: introduce intel_ring_buffer structure (V2)Zou Nan hai2010-05-26
Introduces a more complete intel_ring_buffer structure with callbacks for setup and management of a particular ringbuffer, and converts the render ring buffer consumers to use it. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Xiang Hai hao <haihao.xiang@intel.com> [anholt: Fixed up whitespace fail and rebased against prep patches] Signed-off-by: Eric Anholt <eric@anholt.net>