aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/radeon/rs400.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2009-10-28drm/radeon/kms: fix rc410 suspend/resume.Dave Airlie1-0/+2
This fixes suspend/resume on my rc410 motherboard, it restores the memory controller setup before posting the GPU, since it seems to need the MC_FB_LOCATION setup correctly. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-02drm/radeon/kms: Remove old init path as no hw use it anymoreJerome Glisse1-1/+0
This remove old init path and allow code cleanup, now all hw use the new init path, see top of radeon.h for description of this. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-02drm/radeon/kms: Convert RS400/RS480 to new init path & fix legacy VGA (V3)Jerome Glisse1-86/+190
Also cleanup register specific to RS400/RS480. This patch also fix legacy VGA register used to disable VGA access we were programming wrong register. Now we should properly disable VGA on r100 up to rs400 asics. Note that RS400/RS480 resume is broken, it hangs the computer while reprogramming dynamic clock, doesn't work either without that patch. We need to spend more time investigating this issue. Version 2 of the patch remove dead code that was left commented out in the previous version. Version 3 correct the placement on IGP of the VRAM inside GPU address space to match the stollen RAM placement of IGP. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-15drm/radeon/kms: clear confusion in GART init/deinit pathJerome Glisse1-17/+36
GART static one time initialization was mixed up with GART enabling/disabling which could happen several time for instance during suspend/resume cycles. This patch splits all GART handling into 4 differents function. gart_init is for one time initialization, gart_deinit is called upon module unload to free resources allocated by gart_init, gart_enable enable the GART and is intented to be call after first initialization and at each resume cycle or reset cycle. Finaly gart_disable stop the GART and is intended to be call at suspend time or when unloading the module. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-14drm/radeon/kms: cleanup - remove radeon_share.hJerome Glisse1-1/+0
radeon_share.h was begining to give problem with include order in respect of radeon.h. It's easier and also i think cleaner to move what was in radeon_share.h into radeon.h. At the same time use the extern keyword for function shared accross the module. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08drm/radeon/kms: add r600 KMS supportJerome Glisse1-1/+1
This adds the r600 KMS + CS support to the Linux kernel. The r600 TTM support is quite basic and still needs more work esp around using interrupts, but the polled fencing should work okay for now. Also currently TTM is using memcpy to do VRAM moves, the code is here to use a 3D blit to do this, but isn't fully debugged yet. Authors: Alex Deucher <alexdeucher@gmail.com> Dave Airlie <airlied@redhat.com> Jerome Glisse <jglisse@redhat.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-29drm/radeon/kms: vram sizing on certain r100 chips needs workaround.Dave Airlie1-2/+2
If an rn50/r100/m6/m7 GPU has < 64MB RAM, i.e. 8/16/32, the aperture used to calculate the MC_FB_LOCATION needs to be worked out from the CONFIG_APER_SIZE register, and not the actual vram size. TTM VRAM size was also being initialised wrong, use actual vram size to initialise it. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-29drm/radeon/kms: fix bandwidth computation on avivo hardwareJerome Glisse1-0/+1
Fix bandwidth computation and crtc priority in memory controller so that crtc memory request are fullfill in time to avoid display artifact. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-15drm/radeon/kms: fix VRAM sizing like DDX does it.Dave Airlie1-13/+1
Doing this like the DDX seems like the most sure fire way to avoid having to reinvent it slowly and painfully. At the moment we keep getting things wrong with aper vs vram, so we know the DDX does it right. booted on PCI r100, PCIE rv370, IGP rs400. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-15drm/radeon/kms: respect TOM on rs100->rs480 IGP variants.Dave Airlie1-2/+4
Normally we are free to place VRAM where we want in the GPUs memory address space, however on IGP chips the VRAM is actual RAM, and no special translation or aperture is used inside the GPU MC. So when you move the VRAM aperture away from the TOM register, you actually move it into main memory and can trash things quite badly. This commit makes the code respect the TOM location for MC_FB_LOCATION. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-15drm/radeon/kms: fix some GART table entry bugs.Dave Airlie1-2/+11
1. rv370 can accept 40-bit addresses - also at 24-bit shift not 4 bits 2. rs480 table can be in 40-bit space. - 4 bit shift for top 8 bits 3. rs480 table entries can be in 40-bit space. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-15drm/radeon: introduce kernel modesetting for radeon hardwareJerome Glisse1-0/+411
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>