Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes]
....

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes]
....

In fact, these functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h
drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h
drivers/gpu/drm/nouveau/dispnv04/disp.h.
So this patch adds missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v5: Squashed speedo related commits.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Since gf100 we need a speedo value for calculating the voltage. The readout
will be added in a later patch.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There is a field in the voltage table which tells us if the VIDs are taken
from the entries or calculated through the header.

v2: Don't break older versions.
v5: Reverse flag name.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NKarol Herbst <karolherbst@gmail.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch adds support for advanced features supported by the
Noise-Aware PLL of Maxwell. Glitchless switch allows the PL field to be
updated without disabling the PLL first if the SYNC_MODE bit of the CFG
register is set.

More significantly, DFS allows the PLL to monitor the actual input
voltage and to dynamically lower the output frequency accordingly. This
allows the clock to be more tolerant of lower voltages.

These improvements are only supported for Tegra speedos >= 1.

Also add the voltage table that is suitable for GM20B's NAPLL. This
change needs to be done atomically for the right voltages to be used by
the clock driver.

v2. Fix build on non-Tegra platforms
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Chips may be characterized for a minimum voltage. Support this extra
parameter and select the appropriate minimum voltage for the detected
GPU speedo.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Strip the _ prefix off the gk20a volt constructor.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Give a name to this constant so we at least get an idea of what it is
for.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Nobody else is using these, so make them private.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We always want a equal or higher voltage than the requested ones, otherwise
nouveau undervolts.
Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are now specified directly in the MC subdev.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Add basic GM20B volt driver that reuses the GK20A logic.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Split the constructor function so we can reuse the same logic in other
chips.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The CVB calculation and voltage setting functions can be reused for the
future chips. So move the declaration to gk20a.h.
Signed-off-by: NVince Hsu <vinceh@nvidia.com>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NMartin Peres <martin.peres@free.fr>

Most Keplers actually use the GPIO-based voltage management instead of the new
PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles
the case where no GPIOs exist.

All the Maxwells seem to use the PWM method though.

v2:
 - Do not forget to commit the PWM configuration change!
Signed-off-by: NMartin Peres <martin.peres@free.fr>

This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The copyright header in nvkm/engine/device/platform.c has been replaced
with the NVIDIA one from drm/nouveau_platform.c, as most of the actual
code is now theirs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is purely preparation for upcoming commits, there should be no
code changes here.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver.  This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The symlinks were annoying some people, and they're not used anywhere
else in the kernel tree.  The include directory structure has been
changed so that symlinks aren't needed anymore.

NVKM has been moved from core/ to nvkm/ to make it more obvious as to
what the directory is for, and as some minor prep for when NVKM gets
split out into its own module (virt) at a later date.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>