Small update to modedemo

update app to cycle through 4 fbdev's

tweak it

make modefb/modedemo match each others test output.

consistency

DRM_CONTROL_ALLOW logic was reversed

build fix for older kernels

fix some warnings

build fix for older kernels

Fix function declaration

Add missing round_jiffies_relative() for older kernels

consistency

Remove duplicate

Modedemo now uses two crtc and output pairs

Fix for cursor off

ModeFB demo now display cursor

Misc panning fixes for intel_fb

Added cursor support

if irq already enabled well just keep trucking

don't reinit ring if already initialised

Merge remote branch 'origin/master' into modesetting-101

Conflicts:

linux-core/drm_bo.c
linux-core/drm_drv.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/radeon_irq.c

Fixup modeset ioctl number & typedef usage

Should be 0x08 rather than 0xa0, and shouldn't use typedefs.

Merge commit 'airlied/i915-ttm-cfu'

This requires updated Mesa to handle the new relocation format.

Remove broken 'in vblank' accounting

We need to return an accurate vblank count to the callers of
->get_vblank_counter, and in the Intel case the actual frame count
register isn't udpated until the next active line is displayed, so we
need to return one more than the frame count register if we're currently
in a vblank period.

However, none of the various ways of doing this is working yet, so
disable the logic for now.  This may result in a few missed events, but
should fix the hangs some people have seen due to the current code
tripping the wraparound logic in drm_update_vblank_count.

i915: fix missing header when copying data from userspace

i915 make relocs use copy from user

Switch relocs to using copy from user and remove index and pass buffer
handles in instead.

Fix thinko in get_vblank_counter

Should use vtotal not htotal to figure out if we're in a vblank period.

Fix IS_I915G macro

One to many parantheses...

nouveau: Fix warning in nouveau_mem.c

i915/flush: get the ret the right way around

drm/i915: add support for E7221

Correct vblank count value

The frame count registers don't increment until the start of the next
frame, so make sure we return an incremented count if called during the
actual vblank period.

i915 irq fixes

Ack the IRQs correctly (PIPExSTAT first followed by IIR).  Don't read
vblank counter registers on disabled pipes (might hang otherwise).  And
deal with flipped pipe/plane mappings if present.

Merge branch 'master' into vblank-rework, including mach64 support

Conflicts:

linux-core/drmP.h
linux-core/drm_drv.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_irq.c
shared-core/radeon_irq.c
shared-core/via_irq.c

Mostly trivial conflicts.

mach64 support from Mathieu Bérard.

Revert "Fix pipe<->plane mapping vs. vblank handling (again)"

This reverts commit bfc29606e4a818897eebca46a5e23bbe7bc3ce25.

This regresses i915 here for me I can't get greater than 0.333 fps with gears

nouveau: don't forget NV80.

nouveau: new card family for old card designs.

Made radeon_ms not always compile

i915: fix invalid opcode exception on cpus without clflush

i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.

Signed-off-by: Kyle McMartin <kmcmartin@redhat.com>

Add additional explanation of DRM_BO_FLAG_CACHED_MAPPED before I forget again.

i915: Add chipset id for Intel Integrated Graphics Device

This adds new chipset id in drm.

Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>

radeon_ms: use radeon connector type insted of drm

radeon_ms: cope with lastest drm modesetting change

radeon_ms: add rom parsing & adapt code

Add rom (only combios for now) parsing and use informations
retrieve instead of hardcoded table. Shuffle code around a
bit.

Properly propagate the user-space fence flags.
This avoids a sync flush when user-space has already programmed
and MI_FLUSH in the batchbuffer.

Define i915_compat.c upper_32_bits for kernels < 2.6.21

 this is to fix a deadloop in drm hang system issue.
 (1 << bits) is an undefined value when bits == 32.
 gcc may generate 1 with this expression
 which will lead to an infinite retry loop in
 drm_ht_just_insert_please.
 Because of the different implement of hash_long,
 this  issue is more frequenly see on 64 bit system

fixup i915 compat resource allocation

nouveau: make mem alloc debug a little more verbose.

Fix for X axis panning problem

Panning now works without modeset

Updated the modedemo test

Added fixed misc framebuffer problems

nv05: enable ctx/op methods, and ignore patch valid failures.

Yes, I'm quite aware "real" nv04 doesn't support this, hopefully the GPU
will just ignore those PGRAPH_DEBUG_3 bits on that hw.

Updated test mode and added modedemo

fixup crtcinfo on modes from userspace

add control node open

add internals for opening a control node

allow control getversion

add control ioctls

drm: only call suspend/resume on control node

nouveau: AGP reset correction - don't touch FW bit

nv50: more small changes

nv50: oops, lost some state saving along the way somewhere.

xf86-video-nv will now work again after nouveau.

nv50: hook up timer funcs...

nv50: abort on chips without ctx ucode

nv50: some needed ctx vals

nv50: use dummy page in gart tables

Just to be safe, we don't really know exactly how the tables work yet, so
we can't be certain there's a way to say "page not present".

nv50: some cleanups + small changes

Nouveau: ppc oops.

Nouveau: move PPC bios copy to firstopen.

nouveau: Add ctx_voodoo for NV86

drm: One forgotten rename of 'mask' to 'proposed_flags'.

Due to commit d1187641d64f442968a3b9ea6a19de6cdd45acd4.

drm: add initial support for a drm control device node

crtc: fixup allocation size

via: add P4M900 pci id.

bug 12108

drm: move drm_head to drm_minor and fix up users

[PATCH] nouveau: reset AGP on init for < nv40

This is necessary for AGP to work after running bios init scripts on nv3x, and
is seen in mmio traces of all cards (nv04-nv4x)

I'm not making the equivalent change to nv40_mc.c, as early cards (6200, 6800gt)
use the 0x000018XX PBUS and later cards use the 0x000880XX PBUS and I don't know
the effects of using the wrong one

[PATCH] nouveau: Fix nv20/30 context loading

Don't set the context as valid until it has been loaded

mach64: some more minor cleanups

mach64: cleanup some of the macro formatting

drm: cleanup DRM_DEBUG() parameters

As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.

airlied:- I cleaned up a few that this patch missed also

Merge branch 'r500-support'

remove duplicate pciids

i915: return fence argument from i915_execbuffer ioctl32 routine

i915: i915_execbuffer ioctl32 routine, fix #13732

Change drm_bo_type_dc to drm_bo_type_device and comment usage of this value.

I couldn't figure out what drm_bo_type_dc was for; Dave Airlie finally clued
me in that it was the 'normal' buffer objects with kernel allocated pages
that could be mmapped from the drm device file.

I thought that 'drm_bo_type_device' was a more descriptive name.

I also added a bunch of comments describing the use of the type enum values and
the functions that use them.

Rename inappropriately named 'mask' fields to 'proposed_flags' instead.

Flags pending validation were stored in a misleadingly named field, 'mask'.
As 'mask' is already used to indicate pieces of a flags field which are
changing, it seems better to use a name reflecting the actual purpose of
this field. I chose 'proposed_flags' as they may not actually end up in
'flags', and in an case will be modified when they are moved over.

This affects the API, but not ABI of the user-mode interface.

Use dummy_read_page for unpopulated kernel-allocated ttm pages.

Previously, dummy_read_page was used only for read-only user allocations; it
filled in pages that were not present in the user address map (presumably,
these were allocated but never written to pages).

This patch allows them to be used for read-only ttms allocated from the
kernel, so that applications can over-allocate buffers without forcing every
page to be allocated.

Move dummy_read_page from drm_ttm_set_user to drm_ttm_create.

I'm hoping to use the dummy_read_page for kernel allocated buffers to avoid
allocating extra pages for read-only buffers (like vertex and batch buffers).
This also eliminates the 'write' parameter to drm_ttm_set_user and just
has DRM_TTM_PAGE_WRITE passed into drm_ttm_create.

Clean up and document drm_ttm.c APIs. drm_bind_ttm -> drm_ttm_bind.

Aside from changing drm_bind_ttm to drm_ttm_bind, this patch
adds only documentation and fixes the functions inside drm_ttm.c
to all be prefixed with drm_ttm_.

s/TRUE/true

radeon_ms: update to follow lastest modesetting change

radeon_ms: add sarea & install header

Merge branch 'modesetting-airlied' into modesetting-101

HERE BEZ HACKZ.. magic variable to make shit work

lockdep warned about a possible locking dependency

we should not be unlocking this here

remove output names

Fixed build