Re: MODULE_DESCRIPTION() patches with no maintainer action
On Sun, Jul 14, 2024 at 02:46:19PM -0700, Jeff Johnson wrote: > Andrew & Greg, > > I hate to bother you with such mundane patches, but the following have been > posted for a while without any maintainer or reviewer comment or action, and > they have not yet landed in linux-next. > > What is the path forward to have these MODULE_DESCRIPTION() warnings fixed? > > arch/arm/probes/kprobes/ > https://lore.kernel.org/all/20240622-md-arm-arch-arm-probes-kprobes-v1-1-0832bd6e4...@quicinc.com/ > > arch/x86/mm/ > https://lore.kernel.org/all/20240515-testmmiotrace-md-v1-1-10919a8b2...@quicinc.com/ > > drivers/spmi/ > https://lore.kernel.org/all/20240609-md-drivers-spmi-v1-1-f1d5b24e7...@quicinc.com/ > > (note that beyond these 3 patches I still have an additional 13 patches which > need to land in order to fix these warnings tree-wide, but those 13 patches > have had recent maintainer or reviewer action so I'm not seeking your help at > this time). After -rc1 is out, resend them all as a series and cc: the right people and either me or Andrew can pick them up then and get them merged in before -final is released. thanks, greg k-h
[Nouveau] [PATCH 5.4 04/39] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -121,6 +121,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -916,7 +916,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -852,4 +861,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -101,4 +101,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -566,4 +566,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -991,4 +991,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 5.15 08/89] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -123,6 +123,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -916,7 +916,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -852,4 +861,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -101,4 +101,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -566,4 +566,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -991,4 +991,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 5.10 12/68] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -123,6 +123,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -916,7 +916,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -852,4 +861,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -101,4 +101,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -566,4 +566,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -991,4 +991,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 6.1 025/149] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -123,6 +123,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -916,7 +916,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -852,4 +861,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -101,4 +101,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -566,4 +566,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -991,4 +991,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 6.4 039/206] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -117,6 +117,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -906,7 +906,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -854,4 +863,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -103,4 +103,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -568,4 +568,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -988,4 +988,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 4.19 05/33] drm/nouveau/gr: enable memory loads on helper invocation on all channels
From: Karol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream.
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org # 4.19+
Signed-off-by: Karol Herbst
Reviewed-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c |4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c |1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c |1 +
6 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -121,6 +121,7 @@ void gk104_grctx_generate_r418800(struct
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -916,7 +916,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -852,4 +861,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -101,4 +101,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -566,4 +566,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -991,4 +991,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
[Nouveau] [PATCH 6.3 004/364] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
From: Kees Cook
[ Upstream commit 25feda6fbd0cfefcb69308fb20d4d4815a107c5e ]
More arrays (and arguments) for dcpd were set to 16, when it looks like
DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen
with GCC 13:
../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp':
../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned
char[16][0]' is partly outside array bounds of 'u8[15]' {aka 'unsigned
char[15]'} [-Warray-bounds=]
57 | #define __underlying_memcpy __builtin_memcpy
| ^
...
../drivers/gpu/drm/nouveau/nvif/outp.c:140:9: note: in expansion of macro
'memcpy'
140 | memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
| ^~
../drivers/gpu/drm/nouveau/nvif/outp.c:130:49: note: object 'dpcd' of size [0,
15]
130 | nvif_outp_acquire_dp(struct nvif_outp *outp, u8
dpcd[DP_RECEIVER_CAP_SIZE],
|
~~~^~
Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into acquire")
Cc: Ben Skeggs
Cc: Lyude Paul
Cc: Karol Herbst
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: "Gustavo A. R. Silva"
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Kees Cook
Reviewed-by: Gustavo A. R. Silva
Reviewed-by: Karol Herbst
Signed-off-by: Karol Herbst
Link:
https://patchwork.freedesktop.org/patch/msgid/20230204184307.never.825-k...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/include/nvif/if0012.h| 4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h | 3 ++-
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if0012.h
b/drivers/gpu/drm/nouveau/include/nvif/if0012.h
index eb99d84eb8443..16d4ad5023a3e 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if0012.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if0012.h
@@ -2,6 +2,8 @@
#ifndef __NVIF_IF0012_H__
#define __NVIF_IF0012_H__
+#include
+
union nvif_outp_args {
struct nvif_outp_v0 {
__u8 version;
@@ -63,7 +65,7 @@ union nvif_outp_acquire_args {
__u8 hda;
__u8 mst;
__u8 pad04[4];
- __u8 dpcd[16];
+ __u8 dpcd[DP_RECEIVER_CAP_SIZE];
} dp;
};
} v0;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
index b7631c1ab2420..4e7f873f66e27 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
@@ -3,6 +3,7 @@
#define __NVKM_DISP_OUTP_H__
#include "priv.h"
+#include
#include
#include
#include
@@ -42,7 +43,7 @@ struct nvkm_outp {
bool aux_pwr_pu;
u8 lttpr[6];
u8 lttprs;
- u8 dpcd[16];
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
struct {
int dpcd; /* -1, or index into
SUPPORTED_LINK_RATES table */
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
index 4f0ca709c85a4..fc283a4a1522a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
@@ -146,7 +146,7 @@ nvkm_uoutp_mthd_release(struct nvkm_outp *outp, void *argv,
u32 argc)
}
static int
-nvkm_uoutp_mthd_acquire_dp(struct nvkm_outp *outp, u8 dpcd[16],
+nvkm_uoutp_mthd_acquire_dp(struct nvkm_outp *outp, u8
dpcd[DP_RECEIVER_CAP_SIZE],
u8 link_nr, u8 link_bw, bool hda, bool mst)
{
int ret;
--
2.39.2
[Nouveau] [PATCH 6.2 045/141] drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
From: Jiri Slaby (SUSE)
[ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ]
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel
interlocks")
Cc: Martin Liska
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE)
Signed-off-by: Karol Herbst
Link:
https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 591c852f326b9..76a6ae5d56526 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -35,8 +35,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.39.2
[Nouveau] [PATCH 6.1 058/143] drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
From: Jiri Slaby (SUSE)
[ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ]
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel
interlocks")
Cc: Martin Liska
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE)
Signed-off-by: Karol Herbst
Link:
https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 591c852f326b9..76a6ae5d56526 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -35,8 +35,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.39.2
[Nouveau] [PATCH 5.15 044/145] drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
From: Jiri Slaby (SUSE)
[ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ]
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel
interlocks")
Cc: Martin Liska
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE)
Signed-off-by: Karol Herbst
Link:
https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 980f8ea96d54a..6c64864da4550 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -38,8 +38,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.39.2
[Nouveau] [PATCH 5.10 029/104] drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
From: Jiri Slaby (SUSE)
[ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ]
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel
interlocks")
Cc: Martin Liska
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE)
Signed-off-by: Karol Herbst
Link:
https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 8bed195ae098a..77bf124319fbd 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -38,8 +38,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.39.2
[Nouveau] [PATCH 6.2 0228/1001] drm/nouveau/disp: Fix nvif_outp_acquire_dp() argument size
From: Kees Cook
[ Upstream commit 4076ea2419cf15bc1e1580f8b24ddf675fbdb02c ]
Both Coverity and GCC with -Wstringop-overflow noticed that
nvif_outp_acquire_dp() accidentally defined its second argument with 1
additional element:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp'
accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=]
1813 | nvif_outp_acquire_dp(_encoder->outp,
nv_encoder->dp.dpcd, 0, 0, false, false);
|
^~~
drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: note: referencing argument 2
of type 'u8[16]' {aka 'unsigned char[16]'}
drivers/gpu/drm/nouveau/include/nvif/outp.h:24:5: note: in a call to function
'nvif_outp_acquire_dp'
24 | int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
| ^~~~
Avoid these warnings by defining the argument size using the matching
define (DP_RECEIVER_CAP_SIZE, 15) instead of having it be a literal
(and incorrect) value (16).
Reported-by: coverity-bot
Addresses-Coverity-ID: 1527269 ("Memory - corruptions")
Addresses-Coverity-ID: 1527268 ("Memory - corruptions")
Link: https://lore.kernel.org/lkml/202211100848.FFBA2432@keescook/
Link: https://lore.kernel.org/lkml/202211100848.F4C2819BB@keescook/
Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into acquire")
Reviewed-by: Lyude Paul
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: "Gustavo A. R. Silva"
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221127183036.never.139-k...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/include/nvif/outp.h | 3 ++-
drivers/gpu/drm/nouveau/nvif/outp.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/outp.h
b/drivers/gpu/drm/nouveau/include/nvif/outp.h
index 45daadec3c0c7..fa76a7b5e4b37 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/outp.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/outp.h
@@ -3,6 +3,7 @@
#define __NVIF_OUTP_H__
#include
#include
+#include
struct nvif_disp;
struct nvif_outp {
@@ -21,7 +22,7 @@ int nvif_outp_acquire_rgb_crt(struct nvif_outp *);
int nvif_outp_acquire_tmds(struct nvif_outp *, int head,
bool hdmi, u8 max_ac_packet, u8 rekey, u8 scdc, bool
hda);
int nvif_outp_acquire_lvds(struct nvif_outp *, bool dual, bool bpc8);
-int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
+int nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[DP_RECEIVER_CAP_SIZE],
int link_nr, int link_bw, bool hda, bool mst);
void nvif_outp_release(struct nvif_outp *);
int nvif_outp_infoframe(struct nvif_outp *, u8 type, struct
nvif_outp_infoframe_v0 *, u32 size);
diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c
b/drivers/gpu/drm/nouveau/nvif/outp.c
index 7da39f1eae9fb..c24bc5eae3ecf 100644
--- a/drivers/gpu/drm/nouveau/nvif/outp.c
+++ b/drivers/gpu/drm/nouveau/nvif/outp.c
@@ -127,7 +127,7 @@ nvif_outp_acquire(struct nvif_outp *outp, u8 proto, struct
nvif_outp_acquire_v0
}
int
-nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
+nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[DP_RECEIVER_CAP_SIZE],
int link_nr, int link_bw, bool hda, bool mst)
{
struct nvif_outp_acquire_v0 args;
--
2.39.2
[Nouveau] [PATCH 5.17 309/343] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
[Nouveau] [PATCH 5.16 256/285] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
[Nouveau] [PATCH 5.15 245/277] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
[Nouveau] [PATCH 5.10 153/171] drm/nouveau/pmu: Add missing callbacks for Tegra devices
From: Karol Herbst
commit 38d4e5cf5b08798f093374e53c2f4609d5382dd5 upstream.
Fixes a crash booting on those platforms with nouveau.
Fixes: 4cdd2450bf73 ("drm/nouveau/pmu/gm200-: use alternate falcon reset
sequence")
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v5.17+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220322124800.2605463-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c |2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c |1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h |1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -216,6 +216,7 @@ gm20b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gf100_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp102.c
@@ -23,7 +23,7 @@
*/
#include "priv.h"
-static void
+void
gp102_pmu_reset(struct nvkm_pmu *pmu)
{
struct nvkm_device *device = pmu->subdev.device;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gp10b.c
@@ -83,6 +83,7 @@ gp10b_pmu = {
.intr = gt215_pmu_intr,
.recv = gm20b_pmu_recv,
.initmsg = gm20b_pmu_initmsg,
+ .reset = gp102_pmu_reset,
};
#if IS_ENABLED(CONFIG_ARCH_TEGRA_210_SOC)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/priv.h
@@ -41,6 +41,7 @@ int gt215_pmu_send(struct nvkm_pmu *, u3
bool gf100_pmu_enabled(struct nvkm_pmu *);
void gf100_pmu_reset(struct nvkm_pmu *);
+void gp102_pmu_reset(struct nvkm_pmu *pmu);
void gk110_pmu_pgob(struct nvkm_pmu *, bool);
Re: [Nouveau] [PATCH 5.10 32/77] drm/ttm: fix memleak in ttm_transfered_destroy
On Thu, Nov 04, 2021 at 08:39:18AM +0100, Christian König wrote: > Am 03.11.21 um 22:25 schrieb Karol Herbst: > > On Wed, Nov 3, 2021 at 9:47 PM Sven Joachim wrote: > > > On 2021-11-03 21:32 +0100, Karol Herbst wrote: > > > > > > > On Wed, Nov 3, 2021 at 9:29 PM Karol Herbst wrote: > > > > > On Wed, Nov 3, 2021 at 8:52 PM Sven Joachim wrote: > > > > > > On 2021-11-01 10:17 +0100, Greg Kroah-Hartman wrote: > > > > > > > > > > > > > From: Christian König > > > > > > > > > > > > > > commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream. > > > > > > > > > > > > > > We need to cleanup the fences for ghost objects as well. > > > > > > > > > > > > > > Signed-off-by: Christian König > > > > > > > Reported-by: Erhard F. > > > > > > > Tested-by: Erhard F. > > > > > > > Reviewed-by: Huang Rui > > > > > > > Bug: > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D214029data=04%7C01%7Cchristian.koenig%40amd.com%7C9b70f83c53c74b35fee808d99f1091b3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637715715806624439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UIo0hw0OHeLlGL%2Bcj%2Fjt%2FgTwniaJoNmhgDHSFvymhCc%3Dreserved=0 > > > > > > > Bug: > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D214447data=04%7C01%7Cchristian.koenig%40amd.com%7C9b70f83c53c74b35fee808d99f1091b3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637715715806634433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TIAUb6AdYm2Bo0%2BvFZUFPS8yu55orjnfxMLCmUgC%2FDk%3Dreserved=0 > > > > > > > CC: > > > > > > > Link: > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2Fmsgid%2F20211020173211.2247-1-christian.koenig%40amd.comdata=04%7C01%7Cchristian.koenig%40amd.com%7C9b70f83c53c74b35fee808d99f1091b3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637715715806634433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=c9i7AR44MVUyZuXHZkLOCBx2%2BZeetq8alGtbz0Wgqzk%3Dreserved=0 > > > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > --- > > > > > > > drivers/gpu/drm/ttm/ttm_bo_util.c |1 + > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > > > > > > > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > > > > > > > @@ -322,6 +322,7 @@ static void ttm_transfered_destroy(struc > > > > > > >struct ttm_transfer_obj *fbo; > > > > > > > > > > > > > >fbo = container_of(bo, struct ttm_transfer_obj, base); > > > > > > > + dma_resv_fini(>base.base._resv); > > > > > > >ttm_bo_put(fbo->bo); > > > > > > >kfree(fbo); > > > > > > > } > > > > > > Alas, this innocuous looking commit causes one of my systems to > > > > > > lock up > > > > > > as soon as run startx. This happens with the nouveau driver, two > > > > > > other > > > > > > systems with radeon and intel graphics are not affected. Also I > > > > > > only > > > > > > noticed it in 5.10.77. Kernels 5.15 and 5.14.16 are not affected, > > > > > > and I > > > > > > do not use 5.4 anymore. > > > > > > > > > > > > I am not familiar with nouveau's ttm management and what has changed > > > > > > there between 5.10 and 5.14, but maybe one of their developers can > > > > > > shed > > > > > > a light on this. > > > > > > > > > > > > Cheers, > > > > > > Sven > > > > > > > > > > > could be related to 265ec0dd1a0d18f4114f62c0d4a794bb4e729bc1 > > > > maybe not.. but I did remember there being a few tmm related patches > > > > which only hurt nouveau :/ I guess one could do a git bisect to > > > > figure out what change "fixes" it. > > > Maybe, but since the memory leaks reported by Erhard only started to > > > show up in 5.14 (if I read the bugzilla reports correctly), perhaps the > > > patch should simply be reverted on earlier kernels? > > > > > Yeah, I think this is probably the right approach. > > I agree. The problem is this memory leak could potentially happen with 5.10 > as wel, just much much much less likely. > > But my guess is that 5.10 is so buggy that when the leak does NOT happen we > double free and obviously causing a crash. > > So for the sake of stability please don't apply this patch to 5.10. I'm > going to comment on the original bug report as well. Now reverted from 5.10 and 5.4 kernels, thanks, greg k-h
[Nouveau] [PATCH 5.13 204/266] drm/nouveau: Dont set allow_fb_modifiers explicitly
From: Daniel Vetter commit cee93c028288b9af02919f3bd8593ba61d1e610d upstream. Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Reviewed-by: Lyude Paul Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vet...@ffwll.ch Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/nouveau/nouveau_display.c |1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5.12 180/242] drm/nouveau: Dont set allow_fb_modifiers explicitly
From: Daniel Vetter commit cee93c028288b9af02919f3bd8593ba61d1e610d upstream. Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Reviewed-by: Lyude Paul Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vet...@ffwll.ch Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/nouveau/nouveau_display.c |1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -700,7 +700,6 @@ nouveau_display_create(struct drm_device dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5.10 164/215] drm/nouveau: Dont set allow_fb_modifiers explicitly
From: Daniel Vetter commit cee93c028288b9af02919f3bd8593ba61d1e610d upstream. Since commit 890880ddfdbe256083170866e49c87618b706ac7 Author: Paul Kocialkowski Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Note that this fixes an inconsistency: We've set the cap everywhere, but only nv50+ supports modifiers. Hence cc stable, but not further back then the patch from Paul. Reviewed-by: Lyude Paul Cc: sta...@vger.kernel.org # v5.1 + Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Ben Skeggs Cc: nouveau@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vet...@ffwll.ch Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/nouveau/nouveau_display.c |1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -700,7 +700,6 @@ nouveau_display_create(struct drm_device dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; - dev->mode_config.allow_fb_modifiers = true; if (drm->client.device.info.chipset < 0x11) dev->mode_config.async_page_flip = false; ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5.10 28/63] fbcon: Disable accelerated scrolling
From: Daniel Vetter
commit 39aead8373b3c20bb5965c024dfb51a94e526151 upstream.
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
v2:
- Drop a few more unused local variables, somehow I missed the
compiler warnings (Sam)
- Fix typo in comment (Jiri)
- add a todo entry for the cleanup (Thomas)
v3: Remove more unused variables (0day)
Reviewed-by: Tomi Valkeinen
Reviewed-by: Thomas Zimmermann
Reviewed-by: Greg Kroah-Hartman
Acked-by: Sam Ravnborg
Cc: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201029132229.4068359-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
Documentation/gpu/todo.rst | 18 +++
drivers/video/fbdev/core/fbcon.c | 45 ++-
2 files changed, 26 insertions(+), 37 deletions(-)
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -273,6 +273,24 @@ Contact: Daniel Vetter, Noralf Tronnes
Level: Advanced
+Garbage collect fbdev scrolling acceleration
+
+
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
+- lots of code in fbcon.c
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
+ directly instead of the function table (with a switch on p->rotate)
+- fb_copyarea is unused after this, and can be deleted from all drivers
+
+Note that not all acceleration code can be deleted, since clearing and cursor
+support is still accelerated, which might be good candidates for further
+deletion projects.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
idr_init_base()
---
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1033,7 +1033,7 @@ static void fbcon_init(struct vc_data *v
struct vc_data *svc = *default_mode;
struct fbcon_display *t, *p = _display[vc->vc_num];
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
- int cap, ret;
+ int ret;
if (WARN_ON(info_idx == -1))
return;
@@ -1042,7 +1042,6 @@ static void fbcon_init(struct vc_data *v
con2fb_map[vc->vc_num] = info_idx;
info = registered_fb[con2fb_map[vc->vc_num]];
- cap = info->flags;
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1147,11 +1146,13 @@ static void fbcon_init(struct vc_data *v
ops->graphics = 0;
- if ((cap & FBINFO_HWACCEL_COPYAREA) &&
- !(cap & FBINFO_HWACCEL_DISABLED))
- p->scrollmode = SCROLL_MOVE;
- else /* default to something safe */
- p->scrollmode = SCROLL_REDRAW;
+ /*
+* No more hw acceleration for fbcon.
+*
+* FIXME: Garbage collect all the now dead code after sufficient time
+* has passed.
+*/
+ p->scrollmode = SCROLL_REDRAW;
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1961,45 +1962,15 @@ static void updatescrollmode(struct fbco
{
struct fbcon_ops *op
[Nouveau] [PATCH 5.9 129/152] drm/nouveau: fix relocations applying logic and a double-free
From: Matti Hamalainen
[ Upstream commit 2be65641642ef423f82162c3a5f28c754d1637d2 ]
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
a logic-bug which results in the relocations not actually getting
applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
never reached. This causes a regression with graphical corruption,
triggered when relocations need to be done (for example after a
suspend/resume cycle.)
Fix by setting *apply_relocs value only if there were more than 0
relocations.
Additionally, the never reached code had a leftover u_free() call,
which, after fixing the logic, now got called and resulted in a
double-free. Fix by removing one u_free(), moving the other
and adding check for errors.
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matti Hamalainen
Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl")
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201120152338.1203257-1-...@tnsp.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 124d3dcc5c590..98e99aa8a547e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -570,8 +570,10 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
NV_PRINTK(err, cli, "validating bo list\n");
validate_fini(op, chan, NULL, NULL);
return ret;
+ } else if (ret > 0) {
+ *apply_relocs = true;
}
- *apply_relocs = ret;
+
return 0;
}
@@ -674,7 +676,6 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
}
- u_free(reloc);
return ret;
}
@@ -884,9 +885,10 @@ out:
break;
}
}
- u_free(reloc);
}
out_prevalid:
+ if (!IS_ERR(reloc))
+ u_free(reloc);
u_free(bo);
u_free(push);
--
2.27.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] fbcon: Disable accelerated scrolling
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-ish drivers really only treat
> fbcon as an dumb kernel console until userspace takes over, and Oops
> printer for some emergencies. Looking at drm drivers and the basic
> vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> acceleration:
>
> - nouveau, seems to be enabled by default
> - omapdrm, when a DMM remapper exists using remapper rewriting for
> y/xpanning
> - gma500, but that is getting deleted now for the GTT remapper trick,
> and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> flag, so unused (and could be deleted already I think).
>
> No other driver supportes accelerated fbcon. And fbcon is the only
> user of this accel code (it's not exposed as uapi through ioctls),
> which means we could garbage collect fairly enormous amounts of code
> if we kill this.
>
> Plus because syzbot only runs on virtual hardware, and none of the
> drivers for that have acceleration, we'd remove a huge gap in testing.
> And there's no other even remotely comprehensive testing aside from
> syzbot.
>
> This patch here just disables the acceleration code by always
> redrawing when scrolling. The plan is that once this has been merged
> for well over a year in released kernels, we can start to go around
> and delete a lot of code.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Greg Kroah-Hartman
> Cc: Linus Torvalds
> Cc: Ben Skeggs
> Cc: nouveau@lists.freedesktop.org
> Cc: Tomi Valkeinen
> Cc: Daniel Vetter
> Cc: Jiri Slaby
> Cc: "Gustavo A. R. Silva"
> Cc: Tetsuo Handa
> Cc: Peilin Ye
> Cc: George Kennedy
> Cc: Nathan Chancellor
> Cc: Peter Rosin
> Signed-off-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbcon.c | 38 ++--
> 1 file changed, 7 insertions(+), 31 deletions(-)
Nice!
But I'm with Sam, delete early :)
Reviewed-by: Greg Kroah-Hartman
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5.6 108/166] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf5..2d4c899e1f8b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -734,7 +793,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
[Nouveau] [PATCH 5.4 076/118] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f3..b1beed40e746a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -736,7 +795,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
}
diff --git
Re: [Nouveau] [PATCH 9/9] drm/nouveau/kms/nvd9-: Add CRC support
On Tue, Mar 17, 2020 at 08:41:06PM -0400, Lyude Paul wrote:
> + root = debugfs_create_dir("nv_crc", crtc->debugfs_entry);
> + if (IS_ERR(root))
> + return PTR_ERR(root);
No need to check this, just take the return value and move on.
> +
> + dent = debugfs_create_file("flip_threshold", 0644, root, head,
> +_crc_flip_threshold_fops);
> + if (IS_ERR(dent))
> + return PTR_ERR(dent);
No need to check this either, in fact this test is incorrect :(
Just make the call, and move on. See the loads of debugfs cleanups I
have been doing for examples.
thanks,
greg k-h
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions
On Fri, Feb 14, 2020 at 12:30:48AM +0100, Daniel Vetter wrote: > On Thu, Feb 13, 2020 at 11:39 PM Greg Kroah-Hartman > wrote: > > > > On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote: > > > On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote: > > > > When calling debugfs functions, there is no need to ever check the > > > > return value. The function can work or not, but the code logic should > > > > never do something different based on this. > > > > > > > > > > Should we follow that line of reasoning further, and simply return void > > > from the debugfs functions--rather than playing whack-a-mole with this > > > indefinitely? > > > > That is what we (well I) have been doing. Look at all of the changes > > that have happened to include/linux/debugfs.h over the past few > > releases. I'm slowly winnowing down the api to make it impossible to > > get wrong for this type of thing, and am almost there. > > > > DRM is the big fish left to tackle, I have submitted some patches in the > > past, but lots more cleanup needs to be done to get them into mergable > > shape. I just need to find the time... > > Just to avoid duplication, Wambui (cc'ed) just started working on > this. Expect a lot more void return values and a pile of deleted code > rsn. Nice! It's not duplication if I haven't started on it :) greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions
On Thu, Feb 13, 2020 at 02:30:09PM -0800, John Hubbard wrote: > On 2/9/20 2:55 AM, Greg Kroah-Hartman wrote: > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should > > never do something different based on this. > > > > Should we follow that line of reasoning further, and simply return void > from the debugfs functions--rather than playing whack-a-mole with this > indefinitely? That is what we (well I) have been doing. Look at all of the changes that have happened to include/linux/debugfs.h over the past few releases. I'm slowly winnowing down the api to make it impossible to get wrong for this type of thing, and am almost there. DRM is the big fish left to tackle, I have submitted some patches in the past, but lots more cleanup needs to be done to get them into mergable shape. I just need to find the time... thanks, greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 080e964d49aa..d1c82fc45a68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -224,14 +224,10 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
struct dentry *dentry;
int i;
- for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
- dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
-S_IRUGO | S_IWUSR,
-minor->debugfs_root, minor->dev,
-nouveau_debugfs_files[i].fops);
- if (!dentry)
- return -ENOMEM;
- }
+ for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++)
+ debugfs_create_file(nouveau_debugfs_files[i].name,
+ S_IRUGO | S_IWUSR, minor->debugfs_root,
+ minor->dev, nouveau_debugfs_files[i].fops);
drm_debugfs_create_files(nouveau_debugfs_list,
NOUVEAU_DEBUGFS_ENTRIES,
--
2.25.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > > Hi Greg, > > > > > > > > This feels like it's missing a From: line. > > > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > > Author: Lyude Paul > > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > > > Is this an artifact of your notification-of-patches process and I > > > > never noticed before, or was the patch ingested incorrectly? > > > > > > It was always like this for patches that came through me. Greg's script > > > generates an explicit "From:" line in the patch, but I never saw the > > > value in that since git does the right thing by looking at the "From:" > > > line in the mail header. > > > > > > The right thing is being done in stable-rc and for the releases. For > > > your example here, this is how it looks like in the stable-rc tree: > > > > > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > > > Author: Lyude Paul > > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > > > Commit: Greg Kroah-Hartman > > > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Yeah, we should fix your scripts to put the explicit From: line in here > > as we are dealing with patches in this format and it causes confusion at > > times (like now.) It's not the first time and that's why I added those > > lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch. thanks, greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > Hi Greg, > > > > This feels like it's missing a From: line. > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > Author: Lyude Paul > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Is this an artifact of your notification-of-patches process and I > > never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. > > The right thing is being done in stable-rc and for the releases. For > your example here, this is how it looks like in the stable-rc tree: > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > Author: Lyude Paul > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > Commit: Greg Kroah-Hartman > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >drm/nouveau: Don't WARN_ON VCPI allocation failures Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches. thanks, greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.19 125/190] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
[ Upstream commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 ] On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 This causes a timeout trying to bring up the GR ctx: nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<7faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouveau@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: sta...@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/pci/quirks.c | 58 1 file changed, 58 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6cda8b7ecc821..311f8a33e62ff 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5116,3 +5116,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does + * not always reset the secondary Nvidia GPU between reboots if the system + * is configured to use Hybrid Graphics mode. This results in the GPU + * being left in whatever state it was in during the *previous* boot, which + * causes spurious interrupts from the GPU, which in turn causes us to + * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly, + * this also completely breaks nouveau. + * + * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a + * clean state and fixes all these issues. + * + * When the machine is configured in Dedicated display mode, the issue + * doesn't occur. Fortunately the GPU advertises NoReset+ when in this + * mode, so we can detect that and avoid resetting it. + */ +static void
[Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
multi-stream")
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index f889d41a281fa..5e01bfb69d7a3 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, slots);
- WARN_ON(!r);
+ if (!r)
+ DRM_DEBUG_KMS("Failed to allocate VCPI\n");
if (!mstm->links++)
nv50_outp_acquire(mstm->outp);
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 7dfbbbc1beea..7b3ff55ac9a2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -224,14 +224,10 @@ nouveau_drm_debugfs_init(struct drm_minor *minor)
struct dentry *dentry;
int i, ret;
- for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++) {
- dentry = debugfs_create_file(nouveau_debugfs_files[i].name,
-S_IRUGO | S_IWUSR,
-minor->debugfs_root, minor->dev,
-nouveau_debugfs_files[i].fops);
- if (!dentry)
- return -ENOMEM;
- }
+ for (i = 0; i < ARRAY_SIZE(nouveau_debugfs_files); i++)
+ debugfs_create_file(nouveau_debugfs_files[i].name,
+ S_IRUGO | S_IWUSR, minor->debugfs_root,
+ minor->dev, nouveau_debugfs_files[i].fops);
ret = drm_debugfs_create_files(nouveau_debugfs_list,
NOUVEAU_DEBUGFS_ENTRIES,
--
2.22.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5.1 096/122] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
unknown, but the following steps and possibly a good bit of patience will
reproduce the issue:
1. Boot up the laptop normally in Hybrid Graphics mode
2. Make sure nouveau is loaded and that the GPU is awake
3. Allow the Nvidia GPU to runtime suspend itself after being idle
4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help)
5. If nouveau loads up properly, reboot the machine again and go back to
step 2 until you reproduce the issue
This results in some very strange behavior: the GPU will be left in exactly
the same state it was in when the previously booted kernel started the
reboot. This has all sorts of bad side effects: for starters, this
completely breaks nouveau starting with a mysterious EVO channel failure
that happens well before we've actually used the EVO channel for anything:
nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002
This causes a timeout trying to bring up the GR ctx:
nouveau :01:00.0: timeout
WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547
gf100_grctx_generate+0x7b2/0x850 [nouveau]
Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
...
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00
[GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown]
The GPU never manages to recover. Booting without loading nouveau causes
issues as well, since the GPU starts sending spurious interrupts that cause
other device's IRQs to get disabled by the kernel:
irq 16: nobody cared (try booting with the "irqpoll" option)
...
handlers:
[<7faa9e99>] i801_isr [i2c_i801]
Disabling IRQ #16
...
serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register
(-110).
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled
interrupts!
This causes the touchpad and sometimes other things to get disabled.
Since this happens without nouveau, we can't fix this problem from nouveau
itself.
Add a PCI quirk for the specific P50 variant of this GPU. Make sure the
GPU is advertising NoReset- so we don't reset the GPU when the machine is
in Dedicated graphics mode (where the GPU being initialized by the BIOS is
normal and expected). Map the GPU MMIO space and read the magic 0x2240c
register, which will have bit 1 set if the device was POSTed during a
previous boot. Once we've confirmed all of this, reset the GPU and
re-disable it - bringing it back to a healthy state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003
Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com
Signed-off-by: Lyude Paul
Signed-off-by: Bjorn Helgaas
Cc: nouveau@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Karol Herbst
Cc: Ben Skeggs
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c | 58 +++
1 file changed, 58 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5124,3 +5124,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3
SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+
+/*
+ * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
+ * not always reset the secondary Nvidia GPU between reboots if the system
+ * is configured to use Hybrid Graphics mode. This results in the GPU
+ * being left in whatever state it was in during the *previous* boot, which
+ * causes spurious interrupts from the GPU, which in turn causes us to
+ * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly,
+ * this also completely breaks nouveau.
+ *
+ * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a
+ * clean state and fixes all these issues.
+ *
+ * When the machine is configured in Dedicated display mode, the issue
+ * doesn't occur. Fortunately the GPU advertises NoReset+ when in this
+ * mode, so we can detect that and avoid resetting it.
+ */
+static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
+{
+ void __iomem *map;
[Nouveau] [PATCH 5.0 087/139] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
unknown, but the following steps and possibly a good bit of patience will
reproduce the issue:
1. Boot up the laptop normally in Hybrid Graphics mode
2. Make sure nouveau is loaded and that the GPU is awake
3. Allow the Nvidia GPU to runtime suspend itself after being idle
4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help)
5. If nouveau loads up properly, reboot the machine again and go back to
step 2 until you reproduce the issue
This results in some very strange behavior: the GPU will be left in exactly
the same state it was in when the previously booted kernel started the
reboot. This has all sorts of bad side effects: for starters, this
completely breaks nouveau starting with a mysterious EVO channel failure
that happens well before we've actually used the EVO channel for anything:
nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002
This causes a timeout trying to bring up the GR ctx:
nouveau :01:00.0: timeout
WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547
gf100_grctx_generate+0x7b2/0x850 [nouveau]
Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
...
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00
[GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown]
The GPU never manages to recover. Booting without loading nouveau causes
issues as well, since the GPU starts sending spurious interrupts that cause
other device's IRQs to get disabled by the kernel:
irq 16: nobody cared (try booting with the "irqpoll" option)
...
handlers:
[<7faa9e99>] i801_isr [i2c_i801]
Disabling IRQ #16
...
serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register
(-110).
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled
interrupts!
This causes the touchpad and sometimes other things to get disabled.
Since this happens without nouveau, we can't fix this problem from nouveau
itself.
Add a PCI quirk for the specific P50 variant of this GPU. Make sure the
GPU is advertising NoReset- so we don't reset the GPU when the machine is
in Dedicated graphics mode (where the GPU being initialized by the BIOS is
normal and expected). Map the GPU MMIO space and read the magic 0x2240c
register, which will have bit 1 set if the device was POSTed during a
previous boot. Once we've confirmed all of this, reset the GPU and
re-disable it - bringing it back to a healthy state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003
Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com
Signed-off-by: Lyude Paul
Signed-off-by: Bjorn Helgaas
Cc: nouveau@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Karol Herbst
Cc: Ben Skeggs
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c | 58 +++
1 file changed, 58 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5122,3 +5122,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3
SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+
+/*
+ * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
+ * not always reset the secondary Nvidia GPU between reboots if the system
+ * is configured to use Hybrid Graphics mode. This results in the GPU
+ * being left in whatever state it was in during the *previous* boot, which
+ * causes spurious interrupts from the GPU, which in turn causes us to
+ * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly,
+ * this also completely breaks nouveau.
+ *
+ * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a
+ * clean state and fixes all these issues.
+ *
+ * When the machine is configured in Dedicated display mode, the issue
+ * doesn't occur. Fortunately the GPU advertises NoReset+ when in this
+ * mode, so we can detect that and avoid resetting it.
+ */
+static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
+{
+ void __iomem *map;
[Nouveau] [PATCH 4.14 148/159] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Karol Herbst <kher...@redhat.com>
[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.
On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.
We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.
Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.
Tested-by: Lyude <ly...@redhat.com>
Signed-off-by: Karol Herbst <kher...@redhat.com>
Acked-by: Pekka Paalanen <ppaala...@gmail.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: nouveau@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/mm/ioremap.c |4 ++--
arch/x86/mm/kmmio.c | 12 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -349,11 +349,11 @@ void iounmap(volatile void __iomem *addr
return;
}
+ mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
- mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
ensures there isn't another iounmap for the same address
in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -435,17 +435,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
spin_lock_irqsave(_lock, flags);
- if (get_kmmio_probe(p->addr)) {
+ if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -454,7 +455,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
- if (add_kmmio_fault_page(p->addr + size))
+ if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -528,19 +529,20 @@ void unregister_kmmio_probe(struct kmmio
{
unsigned long flags;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte)
return;
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
- release_kmmio_fault_page(p->addr + size, _list);
+ release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.9 083/145] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Karol Herbst <kher...@redhat.com>
[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.
On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.
We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.
Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.
Tested-by: Lyude <ly...@redhat.com>
Signed-off-by: Karol Herbst <kher...@redhat.com>
Acked-by: Pekka Paalanen <ppaala...@gmail.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: nouveau@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/mm/ioremap.c |4 ++--
arch/x86/mm/kmmio.c | 12 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -347,11 +347,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
+ mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
- mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
ensures there isn't another iounmap for the same address
in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
spin_lock_irqsave(_lock, flags);
- if (get_kmmio_probe(p->addr)) {
+ if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
- if (add_kmmio_fault_page(p->addr + size))
+ if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
{
unsigned long flags;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte)
return;
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
- release_kmmio_fault_page(p->addr + size, _list);
+ release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.4 059/193] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Karol Herbst <kher...@redhat.com>
[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.
On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.
We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.
Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.
Tested-by: Lyude <ly...@redhat.com>
Signed-off-by: Karol Herbst <kher...@redhat.com>
Acked-by: Pekka Paalanen <ppaala...@gmail.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: nouveau@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/mm/ioremap.c |4 ++--
arch/x86/mm/kmmio.c | 12 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -348,11 +348,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
+ mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
- mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
ensures there isn't another iounmap for the same address
in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
spin_lock_irqsave(_lock, flags);
- if (get_kmmio_probe(p->addr)) {
+ if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
- if (add_kmmio_fault_page(p->addr + size))
+ if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
{
unsigned long flags;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte)
return;
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
- release_kmmio_fault_page(p->addr + size, _list);
+ release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3.18 54/58] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Karol Herbst <kher...@redhat.com>
[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.
On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.
We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.
Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.
Tested-by: Lyude <ly...@redhat.com>
Signed-off-by: Karol Herbst <kher...@redhat.com>
Acked-by: Pekka Paalanen <ppaala...@gmail.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: nouveau@lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kher...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/mm/ioremap.c |4 ++--
arch/x86/mm/kmmio.c | 12 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -296,11 +296,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
+ mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
- mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
ensures there isn't another iounmap for the same address
in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
spin_lock_irqsave(_lock, flags);
- if (get_kmmio_probe(p->addr)) {
+ if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(>list, _probes);
while (size < size_lim) {
- if (add_kmmio_fault_page(p->addr + size))
+ if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
{
unsigned long flags;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
- pte = lookup_address(p->addr, );
+ pte = lookup_address(addr, );
if (!pte)
return;
spin_lock_irqsave(_lock, flags);
while (size < size_lim) {
- release_kmmio_fault_page(p->addr + size, _list);
+ release_kmmio_fault_page(addr + size, _list);
size += page_level_size(l);
}
list_del_rcu(>list);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.12 35/43] drm/nouveau: Fix error handling in nv50_disp_atomic_commit
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
commit 813a7e1604eaad1c2792d37d402e1b48b8d0eb3f upstream.
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_planes when
drm_atomic_helper_wait_for_fences fails.
Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces
internally")
Cc: Ben Skeggs <bske...@redhat.com>
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Link:
http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankho...@linux.intel.com
Reviewed-by: Sean Paul <seanp...@chromium.org>
[mlankhorst: Use if (ret) to remove the goto in success case.]
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nv50_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4091,7 +4091,7 @@ nv50_disp_atomic_commit(struct drm_devic
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
- goto done;
+ goto err_cleanup;
}
for_each_plane_in_state(state, plane, plane_state, i) {
@@ -4119,7 +4119,7 @@ nv50_disp_atomic_commit(struct drm_devic
if (crtc->state->enable) {
if (!drm->have_disp_power_ref) {
drm->have_disp_power_ref = true;
- return ret;
+ return 0;
}
active = true;
break;
@@ -4131,6 +4131,9 @@ nv50_disp_atomic_commit(struct drm_devic
drm->have_disp_power_ref = false;
}
+err_cleanup:
+ if (ret)
+ drm_atomic_helper_cleanup_planes(dev, state);
done:
pm_runtime_put_autosuspend(dev->dev);
return ret;
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.13 39/47] drm/nouveau: Fix error handling in nv50_disp_atomic_commit
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
commit 813a7e1604eaad1c2792d37d402e1b48b8d0eb3f upstream.
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_planes when
drm_atomic_helper_wait_for_fences fails.
Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces
internally")
Cc: Ben Skeggs <bske...@redhat.com>
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Link:
http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankho...@linux.intel.com
Reviewed-by: Sean Paul <seanp...@chromium.org>
[mlankhorst: Use if (ret) to remove the goto in success case.]
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nv50_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4134,7 +4134,7 @@ nv50_disp_atomic_commit(struct drm_devic
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
- goto done;
+ goto err_cleanup;
}
for_each_plane_in_state(state, plane, plane_state, i) {
@@ -4162,7 +4162,7 @@ nv50_disp_atomic_commit(struct drm_devic
if (crtc->state->enable) {
if (!drm->have_disp_power_ref) {
drm->have_disp_power_ref = true;
- return ret;
+ return 0;
}
active = true;
break;
@@ -4174,6 +4174,9 @@ nv50_disp_atomic_commit(struct drm_devic
drm->have_disp_power_ref = false;
}
+err_cleanup:
+ if (ret)
+ drm_atomic_helper_cleanup_planes(dev, state);
done:
pm_runtime_put_autosuspend(dev->dev);
return ret;
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 000/102] Convert drivers to explicit reset API
On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote:
> The reset control API has two modes: exclusive access, where the driver
> expects to have full and immediate control over the state of the reset
> line, and shared (clock-like) access, where drivers only request reset
> deassertion while active, but don't care about the state of the reset line
> while inactive.
>
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior.
>
> This series converts all drivers that currently implicitly request
> exclusive reset controls to the corresponding explicit API call. It is,
> for the most part, generated from the following semantic patch:
Hey, I'm all for large api changes, but this really seems ackward, isn't
there a "better" way to do this?
Why not, as you say the "implicit" request is exclusive, just leave
everything alone and state that the "reset_control_get()" call is
exclusive and make the shared one the "odd" usage as that seems to not
be the normal case.
That should be a much smaller patch right?
That way you don't break everything here, and require 100+ patches to
just change the name of a function from one to another and do nothing
else.
thanks,
greg k-h
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.4 137/163] x86/mm/kmmio: Fix mmiotrace for hugepages
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Karol Herbst <nouv...@karolherbst.de>
commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 upstream.
Because Linux might use bigger pages than the 4K pages to handle those mmio
ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.
Using the memory address instead of the page id lets us look up how big the
page is and what its base address is, so that we won't get a page fault
within the same page twice anymore.
Tested-by: Pierre Moreau <pierre.mor...@free.fr>
Signed-off-by: Karol Herbst <nouv...@karolherbst.de>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@amacapital.net>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Luis R. Rodriguez <mcg...@suse.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Toshi Kani <toshi.k...@hp.com>
Cc: linux...@kvack.org
Cc: linux-x86...@vger.kernel.org
Cc: nouveau@lists.freedesktop.org
Cc: p...@iki.fi
Cc: rost...@goodmis.org
Link:
http://lkml.kernel.org/r/1456966991-6861-1-git-send-email-nouv...@karolherbst.de
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/x86/mm/kmmio.c | 88 ++--
1 file changed, 59 insertions(+), 29 deletions(-)
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -33,7 +33,7 @@
struct kmmio_fault_page {
struct list_head list;
struct kmmio_fault_page *release_next;
- unsigned long page; /* location of the fault page */
+ unsigned long addr; /* the requested address */
pteval_t old_presence; /* page presence prior to arming */
bool armed;
@@ -70,9 +70,16 @@ unsigned int kmmio_count;
static struct list_head kmmio_page_table[KMMIO_PAGE_TABLE_SIZE];
static LIST_HEAD(kmmio_probes);
-static struct list_head *kmmio_page_list(unsigned long page)
+static struct list_head *kmmio_page_list(unsigned long addr)
{
- return _page_table[hash_long(page, KMMIO_PAGE_HASH_BITS)];
+ unsigned int l;
+ pte_t *pte = lookup_address(addr, );
+
+ if (!pte)
+ return NULL;
+ addr &= page_level_mask(l);
+
+ return _page_table[hash_long(addr, KMMIO_PAGE_HASH_BITS)];
}
/* Accessed per-cpu */
@@ -98,15 +105,19 @@ static struct kmmio_probe *get_kmmio_pro
}
/* You must be holding RCU read lock. */
-static struct kmmio_fault_page *get_kmmio_fault_page(unsigned long page)
+static struct kmmio_fault_page *get_kmmio_fault_page(unsigned long addr)
{
struct list_head *head;
struct kmmio_fault_page *f;
+ unsigned int l;
+ pte_t *pte = lookup_address(addr, );
- page &= PAGE_MASK;
- head = kmmio_page_list(page);
+ if (!pte)
+ return NULL;
+ addr &= page_level_mask(l);
+ head = kmmio_page_list(addr);
list_for_each_entry_rcu(f, head, list) {
- if (f->page == page)
+ if (f->addr == addr)
return f;
}
return NULL;
@@ -137,10 +148,10 @@ static void clear_pte_presence(pte_t *pt
static int clear_page_presence(struct kmmio_fault_page *f, bool clear)
{
unsigned int level;
- pte_t *pte = lookup_address(f->page, );
+ pte_t *pte = lookup_address(f->addr, );
if (!pte) {
- pr_err("no pte for page 0x%08lx\n", f->page);
+ pr_err("no pte for addr 0x%08lx\n", f->addr);
return -1;
}
@@ -156,7 +167,7 @@ static int clear_page_presence(struct km
return -1;
}
- __flush_tlb_one(f->page);
+ __flush_tlb_one(f->addr);
return 0;
}
@@ -176,12 +187,12 @@ static int arm_kmmio_fault_page(struct k
int ret;
WARN_ONCE(f->armed, KERN_ERR pr_fmt("kmmio page already armed.\n"));
if (f->armed) {
- pr_warning("double-arm: page 0x%08lx, ref %d, old %d\n",
- f->page, f->count, !!f->old_presence);
+ pr_warning("double-arm: addr 0x%08lx, ref %d, old %d\n",
+ f->addr, f->count, !!f->old_presence);
}
ret = clear_page_presence(f, true);
- WARN_ONCE(ret < 0, KERN_ERR pr_fmt("arming 0x%08lx failed.\n"),
- f->page);
+ WARN_ONCE(ret < 0, KERN_ERR pr_fmt("arming at 0x%08lx failed.\n"),
+ f->addr);
f->armed = true;
return ret;
}
@@ -191,7 +202,7 @@ static void disarm_kmmio_fault_pag
