| Age | Commit message (Collapse) | Author | 
|---|
|  | 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> | 
|  |  | 
|  |  |