similar to: [PATCH 1/2] fifo/gf100: take runlist target into account

Presumably we can never actually hit this return, but static checkers complain that we should unlock before we return. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index 3a24788c3185..a7e55c422501 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

gk20a's FB is not special compared to other Kepler chips, besides the fact it does not have VRAM. Use the regular gf100 hooks instead of the incomplete versions we rewrote. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/fb/gk20a.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git

5.2.0-rc4-next-20190613 dmesg nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery nouveau 0000:01:00.0: fifo: channel 5: killed nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery

Address of the ENG_RUNLIST register should be 0x002284 + (engine * 8), not 0x002284 + (engine * 4). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Stumbled upon this one and I'm quite certain the offset was not correct. This is inconsequential for GK20A which only features one runlist, but other GPUs might run into troubles because of this. Not tested, just reported for

On Tue, 17 Sep 2019 at 00:36, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > Hi Ben, > > I messed up the ordering of patches in my tree a bit, so these two fixes > got separated from the others. I don't consider these particularily > urgent because the crash that the first one fixes only happens on

On (06/14/19 11:50), Sergey Senozhatsky wrote: > dmesg > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery > nouveau 0000:01:00.0: fifo: channel 5: killed > nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery >

After observing random crashes on Tegra devices when patch "fb/gf100: defer DMA mapping of scratch page to oneinit() hook" was applied, I noticed that moving the 100c10 page allocation to the oneinit() hook resulted in that page being now allocated for Tegra as well, and accesses be made to members of gf100_fb which were not accessible because gk20a_fb_new() called nvkm_fb_new_()

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

From: Thierry Reding <treding at nvidia.com> Hi Ben, I messed up the ordering of patches in my tree a bit, so these two fixes got separated from the others. I don't consider these particularily urgent because the crash that the first one fixes only happens on gp10b which we don't enable by default yet and the second patch fixes a crash that only happens on module unload (or driver

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

This patchset centralizes the firmware-loading procedure to one set of functions instead of having each engine load its firmware as it pleases. This helps ensure that all firmware comes from the same place, namely nvidia/<chip>/. This changes where the firmware is fetched from for falcon/xtensa/bios, but these locations never seemed to have been official anyway. Also for most (all?) chips

The bulk SPDX addition made all these files into GPL-2.0 licensed files. However the remainder of the project is MIT-licensed, these files (primarily header files) were simply missing the boiler plate and got caught up in the global update. Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license) Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>