| Age | Commit message (Collapse) | Author |
|---|
|
Should be OK on G84 for a single channel, multiple channels *almost* work.
Untested on G80.
|
|
|
|
Allows multiple references to a single object, needed to support PCI(E)GART
scatter-gather DMA objects which would quickly fill PRAMIN if each channel
had its own.
Handle per-channel private instmem areas. This is needed to support NV50,
but might be something we want to do on earlier chipsets at some point?
Everything that touches PRAMIN is a GPU object.
|
|
The frame counter seems to increase only at the end of vertical blank, so we
need to add 1 while in vertical blank.
|
|
|
|
|
|
|
|
Can't use nv04 code for them, since an extra field was inserted into
RAMFC after DMA_PUT/GET.
|
|
|
|
|
|
|
|
|
|
For various reasons, this ioctl was a bad idea.
At channel creation we now automatically create DMA objects covering
available VRAM and GART memory, where the client used to do this themselves.
However, there is still a need to be able to create DMA objects pointing at
specific areas of memory (ie. notifiers). Each channel is now allocated a
small amount of memory from which a client can suballocate things (such as
notifiers), and have a DMA object created which covers the suballocated area.
The NOTIFIER_ALLOC ioctl exposes this functionality.
|
|
|
|
|
|
|
|
|
|
|
|
NV04/NV10 load_context()/save_context() are stubs. I don't know enough about
how they work to implement them sanely. The "old" context_switch() code
remains hooked up, so it shouldn't break anything.
NV20 will probably break if load_context() works. No inital context values
are filled in, so when the first channel is created PGRAPH will probably end
up having its state zeroed. Some setup from nv20_graph_init() will probably
need to be moved to the per-channel context setup.
|
|
|
|
Earlier NV1X chips use the NV04 code, see previous commits about NV10 RAMFC
entry size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- use a timer for disabling vblank events to avoid enable/disable calls too
often
- make i915 work with pre-965 chips again (would like to structure this
better, but this hack works on my test system)
|
|
Failure to do so was probably the root cause of fd.o bug 11287.
|
|
s/u64/drm_u64_t/ to allow userspace code using drm.h to compile.
Move 64 bit arg member to the beginning to avoid alignment issues with 32
bit userspace on 64 bit kernels.
|
|
Simply always acknowledge all interrupts we're interested in, to avoid hard
hangs when an unexpected interrupt is flagged.
|
|
|
|
It's possible that we disable vblank interrupts and clear the
corresponding flag in irq_enable_reg, but receive an interrupt at just
the wrong time, causing us to not ack it properly, nor report to the
core kernel that it was handled. Fix that case by always handling
vblank interrupts, even if the irq_enable_reg field is clear.
|
|
|
|
|
|
routine.
|
|
Fix range of frame counter registers.
Use DRM_ERR() instead of Linux specific error codes in shared code.
Remove duplicate register definitions and superfluous local variables.
|
|
|
|
|
|
(this makes get_vblank_counter return an actual value).
|
|
|
|
|
|
|
|
|
|
Also use drm_calloc instead of drm_alloc and memset, and use the size of the
struct instead of the size of the pointer for allocation...
|
|
- use correct refcount variable in get/put routines
- extract counter update from drm_vblank_get
- make signal handling callback per-crtc
- update interrupt handling logic, drivers should use drm_handle_vblank
- move wakeup and counter update logic to new drm_handle_vblank routine
- fixup usage of get/put in light of counter update extraction
- fix longstanding bug in signal code, update pending counter only
*after* we're sure we'll setup signal handling
|
|
path. It doesn't appear to serve any useful purpose.
|
|
- move pre/post modeset ioctl to core
- fixup i915 buffer swap
- fix outstanding signal count code
- create new core vblank init routine
- test (works with glxgears)
- simplify i915 interrupt handler
|
