114653c7 | 12-Jul-2016 |
Karol Herbst <karolherbst@gmail.com> |
drm/nouveau/volt: Make use of cvb coefficients
I'm quite sure that those coefficients are real close, because while testing the biggest error compared to nvidia was around -1.5% (biggest error with
drm/nouveau/volt: Make use of cvb coefficients
I'm quite sure that those coefficients are real close, because while testing the biggest error compared to nvidia was around -1.5% (biggest error with right coefficients is 12.5mV / 600mV = 2%).
These coefficients were REed by modifing the voltage map entries and by calculating the set voltage back until I was able to forecast which voltage nvidia sets for a given voltage map entry.
With these formulars I am able to precisely predict at which exact temperature Nvidia down- or upvolts due to a changed therm reading.
That's why I am quite sure these are right, or at least really really close.
v4: Use better coefficients and speedo. v5: Add error message when speedo is missing.
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
show more ...
|
5e00e326 | 12-Jul-2016 |
Karol Herbst <karolherbst@gmail.com> |
drm/nouveau/volt: Don't require perfect fit
If we calculate the voltage in the table right, we get all kinds of values, which never fit the hardware steps, so we use the closest higher value the har
drm/nouveau/volt: Don't require perfect fit
If we calculate the voltage in the table right, we get all kinds of values, which never fit the hardware steps, so we use the closest higher value the hardware can do.
v3: Simplify the implementation. v5: Initialize best_err with volt->max_uv.
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
show more ...
|
4a4555a7 | 12-Jul-2016 |
Karol Herbst <karolherbst@gmail.com> |
drm/nouveau/volt: Parse the max voltage map entries
There are at least three "max" entries, which specify the max voltage. Because they are actually normal voltage map entries, they can also be affe
drm/nouveau/volt: Parse the max voltage map entries
There are at least three "max" entries, which specify the max voltage. Because they are actually normal voltage map entries, they can also be affected by the temperature.
Nvidia respects those entries and if they get changed, nvidia uses the lower voltage from all three.
We shouldn't exceed those voltages at any given time.
v2: State what those entries do in the source. v3: Add the third max entry. v5: Better describe the entries.
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
show more ...
|
17d063db | 12-Jul-2016 |
Karol Herbst <karolherbst@gmail.com> |
drm/nouveau/clk: Don't create cstates with voltages higher than what the gpu can do
nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the lowest possible voltage for a cstate.
nvkm
drm/nouveau/clk: Don't create cstates with voltages higher than what the gpu can do
nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the lowest possible voltage for a cstate.
nvkm_volt_map will get a temperature parameter there later and also fix the voltage calculation, so that this functions will be completly different later.
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
show more ...
|
437bb44d | 26-Feb-2016 |
Karol Herbst <nouveau@karolherbst.de> |
drm/nouveau/volt: save the voltage range we are able to set
We shouldn't set voltages below the min or above the max voltage the gpu is able to set, so save the range for future lookups.
Signed-off
drm/nouveau/volt: save the voltage range we are able to set
We shouldn't set voltages below the min or above the max voltage the gpu is able to set, so save the range for future lookups.
Signed-off-by: Karol Herbst <karolherbst@gmail.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
show more ...
|