This will be used to support a privileged client providing PTEs directly,
without a memory object to use as a reference.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

NVKM is currently responsible for managing the allocation of a client's
GPU address-space, but there's various use-cases (ie. HMM address-space
mirroring) where giving a client more direct control is desirable.

This commit allows for a VMM to be created where the area allocated for
NVKM is limited to a client-specified window, the remainder of address-
space is controlled directly by the client.

Leaving a window is necessary to support various internal requirements,
but also to support existing allocation interfaces as not all of the HW
is capable of working with a HMM allocation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

MMU will need access to this info.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

MMU will need access to these.

v2. Apply fix from Rhys Kidd to send correct FECS method for STOP_CTXSW.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

There are a few statements that are indented incorrectly. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It appears that Pascal and newer need something different.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Will want to reuse this for fault replay/cancellation swmthds.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Future changes will want to add some additional things here, keep them
grouped together.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This is already done during golden context creation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Makes the code somewhat less magic.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

There's no need to avoid using copy engines if gr init fails for some
reason (usually missing FW, or incomplete bring-up).

It's not terribly useful for an end-user, but it'll slightly speed up
suspend/resume when saving fb contents, and allow for host/ce code to
be validated.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It has no relevance to the atomic path used by newer GPUs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It has no relevance to the atomic path used by newer GPUs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Swapped order of functions in dispnv04 to allow this, but no code changes.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Some of the pre-NV50 depends on SW methods to implement synchronisation
for page flips, and we want to move this setup out of common code, thus
we require the channel to have been allocation before display init.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We also change the error strings to match NVIDIA's naming.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

As I currently understand it, this is related to features we have no
support for as of yet.

In theory, this change should be a noop, just without the warning.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

Required for ACR.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Turing has its SEC2 instance in an alternate location, and this avoids
needing to duplicate the code here for it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Required to run VPR scrubber binary as part of secboot.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Turing has its NVDEC instances in an alternate location.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

We need this for Turing ACR, but it's present from Volta onwards.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

So we're able to connect fault/interrupt handling to the GSP subdev.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Will be using this in upcoming changes to avoid the need for entirely
new subdevs to deal with Turing register moves.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Exact meaning of the acronym is unknown, but we need this for Turing ACR.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
re-assigning the getparam->value to an undesired value. Fix this by adding
in the missing break.

Detected by CoverityScan, CID#1460507 ("Missing break in switch")

Fixes: 359088d5 ("drm/nouveau: remove trivial cases of nvxx_device() usage")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

This patch fixes the following warning:

drivers/gpu/drm/nouveau/nouveau_bo.c:1434:53: warning: this statement may fall through [-Wimplicit-fallthrough=]

Warning level 3 was used: -Wimplicit-fallthrough=3

This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
updated.

Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable")
Fixes: ebb58dc2 ("drm/nouveau/pmu: rename from pwr (no binary change)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator.  I believe the missing
parentheses around the expression before appying the ! operator will
result in the desired result.

[ Note, not tested ]

Detected by CoveritScan, CID#1324005 ("Operands don't affect result")

Fixes: c25bf7b6 ("drm/nouveau/bios/ramcfg: Separate out RON pull value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Don't populate the array vsoff on the stack but instead make it
static. Makes the object code smaller by 67 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
   5753	    112	      0	   5865	   16e9	.../nouveau/nvkm/subdev/bios/dp.o

After:
   text	   data	    bss	    dec	    hex	filename
   5622	    176	      0	   5798	   16a6	.../nouveau/nvkm/subdev/bios/dp.o

(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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