| Age | Commit message (Collapse) | Author |
|---|
|
Recording the tail pointer in a local variable improves performance, but if
someone messes up and fails to reload at the right time, the driver will
write commands to the wrong part of the ring and scramble execution badly.
This change (available by setting I915_RING_VALIDATE to 1) checks to make
sure the cached tail pointer matches the hardware tail pointer at each ring
buffer addition, calling BUG_ON when that's not true.
|
|
Ring locals must be reloaded from hardware in case the X server ran.
|
|
There are now 3 lists. Active is buffers currently in the ringbuffer.
Flushing is not in the ringbuffer, but needs a flush before unbinding.
Inactive is as before. This prevents object_free → unbind →
wait_rendering → object_reference and a kernel oops about weird refcounting.
This also avoids an synchronous extra flush and wait when freeing a buffer
which had a write_domain set (such as a temporary rendered to and then from
using the 2d engine). It will sit around on the flushing list until the
appropriate flush gets emitted, or we need the GTT space for another
operation.
|
|
|
|
|
|
The dummy read page will point to NULL if drm_bo_driver_init failed at
firstopen (modeset is not enabled), and will cause kernel oops at
subsequent drm_lastclose call, so be sure to check it.
|
|
To avoid bo memory manager being inited twice, it will be called
at firstopen when modeset is not enabled.
|
|
|
|
Since it's a circular list, the entry won't be NULL at termination.
|
|
Otherwise, in the middle of the function called using it the last ref
might disappear.
|
|
Ring locals must be reloaded from hardware in case the X server ran.
|
|
The new display controller has the vblank interrupts in a different place.
Add support for vbl interrupts for these chips
|
|
This lets us get some qualities we desire, such as using the full 32-bit
range (except zero), avoiding DRM_WAIT_ON, and a 1:1 mapping of active
sequence numbers to request structs, which will be used soon for throttling
and interrupt-driven list cleanup.
|
|
|
|
Additionally, a boolean active field is added to indicate which list an
object is on, rather than smashing last_rendering_cookie to 0 to show
inactive. This will help with flush-reduction later on, and makes the code
clearer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit bc0836e12a9790f1cc83f8bc29bc05043c4bc840.
tree has some kref hacks in it - oops
|
|
|
|
Thanks to Alex for supplying this info.
|
|
RS400 (intel based IGP) and RS480 (AMD based IGP) have
different MC and GART setups. Currently we only support
RS480.
|
|
into modesetting-101
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans
things up quite a bit, removing redundant definitions (some with
different names referring to the same register) and generally tidying up
the header file.
|
|
|
|
In order to avoid recursive ->detect->interrupt->detect->interrupt->...
we need to disable TV hotplug interrupts in
intel_tv.c:intel_tv_detect_type. We also need to enable the TV interrupt
detection and hotplug sequence properly in i915_irq.c.
|
|
|
|
|
|
No need to fill the ring that much; wait for it to become nearly empty
before adding the execbuffer request. A better fix will involve scheduling
ring insertion in the irq handler.
|
|
If the ring is full, the engine will surely be running for more than 10ms.
|
|
Leave the flush call in place, which can fix domains up if necessary.
|
|
|
|
drm_crtc->fb may point to NULL, f.e X server will allocate a new fb
and assign it to the CRTC at startup, when X server exits, it will destroy
the allocated fb, making drm_crtc->fb points to NULL.
|
|
Since drm_bo_driver_init will be called in driver_load, we need to free
what it alloced when error to avoid memory leak.
|
|
moving modeset init code into one function and correct error
handling druing i915 init
|
|
We need to alloc a hw status page bo for G33 if modeset is enabled since the 2D
driver can't alloc gfx memory when working in drm modeset.
|
|
|
|
Similar (broken) code in mesa needs to be removed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
first step in merging rs4xx/rs6xx gart setup
|
|
|
|
|
