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>

This check was introduced with the logic the wrong way around.

Fixes regression: http://bugzilla.kernel.org/show_bug.cgi?id=12216Tested-by: NFrançois Valenduc <francois.valenduc@tvcablenet.be>
Signed-off-by: NDave Airlie <airlied@redhat.com>

vblank can try and enable the IRQ registers before we've set the interrupt
handler up.
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm vblank initialization keeps track of the changes in driver-supplied
frame counts across vt switch and mode setting, but only if you let it by
not tearing down the drm vblank structure.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now that the radeon driver has suspend/resume functions, it needs to map its
registers at load time or it will likely crash if a suspend operation occurs
before the driver has been initialized.

This patch moves the register mapping code from firstopen to load and makes
the mapping into a _DRM_DRIVER one so that the core won't remove it at
lastclose time.

Fixes (at least partially) kernel bz #11891.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

rs400/480 are like previous chips not like rs6xx chips.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Someone noticed these registers moved around for later chips,
so we redo the codepaths per-chip. PCIE chips don't appear to
require explicit enables.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds support for the RS400 family of IGPs for Intel CPUs.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds support for the HS2100 IGP chipset.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Like the last patch but adds a macro to get at the irq value instead of
dereferencing pdev directly.  Should  make things easier for the BSD guys and
if we ever support non-PCI devices.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Previously, drivers supporting vblank interrupt waits would run the interrupt
all the time, or all the time that any 3d client was running, preventing the
CPU from sleeping for long when the system was otherwise idle.  Now, interrupts
are disabled any time that no client is waiting on a vblank event. The new
method uses vblank counters on the chipsets when the interrupts are turned
off, rather than counting interrupts, so that we can continue to present
accurate vblank numbers.

Co-author: Michel Dänzer <michel@tungstengraphics.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make writeback not get disabled on resume.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If this triggers its bad, however some machines seem to have been
triggering it for ages and we didn't know until we added the debug.

So downgrade the debug now so people don't call this a regression.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes our handling of cliprects sane. drm_clip_rect always has exclusiv
bottom-right corners, but the hardware expects inclusive bottom-right corner
so we adjust this here.

This complements Michel Daenzer's commit 57aea290e1e0a26d1e74df6cff777eb9f03
to Mesa. See also http://bugs.freedesktop.org/show_bug.cgi?id=16123Signed-off-by: NDave Airlie <airlied@redhat.com>

DRAW_INDEX writes a vertex count to VAP_VF_CNTL. Docs say that behaviour
is undefined (i.e. lockups happen) when this write is not followed by the
right number of vertex indices.

Thus we used to do the wrong thing when drawing across many cliprects was
necessary, because we emitted a sequence
DRAW_INDEX, DRAW_INDEX, INDX_BUFFER, INDX_BUFFER
instead of
DRAW_INDEX, INDX_BUFFER, DRAW_INDEX, INDX_BUFFER
The latter is what we're doing now and which ought to be correct.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch should fix hard lockup and convert them in
softlockup (ie you can ssh the box but the gpu is busted
and we are waiting in loop for it to come back to reason).
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some module parameters with only one line have the '\n' at the end of the
description.  This is not needed nor wanted as after the description the
type (i.e.  int) is followed by a newline.

Some modules contain a multi-line description, these are not affected
by this patch.
Signed-off-by: NNiels de Vos <niels.devos@wincor-nixdorf.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Ed L. Cashin <ecashin@coraid.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Roland Dreier <rolandd@cisco.com>
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With new userspace libpciaccess we can get a conflicting mapping
on the PCIE GART table in the video RAM. Always try and map it _wc.
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.

This restructures the drm along the lines of other kernel components.

It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.
Signed-off-by: NDave Airlie <airlied@redhat.com>