Commit graph

35 commits

Author SHA1 Message Date
Dave Airlie
0bcb1d844a Merge branch 'drm-radeon-lockup' into drm-core-next
* drm-radeon-lockup:
  drm/radeon/kms: simplify & improve GPU reset V2
  drm/radeon/kms: rename gpu_reset to asic_reset
  drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4

Conflicts:
	drivers/gpu/drm/radeon/r300.c
2010-04-20 13:15:05 +10:00
Jerome Glisse
90aca4d274 drm/radeon/kms: simplify & improve GPU reset V2
This simplify and improve GPU reset for R1XX-R6XX hw, it's
not 100% reliable here are result:
- R1XX/R2XX works bunch of time in a row, sometimes it
  seems it can work indifinitly
- R3XX/R3XX the most unreliable one, sometimes you will be
  able to reset few times, sometimes not even once
- R5XX more reliable than previous hw, seems to work most
  of the times but once in a while it fails for no obvious
  reasons (same status than previous reset just no same
  happy ending)
- R6XX/R7XX are lot more reliable with this patch, still
  it seems that it can fail after a bunch (reset every
  2sec for 3hour bring down the GPU & computer)

This have been tested on various hw, for some odd reasons
i wasn't able to lockup RS480/RS690 (while they use to
love locking up).

Note that on R1XX-R5XX the cursor will disapear after
lockup haven't checked why, switch to console and back
to X will restore cursor.

Next step is to record the bogus command that leaded to
the lockup.

V2 Fix r6xx resume path to avoid reinitializing blit
module, use the gpu_lockup boolean to avoid entering
inifinite waiting loop on fence while reiniting the GPU

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-06 11:21:11 +10:00
Jerome Glisse
a2d07b7438 drm/radeon/kms: rename gpu_reset to asic_reset
Patch rename gpu_reset to asic_reset in prevision of having
gpu_reset doing more stuff than just basic asic reset.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-06 11:21:04 +10:00
Tejun Heo
336f5899d2 Merge branch 'master' into export-slabh 2010-04-05 11:37:28 +09:00
Dave Airlie
08a370fa75 drm/radeon/kms: rs400/480 should set common registers.
These GPUs should be setting these registers up also.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-01 12:50:28 +10:00
Jerome Glisse
f927456202 drm/radeon/kms: avoid possible oops (call gart_fini before gart_disable)
radeon_gart_fini might call GART unbind callback function which
might try to access GART table but if gart_disable is call first
the GART table will be unmapped so any access to it will oops.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-03-31 13:11:42 +10:00
Alex Deucher
b2f8ccd840 drm/radeon/kms: fix display bandwidth setup on rs4xx
I missed rs4xx in 7f1e613daf0fdd0884316ab25a749db3c671329e

Fixes fdo bug 27219.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-03-31 13:11:13 +10:00
Alex Deucher
29fb52ca78 drm/radeon/kms: expose thermal/fan i2c buses
Look up i2c bus in the power table and expose it.
You'll need to load a hwmon driver for any chips
on the bus, this patch just exposes the bus.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
2010-03-31 09:38:06 +10:00
Tejun Heo
5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
Daniel Vetter
e6990375ef drm/radeon: include radeon_asic.h in the asic specific files
In essence this creates a home for all asic specific declarations in
radeon_asic.h

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-03-15 11:27:22 +10:00
Jerome Glisse
d594e46ace 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>
2010-02-18 14:49:35 +10:00
Dave Airlie
8256856568 drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page
this uses a new entrypoint to invalidate gart entries instead of using 0.
Changed to rather than pointing to 0 address point empty entry to dummy
page. This might help to avoid hard lockup if for some wrong
reasons GPU try to access unmapped GART entry.

I'm not 100% sure this is going to work, we probably need to allocate
a dummy page and point all the GTT entries at it similiar to what AGP does.
but we can test this first I suppose.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-11 19:11:32 +10:00
Dave Airlie
a17538f93c drm/radeon/kms: rs400/480 MC setup is different than r300.
Boot testing on my rs480 laptop found the MC idle never happened
on startup, a quick check with AMD found the idle bit is in a different
place on the rs4xx than r300.

Implement a new rs400 mc idle function to fix this.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-05 13:40:16 +10:00
Jerome Glisse
655efd3dc9 drm/radeon/kms: don't call suspend path before cleaning up GPU
In suspend path we unmap the GART table while in cleaning up
path we will unbind buffer and thus try to write to unmapped
GART leading to oops. In order to avoid this we don't call the
suspend path in cleanup path. Cleanup path is clever enough
to desactive GPU like the suspend path is doing, thus this was
redondant.

Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE)

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-05 11:49:52 +10:00
Jerome Glisse
cafe6609d6 drm/radeon/kms: Schedule host path read cache flush through the ring V2
R300 family will hard lockup if host path read cache flush is
done through MMIO to HOST_PATH_CNTL. But scheduling same flush
through ring seems harmless. This patch remove the hdp_flush
callback and add a flush after each fence emission which means
a flush after each IB schedule. Thus we should have same behavior
without the hard lockup.

Tested on R100,R200,R300,R400,R500,R600,R700 family.

V2: Adjust fence counts in r600_blit_prepare_copy()

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-01-08 13:09:59 +10:00
Alex Deucher
06b6476d6b drm/radeon/kms: detect sideport memory on IGP chips
This detects if the sideport memory is enabled and
if it is VRAM is evicted on suspend/resume.

This should fix s/r issues on some IGPs.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-01-08 13:08:56 +10:00
Rafał Miłecki
6234077d6b drm/radeon/kms: init pm on all chipsets
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-16 15:56:15 +10:00
Dave Airlie
550e2d9270 drm/radeon/kms: restore surface registers on resume.
On resume on my rv530 laptop surface cntl was left disabled, so
wierd stuff would happen with rendering to a tiled front buffer.

This checks if the surface regs are assigned to bos and reprograms
the surface registers on resume using the same path that clears
them all on init.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-10 15:25:45 +10:00
Alex Deucher
22dd50133a drm/radeon/kms: fix vram setup on rs600/rs690/rs740
Don't remap vram to 0 on IGP chips.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-08 08:58:33 +10:00
Jerome Glisse
4c78867912 drm/radeon/kms: Rework radeon object handling
The locking & protection of radeon object was somewhat messy.
This patch completely rework it to now use ttm reserve as a
protection for the radeon object structure member. It also
shrink down the various radeon object structure by removing
field which were redondant with the ttm information. Last it
converts few simple functions to inline which should with
performances.

airlied: rebase on top of r600 and other changes.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-02 14:00:18 +10:00
Dave Airlie
1614f8b17b drm/radeon/kms: add irq mitigation code for sw interrupt.
We really don't need to process every irq that comes in, we only
really want to do SW irq processing when we are actually waiting for
a fence to pass. I'm not 100% sure this is race free esp on non-MSI systems
so it needs some testing.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-02 14:00:13 +10:00
Dave Airlie
72542d7705 drm/radeon/kms: ignore unposted GPUs with no BIOS.
If we find a GPU but we can't find its BIOS and it isn't posted,
then ignore it.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-02 11:37:17 +10:00
Dave Airlie
17e15b0c71 drm/radeon/kms: AGP systems need PCI bus mastering enabled
We might not hit this yet, but when if we do any sort of writeback
we really need to enable PCI bus mastering on these systems from
what I can see.

This enables PCI BM on all radeons that require it.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-02 11:36:41 +10:00
Dave Airlie
ea1495a627 drm/radeon/kms: fix rc410 suspend/resume.
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-28 16:01:58 +10:00
Jerome Glisse
62a8ea3f7b drm/radeon/kms: Remove old init path as no hw use it anymore
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-02 09:33:46 +10:00
Jerome Glisse
ca6ffc64cb drm/radeon/kms: Convert RS400/RS480 to new init path & fix legacy VGA (V3)
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-10-02 08:51:46 +10:00
Jerome Glisse
4aac047323 drm/radeon/kms: clear confusion in GART init/deinit path
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-15 08:53:14 +10:00
Jerome Glisse
21f9a43722 drm/radeon/kms: cleanup - remove radeon_share.h
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-14 16:10:00 +10:00
Jerome Glisse
3ce0a23d2d drm/radeon/kms: add r600 KMS support
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-09-08 11:15:52 +10:00
Dave Airlie
7a50f01a4a drm/radeon/kms: vram sizing on certain r100 chips needs workaround.
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-29 15:53:25 +10:00
Jerome Glisse
c93bb85b5c drm/radeon/kms: fix bandwidth computation on avivo hardware
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-29 15:45:09 +10:00
Dave Airlie
2a0f8918fc drm/radeon/kms: fix VRAM sizing like DDX does it.
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-15 17:13:19 +10:00
Dave Airlie
3e43d82125 drm/radeon/kms: respect TOM on rs100->rs480 IGP variants.
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-15 17:13:07 +10:00
Dave Airlie
ed10f95d60 drm/radeon/kms: fix some GART table entry bugs.
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-07-15 17:13:02 +10:00
Jerome Glisse
771fe6b912 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>
2009-06-15 12:01:53 +10:00