| Age | Commit message (Collapse) | Author |
|---|
|
Documentation/CodingStyle says that 'typedef struct foo foo_t' is
evil. I tend to agree. Elminate all uses of such construct.
|
|
This function used to return 'void *', which was then cast to
'xgi_pcie_block_t *' at the only caller. I changed the return type to
'struct xgi_pcie_block_s *' and removed the explicit cast.
|
|
|
|
Buffer object dereference cleanup.
Add a struct drm_device member to fence objects:
This can simplify code, particularly in drivers.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See attachment 10246 on https://bugs.freedesktop.org/show_bug.cgi?id=5921
|
|
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)
|
|
Sync-to-vblank actually works again for me with radeon.
|
|
|
|
Commit 9b01bd5b284bbf519b726b39f1352023cb5e9e69 introduced a
compat_ioctl handler for RADEON_SETPARAM, the sole purpose of which was
to handle the fact that on i386, alignof(uint64_t)==4.
Unfortunately, this handler was installed for _all_ 64-bit
architectures, instead of only x86_64 and ia64. And thus it breaks
32-bit compatibility on every other arch, where 64-bit integers are
aligned to 8 bytes in 32-bit mode just the same as in 64-bit mode.
Arnd has a cunning plan to use 'compat_u64' with appropriate alignment
attributes according to the 32-bit ABI, but for now let's just make the
compat_radeon_cp_setparam routine entirely disappear on 64-bit machines
whose 32-bit compat support isn't for i386. It would be a no-op with
compat_u64 anyway.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
|
|
|
|
|
If the driver doesn't support vertical blank interrupts, it won't call
drm_vblank_init(), and dev->num_crtcs will be 0.
Also fix an off-by-one test against dev->num_crtcs.
|
|
|
|
|
|
|
|
Reported by Steve Wilkins / Michel Dänzer.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
- 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
|
|
of vblank interrupt in order to save power.
|
|
|
|
Introduce tile members for future tiled buffer support.
Allow user-space to explicitly define a fence-class.
Remove the implicit fence-class mechanism.
64-bit wide buffer object flag member.
|
|
|
|
|
|
|
|
|
|
This reverts commit 6e860d08d0f5b1e9a2d711aaf9fd6b982aa8039e.
As I said not a good plan - this macro will have to stay for now,
trying to do the vbl code with the inline was a bit messy - may need specialised
drm wait on functions
|
