summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nvkm/engine
AgeCommit message (Collapse)AuthorFilesLines
2018-12-11drm/nouveau/core: recognise TU104Ben Skeggs2-0/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gv100: return work submission token in channel ctor argsBen Skeggs3-11/+25
The token will also contain runlist ID on Turing, so instead expose it as an opaque value from NVKM so the client doesn't need to care. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gv100: allocate method bufferBen Skeggs3-3/+22
The GPU saves off some stuff to the address specified in this part of RAMFC when the channel faults, so we should probably point it at a valid address. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gm200-: read pbdma count more directlyBen Skeggs8-8/+36
The trick we used (and still use for older GPUs) doesn't work on Turing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gk104-: virtualise pbdma enable functionBen Skeggs3-1/+12
Turing will require different code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gk104-: group pbdma functions togetherBen Skeggs11-13/+28
We're about to be adding more of them. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gk104-: separate runlist building from committing to hwBen Skeggs6-25/+41
We will need to bash different registers on Turing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gk104-: support enabling privileged ce functionsBen Skeggs2-8/+15
Will be used by SVM code to allow direct (without going through MMU) memcpy using the GPU copy engines. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gk104-: return channel instance in ctor argsBen Skeggs2-2/+6
Will be used to match fault buffer entries with a channel. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/fifo/gf100-: call into BAR to reset BARs after MMU faultBen Skeggs2-4/+4
This is needed for Turing, but we're supposed to wait for completion after re-writing the value on older GPUs anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/disp/gv100: fix name of window channels in debug outputBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/core: support multiple nvdec instancesBen Skeggs3-10/+12
Turing GPUs can have more than one. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: keep track of high-speed state, program into clockIlia Mirkin3-4/+14
The register programmed by the clock method needs to contain a different setting for the link speed as well as special divider settings. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp/gm200-: add scdc parameter setterIlia Mirkin5-0/+39
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: add a way to configure scrambling/tmds for hdmi 2.0Ilia Mirkin2-2/+9
High pixel clocks are required to use a 40 TMDS divider instead of 10, and even low ones may optionally use scrambling depending on device support. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-09-07drm/nouveau/disp/gm200-: enforce identity-mapped SOR assignment for LVDS/eDP ↵Ben Skeggs4-3/+28
panels Fixes eDP backlight issues on more recent laptops. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-09-07drm/nouveau/disp: fix DP disable raceBen Skeggs4-9/+19
If a HPD pulse signalling the need to retrain the link occurs between the KMS driver releasing the output and the supervisor interrupt that finishes the teardown, it was possible get a NULL-ptr deref. Avoid this by marking the link as inactive earlier. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-09-07drm/nouveau/disp: move eDP panel power handlingBen Skeggs1-3/+34
We need to do this earlier to prevent aux channel timeouts in resume paths on certain systems. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-09-07drm/nouveau/disp: remove unused struct memberBen Skeggs2-2/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-16drm/nouveau: tegra: Detach from ARM DMA/IOMMU mappingThierry Reding1-0/+13
Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults. As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-16drm/nouveau/disp/nv50-gp10x: fix coverity warningBen Skeggs2-3/+3
Change values to u32, there's no need for them to be 64-bit. Reported-by: Colin Ian King <colin.king@canonical.com> Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-16drm/nouveau/gr/gv100: handle multiple SM-per-TPC for shader exceptionsBen Skeggs1-7/+14
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-06-12treewide: kzalloc() -> kcalloc()Kees Cook1-1/+1
The kzalloc() function has a 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a * b, gfp) as well as handling cases of: kzalloc(a * b * c, gfp) with: kzalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kzalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kzalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kzalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kzalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kzalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(char) * COUNT + COUNT , ...) | kzalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kzalloc + kcalloc ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kzalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kzalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kzalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kzalloc(C1 * C2 * C3, ...) | kzalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kzalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kzalloc(sizeof(THING) * C2, ...) | kzalloc(sizeof(TYPE) * C2, ...) | kzalloc(C1 * C2 * C3, ...) | kzalloc(C1 * C2, ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - (E1) * E2 + E1, E2 , ...) | - kzalloc + kcalloc ( - (E1) * (E2) + E1, E2 , ...) | - kzalloc + kcalloc ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-06Merge tag 'overflow-v4.18-rc1' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull overflow updates from Kees Cook: "This adds the new overflow checking helpers and adds them to the 2-factor argument allocators. And this adds the saturating size helpers and does a treewide replacement for the struct_size() usage. Additionally this adds the overflow testing modules to make sure everything works. I'm still working on the treewide replacements for allocators with "simple" multiplied arguments: *alloc(a * b, ...) -> *alloc_array(a, b, ...) and *zalloc(a * b, ...) -> *calloc(a, b, ...) as well as the more complex cases, but that's separable from this portion of the series. I expect to have the rest sent before -rc1 closes; there are a lot of messy cases to clean up. Summary: - Introduce arithmetic overflow test helper functions (Rasmus) - Use overflow helpers in 2-factor allocators (Kees, Rasmus) - Introduce overflow test module (Rasmus, Kees) - Introduce saturating size helper functions (Matthew, Kees) - Treewide use of struct_size() for allocators (Kees)" * tag 'overflow-v4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: Use struct_size() for devm_kmalloc() and friends treewide: Use struct_size() for vmalloc()-family treewide: Use struct_size() for kmalloc()-family device: Use overflow helpers for devm_kmalloc() mm: Use overflow helpers in kvmalloc() mm: Use overflow helpers in kmalloc_array*() test_overflow: Add memory allocation overflow tests overflow.h: Add allocation size calculation helpers test_overflow: Report test failures test_overflow: macrofy some more, do more tests for free lib: add runtime test of check_*_overflow functions compiler.h: enable builtin overflow checkers and add fallback code
2018-06-06treewide: Use struct_size() for kmalloc()-familyKees Cook1-2/+2
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This patch makes the changes for kmalloc()-family (and kvmalloc()-family) uses. It was done via automatic conversion with manual review for the "CHECKME" non-standard cases noted below, using the following Coccinelle script: // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len * // sizeof *pkey_cache->table, GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // Same pattern, but can't trivially locate the trailing element name, // or variable name. @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; expression SOMETHING, COUNT, ELEMENT; @@ - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP) + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-18drm/nouveau/gr/gf100-: insert some WFIs during gr initBen Skeggs2-0/+6
Inserted wait-for-gr-idle in the places it seems that RM does it, seems to prevent some random mmio timeouts on Quadro GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/gr/gv100: initial supportBen Skeggs8-3/+369
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/ce/gv100: initial supportBen Skeggs3-0/+50
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/fifo/gv100: initial supportBen Skeggs10-10/+635
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/disp/gv100: initial supportBen Skeggs21-9/+1511
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/dma/gv100: initial supportBen Skeggs5-0/+158
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/therm/gv100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/pmu/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/fault/gv100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/bar/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GM107. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/mmu/gv100: initial supportBen Skeggs1-0/+1
VEID support hacked in here, as it's the most convenient place for now. Will be refined once it's better understood. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/ltc/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GP102. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/fb/gv100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/imem/gv100: initial supportBen Skeggs1-0/+1
Can't imagine this will be any different. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/tmr/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GK20A. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/bus/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GF100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/mc/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GP100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/fuse/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GM107. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/i2c/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GM200. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/gpio/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GK104. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/ibus/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GM200. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/top/gv100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/devinit/gv100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/bios/gv100: initial supportBen Skeggs1-0/+1
No real surprises here so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/pci/gv100: initial supportBen Skeggs1-0/+1
Appears to be compatible with GP100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>