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

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

We also change the error strings to match NVIDIA's naming.
Signed-off-by: NBen 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: NBen Skeggs <bskeggs@redhat.com>

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

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

Required for ACR.
Signed-off-by: NBen 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: NBen Skeggs <bskeggs@redhat.com>

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

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

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

So we're able to connect fault/interrupt handling to the GSP subdev.
Signed-off-by: NBen 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: NBen Skeggs <bskeggs@redhat.com>

Exact meaning of the acronym is unknown, but we need this for Turing ACR.
Signed-off-by: NBen 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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBen 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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBen 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: NColin Ian King <colin.king@canonical.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>

GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Would usually do this split-out, verifying each component indivitually, but
this has been squashed together to be more palatable for merging in 5.0-rc.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling.  Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.

Fixes: 800efb4c ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447Reported-by: NThomas Blume <thomas.blume@suse.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GV100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP102.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with TU104.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GP102.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Appears to be compatible with GV100.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>