Check for do_mmap errors

Add a bit of /proc/dri/*/gem support. Clean up some refcount/pagelock issues.

Track named objects in /proc/dri/0/gem_names.
Track total object count in /proc/dri/0/gem_objects.
Initialize device gem data.
return -ENODEV for gem ioctls if the driver doesn't support gem.
Call unlock_page when unbinding from gtt.
Add numerous misssing calls to drm_gem_object_unreference.

Add name/open ioctls, separate handle and pointer ref counts.

Names are just another unique integer set (from another idr object).
Names are removed when the user refernces (handles) are all destroyed --
this required that handles for objects be counted separately from
internal kernel references (so that we can tell when the handles are all
gone).

Remove drm_driver argument to functions taking drm_gem_object.

Now that drm_gem_object has a drm_driver * in it, functions don't need both
parameters.

Fix nouveau warning when returning pointers in uint64_t objects.

Add alignment to all aperture allocation requests.

When pinning buffers, or using execbuffer, allow the application to specify
the necessary aperture allocation alignment constraints.

Fix gem ioctls to be 32/64-bit clean.

mixed 32/64 bit systems need 'special' help for ioctl where the user-space
and kernel-space datatypes differ. Fixing the datatypes to be the same size,
and align the same way for both 32 and 64-bit ppc and x86 environments will
elimiante the need to have magic 32/64-bit ioctl translation code.

Use krefs for refcounting.

krefs are way easier than a custom-coded spinlock+int combo.

Unbind objects when freeing, fix some error paths, and warn in others.

Fix offset passed to AGP to be pages instead of bytes.

Fix some utterly bonged loop while we were staring at it.

Fix missing member settings in obj/obj_priv, and some error paths.

Make GEM object handles be nonzero.

Update mm tests for GEM rename.

Remove _args from gem ioctl argument structure tags.

Add pin/unpin object ioctls for gem.

checkpoint: relocations support.

checkpoint: gtt binding written.

checkpoint: rename to GEM and a few more i915 bits.

Hacking towards hooking up execbuffer.

Remove the remainder of the mmfs device.

Move mmfs tests over to be drm tests.

Move mmfs ioctls into the DRM. Untested.

Rename drm_mm.c and its fuctions to drm_memrange.

It's not really a graphics memory allocator, just something to track ranges
of address space.  It doesn't involve actual allocation, and was consuming
some desired namespace.

Add mmap ioctl to mmfs.

Add pread/pwrite ioctls to mmfs.

Extend the mmfs basic test to do a couple of ioctls.

Move mmfs.h userland interface to shared-core.

Initial add of mmfs module.

Clarify that drm_agp_ttm_backend is associated with a drm_ttm.

On first looking at it I assumed it was an aspect of the ttm backend as a
whole rather than specific allocations from a backend.

linux-core Makefile: add GIT_REVISION

This tries to automatically fetch a git revision string and if succeeds,
it #defines GIT_REVISION string macro. Packagers can override it by
'make GIT_REVISION=foo'.

Update Nouveau to use GIT_REVISION, if defined, instead of DRIVER_DATE
in struct drm_driver.

Signed-off-by: Pekka Paalanen <pq@iki.fi>

i915: gfx hw and i945gme fixes from upstream

From Jesse and Zhenyu originally.

[I915] Handle tiled buffers in vblank tasklet

The vblank tasklet update code must build 2D blt commands with the
appropriate tiled flags.

On I965, use correct 3DSTATE_DRAWING_RECTANGLE command in vblank

The batchbuffer submission paths were fixed to use the 965-specific command,
but the vblank tasklet was not. When the older version is sent, the 965 will
lock up.

Fix buffer object map wait error.
Add some branch prediction hints.

Fix buffer object creation validation.

BO lock fixes.

Unlock the BO mutex while waiting for idle, unmapped, unfenced.

Move unfenced checking into idle checking.
Never time out while waiting for software events like unmapped or unfenced.

Fix up buffer manager locking.

Save and restore dsparb and d_state regs

Missing KERNEL_VERSION macro

Add DragonFly BSD support for device creation

DragonFly behaves just like FreeBSD in this regard.

nouveau: enable accelerated move to sysmem

nouveau: enable m2mf for tt<->vram moves, fix fence_poll

Place highmem pages last in the ttm page array.

Use clflush() when available for cache flushing.

[I915] Fix VRAM eviction.

Fix emergency allocation accounting.

nv50: primitive i2c interrupt handler

nv50: primitive display interrupt handler.

nouveau: fix return from function..

dude kernel moduless use kernel errors :)

this fixes an oops on init when this codepath hits.

Initialize the fence::error member.

[i915] Report buffer state _after_ fence submission to user-space.
This fixes a problem where the wrong bo->fence_type was reported, and
also saves some memory space.
[bo core] export the drm_bo_fill_rep_arg function.

Don't call fence::poll during irq if there are no waiters.

nouveau: forgot to add a break

nouveau: Add ctx values for nv86.

- Note that this may not work for all nv86.

drm/r300: fix wait interface mixup

This interface was defined completely wrong, however userspace has only
ever used 4 values from it (0x1, 0x2, 0x3 and 0x6), so fix the interface to do what userspace actually expected but define new defines for new users to use
it properly.

r300: Correctly translate the value for the R300_CMD_WAIT command.

Previously, the R300_CMD_WAIT command would write the passed directly to the
hardware. However this is incorrect because the R300_WAIT_* values used are
internal interface values that do not map directly to the hardware.

The new function I have added translates the R300_WAIT_* values into appropriate
values for the hardware before writing the register.

Thanks to John Bridgman for pointing this out. :-)

nouveau: nv20 bios does not initialise PTIMER

The wait functions depend on PTIMER, so write the old (incorrect, but working) values for uninitialised hw

i915: fix oops on agp=off

Kernel bug 10289.

Merge branch 'r500-fp'

nouveau: silence warning

nv40: voodoo - not quite.

nv40: allocate massive amount of PRAMIN for grctx on all chipsets.

More or less a workaround for issues on some chipsets where a context
switch results in critical data in PRAMIN being overwritten by the GPU.

The correct fix is known, but may take some time before it's a feasible
option.

r500: fragment program upload is also used to upload constants.

Limit frag address to 8 bits

drm: fixup r500fp submission

nouveau: do not set on-board timer's numerator/denominator to bad values

RADEON: switch over to new production microcode

This needs to be tested thoroughly before pushing to the
kernel.

RADEON: production microcode for all radeons, r1xx-r6xx

This updated microcode is not in use yet.

move some more r300 regs into not allowed on r500

drm: add new rs690 pci id

Evict cached_mapped relocatee before applying reloc.

Fix that got left out after the intel-post-reloc merge.

initial r500 RS and FP register and upload code

drm/pcigart: fix the pci gart to use the drm_pci wrapper.

This is the correct fix for the RS690 and hopefully the dma coherent work.

For now we limit everybody to a 32-bit DMA mask but it is possible for
RS690 to use a 40-bit DMA mask for the GART table itself,
and the PCIE cards can use 40-bits for the table entries.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Avoid unnecessary waits for command regulator pause.

[via] Remove some leftover vars.

[via] Allow a little larger stride for SG DMA DownloadFromScreen.

[via] The millionth fixup for the millionth-1 attempt to stabilize the AGP
DMA command submission. It's worth remembering that all new bright ideas on how
to make this command reader work properly and according to docs
will probably fail :( Bring in some old code.

[via] Fix driver after vblank-rework merge.

ati: fix rs690 igp gart by allocating the page table in 32-bit memory

drm/rs690: set AGP_BASE_2 to 0

drm: set rs690 gart base completly.

The docs state bits 4-11 represent bits 32-39 of a 40-bit address

drm: this u32 should be a dma_addr_t

doesn't fix anything but just making it consistent

fix build problems

drm: Fix race that can lockup the kernel

The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt.  Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet.  In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func().  The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock.  This semantic would be safe if all attempts to use
the spinlock only happen from process context.  However this buffer
swap happens from softirq context which is really a form of interrupt
context.  Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet.  This wedges the kernel hard.

To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt.  In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half.  I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds).  This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).

The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form.  After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).

Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.

Signed-off-by: Mike Isely <isely@pobox.com>

Fix chip family for RV550

nv50: force channel vram access through vm

If we ever want to be able to use the 3D engine we have no choice.  It
appears that the tiling setup (required for 3D on G8x) is in the page tables.

The immediate benefit of this change however is that it's now not possible
for a client to use the GPU to render over the top of important engine setup
tables, which also live in VRAM.

G8x VRAM size is limited to 512MiB at the moment, as we use a 1-1 mapping
of real vram pages to their offset within the start of a channel's VRAM
DMA object and only populate a single PDE for VRAM use.

Merge branch 'intel-post-reloc'

Conflicts:

linux-core/drm_compat.c
linux-core/drm_compat.h
linux-core/drm_ttm.c
shared-core/i915_dma.c

Bump driver minor to 13 due to introduction of new
relocation type.

Bug # 14712
Disable page saving for GPU read-only TTMs.

Dont allow !sysadmin clients to alter the memory type of
NO_EVICT buffers.

Fix for debug memory routines

Add error message

Add an emergency pinnable memory quota for root-only processes.

Fix kernel crash when we hit OOM conditions.
(Alan Hourihane)

Avoid duplicate calls to drm_ttm_bind in some cases.

Make sure other TTM memory types than TT is really unbound when evicted.

Avoid large kmallocs.

nouveau: move AGP reset to mem_init_agp

Also, power cycle PGRAPH when resetting AGP -- it seems to fix problems encountered by p0g on nv25

remove unneeded load call

Switch from PIPE_VBLANK to PIPE_EVENT interrupts.

My 965GM gets interrupts stuck when using the old PIPE_VBLANK interrupt.
Switch to the PIPE_EVENT interrupt mechanism, and set the PIPE*STAT
registers to use START_VBLANK on 965 and VBLANK on previous chips.

drm/radeon: check sarea_priv exists

nouveau: redo channel idle detection

Will hopefully work a bit better than previous code, which depended on
knowing the channel's most recent PUT value.  Some chips always return
0 on reading these regs, and currently userspace is the only other entity
which knows the value.