History log of /drivers/gpu/drm/radeon/radeon_agp.c
Revision Date Author Comments
e57415d85f72e36029b75fdb556c95fb5346b692 18-Aug-2010 Alex Deucher <alexdeucher@gmail.com> drm/radeon/kms: fix agp mode setup on cards that use pcie bridges

Asics that use an AGP to PCIE bridge don't have the AGP_STATUS
register so just use whatever mode the host side setup.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
10b06122afcc78468bd1d009633cb71e528acdc5 21-May-2010 Jerome Glisse <jglisse@redhat.com> drm/radeon/kms: release AGP bridge at suspend

I think it's good to release the AGP bridge at suspend
and reacquire it at resume. Also fix :
https://bugzilla.kernel.org/show_bug.cgi?id=15969

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ccb2ad579f910e6146adf4eb3aa50325253ee8c9 24-Apr-2010 Robert Fitzsimons <robfitz@273k.net> drm/radeon/kms/agp The wrong AGP chipset can cause a NULL pointer dereference

Selecting the wrong or no CONFIG_AGP_* chipset can cause a NULL pointer
dereference when combined with CONFIG_DRM_RADEON_KMS and an old system
with a R100 AGP card (should effect other cards too). The agp field
will be set to NULL if no suitable AGP chipset driver is loaded,
drm_agp_acquire already preforms a suitable NULL check so it can be used
directly.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
d594e46ace22afa1621254f6f669e65430048153 17-Feb-2010 Jerome Glisse <jglisse@redhat.com> drm/radeon/kms: simplify memory controller setup V2

Get rid of _location and use _start/_end also simplify the
computation of vram_start|end & gtt_start|end. For R1XX-R2XX
we place VRAM at the same address of PCI aperture, those GPU
shouldn't have much memory and seems to behave better when
setup that way. For R3XX and newer we place VRAM at 0. For
R6XX-R7XX AGP we place VRAM before or after AGP aperture this
might limit to limit the VRAM size but it's very unlikely.
For IGP we don't change the VRAM placement.

Tested on (compiz,quake3,suspend/resume):
PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710
AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730
IGP:RS480(RPB*),RS690,RS780(RPB*),RS880

RPB: resume previously broken

V2 correct commit message to reflect more accurately the bug
and move VRAM placement to 0 for most of the GPU to avoid
limiting VRAM.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
4b866288be6ffaefaad9cec212cb09e3258a68ee 01-Feb-2010 Dave Airlie <airlied@redhat.com> drm/radeon/kms: release agp on error.

if we get an error, release the AGP if we've acquired it already.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2dea2e29b9fad48c759aa406b5ea426bff4339af 31-Jan-2010 John Kacur <jkacur@redhat.com> drm/kms/radeon/agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info

First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.

Signed-off-by: John Kacur <jkacur@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
cdb6e375c3c84558ed2c13c5461b22e8f7b7980e 31-Jan-2010 John Kacur <jkacur@redhat.com> drm/kms/radeon/agp: Fix warning, format ‘%d’ expects type ‘int’, but argument 4 has type ‘size_t’

- Fix warning by using %zu instead of %d for size_t
- Fix spelling mistake, "to" should be "too".

Signed-off-by: John Kacur <jkacur@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
0a3f316370da07fcdb11fde4f5a683d60713b7fd 13-Jan-2010 Jerome Glisse <jglisse@redhat.com> drm/radeon/kms: Disable AGP is aperture size < 32M

radeon KMS need a GART of at least 32M to properly work. This patch
check the AGP aperture size and disable if it's less than 32M. Note
than unlike non KMS path we don't staticaly allocate AGP memory so
we are not wasting memory not used by graphic processing.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
d0269ed8580b492df75dafb011dc51a1390bf200 07-Jan-2010 Jerome Glisse <jglisse@redhat.com> drm/radeon/kms: Make sure we release AGP device if we acquired it

In some case we weren't releasing the AGP device at module unloading.
This leaded to unfunctional AGP at next module load. This patch make
sure we release the AGP bus if we acquire it.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
0ebf17174b4bdd99ab81c476714c91ee335fdcbf 05-Nov-2009 Dave Airlie <airlied@redhat.com> drm/radeon/kms: resume AGP by calling init.

AGP resume was broken since we moved to the new init path,
because we never re-enabled AGP on these systems at resume time.

This patch just calls the AGP resume call which just does the reinit
at resume time like the old path did.

Since AGP is pretty much gpu independant I did it outside
the gpu specific code.

Signed-off-by: Dave Airlie <airlied@redhat.com>
771fe6b912fca54f03e8a72eb63058b582775362 05-Jun-2009 Jerome Glisse <jglisse@redhat.com> drm/radeon: introduce kernel modesetting for radeon hardware

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: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>