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.
- 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)
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.
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.
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.
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>
Ian Romanick
Ben Skeggs
Thomas Hellstrom
Jesse Barnes
Michel Dänzer
Jesse Barnes
Oliver McFadden
David Woodhouse