Commit Graph

12 Commits

Author SHA1 Message Date
Ben Skeggs
0ce7141558 drm/nv50: fix detection of second vram rank
Goes a long way to correcting NVS295 memory reclocking issues.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
2012-03-13 17:08:51 +10:00
Roy Spliet
c7c039fd31 drm/nouveau/pm: implement DDR2/DDR3/GDDR3/GDDR5 MR generation and validation
Roy Spliet:
- Implement according to specs
- Simplify
- Make array for mc latency registers

Martin Peres:
- squash and split all the commits from Roy
- rework following Ben Skeggs comments
- add a form of timings validation
- store the initial timings for later use

Ben Skeggs
- merge slightly modified tidy-up patch with this one
- remove perflvl-dropping logic for the moment

Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-03-13 17:07:50 +10:00
Ben Skeggs
c70c41e89f drm/nv50: hopefully handle the DDR2/DDR3 memtype detection somewhat better
M version 2 appears to have a table with some form of memory type info
available.

NVIDIA appear to ignore the table information except for this DDR2/DDR3
case (which has the same value in 0x100714).  My guess is this is due to
some of the supported memory types not being represented in the table.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-03-13 17:05:46 +10:00
Ben Skeggs
1072856a1c drm/nv50: add memory type detection
DDR1/DDR[23] confirmed on NVA8 (see note about DDR3 in source) by changing
the value and watching the binary driver's behaviour.

GDDR3/4 values confirmed on a NV96 via the same method above.  That GDDR4
is present is interesting, as far as I can see no boards using it were ever
released.

GDDR5 value is based on VBIOS images of known GDDR5 boards.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2012-03-13 17:05:40 +10:00
Ben Skeggs
7b4b98fa0c drm/nv50/vram: fix incorrect detection of bank count on newer chipsets
NVA3+ has an extra bit here compared to NV50:NVA3 chipsets.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-11-10 08:58:47 +10:00
Ben Skeggs
987eec10dd drm/nouveau: embed nouveau_mm
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-09-20 16:03:56 +10:00
Ben Skeggs
24f246ac10 drm/nouveau: rework vram init/fini ordering a little
Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
revealed an issue where vram mm takedown would actually fail due to there
still being nodes present, causing nouveau to leak a small amount of memory
on module unload.

This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
isn't done until all gpuobjs are also destroyed.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-06-23 16:03:46 +10:00
Ben Skeggs
8f7286f8e4 drm/nv50: support for compression
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-02-25 06:46:07 +10:00
Ben Skeggs
d5f423947a drm/nouveau: rename nouveau_vram to nouveau_mem
This structure will also be used for GART in the near future.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2011-02-25 06:45:55 +10:00
Dan Carpenter
d095e23206 drm/nouveau: sizeof() vs ARRAY_SIZE()
ARRAY_SIZE() was intended here, sizeof() is too large.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-21 11:53:32 +10:00
Ben Skeggs
60d2a88ae8 drm/nouveau: kick vram functions out into an "engine"
NVC0 will be able to share some of nv50's paths this way.  This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-08 13:48:20 +10:00
Ben Skeggs
573a2a37e8 drm/nv50: implement custom vram mm
This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.

This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2010-12-08 13:48:07 +10:00