- 18 May, 2018 40 commits
-
-
Ben Skeggs authored
There should be no code changes here, just shuffling stuff around. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Removes duplicated code from OR-specific functions. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We don't support address-only transactions there. Signed-off-by: -
Ben Skeggs authored
The code is about to be split up, and this matches dispnv04. Signed-off-by: -
Ben Skeggs authored
This function is useful outside of DRM code. Signed-off-by: -
Ben Skeggs authored
Hasn't been required for a long time. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Fences attached to deferred client work items now originate from channels belonging to the client, meaning we can be certain they've been signalled before we destroy a client. This closes a race that could happen if the dma_fence_wait_timeout() call didn't succeed. When the fence was later signalled, a use-after-free was possible. Signed-off-by: -
Ben Skeggs authored
As VMAs are per-client, unlike buffers, this allows us to avoid referencing foreign fences (those that belong to another client/driver) from the client deferred work handler, and prevent some not-fun race conditions that can be triggered when a fence stalls. Signed-off-by: -
Ben Skeggs authored
An upcoming patch will use these to fix issues related to the deferred unmapping of GEM objects. Signed-off-by: -
Ben Skeggs authored
We previously only did this for push buffers, but an upcoming patch will need to attach fences to all VMAs to resolve another issue. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
These were missed the first time around due to the driver version I traced using the older registers still. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
There are differences on GM200 and newer too, but we can't fix them there as they come from firmware packages. A request has been made to NVIDIA to release updated firmware. Signed-off-by: -
Ben Skeggs authored
Makes it easier to diff against RM traces. Signed-off-by: -
Ben Skeggs authored
There's a number of places that require this data, so let's separate out the calculations to ensure they remain consistent. This is incorrect for GM200 and newer, but will produce the same results as we did before. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
There's also a couple of hardcoded tables for a couple of very specific configurations that NVGPU's algorithm didn't work for. Signed-off-by: -
Ben Skeggs authored
Required to support Volta. Signed-off-by: -
Ben Skeggs authored
RM and NVGPU both have a variant of this, we probably should too. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We weren't placing higher TPC IDs in the right place on some configurations. Signed-off-by: -
Ben Skeggs authored
Removed from GK110[B]/GK208 as RM traces show it not being touched. Signed-off-by:
-
