- 14 Mar, 2016 40 commits
-
-
Alexandre Courbot authored
Split the constructor function so we can reuse the same logic in other chips. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Vince Hsu authored
The CVB calculation and voltage setting functions can be reused for the future chips. So move the declaration to gk20a.h. Signed-off-by:
Vince Hsu <vinceh@nvidia.com> Signed-off-by:
-
Ben Skeggs authored
The HW accepts KeplerDmaCopyA and MaxwellDmaCopyA classes. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This class supports a WFI method (0x0078) that's not present on the KeplerChannelGpfifoA class. The binary driver exposes both classes on these GPUs for some reason, though there doesn't appear to be any difference in the setup that's done for each (ie. even if you allocate GpfifoA, the WFI method will still work). We shall just expose GpfifoB, as I don't see a good reason to report the presence of both. Signed-off-by: -
Ben Skeggs authored
Prevents the same interrupt from re-triggering forever. 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
Unlike subdevs, these aren't initialised in a defined order. 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
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Roy Spliet authored
It's supposed to always be 0, but at least nv_iowr() temporarily violates this. Since the ih touches $r0, it should be stored. Signed-off-by:
Roy Spliet <rs855@cam.ac.uk> Signed-off-by:
-
Karol Herbst authored
Signed-off-by:
Karol Herbst <nouveau@karolherbst.de> Reviewed-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Karol Herbst authored
the macro deals with target specific differences and so we should always use this Signed-off-by:
-
Karol Herbst authored
on gk208+ we can simply mov 32bits, so we should have a single mov there v2: use or operator instead of add Signed-off-by:
-
Karol Herbst authored
Signed-off-by:
-
Ilia Mirkin authored
Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a fairly sizeable chunk of memory to be allocated, which may not be available with kzalloc. Since this is done fairly rarely (once per channel), use vzalloc instead. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Alexandre Courbot authored
A channel may still be processed by the PBDMA even after removal, unless it is properly kicked. Some chips are more sensible to this than others, with GM20B triggering the issue very easily (the PBDMA will try to fetch methods from the previously-removed channel after a new one is added). Make sure this cannot happen by kicking the channel right after it is disabled, and before the new runlist is submitted. Signed-off-by:
-
Alexandre Courbot authored
When using the DMA-API for instmem, we may obtain a write-combined mapping. For such cases, add a write barrier in gk20a_instobj_release_dma() to make sure that all writes have reached memory at this time. Signed-off-by:
-
Alexandre Courbot authored
Without this buffer inconsistencies may appear between the CPU and GPU when using a PCI GPU on an ARM64 board. Signed-off-by:
-
Alexandre Courbot authored
Registration of the hwmon device will fail on non-PCI systems since dev->pdev is NULL in that case. Use the more generic drm_device::dev member that points to the same and is always set no matter the platform. Signed-off-by:
-
Alexandre Courbot authored
On non-PCI devices, nobody should really care if the device does not provide HDMI... Signed-off-by:
-
Alexandre Courbot authored
The DMA API has different semantics on different architectures. Currently on arm64, it can only provide memory from a small pool which dries up quickly if we attempt to allocate big buffers from it. Do not consider that option when running on non-x86, since regular TTM buffers are the (current) best-fit for ARM platforms. Signed-off-by:
-
