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>

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>

Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Tested-by: NAidan Epstein <aidan@jmad.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

GFxxx/GM1xx support the selection of 64/128KiB big pages globally.

GM2xx supports the same, as well as another mode where the page size
can be selected per-instance.

We default to 128KiB pages (With per-instance for GM200, but the current
code selects 128KiB there already) as the MMU code isn't currently able
to handle otherwise.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Later chipsets require setting this up both in FB and GR, so let's just
move the allocation to FB.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

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

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch uses an approach closer to the nvidia driver to configure
both PLLs for high gddr5 memory clocks (usually above 2400MHz)

Previously nouveau used the one PLL as it was used for the lower clocks
and just adjusted the second PLL to get as close as possible to the
requested clock.  This means for my card, that I got a 4050 MHz clock
although 4008 MHz was requested.

Now the driver iterates over a list of PLL configuration also used by
the nvidia driver and then adjust the second PLL to get near the
requested clock.  Also it hold to some restriction I found while
analyzing the PLL configurations

This won't fix all gddr5 high clock issues itself, but it should be
fine on hybrid gpu systems as found on many laptops these days.  Also
switching while normal desktop usage should be a lot more stable than
before.

v2: move the pll code into ramgk104
Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Avoids waiting for VBLANKS that never arrive on headless or otherwise
unconventional set-ups. Strategy taken from MEMX.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

10053c is not even read on some cards, and I have no idea exactly what the
criteria are. Likely NVIDIA pre-scans the VBIOS and in their driver disables
all features that are never used. The practical effect should be the same
as this implementation though.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Like Pierre's G94. We might want to structure Kepler similarly in a follow-up.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Does not seem to be necessary for NVA0, hence untested by me.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Seems to be mostly equal to DDR3 on < GT218, should improve stability for
DDR2 reclocks.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In preparation of changing FBVDDQ, as observed on at least one GDDR3 card.
While at it, adhere to func.log[1] properly for consistency.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
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>

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>

Pretty much every subdev/engine is going to need access to nvkm_device
shortly to touch registers and/or output messages.

The odd placement of the includes is necessary to work around some
inter-dependencies that currently exist.  This will be fixed later.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>