- 13 Mar, 2012 40 commits
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Roy Spliet authored
This patch fixes two small issues in timing generation as spotted on several NVCx cards. In addition, the header of the file is updated to also contain (some of) the current developers of this code. Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Fixes reclocking failure on some chips where we attempted to set PDAEMON to PLL mode. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Xi Wang authored
The comparison (lpre == DP_TRAIN_PRE_EMPHASIS_9_5) is always false: lpre is initialized as (lane & 0x0c) >> 2, which is at most 3, while DP_TRAIN_PRE_EMPHASIS_9_5 is defined as (3 << 3). Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
There's a HP laptop out there where the MXM version in the VBIOS doesn't match what the ACPI implementation is expecting. These tables will accept 0x00 to MXMS to return latest version, but *only* if MXMI has been called first.. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This patch fixes an oops cause by pm_trigger accessing the (uninitialised) crtc list. Reported-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Christoph Bumiller authored
Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
v2 (Emil Velikov <emil.l.velikov@gmail.com>): - Fixed a regression on certain nv50 IGP due to not passing the correct target type to nv50_vm_addr() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Johannes Obermayr <johannesobermayr@gmx.de>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Fixes minor flickering on NVS295 when at perflvl 0. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
There's some "extended" GDDR3 chipsets out there with EMRS2 settings that change the layout of MRS/EMRS1 bitmaps.. Sigh.. Still need to track down how exactly we're supposed to handle this. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Idea from Martin Peres, different implementation by me. v2: Martin Peres: - fix mast calculation Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
This will probably result in more lines of code, however, we're going to have at least 3 slightly different implementations of this very soon and I'd rather keep the ram reclocking logic separate from the hw specifics. DDR2/DDR3/GDDR3 implemented thus far, others will be added as necessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Statically generating the PFB register and MR values for each timing set turns out to be insufficient. There's at least one (so far) known piece of information which effects MR values which is stored in the perflvl entry on some chipsets (and in another table on later ones), which is disconnected from the timing table entries. After this change we will generate a timing set based on an input clock frequency instead, and have this data stored in the performance level data. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
We might want/need the boot data to generate the other perflevels. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Roy Spliet authored
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>
-
Ben Skeggs authored
It turns out we need access to some additional information in various VBIOS tables to handle PFB memory timings correctly. Rather than hack in parsing of the new stuff in some kludgy way, I've restructured the VBIOS parsing to be more primitive, so we can use them in more flexible ways in the future. The perflvl->timing association code is disabled for the moment until it can be reworked. We don't use this stuff yet anyway, so no harm done. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
-
Jean Delvare authored
Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also remove trailing space. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Roy Spliet authored
- Rename several VBIOS entries to closer match the real world - Add the missing 0x100238 and 0x100240 register values - Parse bit 14 of the VBIOS timing table - "Magic value" -> tCWL, fixing some minor bugs in the process - Also name a few more by their name rather than their number. - Some values seem to be dependent on the memory type. Fix Edits by Martin Peres <martin.peres@labri.fr>: - this is a squash commit - reworked for fixing some style issues 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>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Uses only the VBIOS tables, from what I can tell this is what NVIDIA do too, I was able to change the detected memory type by modifying this table on a NVC1 chipset. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
NV20/NV30 is partially educated guesswork at this point, based on any information around about available memory types and a horribly unspeakable amount of vbios image scouring. I'm not entirely certain the GDDR3 define is correct, I have not spotted a single vbios with that value yet (though it is mentioned in some 1218-using nv4x vbios), but there are reports that some nv3x did use it.. NV40(100914) confirmed by switching an NV49 to DDR1/DDR2 values and making sure that the binary driver behaviour showed it had detected DDR1/DDR2 instead of GDDR3 before dying horribly. NV40(100474) confirmed by doing much the same task as above on an NV44, except this was *much* easier as changing the values didn't seem to have any noticable effect on the memory controller aside from changing the binary driver's behaviour. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Most functions were quite different between NV10/NV20 already, and they're about to get even more so. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-