Add kernel modesetting support to radeon driver, use the ttm memory
manager to manage memory and DRM/GEM to provide userspace API.
In order to avoid backward compatibility issue and to allow clean
design and code the radeon kernel modesetting use different code path
than old radeon/drm driver.

When kernel modesetting is enabled the IOCTL of radeon/drm
driver are considered as invalid and an error message is printed
in the log and they return failure.

KMS enabled userspace will use new API to talk with the radeon/drm
driver. The new API provide functions to create/destroy/share/mmap
buffer object which are then managed by the kernel memory manager
(here TTM). In order to submit command to the GPU the userspace
provide a buffer holding the command stream, along this buffer
userspace have to provide a list of buffer object used by the
command stream. The kernel radeon driver will then place buffer
in GPU accessible memory and will update command stream to reflect
the position of the different buffers.

The kernel will also perform security check on command stream
provided by the user, we want to catch and forbid any illegal use
of the GPU such as DMA into random system memory or into memory
not owned by the process supplying the command stream. This part
of the code is still incomplete and this why we propose that patch
as a staging driver addition, future security might forbid current
experimental userspace to run.

This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
(radeon up to X1950). Works is underway to provide support for R6XX,
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).

Authors:
    Jerome Glisse <jglisse@redhat.com>
    Dave Airlie <airlied@redhat.com>
    Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds the PCI IDs for the rv790 which are equiv to the rv770.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds drm support for the RV740 family of chips to the r600 support code.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This shouldn't be there and is what broke r600 late in the 2.6.30
release cycle with Ben's patch.
Signed-off-by: NDave Airlie <airlied@redhat.com>

We already added support, just need to let userspace
know when it can use them.
Signed-off-by: NMaciej Cencora <m.cencora@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Copy/paste error.  The RV670 microcode should work ok, so it's
not a show stopper.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

[airlied: cleaned up slightly for drm-next]
Signed-off-by: NMaciej Cencora <m.cencora@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes page table init on rs600.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

Until we sort out r600 IRQs don't do this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This update was done in mainline radeon, but not in the r600.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes 2 bugs:
1. the AGP calculation wasn't consistent with the PCI(E) calc for the
RPTR_ADDR registers. This consolidates the writes and fixes it up.

2. The scratch address was being incorrectly calculated, this breaks
it out into a lot more linear steps.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix this sparse warning:
  drivers/gpu/drm/radeon/r600_cp.c:1811:52: warning: Using plain integer as NULL pointer
  drivers/gpu/drm/radeon/radeon_cp.c:1363:52: warning: Using plain integer as NULL pointer
  drivers/gpu/drm/radeon/radeon_state.c:1983:61: warning: Using plain integer as NULL pointer
Signed-off-by: NHannes Eder <hannes@hanneseder.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This realigns the r600 pci mapping calls with the ati pcigart ones,
fixing the direction and using the correct interface.

Suggested by Jerome Glisse.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This calls the correct idle function for the R600 and previous chips.
Signed-off-by: NDave Airlie <airlied@redhat.com>

the checks weren't updated when RS600 support
was added.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

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

This attempts to fixup the r600 GART accessors so they work on other arches.
Signed-off-by: NDave Airlie <airlied@redhat.com>

RS600s are an AMD IGP for Intel CPUs, that look like RS690s from
a lot of perspectives but look like r600s from a memory controller
point of view.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes the ioremap issues with r600 AGP.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds support for 2D/Xv acceleration in the X.org 2D driver,
to the drm. It doesn't yet provide any 3D support hooks.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This uses the same microcode system as the current radeon code.

It should be converted to the new microcode loader I suppose,
though really I need a lot more proof of the worth of me maintaining
firmware blobs externally.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- add r6xx/r7xx regs and macros
- add r6xx/r7xx chip families
- fix register access for regs with offsets >= 0x10000
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this is just a code cleanup from the kms tree.
Signed-off-by: NDave Airlie <airlied@redhat.com>

On some radeon GPUs this appears to introduce another level of
stability around interacting with the ring.

Its pretty much what fglrx appears to do.
Signed-off-by: NDave Airlie <airlied@redhat.com>

In compat mode, the cmdbuf->buf 64-bit address cookie can
potentially be only 32-bit aligned.  Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.

Use get_unaligned() to fix.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.

We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV.  On the last close, we
release that surface.

Just to be doubly safe, we run the pcigart table setup with the main
surface control register clear.

Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.

However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.

Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd memory.

Adjust all of the ring_rptr access code as needed.

While we're here, kill the 'scratch' pointer in drm_radeon_private.
It's only used in the one place where it is initialized.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The kernel shouldn't be in the business of telling user space which
driver to load.  The kernel defers mapping PCI IDs to module names
to user space and we should do the same for DRI drivers.

And in fact, that's how it does work today.  Nothing uses the
dri_library_name attribute, and the attribute is in fact broken.
For intel devices, it falls back to the default behaviour of returning
the kernel module name as the DRI driver name, which doesn't work for
i965 devices.  Nobody has ever hit this problem or filed a bug about this.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This changes drm_local_map to use a resource_size for its "offset"
member instead of an unsigned long, thus allowing 32-bit machines
with a >32-bit physical address space to be able to store there
their register or framebuffer addresses when those are above 4G,
such as when using a PCI video card on a recent AMCC 440 SoC.

This patch isn't as "trivial" as it sounds: A few functions needed
to have some unsigned long/int changed to resource_size_t and a few
printk's had to be adjusted.

But also, because userspace isn't capable of passing such offsets,
I had to modify drm_find_matching_map() to ignore the offset passed
in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.

If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps
for a given device, we might have to change that trick, but I don't
think that happens on any current driver.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

The DRM uses its own wrappers to obtain resources from PCI devices,
which currently convert the resource_size_t into an unsigned long.

This is broken on 32-bit platforms with >32-bit physical address
space.

This fixes them, along with a few occurences of unsigned long used
to store such a resource in drivers.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This fixes a regression reported in bug #12613.

[airlied: not I tweaked the patch slightly and fixed it by etienne did
all the hardwork so gets authorship]
Signed-off-by: Netienne <etienne.basset@numericable.fr>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this solves a regression from
http://bugzilla.kernel.org/show_bug.cgi?id=12441Reported-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this exports the locked version of the symbol as struct_mutex locks it all.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Thanks to Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> for reporting
this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

This is step one towards having multiple masters sharing a drm
device in order to get fast-user-switching to work.

It splits out the information associated with the drm master
into a separate kref counted structure, and allocates this when
a master opens the device node. It also allows the current master
to abdicate (say while VT switched), and a new master to take over
the hardware.

It moves the Intel and radeon drivers to using the sarea from
within the new master structures.
Signed-off-by: NDave Airlie <airlied@redhat.com>