| 0ce71415587b1fd56f67294ac46f860b8b679b95 |
|
24-Jan-2012 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| c7c039fd31be82ecb8d48477955e76badd38141a |
|
09-Jan-2012 |
Roy Spliet <r.spliet@student.tudelft.nl> |
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>
|
| c70c41e89f0481f26749d8264aebc594566c2a6d |
|
13-Dec-2011 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| 1072856a1c604726be6a8adfb6b2c86033e6a314 |
|
13-Dec-2011 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| 7b4b98fa0c4d3a975b36bfe9984e4cd117f2ddff |
|
07-Oct-2011 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| 987eec10dd76624d0edacdc7ecc7e1a6fc877373 |
|
24-Jun-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: embed nouveau_mm
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| 24f246ac10ae6a6ae873045387d4501498869f74 |
|
10-Jun-2011 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| 8f7286f8e4e80f7b868ba3d117ae900f0d207cbe |
|
14-Feb-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv50: support for compression
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
| d5f423947a11103c43ad26ebb680d049c2d8edd6 |
|
09-Feb-2011 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| d095e23206e6291cbde4b2937d1316a42d9e6440 |
|
19-Dec-2010 |
Dan Carpenter <error27@gmail.com> |
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>
|
| 60d2a88ae896ae51c76f8b15c2f4b762d5b00864 |
|
06-Dec-2010 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|
| 573a2a37e8648a3249426c816f51e7ef50f6f73e |
|
25-Aug-2010 |
Ben Skeggs <bskeggs@redhat.com> |
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>
|