kernel/drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.c, branch linux-4.17.y

drm/nouveau/bios/volt: pointers are 32-bit

2016-11-28T05:39:35Z

Signed-off-by: Ben Skeggs

drm/nouveau/bios/vmap: pointers are 32-bit

2016-11-28T05:39:35Z

Signed-off-by: Ben Skeggs

drm/nouveau/volt: use kernel's 64-bit signed division function

2016-10-12T07:29:30Z

Doing direct 64 bit divisions in kernel code leads to references to undefined symbols on 32 bit architectures. Replace such divisions with calls to div64_s64 to make the module usable on 32 bit archs. Signed-off-by: Alexandre Courbot Reviewed-by: Karol Herbst Signed-off-by: Ben Skeggs

drm/nouveau/volt: Make use of cvb coefficients

2016-10-12T07:29:28Z

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 Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/volt/gf100-: Add speedo

2016-10-12T07:29:27Z

v5: Squashed speedo related commits. Signed-off-by: Karol Herbst Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/volt: Don't require perfect fit

2016-10-12T07:29:25Z

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 Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/clk: Respect voltage limits in nvkm_cstate_prog

2016-10-12T07:29:24Z

We should never allow to select a cstate which current voltage (depending on the temperature) is higher than 1. the max volt entries in the voltage map table. 2. what tha gpu actually can volt to. v3: Use find_best for all cstates before actually trying. Add nvkm_cstate_get function to get cstate by index. v5: Cstates with voltages lower then min_uv are valid. Move nvkm_cstate_get into the previous commit. Signed-off-by: Karol Herbst Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/volt: Add temperature parameter to nvkm_volt_map

2016-10-12T07:29:23Z

The voltage entries actually may map to a different voltage depending on the current temperature. v2: Only read the temperature when actually needed. v5: Be smarter about using max(). Don't read the temperature anymore. Signed-off-by: Karol Herbst Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/volt: Add min_id parameter to nvkm_volt_set_id

2016-10-12T07:29:21Z

Each pstate has its own voltage map entry like each cstate has. The voltages of those entries act as a floor value for the currently selected pstate and nvidia never sets a voltage below them. Signed-off-by: Karol Herbst Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs

drm/nouveau/volt: Parse the max voltage map entries

2016-10-12T07:29:20Z

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 Reviewed-by: Martin Peres Signed-off-by: Ben Skeggs