- 20 9月, 2011 2 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Instead of 10s of millivolts, to match fermi vbios. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 18 6月, 2011 1 次提交
-
-
由 Emil Velikov 提交于
While parsing the perf table, there is no check if the num of entries read from the vbios is less than the currently allocated number. In case of a buggy vbios this will cause overwriting of kernel memory, causing aditional problems. Add a simple check in order to prevent the case Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 16 5月, 2011 6 次提交
-
-
由 Ben Skeggs 提交于
Hopefully this is how we're supposed to correctly handle when the RAMCFG strap is above the number of entries in timing-related tables. It's rather difficult to confirm without finding a configuration where the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's not a single vbios in the repo which is configured differently.. In any case, this is probably still better than potentially reading outside of the bounds of various tables.. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
We need to parse some of these other entries still, but I've yet to determine exactly which PLLs the rest map to. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Really not necessary here, we want to be able to see if/how we managed to match a timingset to a performance level, even if we can't currently program it. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40 Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 05 4月, 2011 1 次提交
-
-
由 Emil Velikov 提交于
Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough to store the voltage label/id v2 - Remove comment from the code Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 05 10月, 2010 3 次提交
-
-
由 Ben Skeggs 提交于
This was disabled previously because of some uncertainty that +2 was indeed the voltage. It appears it is, checked on a NVA8 and a NVA3M. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 24 9月, 2010 4 次提交
-
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Used on nv17-nv28, they contain memory clocks and timings, only one of the table entries can actually be used, depending on the RAMCFG straps, and it's usually higher than the frequency programmed on boot by the BIOS. The memory timings listed in table version 0x1x are used to init the 0x12xx range but they aren't required for reclocking to work. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Reported-by: NRoy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-