| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
PCI- or high memory.
This is substantially more efficient than drm_bo_kmap,
since the mapping only lives on a single processor.
Unmapping is done use kunmap_atomic(). Flushes only a single tlb() entry.
Add a support utility int drm_bo_pfn_prot() that returns the
pfn and desired page protection for a given bo offset.
This is all intended for relocations in bound TTMS or vram.
Mapping-accessing-unmapping must be atomic, either using preempt_xx() macros
or a spinlock.
|
|
|
|
|
|
|
|
In particular -EAGAINs, which should be common during Xserver operation.
Also handle the fence creation failure case.
|
|
Texture uploads could hit the blitter coordinate limit, adjust the texture
offset when uploading the pieces. Make sure to check the end address of the
upload too.
|
|
Fixes resume from hibernate in some configurations.
|
|
|
|
|
|
Thanks to Todd Merrill for pointing it out.
|
|
This matches the changes in mesa to use the system drm includes
for the definitions of the drm ioctl structs.
|
|
|
|
This fixes at least two problems:
* The vblank_disable_fn timer callback could get called after the DRM was
de-initialized, e.g. on X server shutdown.
* Leak of vblank related resources when disabling and re-enabling the IRQ, e.g.
on an X server reset.
|
|
|
|
fix i915 driver to use state for hibernate save avoidance.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Failing to preserve the MI_ARB_STATE register was causing FIFO underruns on
the VGA output on my HP 2510p after resume.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On many chipsets, the checks for DPLL enable or VGA mode will prevent the
pipeconf regs from being restored, which could result in a blank display or X
failing to come back after resume. So restore them unconditionally along with
actually restoring pipe B's palette correctly.
|
|
Make sure we have enough room for all the GR registers or we'll end up
clobbering the AR index register (which should actually be harmless
unless the BIOS is making an assumption about it).
|
|
On resume, if the interrupt state isn't restored correctly, we may end
up with a flood of unexpected or ill-timed interrupts, which could cause
the kernel to disable the interrupt or vblank events to happen at the
wrong time. So save/restore them properly.
|
|
There were two problems with the existing callback code: the vblank
enable callback happened multiple times per disable, making drivers more
complex than they had to be, and there was a race between the final
decrement of the vblank usage counter and the next enable call, which
could have resulted in a put->schedule disable->get->enable->disable
sequence, which would be bad.
So add a new vblank_enabled array to track vblank enable on per-pipe
basis, and add a lock to protect it along with the refcount +
enable/disable calls to fix the race.
|
|
since a breadcrumb may actually turn up before a corresponding fence object
has been placed on the fence ring.
|
|
And make nv30_graph_init a bit more like mmio-traces
|
|
- Moved the fix from the ddx to drm, because it seemed more appropriate.
- Don't be shy, report if it works for you or not.
|
|
sequence number may actually turn up before the corresponding fence
object has been queued on the ring.
Fence drivers can use this member to determine whether a
sequence number must be re-reported.
|
|
|
|
waiting types.
Add a "command_stream_barrier" method to the bo driver.
|
|
With some luck the drm-side will be OK now for this chipset.
|
|
bug 14289
|
|
In hibernate, we may end up calling the VGA save regs function twice, so we
need to make sure it's idempotent. That means leaving ARX in index mode after
the first save operation. Fixes hibernate on 965.
|
|
This adds support for configuring the RS690 GART.
|
|
don't disable vblank interrupts (similar to r128)
|
|
Should be 0x08 rather than 0xa0, and shouldn't use typedefs.
|
|
This requires updated Mesa to handle the new relocation format.
|
|
We need to return an accurate vblank count to the callers of
->get_vblank_counter, and in the Intel case the actual frame count
register isn't udpated until the next active line is displayed, so we
need to return one more than the frame count register if we're currently
in a vblank period.
However, none of the various ways of doing this is working yet, so
disable the logic for now. This may result in a few missed events, but
should fix the hangs some people have seen due to the current code
tripping the wraparound logic in drm_update_vblank_count.
|
|
|
|
Switch relocs to using copy from user and remove index and pass buffer
handles in instead.
|
|
Should use vtotal not htotal to figure out if we're in a vblank period.
|
|
One to many parantheses...
|
|
|
|
|
|
|
|
The frame count registers don't increment until the start of the next
frame, so make sure we return an incremented count if called during the
actual vblank period.
|
