similar to: [PATCH AUTOSEL 4.19 172/252] drm/nouveau/fault/gv100-: fix memory leak on module unload

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 633cc9beeb6f9b5fa2f17a2a9d0e2790cb6c3de7 ] Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.c

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 633cc9beeb6f9b5fa2f17a2a9d0e2790cb6c3de7 ] Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/base.c

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The engine field in the FIFO fault information registers is actually 9 > bits wide. Looks like this is true for fault buffer parsing too. > > Signed-off-by: Thierry Reding <treding at nvidia.com> > --- >

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The fault information register contains data about the aperture that > caused the failure. This can be useful in debugging aperture related > programming bugs. Should this be parsed for fault buffer entries too? > >

From: Thierry Reding <treding at nvidia.com> The engine field in the FIFO fault information registers is actually 9 bits wide. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c

From: Thierry Reding <treding at nvidia.com> The fault information register contains data about the aperture that caused the failure. This can be useful in debugging aperture related programming bugs. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 3 ++-

Do not export gv100_fifo_runlist as it isn't not used to remove the following morning: drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol 'gv100_fifo_runlist' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c | 2 +- 1 file changed, 1 insertion(+), 1

While certain modeset operations on gv100+ need us to temporarily disable the LUT, we make the mistake of sometimes neglecting to reprogram the LUT after such modesets. In particular, moving a head from one encoder to another seems to trigger this quite often. GV100+ is very picky about having a LUT in most scenarios, so this causes the display engine to hang with the following error code: disp:

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: facaed62b4cb ("drm/nouveau/kms/gv100: initial support"). The bot has tested the following trees: v5.5.3, v5.4.19, v4.19.103. v5.5.3: Build OK! v5.4.19: Build OK! v4.19.103: Failed to apply! Possible dependencies: 88b703527ba7 ("drm/nouveau/kms/gf119-:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ] Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances. Fixes suspend/resume on (at least) Quadro RTX4000 (TU104). Reported-by: Lyude

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ] Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances. Fixes suspend/resume on (at least) Quadro RTX4000 (TU104). Reported-by: Lyude

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ] Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances. Fixes suspend/resume on (at least) Quadro RTX4000 (TU104). Reported-by: Lyude

The gv100_disp_wimm is not declared, so make it static to avoid the following warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c:39:1: warning: symbol 'gv100_disp_wimm' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.c | 2 +- 1 file changed, 1 insertion(+), 1

The gv100_disp_core_mthd_{base,sor} are not used outside of the file they are defined in, so make them static to avoid the following sparse warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c:43:1: warning: symbol

On Mon, May 11, 2020 at 6:42 PM Lyude Paul <lyude at redhat.com> wrote: > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c > index 43bcbb6d73c4..6dae00da5d7e 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c > @@ -1065,7 +1065,7 @@

We advertise being able to set interlaced modes, so let's actually make sure to do that. Otherwise, we'll end up hanging the display engine due to trying to set a mode with timings adjusted for interlacing without telling the hardware it's actually an interlaced mode. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org ---

We advertise being able to set interlaced modes, so let's actually make sure to do that. Otherwise, we'll end up hanging the display engine due to trying to set a mode with timings adjusted for interlacing without telling the hardware it's actually an interlaced mode. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +++--

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, 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