Panning now works without modeset

Updated the modedemo test

Added fixed misc framebuffer problems

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

drm: add initial support for a drm control device node

crtc: fixup allocation size

drm: move drm_head to drm_minor and fix up users

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

Fix and cleanup of Hotplug

Modesetting Hotplug

Merge branch 'master' of git+ssh://git.freedesktop.org/git/mesa/drm into modesetting-101

catch an out of memory condition

Make relocation validate client computed values when debugging

i915: wait for buffer idle before writing relocations

When writing a relocation entry, make sure the target buffer is idle,
otherwise the GPU may see inconsistent data.

Bump driver minor for relocation optimzations

Allow relocation to be skipped when buffers don't move.

One of the costs of superioctl has been the need to perform relocations
inside the kernel. The cost of mapping the buffers to the CPU and writing
data is fairly high, especially if those buffers have been mapped and read
by the GPU.

If we assume that buffers don't move around very often, we can have the
client compute the relocations itself using the previous GPU address. When
that object doesn't move, the kernel can skip computing and writing the
updated data.

Here's a patch which adds a new field to struct drm_bo_info_req called
'presumed_offset', and a new DRM_BO_HINT_PRESUMED_OFFSET that is set when
this field has been filled in by the client.

There are two separate optimizations performed when the presumed_offset is
correct:

 1. i915_exec_reloc checks to see if all previous buffer offsets were guessed
    correctly. If so, there's no need for it to look at *any* of the
    relocations for a buffer. When this happens, it skips the whole
    relocation process, simply returning success.

 2. i915_apply_reloc checks to see if the target buffer offset was guessed
    correctly. If so, it skips mapping the relocatee, computing the
    relocation and writing the value. If no relocations are needed, the
    relocatee should never be mapped to the CPU, and so the kernel shouldn't
    need to wait for any fences to pass.

Merge branch 'master' of ssh://git.freedesktop.org/git/mesa/drm into modesetting-101

Conflicts:

linux-core/drm_drv.c
shared-core/drm.h
shared-core/i915_dma.c

modesetting: fixup property setting and add connector property

modesetting: add dpms property and initial settable property ioctl

drm: move agp include outside CONFIG_AGP as it isn't dependant on agp in kernel

mach64: comment bus master / ring buffer behavior and security

radeon_ms: fix pll computation to follow hw constraint

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

If drmMinor >= 6, the intel DDX driver will enable vblank events on both
pipes.  If drmMinor >= 10 on pre-965 chipsets, the intel DDX driver will
swap the pipe<->plane mapping to allow for framebuffer compression on
laptop screens.  This means the secondary vblank counter (corresponding
to pipe B) will be incremented when vblank interrupts occur.

Now Mesa waits for vblank events on whichever plane has a greater
portion of the displayed window.  So it will happly ask to wait for the
primary counter even though that one won't increment.

So we can fix this in either the DDX driver, Mesa or the kernel (though
I thought we already had several times).

Since current (and previous) userspace assumes it's talking about a pipe
== plane situation and now uses planes when talking to the kernel, we
should probably just hide the mapping details there (indeed they already
are hidden there for vblank swaps), which this patch does.

So as far as userland is concerned, whether we call things planes or
pipes is irrelevant, as long as kernel developers understand that
userland hands them planes and they have to figure out which pipe that
corresponds to (which will typically be the same on 965+ hardware and
reversed on pre-965 mobile chips).

radeon_ms: fix fbcon by fixing palette

radeon_ms: update to lastest fb change

Merge commit 'origin/modesetting-101' into modesetting-radeon

radeon_ms: avoid to unintialize things which haven't been initialized

take down stuff after asking driver to unload

retab intelfb code

check previous mode first

oops initialise variable to false

add property blobs and edid reporting support

mach64: make buffer emission macros normal functions

mach64: use utf-8

Remove references to the sarea_priv perf_boxes field.

This field isn't touched or read by any other code in the stack so it's
time to retire these last few references.

more WIP on blobs..

I'm going to pass back a list of blob ids and lengths in the getproperty.
will need another ioctl to return the blob data as it is variable length.

arrgggh.. make all ioctl structs 32/64-bit compatible hopefully.

This also starts to add blob property support.

someone needs to check this work for other things like ppc/x86 alignment diffs

Don't free driver mapped locks

This fix is actually a bit of a cleanup too--it moves lock freeing to
drm_rmmap_locked and out of drm_lastclose.  This makes it symmetrical with
addmap and also prevents the lock from being incorrectly freed from driver
mappings.

radeon_ms: radeon modesetting first commit.

This should work on all radeon but there is still many things todo:
    - add crtc2
    - tmds
    - lvds
    - add bios data table so we don't need to hardcode dac/crtc infos
    - separate clock control to make power saving easier & cleaner
    - tiling (warning tiling shouldn't be enable in double scan or interlace)
    - surface reg manager (this goes along with tiling)
    - suspend/resume hook
    - avivo & r500 family support
    - atom bios support (for posting card mostly)
    - finish superioctl skeleton
    - what else ? :)

patch from -mm kernel to use upper_32_bits

hooks up sync and flags and also clocks to get mode matching better

add flags to mode debug print

mode: copy back the mode if is valid correctly

finish of mode add/remove, just have attach/detach modes

modesetting API change for removing mode ids and making modes per output.

so really want to get a list of modes per output not the global hammer list.
also we remove the mode ids and let the user pass back the full mode description

need to fix up add/remove mode for user modes now

bsd: Replace other occurrences of msleep with mtx_sleep

bsd: Now make secondary vblank work

We needed to specifically check for driver support and test the correct
vbl_received value.  Also pulled over support for _DRM_VBLANK_NEXTONMISS
from the linux code.

bsd: Hook secondary vblank support.

bsd: Fix typo in i915_drv.c

mtx_sleep is preferred to msleep

Calling semantics are the same and both were introduced in 5.0

Clarify order of operations

DRM_DEBUG already prints the function name.

drm: Add _DRM_DRIVER map flag.

This flag indicates that the driver is responsible for the map.

bsd: Move counter initialization to load time.

nouveau: Properly identify NV40 and NV44 generation.

Beside the emitted warning, the added cast (u64 -> unsigned) strips out
part of address on 64 bit. Cast to unsigned long instead.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

drm: enable udev node creation

drm: oops not a cleanup..

Fix up drm_ati_pcigart_info

drm: more cleanups

i965: oops force mi batchbuffer start

Don't use panel fitter if we're programming a native mode

Fix from the DDX driver.

drm/modesetting: add initial gettable properites code.

This allow the user to retrieve a list of properties for an output.
Properties can either be 32-bit values or an enum with an associated name.
Range properties are to be supported.

This API is probably not all correct, I may make properties part of the general
resource get when I think about it some more.

So basically you can create properties and attached them to whatever outputs you want,
so it should be possible to create some generics and just attach them to every output.

fb: make fb interface use user mode attach/detach for adding modes

add _ioctl to the end of two more ioctls

drm: make fb modes use usermode add/remove interface

this stops usermode from getting a mode in the crtc it can't make sense off.

Merge branch 'origin' into modesetting-101

Conflicts:

linux-core/drmP.h
shared-core/i915_dma.c
shared-core/i915_drm.h
shared-core/radeon_drv.h

drm: major whitespace/coding style realignment with kernel

drm: cleanup drm_regman.c coding style

i915: add context handle to superioctl struct

This will be used later for lockless operation.

drm: don't reset to 0 irq_enabled when client open file descriptor

drm: don't reset to 0 irq_enabled when client open file descriptor

Fix capitalization of __linux__ define.

drm: fix dead lock in drm_buffer_object_transfer

drm: fix dead lock in drm_buffer_object_transfer

Bug #13233: Fix build on FreeBSD.

Bug #13233: Chase move of agp headers on FreeBSD.

radeon: refactor out the fb/agp location read/write.

Add a new get param to get the fb location into userspace. Mesa currently
hits MMIO to do this, but this isn't always possible.

Fix connection status ABI

Userspace expects a 1 based enum for connection status so fix up the kernel
definition.

Fix typo in copy_to_user calls

We want to copy to card_res->modes + copied, not &card_res->modes + copied.

nouveau: also mention the number of succcessfully copied bios bytes.

nouveau: rename

nouveau: flip buffer into gart.

Use user copy routines for writing modes & ids back to userspace

Since the drm_mode_card_res structure contains user pointers, we have to use
put_user and copy_to_user to write stuff out.  The DRM ioctl wrapper will only
take care of copying the base drm_mode_card_res struct, not the included
arrays.

nouveau: be verbose about PPC bios for now.

nouveau: revert the nv34 context size change, it was not the culprit after all.