- 19 Feb, 2019 40 commits
-
-
Ben Skeggs authored
Host methods exist to do at least some of what we need, but we are not currently pushing replay/cancels through a channel like UVM does as it's not clear whether it's necessary in our case (UVM also updates PTEs with the GPU). UVM also pushes a software method for fault cancels on Pascal, seemingly because the host methods don't appear to be sufficient. If/when we want to push the replay/cancel on the GPU, we can re-purpose the cancellation code here to implement that swmthd. Keep it simple for now, until we figure out exactly what we need here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This provides a somewhat more direct method of manipulating the GPU page tables, which will be required to support SVM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
MMU will need access to this info. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Colin Ian King authored
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>
-
Ben Skeggs authored
It appears that Pascal and newer need something different. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Will want to reuse this for fault replay/cancellation swmthds. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Future changes will want to add some additional things here, keep them grouped together. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This is already done during golden context creation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
It has no relevance to the atomic path used by newer GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
It has no relevance to the atomic path used by newer GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Swapped order of functions in dispnv04 to allow this, but no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
We also change the error strings to match NVIDIA's naming. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Required for ACR. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Required to run VPR scrubber binary as part of secboot. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Turing has its NVDEC instances in an alternate location. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We need this for Turing ACR, but it's present from Volta onwards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
So we're able to connect fault/interrupt handling to the GSP subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Exact meaning of the acronym is unknown, but we need this for Turing ACR. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Colin Ian King authored
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>
-
Gustavo A. R. Silva authored
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>
-
Lyude Paul authored
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>
-
Colin Ian King authored
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>
-
Colin Ian King authored
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>
-