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>

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

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

This sequence is incorrect for GP102/GP104 boards.  This is now being
handled correctly by the PMU subdev during preinit();
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It appears to be safe to access PTIMER on an unposted board with newer
chipsets.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GP102/GP104 require a harder reset of PMU prior to DEVINIT, or the IFR
image will hang.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just enough to hookup preinit reset(), which DEVINIT will depend on later.
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>

gm20b's FB has the same capabilities as gm200, minus the ability to
allocate RAM. Create a device that reflects this instead of re-using the
gk20a device which may be incorrect.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-By: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gk20a's FB is not special compared to other Kepler chips, besides the
fact it does not have VRAM. Use the regular gf100 hooks instead of the
incomplete versions we rewrote.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-By: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The gf100 constructor should be called, otherwise we will allocate a
smaller object than expected. This was without effect so far because
gk20a did not allocate a page, but with gf100's page allocation moved
to the oneinit() hook this problem has become apparent.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The reset hook of pmu_func is never called, and gt215 was the only chip
to implement. Remove this dead code.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.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>

This fixes (works around?) link training failures seen on (at least)
the Lenovo P50's internal panel.

It's also an important fix on the same system for MST support on the
dock.  Sometimes, right after receiving an IRQ from the sink, there's
an error bit (SINKSTAT_ERR) set in the DPAUX registers before we've
even attempted a transaction.

v2. Fixed regression on passive DP->DVI adapters.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .oneinit hook, which executes after the
DMA mask has been set.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The 100c10 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .oneinit hook, which executes after the
DMA mask has been set.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The BAR2 page table was being made WAY too big - oops.
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>

This enables memory reclocking on Maxwell. Sadly without a PMU firmware it
is useless for gm20x gpus.
Signed-off-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>

Depending on the value a different formular is used to calculated the
voltage for this entry.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
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>

0: base clock from the vbios is max clock (default)
1: boost only to boost clock from the vbios
2: boost to max clock available

v2: Moved into nvkm_cstate_valid.
v4: Check the existence of the clocks before limiting.
v5: Default to boost level 0.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This table contains three important clocks:

base  clock: This is the non boosted max clock.
tdp   clock: The clock at wich the vbios guarentees the TDP won't ever be
             exceeded at max load (seems to be always the same as the base
             clock, but behaves differently).
boost clock: The avg clock the gpu will stay boosted to. It doesn't seem to
             affect the behaviour of the nvidia driver at all though.

v2: Make clear that base/boost/tdp fields are ids.
v5: Rename Base clock to vpstate.
    Make vbios pointers 32bit.
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>

Now the cstatei parameter can be used of the nvkm_cstate_prog function to
select a specific cstate.

v5: Make a constant for the magic value.
    Use list_last_entry.
    Add nvkm_cstate_get here instead of in the next commit.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
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>