| Age | Commit message (Collapse) | Author |
|---|
|
These two structures were used as the request and reply for certain
ioctls. Having a different type for an ioctl's input and output is
just wierd. In addition, each structure contained fields (e.g., pid)
that had no business being there.
This change requires updates to user-space.
|
|
Should be OK on G84 for a single channel, multiple channels *almost* work.
Untested on G80.
|
|
|
|
Two large blocks of code were moved out of this function into separate
functions. This brought some much needed sanity to the indentation.
Some dead varaibles were removed.
|
|
I'm not convinced that get_cycles is the right approach here, but it's
better than the weird way that rtdsc was being used.
|
|
|
|
|
|
Dave Airlie pointed out on IRC that idr_replace lets us know if the ID hasn't
been allocated, so we don't need a special pointer value for allocated IDs that
don't have valid information yet.
|
|
There's a difference between a drawable ID not having valid drawable
information and not being allocated at all. Not making the distinction would
break i915 DRM swap scheduling with older X servers that don't push drawable
cliprect information to the DRM.
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe
|
|
The whole purpose of xgi_pcie_heap_check is to log information about
entries on the used_list. If XGI_DEBUG is not set, it doesn't print
anything. Therefore we can #ifdef the whole function body.
Convert open-code list iteration to use list_for_each_entry.
|
|
Comment in the code explains it. Basically, I put an if-statement
around a block of code to prevent a NULL pointer dereference that
should never happen in the first place. Eventually, this will need to
come out.
|
|
A few of the PCI-e GART related fields in struct xgi_info were
hardcoded to u32. None of them need to be. Convert them to either
unsigned int or bool.
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
