[PATCH v2 2/2] drm/nouveau: move more missing UAPI bits
Those are already de-facto UAPI, so let's just move it into the uapi
header.
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Reviewed-by: Danilo Krummrich
Link:
https://patchwork.freedesktop.org/patch/msgid/20240304183157.1587152-2-kher...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
drivers/gpu/drm/nouveau/nouveau_abi16.h | 12
include/uapi/drm/nouveau_drm.h | 22 ++
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index cd14f993bdd1b..92f9127b284ac 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -312,11 +312,21 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
if (device->info.family >= NV_DEVICE_INFO_V0_KEPLER) {
if (init->fb_ctxdma_handle == ~0) {
switch (init->tt_ctxdma_handle) {
- case 0x01: engine = NV_DEVICE_HOST_RUNLIST_ENGINES_GR
; break;
- case 0x02: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSPDEC; break;
- case 0x04: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSPPP ; break;
- case 0x08: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSVLD ; break;
- case 0x30: engine = NV_DEVICE_HOST_RUNLIST_ENGINES_CE
; break;
+ case NOUVEAU_FIFO_ENGINE_GR:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_GR;
+ break;
+ case NOUVEAU_FIFO_ENGINE_VP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSPDEC;
+ break;
+ case NOUVEAU_FIFO_ENGINE_PPP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSPPP;
+ break;
+ case NOUVEAU_FIFO_ENGINE_BSP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSVLD;
+ break;
+ case NOUVEAU_FIFO_ENGINE_CE:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_CE;
+ break;
default:
return nouveau_abi16_put(abi16, -ENOSYS);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 11c8c4a80079b..661b901d8ecc9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
@@ -50,18 +50,6 @@ struct drm_nouveau_grobj_alloc {
int class;
};
-struct drm_nouveau_notifierobj_alloc {
- uint32_t channel;
- uint32_t handle;
- uint32_t size;
- uint32_t offset;
-};
-
-struct drm_nouveau_gpuobj_free {
- int channel;
- uint32_t handle;
-};
-
struct drm_nouveau_setparam {
uint64_t param;
uint64_t value;
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 77d7ff0d5b110..5404d4cfff4c2 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -73,6 +73,16 @@ struct drm_nouveau_getparam {
__u64 value;
};
+/*
+ * Those are used to support selecting the main engine used on Kepler.
+ * This goes into drm_nouveau_channel_alloc::tt_ctxdma_handle
+ */
+#define NOUVEAU_FIFO_ENGINE_GR 0x01
+#define NOUVEAU_FIFO_ENGINE_VP 0x02
+#define NOUVEAU_FIFO_ENGINE_PPP 0x04
+#define NOUVEAU_FIFO_ENGINE_BSP 0x08
+#define NOUVEAU_FIFO_ENGINE_CE 0x30
+
struct drm_nouveau_channel_alloc {
__u32 fb_ctxdma_handle;
__u32 tt_ctxdma_handle;
@@ -95,6 +105,18 @@ struct drm_nouveau_channel_free {
__s32 channel;
};
+struct drm_nouveau_notifierobj_alloc {
+ __u32 channel;
+ __u32 handle;
+ __u32 size;
+ __u32 offset;
+};
+
+struct drm_nouveau_gpuobj_free {
+ __s32 channel;
+ __u32 handle;
+};
+
#define NOUVEAU_GEM_DOMAIN_CPU (1 << 0)
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
--
2.44.0
[PATCH v2 1/2] drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf
If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Cc: Danilo Krummrich
Cc: # v6.6+
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
Reviewed-by: Danilo Krummrich
Link:
https://patchwork.freedesktop.org/patch/msgid/20240304183157.1587152-1-kher...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 49c2bcbef1299..5a887d67dc0e8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -764,7 +764,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
return -ENOMEM;
if (unlikely(nouveau_cli_uvmm(cli)))
- return -ENOSYS;
+ return nouveau_abi16_put(abi16, -ENOSYS);
list_for_each_entry(temp, >channels, head) {
if (temp->chan->chid == req->channel) {
--
2.44.0
[PATCH 2/2] drm/nouveau: move more missing UAPI bits
Those are already de-facto UAPI, so let's just move it into the uapi
header.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
drivers/gpu/drm/nouveau/nouveau_abi16.h | 12
include/uapi/drm/nouveau_drm.h | 22 ++
3 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index cd14f993bdd1b..92f9127b284ac 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -312,11 +312,21 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
if (device->info.family >= NV_DEVICE_INFO_V0_KEPLER) {
if (init->fb_ctxdma_handle == ~0) {
switch (init->tt_ctxdma_handle) {
- case 0x01: engine = NV_DEVICE_HOST_RUNLIST_ENGINES_GR
; break;
- case 0x02: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSPDEC; break;
- case 0x04: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSPPP ; break;
- case 0x08: engine =
NV_DEVICE_HOST_RUNLIST_ENGINES_MSVLD ; break;
- case 0x30: engine = NV_DEVICE_HOST_RUNLIST_ENGINES_CE
; break;
+ case NOUVEAU_FIFO_ENGINE_GR:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_GR;
+ break;
+ case NOUVEAU_FIFO_ENGINE_VP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSPDEC;
+ break;
+ case NOUVEAU_FIFO_ENGINE_PPP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSPPP;
+ break;
+ case NOUVEAU_FIFO_ENGINE_BSP:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_MSVLD;
+ break;
+ case NOUVEAU_FIFO_ENGINE_CE:
+ engine = NV_DEVICE_HOST_RUNLIST_ENGINES_CE;
+ break;
default:
return nouveau_abi16_put(abi16, -ENOSYS);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 11c8c4a80079b..661b901d8ecc9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
@@ -50,18 +50,6 @@ struct drm_nouveau_grobj_alloc {
int class;
};
-struct drm_nouveau_notifierobj_alloc {
- uint32_t channel;
- uint32_t handle;
- uint32_t size;
- uint32_t offset;
-};
-
-struct drm_nouveau_gpuobj_free {
- int channel;
- uint32_t handle;
-};
-
struct drm_nouveau_setparam {
uint64_t param;
uint64_t value;
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 77d7ff0d5b110..5404d4cfff4c2 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -73,6 +73,16 @@ struct drm_nouveau_getparam {
__u64 value;
};
+/*
+ * Those are used to support selecting the main engine used on Kepler.
+ * This goes into drm_nouveau_channel_alloc::tt_ctxdma_handle
+ */
+#define NOUVEAU_FIFO_ENGINE_GR 0x01
+#define NOUVEAU_FIFO_ENGINE_VP 0x02
+#define NOUVEAU_FIFO_ENGINE_PPP 0x04
+#define NOUVEAU_FIFO_ENGINE_BSP 0x08
+#define NOUVEAU_FIFO_ENGINE_CE 0x30
+
struct drm_nouveau_channel_alloc {
__u32 fb_ctxdma_handle;
__u32 tt_ctxdma_handle;
@@ -95,6 +105,18 @@ struct drm_nouveau_channel_free {
__s32 channel;
};
+struct drm_nouveau_notifierobj_alloc {
+ __u32 channel;
+ __u32 handle;
+ __u32 size;
+ __u32 offset;
+};
+
+struct drm_nouveau_gpuobj_free {
+ __s32 channel;
+ __u32 handle;
+};
+
#define NOUVEAU_GEM_DOMAIN_CPU (1 << 0)
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
--
2.43.2
[PATCH 1/2] drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf
If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Cc: Danilo Krummrich
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 49c2bcbef1299..5a887d67dc0e8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -764,7 +764,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
return -ENOMEM;
if (unlikely(nouveau_cli_uvmm(cli)))
- return -ENOSYS;
+ return nouveau_abi16_put(abi16, -ENOSYS);
list_for_each_entry(temp, >channels, head) {
if (temp->chan->chid == req->channel) {
--
2.43.2
[PATCH] drm/nouveau/disp: fix DP capable DSM connectors
Just special case DP DSM connectors until we properly figure out how to
deal with this.
This resolves user regressions on GPUs with such connectors without
reverting the original fix.
Cc: Lyude Paul
Cc: sta...@vger.kernel.org # 6.4+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/255
Fixes: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX
interrupts")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
index 46b057fe1412e..3249e5c1c8930 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
@@ -62,6 +62,18 @@ nvkm_uconn_uevent_gpio(struct nvkm_object *object, u64
token, u32 bits)
return object->client->event(token, , sizeof(args.v0));
}
+static bool
+nvkm_connector_is_dp_dms(u8 type)
+{
+ switch (type) {
+ case DCB_CONNECTOR_DMS59_DP0:
+ case DCB_CONNECTOR_DMS59_DP1:
+ return true;
+ default:
+ return false;
+ }
+}
+
static int
nvkm_uconn_uevent(struct nvkm_object *object, void *argv, u32 argc, struct
nvkm_uevent *uevent)
{
@@ -101,7 +113,7 @@ nvkm_uconn_uevent(struct nvkm_object *object, void *argv,
u32 argc, struct nvkm_
if (args->v0.types & NVIF_CONN_EVENT_V0_UNPLUG) bits |= NVKM_GPIO_LO;
if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ) {
/* TODO: support DP IRQ on ANX9805 and remove this hack. */
- if (!outp->info.location)
+ if (!outp->info.location &&
!nvkm_connector_is_dp_dms(conn->info.type))
return -EINVAL;
}
--
2.41.0
Re: [PATCH 06/20] drm/nouveau/dispnv04/crtc: Demote kerneldoc abuses
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > drivers/gpu/drm/nouveau/dispnv04/crtc.c:629: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Signed-off-by: Lee Jones > --- > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > index a34924523133c..5454dbb669566 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct > drm_display_mode *mode) > regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct > drm_framebuffer *old_fb) > return ret; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > -- > 2.42.0.rc1.204.g551eb34607-goog > Reviewed-by: Karol Herbst
Re: [PATCH 05/20] drm/nouveau/nvkm/engine/gr/gf100: Demote kerneldoc abuse
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1044: warning: This comment > starts with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Signed-off-by: Lee Jones > --- > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > --- > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > index 3648868bb9fc5..788b1773c46a7 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > @@ -1040,7 +1040,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr) > } > } > > -/** > +/* > * Wait until GR goes idle. GR is considered idle if it is disabled by the > * MC (0x200) register, or GR is not busy and a context switch is not in > * progress. > -- > 2.42.0.rc1.204.g551eb34607-goog > Reviewed-by: Karol Herbst
Re: [PATCH 04/20] drm/nouveau/nvkm/subdev/volt/gk20a: Demote kerneldoc abuses
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:49: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:62: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
> Signed-off-by: Lee Jones
> ---
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> index 8c2faa9645111..ccac88da88648 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> @@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
> /* 852 */ { 1608418, -21643, -269, 0,763, -48},
> };
>
> -/**
> +/*
> * cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
> */
> static inline int
> @@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const
> struct cvb_coef *coef)
> return mv;
> }
>
> -/**
> +/*
> * cvb_t_mv =
> * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
> * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
> --
> 2.42.0.rc1.204.g551eb34607-goog
>
Reviewed-by: Karol Herbst
Re: [PATCH 03/20] drm/nouveau/nvkm/subdev/bios/init: Demote a bunch of kernel-doc abuses
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting
> prototype for INIT_DONE(). Prototype was for init_done() instead
> [Snipped ~140 lines for brevity]
>
> Signed-off-by: Lee Jones
> ---
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> ---
> .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 136 +-
> 1 file changed, 68 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> index 1420794038642..b54f044c4483b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> @@ -575,7 +575,7 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
> * init opcode handlers
>
> */
>
> -/**
> +/*
> * init_reserved - stub for various unknown/unused single-byte opcodes
> *
> */
> @@ -602,7 +602,7 @@ init_reserved(struct nvbios_init *init)
> init->offset += length;
> }
>
> -/**
> +/*
> * INIT_DONE - opcode 0x71
> *
> */
> @@ -613,7 +613,7 @@ init_done(struct nvbios_init *init)
> init->offset = 0x;
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PROG - opcode 0x32
> *
> */
> @@ -650,7 +650,7 @@ init_io_restrict_prog(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_REPEAT - opcode 0x33
> *
> */
> @@ -676,7 +676,7 @@ init_repeat(struct nvbios_init *init)
> init->repeat = repeat;
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PLL - opcode 0x34
> *
> */
> @@ -716,7 +716,7 @@ init_io_restrict_pll(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_END_REPEAT - opcode 0x36
> *
> */
> @@ -732,7 +732,7 @@ init_end_repeat(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_COPY - opcode 0x37
> *
> */
> @@ -759,7 +759,7 @@ init_copy(struct nvbios_init *init)
> init_wrvgai(init, port, index, data);
> }
>
> -/**
> +/*
> * INIT_NOT - opcode 0x38
> *
> */
> @@ -771,7 +771,7 @@ init_not(struct nvbios_init *init)
> init_exec_inv(init);
> }
>
> -/**
> +/*
> * INIT_IO_FLAG_CONDITION - opcode 0x39
> *
> */
> @@ -788,7 +788,7 @@ init_io_flag_condition(struct nvbios_init *init)
> init_exec_set(init, false);
> }
>
> -/**
> +/*
> * INIT_GENERIC_CONDITION - opcode 0x3a
> *
> */
> @@ -840,7 +840,7 @@ init_generic_condition(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_IO_MASK_OR - opcode 0x3b
> *
> */
> @@ -859,7 +859,7 @@ init_io_mask_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
> }
>
> -/**
> +/*
> * INIT_IO_OR - opcode 0x3c
> *
> */
> @@ -878,7 +878,7 @@ init_io_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data | (1 << or));
> }
>
> -/**
> +/*
> * INIT_ANDN_REG - opcode 0x47
> *
> */
> @@ -895,7 +895,7 @@ init_andn_reg(struct nvbios_init *init)
> init_mask(init, reg, mask, 0);
> }
>
> -/**
> +/*
> * INIT_OR_REG - opcode 0x48
> *
> */
> @@ -912,7 +912,7 @@ init_or_reg(struct nvbios_init *init)
> init_mask(init, reg, 0, mask);
> }
>
> -/**
> +/*
> * INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
> *
> */
> @@ -942,7 +942,7 @@ init_idx_addr_latched(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PLL2 - opcode 0x4a
> *
> */
> @@ -977,7 +977,7 @@ init_io_restrict_pll2(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_PLL2 - opcode 0x4b
> *
> */
> @@ -994,7 +994,7 @@ init_pll2(struct nvbios_init *init)
> init_prog_pll(init, reg, freq);
> }
>
> -/**
> +/*
> * INIT_I2C_BYTE - opcode 0x4c
> *
> */
> @@ -1025,7 +1025,7 @@ init_i2c_byte(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_ZM_I2C_BYTE - opcode 0x4d
> *
> */
> @@ -1051,7 +1051,7 @@ init_zm_i2
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Thu, Aug 17, 2023 at 12:11 PM Borislav Petkov wrote: > > On Thu, Aug 17, 2023 at 12:00:47PM +0200, Karol Herbst wrote: > > btw, what would help is to know where `nvkm_uconn_uevent` actually > > fails, or rather, are you running into this "/* TODO: support DP IRQ > > on ANX9805 and remove this hack. */" condition? > > Send me a diff, I'll run it here and catch output over serial. > simply throw a printk(KERN_WARNING "nvkm_uconn_uevent %u\n", outp->info.location); inside drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c:104 after that mentioned comment. > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Thu, Aug 17, 2023 at 11:58 AM Karol Herbst wrote: > > On Thu, Aug 17, 2023 at 10:10 AM Borislav Petkov wrote: > > > > On Thu, Aug 17, 2023 at 01:18:12AM +0200, Karol Herbst wrote: > > > do you have one of these? https://en.wikipedia.org/wiki/DMS-59 > > > > Ah, DMS == Dual Monitor Solution :-) > > > > Yap, that's exactly what the GPU has. And the Y-cable is 2xDVI. It is > > a Dell workstation and it came this way, meaning I haven't done any > > changes there. > > > > Thx. > > right.. seems like on my GPU with such a connector I'm not seeing any > issues... let me dig further into the vbios and see if I can figure > something out there. > btw, what would help is to know where `nvkm_uconn_uevent` actually fails, or rather, are you running into this "/* TODO: support DP IRQ on ANX9805 and remove this hack. */" condition? > > > > -- > > Regards/Gruss, > > Boris. > > > > https://people.kernel.org/tglx/notes-about-netiquette > >
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Thu, Aug 17, 2023 at 10:10 AM Borislav Petkov wrote: > > On Thu, Aug 17, 2023 at 01:18:12AM +0200, Karol Herbst wrote: > > do you have one of these? https://en.wikipedia.org/wiki/DMS-59 > > Ah, DMS == Dual Monitor Solution :-) > > Yap, that's exactly what the GPU has. And the Y-cable is 2xDVI. It is > a Dell workstation and it came this way, meaning I haven't done any > changes there. > > Thx. right.. seems like on my GPU with such a connector I'm not seeing any issues... let me dig further into the vbios and see if I can figure something out there. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Thu, Aug 17, 2023 at 12:14 AM Borislav Petkov wrote: > > On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote: > > that GPU has only a `DMS-59` connector, is that right? > > No clue. How do I figure that out? > do you have one of these? https://en.wikipedia.org/wiki/DMS-59 > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Wed, Aug 16, 2023 at 5:13 PM Borislav Petkov wrote: > > On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote: > > Do you have any connectors listed in "/sys/class/drm"? > > tree /sys/class/drm/ > /sys/class/drm/ > ├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0 > ├── renderD128 -> > ../../devices/pci:00/:00:02.0/:03:00.0/drm/renderD128 > └── version > > > Also, mind sharing your vbios.rom file from > > "/sys/kernel/debug/dri/0/vbios.rom"? > > Attached. that GPU has only a `DMS-59` connector, is that right? I have such a GPU myself, so maybe I can trigger that bug there, let's see.. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Wed, Aug 16, 2023 at 4:54 PM Borislav Petkov wrote: > > On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote: > > Mind sharing your kernel logs with that patch applied? I suspect your > > system boots up but you might just not have the connector available or > > something? It could be that you have one of those GPUs affected by the > > original change and then we'd have to figure out what to do with that. > > Close. With your patch applied, the machine is up and I can log in and > use it. However, the output on the connected monitor stops after... > > [6.815167] ACPI: \_PR_.CP05: Found 4 idle states > [6.825438] ACPI: \_PR_.CP06: Found 4 idle states > [6.835661] ACPI: \_PR_.CP07: Found 4 idle states > [7.280093] Freeing initrd memory: 8328K > [7.601986] tsc: Refined TSC clocksource calibration: 3591.346 MHz > [7.608360] clocksource: tsc: mask: 0x max_cycles: > 0x33c46403b59, max_idle_ns: 440795293818 ns > [7.620254] clocksource: Switched to clocksource tsc > [8.337724] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [8.350553] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [8.375311] serial :00:16.3: enabling device ( -> 0003) > [8.403681] :00:16.3: ttyS1 at I/O 0xf0a0 (irq = 17, base_baud = > 115200) is a 16550A > [8.424951] Linux agpgart interface v0.103 > [8.432456] ACPI: bus type drm_connector registered > > ... this line here above. It is the last one output. What you see here > below what I'm catching from serial. > > [8.456734] Console: switching to colour dummy device 80x25 > [8.464414] nouveau :03:00.0: vgaarb: deactivate vga console > [8.473063] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > [8.594096] nouveau :03:00.0: bios: version 70.18.83.00.08 > [8.607906] nouveau :03:00.0: fb: 512 MiB DDR3 > [8.926721] nouveau :03:00.0: DRM: VRAM: 512 MiB > [8.931763] nouveau :03:00.0: DRM: GART: 1048576 MiB > [8.937156] nouveau :03:00.0: DRM: TMDS table version 2.0 > [8.942969] nouveau :03:00.0: DRM: DCB version 4.0 > [8.948173] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > [8.954696] nouveau :03:00.0: DRM: DCB outp 01: 02000362 00020010 > [8.961211] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 0f220010 > [8.967739] nouveau :03:00.0: DRM: DCB outp 03: 01011380 > [8.974261] nouveau :03:00.0: DRM: DCB outp 04: 08011382 00020010 > [8.980769] nouveau :03:00.0: DRM: DCB outp 05: 088113c6 0f220010 > [8.987293] nouveau :03:00.0: DRM: DCB conn 00: 00101064 > [8.993015] nouveau :03:00.0: DRM: DCB conn 01: 00202165 > [9.005724] nouveau :03:00.0: DRM: MM: using COPY for buffer copies > [9.023889] [drm] Initialized nouveau 1.3.1 20120801 for :03:00.0 on > minor 0 > [9.032044] nouveau :03:00.0: [drm] Cannot find any crtc or sizes > [9.162909] megasas: 07.725.01.00-rc1 > [9.167537] st: Version 20160209, fixed bufsize 32768, s/g segs 256 > [9.176058] ahci :00:1f.2: version 3.0 > [9.194078] ahci :00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3 > impl SATA mode > [9.202487] ahci :00:1f.2: flags: 64bit ncq sntf pm led clo pio slum > part ems apst > [9.243154] scsi host0: ahci > [9.252090] scsi host1: ahci > [9.260389] scsi host2: ahci > [9.268061] scsi host3: ahci > [9.273542] scsi host4: ahci > [9.279071] scsi host5: ahci > ... > > and so on until full boot. > okay, so the patch at least fixes the memory corruption, which is good, so I'd go ahead and push it out as it might also fix other unrelated crashes. Do you have any connectors listed in "/sys/class/drm"? Also, mind sharing your vbios.rom file from "/sys/kernel/debug/dri/0/vbios.rom"? Thanks > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >
Re: [PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
On Wed, Aug 16, 2023 at 11:30 AM Borislav Petkov wrote:
>
> On Mon, Aug 14, 2023 at 04:49:32PM +0200, Karol Herbst wrote:
> > We can't simply free the connector after calling drm_connector_init on it.
> > We need to clean up the drm side first.
> >
> > It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp:
> > PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it
> > fixes a memory corruption in error handling related to that commit.
> >
> > Link:
> > https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/
> > Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class")
> > Signed-off-by: Karol Herbst
> > ---
> > drivers/gpu/drm/nouveau/nouveau_connector.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
>
> This one ontop of -rc5 doesn't help, unfortunately.
>
Mind sharing your kernel logs with that patch applied? I suspect your
system boots up but you might just not have the connector available or
something? It could be that you have one of those GPUs affected by the
original change and then we'd have to figure out what to do with that.
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
>
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Mon, Aug 14, 2023 at 4:19 PM Karol Herbst wrote: > > On Mon, Aug 14, 2023 at 3:35 PM Takashi Iwai wrote: > > > > On Mon, 14 Aug 2023 15:19:11 +0200, > > Karol Herbst wrote: > > > > > > On Mon, Aug 14, 2023 at 2:56 PM Karol Herbst wrote: > > > > > > > > On Mon, Aug 14, 2023 at 2:48 PM Takashi Iwai wrote: > > > > > > > > > > On Mon, 14 Aug 2023 14:38:18 +0200, > > > > > Karol Herbst wrote: > > > > > > > > > > > > On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote: > > > > > > > > > > > > > > On Wed, 09 Aug 2023 16:46:38 +0200, > > > > > > > Takashi Iwai wrote: > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 15:13:23 +0200, > > > > > > > > Takashi Iwai wrote: > > > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 14:19:23 +0200, > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 13:42:09 +0200, > > > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > > > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol > > > > > > > > > > > > > > > Herbst wrote: > > > > > > > > > > > > > > > > in what way does it stop? Just not progressing? > > > > > > > > > > > > > > > > That would be kinda > > > > > > > > > > > > > > > > concerning. Mind tracing with what arguments > > > > > > > > > > > > > > > > `nvkm_uevent_add` is > > > > > > > > > > > > > > > > called with and without that patch? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, me dumping those args I guess made the box > > > > > > > > > > > > > > > not freeze before > > > > > > > > > > > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > > > > > > > > > > > [3.416319] software IO TLB: mapped [mem > > > > > > > > > > > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > > > > > > > > > > > [3.418227] Initialise system trusted keyrings > > > > > > > > > > > > > > > [3.432273] workingset: timestamp_bits=56 > > > > > > > > > > > > > > > max_order=22 bucket_order=0 > > > > > > > > > > > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > > > > > > > > > > > [3.443368] fuse: init (API version 7.38) > > > > > > > > > > > > > > > [3.447601] 9p: Installing v9fs 9p2000 file > > > > > > > > > > > > > > > system support > > > > > > > > > > > > &
[PATCH] drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
We can't simply free the connector after calling drm_connector_init on it.
We need to clean up the drm side first.
It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp:
PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it
fixes a memory corruption in error handling related to that commit.
Link:
https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/
Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index a2e0033e8a260..622f6eb9a8bfd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1408,8 +1408,7 @@ nouveau_connector_create(struct drm_device *dev,
ret = nvif_conn_ctor(>disp, nv_connector->base.name,
nv_connector->index,
_connector->conn);
if (ret) {
- kfree(nv_connector);
- return ERR_PTR(ret);
+ goto drm_conn_err;
}
ret = nvif_conn_event_ctor(_connector->conn, "kmsHotplug",
@@ -1426,8 +1425,7 @@ nouveau_connector_create(struct drm_device *dev,
if (ret) {
nvif_event_dtor(_connector->hpd);
nvif_conn_dtor(_connector->conn);
- kfree(nv_connector);
- return ERR_PTR(ret);
+ goto drm_conn_err;
}
}
}
@@ -1475,4 +1473,9 @@ nouveau_connector_create(struct drm_device *dev,
drm_connector_register(connector);
return connector;
+
+drm_conn_err:
+ drm_connector_cleanup(connector);
+ kfree(nv_connector);
+ return ERR_PTR(ret);
}
--
2.41.0
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Mon, Aug 14, 2023 at 3:35 PM Takashi Iwai wrote: > > On Mon, 14 Aug 2023 15:19:11 +0200, > Karol Herbst wrote: > > > > On Mon, Aug 14, 2023 at 2:56 PM Karol Herbst wrote: > > > > > > On Mon, Aug 14, 2023 at 2:48 PM Takashi Iwai wrote: > > > > > > > > On Mon, 14 Aug 2023 14:38:18 +0200, > > > > Karol Herbst wrote: > > > > > > > > > > On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote: > > > > > > > > > > > > On Wed, 09 Aug 2023 16:46:38 +0200, > > > > > > Takashi Iwai wrote: > > > > > > > > > > > > > > On Wed, 09 Aug 2023 15:13:23 +0200, > > > > > > > Takashi Iwai wrote: > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 14:19:23 +0200, > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 13:42:09 +0200, > > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol > > > > > > > > > > > > > > Herbst wrote: > > > > > > > > > > > > > > > in what way does it stop? Just not progressing? > > > > > > > > > > > > > > > That would be kinda > > > > > > > > > > > > > > > concerning. Mind tracing with what arguments > > > > > > > > > > > > > > > `nvkm_uevent_add` is > > > > > > > > > > > > > > > called with and without that patch? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, me dumping those args I guess made the box > > > > > > > > > > > > > > not freeze before > > > > > > > > > > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > > > > > > > > > > [3.416319] software IO TLB: mapped [mem > > > > > > > > > > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > > > > > > > > > > [3.418227] Initialise system trusted keyrings > > > > > > > > > > > > > > [3.432273] workingset: timestamp_bits=56 > > > > > > > > > > > > > > max_order=22 bucket_order=0 > > > > > > > > > > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > > > > > > > > > > [3.443368] fuse: init (API version 7.38) > > > > > > > > > > > > > > [3.447601] 9p: Installing v9fs 9p2000 file > > > > > > > > > > > > > > system support > > > > > > > > > > > > > > [3.453223] Key type asymmetric registered > > > > > > > > > > > > > > [3.457332] Asymmetric key parser 'x509' > > > > > > > > > > > > > > registered > > > > > > > > > > > > > > [3.462236] Block layer SCSI gene
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Tue, Aug 8, 2023 at 3:47 PM Borislav Petkov wrote:
>
> On Tue, Aug 08, 2023 at 12:39:32PM +0200, Karol Herbst wrote:
> > ahh, that would have been good to know :)
>
> Yeah, I didn't see it before - it would only freeze. Only after I added
> the printk you requested.
>
> > Mind figuring out what's exactly NULL inside nvif_object_mthd? Or
> > rather what line `nvif_object_mthd+0x136` belongs to, then it should
> > be easy to figure out what's wrong here.
>
> That looks like this:
>
> 816ddfee: e8 8d 04 4e 00 callq 81bbe480
> <__memcpy>
> 816ddff3: 41 8d 56 20 lea0x20(%r14),%edx
> 816ddff7: 49 8b 44 24 08 mov0x8(%r12),%rax
> 816ddffc: 83 fa 17cmp$0x17,%edx
> 816ddfff: 76 7d jbe816de07e
>
> 816de001: 49 39 c4cmp%rax,%r12
> 816de004: 74 45 je 816de04b
>
>
> <--- RIP points here.
>
> The 0x20 also fits the deref address: 0020.
>
> Which means %rax is 0. Yap.
>
> 816de006: 48 8b 78 20 mov0x20(%rax),%rdi
> 816de00a: 4c 89 64 24 10 mov%r12,0x10(%rsp)
> 816de00f: 48 8b 40 38 mov0x38(%rax),%rax
> 816de013: c6 44 24 06 ff movb $0xff,0x6(%rsp)
> 816de018: 31 c9 xor%ecx,%ecx
> 816de01a: 48 89 e6mov%rsp,%rsi
> 816de01d: 48 8b 40 28 mov0x28(%rax),%rax
> 816de021: e8 3a 0c 4f 00 callq 81bcec60
> <__x86_indirect_thunk_array>
>
>
> Now, the preprocessed asm version of nvif/object.c says around here:
>
>
> callmemcpy #
> # drivers/gpu/drm/nouveau/nvif/object.c:160:ret =
> nvif_object_ioctl(object, args, sizeof(*args) + size, NULL);
> leal32(%r14), %edx #, _108
> # drivers/gpu/drm/nouveau/nvif/object.c:33: struct nvif_client *client =
> object->client;
> movq8(%r12), %rax # object_19(D)->client, client
> # drivers/gpu/drm/nouveau/nvif/object.c:38: if (size >= sizeof(*args) &&
> args->v0.version == 0) {
> cmpl$23, %edx #, _108
> jbe .L69#,
> # drivers/gpu/drm/nouveau/nvif/object.c:39: if (object !=
> >object)
> cmpq%rax, %r12 # client, object
> je .L70#,
> # drivers/gpu/drm/nouveau/nvif/object.c:47: return
> client->driver->ioctl(client->object.priv, data, size, hack);
> movq32(%rax), %rdi # client_109->object.priv,
> client_109->object.priv
>
>
> So I'd say that client is NULL. IINM.
>
>
> movq%r12, 16(%rsp) # object, MEM[(union *)].v0.object
> # drivers/gpu/drm/nouveau/nvif/object.c:47: return
> client->driver->ioctl(client->object.priv, data, size, hack);
> movq56(%rax), %rax # client_109->driver, client_109->driver
> # drivers/gpu/drm/nouveau/nvif/object.c:43: args->v0.owner =
> NVIF_IOCTL_V0_OWNER_ANY;
> movb$-1, 6(%rsp)#, MEM[(union *)].v0.owner
> .L64:
> # drivers/gpu/drm/nouveau/nvif/object.c:47: return
> client->driver->ioctl(client->object.priv, data, size, hack);
> xorl%ecx, %ecx #
> movq%rsp, %rsi #,
> movq40(%rax), %rax #, _77->ioctl
> call__x86_indirect_thunk_rax
> # drivers/gpu/drm/nouveau/nvif/object.c:161:memcpy(data, args->mthd.data,
> size);
>
> > > [4.144676] #PF: supervisor read access in kernel mode
> > > [4.144676] #PF: error_code(0x) - not-present page
> > > [4.144676] PGD 0 P4D 0
> > > [4.144676] Oops: [#1] PREEMPT SMP PTI
> > > [4.144676] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc5-dirty
> > > #1
> > > [4.144676] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13
> > > 05/11/2014
> > > [4.144676] RIP: 0010:nvif_object_mthd+0x136/0x1e0
> > > [4.144676] Code: f2 4c 89 ee 48 8d 7c 24 20 66 89 04 24 c6 44 24 18
> > > 00 e8 8d 04 4e 00 41 8d 56 20 49 8b 44 24 08 83 fa 17 76 7d 49 39 c4 74
> > > 45 <48> 8b 78 20 4c 89 64 24 10 48 8b 40 38 c6 44 24 06 ff 31 c9 48 89
>
> Opcode bytes around RIP look correct too:
>
> ./scripts/decodecode < /tmp/oops
> [ 4.144676] Code: f2 4c 89 ee 48 8d 7c 24 20 66 89 04 24 c6 44 24 18 00 e8 8d
> 04 4e 00 41 8d 56 20 49 8b 44 24 08 83 fa 17 76 7d 49 39 c4
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Mon, Aug 14, 2023 at 2:56 PM Karol Herbst wrote: > > On Mon, Aug 14, 2023 at 2:48 PM Takashi Iwai wrote: > > > > On Mon, 14 Aug 2023 14:38:18 +0200, > > Karol Herbst wrote: > > > > > > On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote: > > > > > > > > On Wed, 09 Aug 2023 16:46:38 +0200, > > > > Takashi Iwai wrote: > > > > > > > > > > On Wed, 09 Aug 2023 15:13:23 +0200, > > > > > Takashi Iwai wrote: > > > > > > > > > > > > On Wed, 09 Aug 2023 14:19:23 +0200, > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote: > > > > > > > > > > > > > > > > On Wed, 09 Aug 2023 13:42:09 +0200, > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst > > > > > > > > > > > > wrote: > > > > > > > > > > > > > in what way does it stop? Just not progressing? That > > > > > > > > > > > > > would be kinda > > > > > > > > > > > > > concerning. Mind tracing with what arguments > > > > > > > > > > > > > `nvkm_uevent_add` is > > > > > > > > > > > > > called with and without that patch? > > > > > > > > > > > > > > > > > > > > > > > > Well, me dumping those args I guess made the box not > > > > > > > > > > > > freeze before > > > > > > > > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > > > > > > > > [3.416319] software IO TLB: mapped [mem > > > > > > > > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > > > > > > > > [3.418227] Initialise system trusted keyrings > > > > > > > > > > > > [3.432273] workingset: timestamp_bits=56 > > > > > > > > > > > > max_order=22 bucket_order=0 > > > > > > > > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > > > > > > > > [3.443368] fuse: init (API version 7.38) > > > > > > > > > > > > [3.447601] 9p: Installing v9fs 9p2000 file system > > > > > > > > > > > > support > > > > > > > > > > > > [3.453223] Key type asymmetric registered > > > > > > > > > > > > [3.457332] Asymmetric key parser 'x509' registered > > > > > > > > > > > > [3.462236] Block layer SCSI generic (bsg) driver > > > > > > > > > > > > version 0.4 loaded (major 250) > > > > > > > > > > > > [3.475865] efifb: probing for efifb > > > > > > > > > > > > [3.479458] efifb: framebuffer at 0xf900, using > > > > > > > > > > > > 1920k, total 1920k > > > > > > > > > > > > [3.485969] efifb: mode is 800x600x32, > > > > > > > > > > > > linelength=3200, pages=1 > > > > > > > > > > > > [3.491872] efifb: scrolling: redraw > > > > > > > > > > > > [3.495438] efifb: Truecolor: size=8:8:8:8, > > > > > > > >
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Mon, Aug 14, 2023 at 2:48 PM Takashi Iwai wrote: > > On Mon, 14 Aug 2023 14:38:18 +0200, > Karol Herbst wrote: > > > > On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote: > > > > > > On Wed, 09 Aug 2023 16:46:38 +0200, > > > Takashi Iwai wrote: > > > > > > > > On Wed, 09 Aug 2023 15:13:23 +0200, > > > > Takashi Iwai wrote: > > > > > > > > > > On Wed, 09 Aug 2023 14:19:23 +0200, > > > > > Karol Herbst wrote: > > > > > > > > > > > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote: > > > > > > > > > > > > > > On Wed, 09 Aug 2023 13:42:09 +0200, > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst > > > > > > > > > > > wrote: > > > > > > > > > > > > in what way does it stop? Just not progressing? That > > > > > > > > > > > > would be kinda > > > > > > > > > > > > concerning. Mind tracing with what arguments > > > > > > > > > > > > `nvkm_uevent_add` is > > > > > > > > > > > > called with and without that patch? > > > > > > > > > > > > > > > > > > > > > > Well, me dumping those args I guess made the box not > > > > > > > > > > > freeze before > > > > > > > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > > > > > > > [3.416319] software IO TLB: mapped [mem > > > > > > > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > > > > > > > [3.418227] Initialise system trusted keyrings > > > > > > > > > > > [3.432273] workingset: timestamp_bits=56 max_order=22 > > > > > > > > > > > bucket_order=0 > > > > > > > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > > > > > > > [3.443368] fuse: init (API version 7.38) > > > > > > > > > > > [3.447601] 9p: Installing v9fs 9p2000 file system > > > > > > > > > > > support > > > > > > > > > > > [3.453223] Key type asymmetric registered > > > > > > > > > > > [3.457332] Asymmetric key parser 'x509' registered > > > > > > > > > > > [3.462236] Block layer SCSI generic (bsg) driver > > > > > > > > > > > version 0.4 loaded (major 250) > > > > > > > > > > > [3.475865] efifb: probing for efifb > > > > > > > > > > > [3.479458] efifb: framebuffer at 0xf900, using > > > > > > > > > > > 1920k, total 1920k > > > > > > > > > > > [3.485969] efifb: mode is 800x600x32, > > > > > > > > > > > linelength=3200, pages=1 > > > > > > > > > > > [3.491872] efifb: scrolling: redraw > > > > > > > > > > > [3.495438] efifb: Truecolor: size=8:8:8:8, > > > > > > > > > > > shift=24:16:8:0 > > > > > > > > > > > [3.502349] Console: switching to colour frame buffer > > > > > > > > > > > device 100x37 > > > > > > > > > > > [3.509564] fb0: EFI VGA frame buffer device > > > > > > > > > > > [3.514013] ACPI: \_PR
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Wed, Aug 9, 2023 at 6:16 PM Takashi Iwai wrote: > > On Wed, 09 Aug 2023 16:46:38 +0200, > Takashi Iwai wrote: > > > > On Wed, 09 Aug 2023 15:13:23 +0200, > > Takashi Iwai wrote: > > > > > > On Wed, 09 Aug 2023 14:19:23 +0200, > > > Karol Herbst wrote: > > > > > > > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote: > > > > > > > > > > On Wed, 09 Aug 2023 13:42:09 +0200, > > > > > Karol Herbst wrote: > > > > > > > > > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote: > > > > > > > > > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > > > > > Karol Herbst wrote: > > > > > > > > > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote: > > > > > > > > > > in what way does it stop? Just not progressing? That would > > > > > > > > > > be kinda > > > > > > > > > > concerning. Mind tracing with what arguments > > > > > > > > > > `nvkm_uevent_add` is > > > > > > > > > > called with and without that patch? > > > > > > > > > > > > > > > > > > Well, me dumping those args I guess made the box not freeze > > > > > > > > > before > > > > > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > > > > > [3.416319] software IO TLB: mapped [mem > > > > > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > > > > > [3.418227] Initialise system trusted keyrings > > > > > > > > > [3.432273] workingset: timestamp_bits=56 max_order=22 > > > > > > > > > bucket_order=0 > > > > > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > > > > > [3.443368] fuse: init (API version 7.38) > > > > > > > > > [3.447601] 9p: Installing v9fs 9p2000 file system support > > > > > > > > > [3.453223] Key type asymmetric registered > > > > > > > > > [3.457332] Asymmetric key parser 'x509' registered > > > > > > > > > [3.462236] Block layer SCSI generic (bsg) driver version > > > > > > > > > 0.4 loaded (major 250) > > > > > > > > > [3.475865] efifb: probing for efifb > > > > > > > > > [3.479458] efifb: framebuffer at 0xf900, using 1920k, > > > > > > > > > total 1920k > > > > > > > > > [3.485969] efifb: mode is 800x600x32, linelength=3200, > > > > > > > > > pages=1 > > > > > > > > > [3.491872] efifb: scrolling: redraw > > > > > > > > > [3.495438] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > > > > > > > > [3.502349] Console: switching to colour frame buffer > > > > > > > > > device 100x37 > > > > > > > > > [3.509564] fb0: EFI VGA frame buffer device > > > > > > > > > [3.514013] ACPI: \_PR_.CP00: Found 4 idle states > > > > > > > > > [3.518850] ACPI: \_PR_.CP01: Found 4 idle states > > > > > > > > > [3.523687] ACPI: \_PR_.CP02: Found 4 idle states > > > > > > > > > [3.528515] ACPI: \_PR_.CP03: Found 4 idle states > > > > > > > > > [3.533346] ACPI: \_PR_.CP04: Found 4 idle states > > > > > > > > > [3.538173] ACPI: \_PR_.CP05: Found 4 idle states > > > > > > > > > [3.543003] ACPI: \_PR_.CP06: Found 4 idle states > > > > > > > > > [3.544219] Freeing initrd memory: 8196K > > > > > > > > > [3.547844] ACPI: \_PR_.CP07: Found 4 idle states > > > > > > > > > [3.609542] Serial: 8250/16550 driver, 4 ports, IRQ > > > > > > >
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Wed, Aug 9, 2023 at 8:28 PM Karol Herbst wrote: > > On Wed, Aug 9, 2023 at 4:04 PM Thorsten Leemhuis > wrote: > > > > On 09.08.23 15:13, Takashi Iwai wrote: > > > > > > If this can't be fixed quickly, I suppose it's safer to revert it from > > > 6.4.y for now. 6.5 is still being cooked, but 6.4.x is already in > > > wide deployment, hence the regression has to be addressed quickly. > > > > feel free to send reverts to mainline and add my r-by tage to it and I > can push those changes up. Sadly those patches fixed another > use-after-free, but it seems like we have to take another shot unless > somebody does have time to look into it promptly. > uhm and the two patches around that one, 752a281032b2d6f4564be827e082bde6f7d2fd4fand ea293f823a8805735d9e00124df81a8f448ed1ae > > Good luck with that. To quote > > https://docs.kernel.org/process/handling-regressions.html : > > > > ``` > > Regarding stable and longterm kernels: > > > > [...] > > > > * Whenever you want to swiftly resolve a regression that recently also > > made it into a proper mainline, stable, or longterm release, fix it > > quickly in mainline; when appropriate thus involve Linus to fast-track > > the fix (see above). That's because the stable team normally does > > neither revert nor fix any changes that cause the same problems in mainline. > > ``` > > > > Note the "normally" in there, so there is a chance. > > > > Ciao, Thorsten > >
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Wed, Aug 9, 2023 at 4:04 PM Thorsten Leemhuis wrote: > > On 09.08.23 15:13, Takashi Iwai wrote: > > > > If this can't be fixed quickly, I suppose it's safer to revert it from > > 6.4.y for now. 6.5 is still being cooked, but 6.4.x is already in > > wide deployment, hence the regression has to be addressed quickly. > feel free to send reverts to mainline and add my r-by tage to it and I can push those changes up. Sadly those patches fixed another use-after-free, but it seems like we have to take another shot unless somebody does have time to look into it promptly. > Good luck with that. To quote > https://docs.kernel.org/process/handling-regressions.html : > > ``` > Regarding stable and longterm kernels: > > [...] > > * Whenever you want to swiftly resolve a regression that recently also > made it into a proper mainline, stable, or longterm release, fix it > quickly in mainline; when appropriate thus involve Linus to fast-track > the fix (see above). That's because the stable team normally does > neither revert nor fix any changes that cause the same problems in mainline. > ``` > > Note the "normally" in there, so there is a chance. > > Ciao, Thorsten >
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote: > > On Wed, 09 Aug 2023 13:42:09 +0200, > Karol Herbst wrote: > > > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote: > > > > > > On Tue, 08 Aug 2023 12:39:32 +0200, > > > Karol Herbst wrote: > > > > > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov wrote: > > > > > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote: > > > > > > in what way does it stop? Just not progressing? That would be kinda > > > > > > concerning. Mind tracing with what arguments `nvkm_uevent_add` is > > > > > > called with and without that patch? > > > > > > > > > > Well, me dumping those args I guess made the box not freeze before > > > > > catching a #PF over serial. Does that help? > > > > > > > > > > > > > > > [3.410135] Unpacking initramfs... > > > > > [3.416319] software IO TLB: mapped [mem > > > > > 0xa877d000-0xac77d000] (64MB) > > > > > [3.418227] Initialise system trusted keyrings > > > > > [3.432273] workingset: timestamp_bits=56 max_order=22 > > > > > bucket_order=0 > > > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > > > [3.443368] fuse: init (API version 7.38) > > > > > [3.447601] 9p: Installing v9fs 9p2000 file system support > > > > > [3.453223] Key type asymmetric registered > > > > > [3.457332] Asymmetric key parser 'x509' registered > > > > > [3.462236] Block layer SCSI generic (bsg) driver version 0.4 > > > > > loaded (major 250) > > > > > [3.475865] efifb: probing for efifb > > > > > [3.479458] efifb: framebuffer at 0xf900, using 1920k, total > > > > > 1920k > > > > > [3.485969] efifb: mode is 800x600x32, linelength=3200, pages=1 > > > > > [3.491872] efifb: scrolling: redraw > > > > > [3.495438] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > > > > [3.502349] Console: switching to colour frame buffer device 100x37 > > > > > [3.509564] fb0: EFI VGA frame buffer device > > > > > [3.514013] ACPI: \_PR_.CP00: Found 4 idle states > > > > > [3.518850] ACPI: \_PR_.CP01: Found 4 idle states > > > > > [3.523687] ACPI: \_PR_.CP02: Found 4 idle states > > > > > [3.528515] ACPI: \_PR_.CP03: Found 4 idle states > > > > > [3.533346] ACPI: \_PR_.CP04: Found 4 idle states > > > > > [3.538173] ACPI: \_PR_.CP05: Found 4 idle states > > > > > [3.543003] ACPI: \_PR_.CP06: Found 4 idle states > > > > > [3.544219] Freeing initrd memory: 8196K > > > > > [3.547844] ACPI: \_PR_.CP07: Found 4 idle states > > > > > [3.609542] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > > > > > [3.616224] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = > > > > > 115200) is a 16550A > > > > > [3.625552] serial :00:16.3: enabling device ( -> 0003) > > > > > [3.633034] :00:16.3: ttyS1 at I/O 0xf0a0 (irq = 17, base_baud > > > > > = 115200) is a 16550A > > > > > [3.642451] Linux agpgart interface v0.103 > > > > > [3.647141] ACPI: bus type drm_connector registered > > > > > [3.653261] Console: switching to colour dummy device 80x25 > > > > > [3.659092] nouveau :03:00.0: vgaarb: deactivate vga console > > > > > [3.665174] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > > > > > [3.784585] nouveau :03:00.0: bios: version 70.18.83.00.08 > > > > > [3.792244] nouveau :03:00.0: fb: 512 MiB DDR3 > > > > > [3.948786] nouveau :03:00.0: DRM: VRAM: 512 MiB > > > > > [3.953755] nouveau :03:00.0: DRM: GART: 1048576 MiB > > > > > [3.959073] nouveau :03:00.0: DRM: TMDS table version 2.0 > > > > > [3.964808] nouveau :03:00.0: DRM: DCB version 4.0 > > > > > [3.969938] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > > > > > > > > > > [3.976367] nouveau :03:00.0: DRM: DCB outp 01: 02000362 > > > > > 00020010 > > > > > [3.982792] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 > > >
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote: > > On Tue, 08 Aug 2023 12:39:32 +0200, > Karol Herbst wrote: > > > > On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov wrote: > > > > > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote: > > > > in what way does it stop? Just not progressing? That would be kinda > > > > concerning. Mind tracing with what arguments `nvkm_uevent_add` is > > > > called with and without that patch? > > > > > > Well, me dumping those args I guess made the box not freeze before > > > catching a #PF over serial. Does that help? > > > > > > > > > [3.410135] Unpacking initramfs... > > > [3.416319] software IO TLB: mapped [mem > > > 0xa877d000-0xac77d000] (64MB) > > > [3.418227] Initialise system trusted keyrings > > > [3.432273] workingset: timestamp_bits=56 max_order=22 bucket_order=0 > > > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > > > [3.443368] fuse: init (API version 7.38) > > > [3.447601] 9p: Installing v9fs 9p2000 file system support > > > [3.453223] Key type asymmetric registered > > > [3.457332] Asymmetric key parser 'x509' registered > > > [3.462236] Block layer SCSI generic (bsg) driver version 0.4 loaded > > > (major 250) > > > [3.475865] efifb: probing for efifb > > > [3.479458] efifb: framebuffer at 0xf900, using 1920k, total 1920k > > > [3.485969] efifb: mode is 800x600x32, linelength=3200, pages=1 > > > [3.491872] efifb: scrolling: redraw > > > [3.495438] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > > [3.502349] Console: switching to colour frame buffer device 100x37 > > > [3.509564] fb0: EFI VGA frame buffer device > > > [3.514013] ACPI: \_PR_.CP00: Found 4 idle states > > > [3.518850] ACPI: \_PR_.CP01: Found 4 idle states > > > [3.523687] ACPI: \_PR_.CP02: Found 4 idle states > > > [3.528515] ACPI: \_PR_.CP03: Found 4 idle states > > > [3.533346] ACPI: \_PR_.CP04: Found 4 idle states > > > [3.538173] ACPI: \_PR_.CP05: Found 4 idle states > > > [3.543003] ACPI: \_PR_.CP06: Found 4 idle states > > > [3.544219] Freeing initrd memory: 8196K > > > [3.547844] ACPI: \_PR_.CP07: Found 4 idle states > > > [3.609542] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > > > [3.616224] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is > > > a 16550A > > > [3.625552] serial :00:16.3: enabling device ( -> 0003) > > > [3.633034] :00:16.3: ttyS1 at I/O 0xf0a0 (irq = 17, base_baud = > > > 115200) is a 16550A > > > [3.642451] Linux agpgart interface v0.103 > > > [3.647141] ACPI: bus type drm_connector registered > > > [3.653261] Console: switching to colour dummy device 80x25 > > > [3.659092] nouveau :03:00.0: vgaarb: deactivate vga console > > > [3.665174] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > > > [3.784585] nouveau :03:00.0: bios: version 70.18.83.00.08 > > > [3.792244] nouveau :03:00.0: fb: 512 MiB DDR3 > > > [3.948786] nouveau :03:00.0: DRM: VRAM: 512 MiB > > > [3.953755] nouveau :03:00.0: DRM: GART: 1048576 MiB > > > [3.959073] nouveau :03:00.0: DRM: TMDS table version 2.0 > > > [3.964808] nouveau :03:00.0: DRM: DCB version 4.0 > > > [3.969938] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > > > [3.976367] nouveau :03:00.0: DRM: DCB outp 01: 02000362 00020010 > > > [3.982792] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 0f220010 > > > [3.989223] nouveau :03:00.0: DRM: DCB outp 03: 01011380 > > > [3.995647] nouveau :03:00.0: DRM: DCB outp 04: 08011382 00020010 > > > [4.002076] nouveau :03:00.0: DRM: DCB outp 05: 088113c6 0f220010 > > > [4.008511] nouveau :03:00.0: DRM: DCB conn 00: 00101064 > > > [4.014151] nouveau :03:00.0: DRM: DCB conn 01: 00202165 > > > [4.021710] nvkm_uevent_add: uevent: 0x888100242100, event: > > > 0x8881022de1a0, id: 0x0, bits: 0x1, func: 0x > > > [4.033680] nvkm_uevent_add: uevent: 0x888100242300, event: > > > 0x8881022de1a0, id: 0x0, bits: 0x1, func: 0x > > > [4.045429] nouveau :03:00.0: DRM: MM: using COPY for buffer copies > > > [4.052059] stackdepot: allocating hash table of 10
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Mon, Aug 7, 2023 at 5:05 PM Borislav Petkov wrote: > > On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote: > > in what way does it stop? Just not progressing? That would be kinda > > concerning. Mind tracing with what arguments `nvkm_uevent_add` is > > called with and without that patch? > > Well, me dumping those args I guess made the box not freeze before > catching a #PF over serial. Does that help? > > > [3.410135] Unpacking initramfs... > [3.416319] software IO TLB: mapped [mem > 0xa877d000-0xac77d000] (64MB) > [3.418227] Initialise system trusted keyrings > [3.432273] workingset: timestamp_bits=56 max_order=22 bucket_order=0 > [3.439006] ntfs: driver 2.1.32 [Flags: R/W]. > [3.443368] fuse: init (API version 7.38) > [3.447601] 9p: Installing v9fs 9p2000 file system support > [3.453223] Key type asymmetric registered > [3.457332] Asymmetric key parser 'x509' registered > [3.462236] Block layer SCSI generic (bsg) driver version 0.4 loaded > (major 250) > [3.475865] efifb: probing for efifb > [3.479458] efifb: framebuffer at 0xf900, using 1920k, total 1920k > [3.485969] efifb: mode is 800x600x32, linelength=3200, pages=1 > [3.491872] efifb: scrolling: redraw > [3.495438] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > [3.502349] Console: switching to colour frame buffer device 100x37 > [3.509564] fb0: EFI VGA frame buffer device > [3.514013] ACPI: \_PR_.CP00: Found 4 idle states > [3.518850] ACPI: \_PR_.CP01: Found 4 idle states > [3.523687] ACPI: \_PR_.CP02: Found 4 idle states > [3.528515] ACPI: \_PR_.CP03: Found 4 idle states > [3.533346] ACPI: \_PR_.CP04: Found 4 idle states > [3.538173] ACPI: \_PR_.CP05: Found 4 idle states > [3.543003] ACPI: \_PR_.CP06: Found 4 idle states > [3.544219] Freeing initrd memory: 8196K > [3.547844] ACPI: \_PR_.CP07: Found 4 idle states > [3.609542] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [3.616224] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [3.625552] serial :00:16.3: enabling device ( -> 0003) > [3.633034] :00:16.3: ttyS1 at I/O 0xf0a0 (irq = 17, base_baud = > 115200) is a 16550A > [3.642451] Linux agpgart interface v0.103 > [3.647141] ACPI: bus type drm_connector registered > [3.653261] Console: switching to colour dummy device 80x25 > [3.659092] nouveau :03:00.0: vgaarb: deactivate vga console > [3.665174] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > [3.784585] nouveau :03:00.0: bios: version 70.18.83.00.08 > [3.792244] nouveau :03:00.0: fb: 512 MiB DDR3 > [3.948786] nouveau :03:00.0: DRM: VRAM: 512 MiB > [3.953755] nouveau :03:00.0: DRM: GART: 1048576 MiB > [3.959073] nouveau :03:00.0: DRM: TMDS table version 2.0 > [3.964808] nouveau :03:00.0: DRM: DCB version 4.0 > [3.969938] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > [3.976367] nouveau :03:00.0: DRM: DCB outp 01: 02000362 00020010 > [3.982792] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 0f220010 > [3.989223] nouveau :03:00.0: DRM: DCB outp 03: 01011380 > [3.995647] nouveau :03:00.0: DRM: DCB outp 04: 08011382 00020010 > [4.002076] nouveau :03:00.0: DRM: DCB outp 05: 088113c6 0f220010 > [4.008511] nouveau :03:00.0: DRM: DCB conn 00: 00101064 > [4.014151] nouveau :03:00.0: DRM: DCB conn 01: 00202165 > [4.021710] nvkm_uevent_add: uevent: 0x888100242100, event: > 0x8881022de1a0, id: 0x0, bits: 0x1, func: 0x > [4.033680] nvkm_uevent_add: uevent: 0x888100242300, event: > 0x8881022de1a0, id: 0x0, bits: 0x1, func: 0x > [4.045429] nouveau :03:00.0: DRM: MM: using COPY for buffer copies > [4.052059] stackdepot: allocating hash table of 1048576 entries via > kvcalloc > [4.067191] nvkm_uevent_add: uevent: 0x888100242800, event: > 0x888104b3e260, id: 0x0, bits: 0x1, func: 0x > [4.078936] nvkm_uevent_add: uevent: 0x888100242900, event: > 0x888104b3e260, id: 0x1, bits: 0x1, func: 0x > [4.090514] nvkm_uevent_add: uevent: 0x888100242a00, event: > 0x888102091f28, id: 0x1, bits: 0x3, func: 0x8177b700 > [4.102118] tsc: Refined TSC clocksource calibration: 3591.345 MHz > [4.108342] clocksource: tsc: mask: 0x max_cycles: > 0x33c4635c383, max_idle_ns: 440795314831 ns > [4.108401] nvkm_uevent_add: uevent: 0x8881020b6000, event: > 0x888102091f28, id: 0xf, bits: 0x3, func: 0x8177b700 > [4.129864] clocksource:
Re: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts")
On Sun, Aug 6, 2023 at 11:40 PM Borislav Petkov wrote: > > Hi folks, > > the patch in $Subject breaks booting here on one of my test boxes, see > below. > > Reverting it ontop of -rc4 fixes the issue. > > Thx. > > [3.580535] ACPI: \_PR_.CP04: Found 4 idle states > [3.585694] ACPI: \_PR_.CP05: Found 4 idle states > [3.590852] ACPI: \_PR_.CP06: Found 4 idle states > [3.596037] ACPI: \_PR_.CP07: Found 4 idle states > [3.644065] Freeing initrd memory: 6740K > [3.742932] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [3.750409] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [3.762111] serial :00:16.3: enabling device ( -> 0003) > [3.771589] :00:16.3: ttyS1 at I/O 0xf0a0 (irq = 17, base_baud = > 115200) is a 16550A > [3.782503] Linux agpgart interface v0.103 > [3.787805] ACPI: bus type drm_connector registered > > <--- boot stops here. > in what way does it stop? Just not progressing? That would be kinda concerning. Mind tracing with what arguments `nvkm_uevent_add` is called with and without that patch? Also a boot log with `nouveau.debug=trace` might be helpful here. > It should continue with this: > > [3.795491] Console: switching to colour dummy device 80x25 > [3.801933] nouveau :03:00.0: vgaarb: deactivate vga console > [3.808303] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > [3.931002] nouveau :03:00.0: bios: version 70.18.83.00.08 > [3.941731] nouveau :03:00.0: fb: 512 MiB DDR3 > [4.110348] tsc: Refined TSC clocksource calibration: 3591.349 MHz > [4.116627] clocksource: tsc: mask: 0x max_cycles: > 0x33c466a1ab5, max_idle_ns: 440795209767 ns > [4.126871] clocksource: Switched to clocksource tsc > [4.252013] nouveau :03:00.0: DRM: VRAM: 512 MiB > [4.257088] nouveau :03:00.0: DRM: GART: 1048576 MiB > [4.262501] nouveau :03:00.0: DRM: TMDS table version 2.0 > [4.268333] nouveau :03:00.0: DRM: DCB version 4.0 > [4.273561] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > [4.280104] nouveau :03:00.0: DRM: DCB outp 01: 02000362 00020010 > [4.286630] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 0f220010 > [4.293176] nouveau :03:00.0: DRM: DCB outp 03: 01011380 > [4.299711] nouveau :03:00.0: DRM: DCB outp 04: 08011382 00020010 > [4.306243] nouveau :03:00.0: DRM: DCB outp 05: 088113c6 0f220010 > [4.312772] nouveau :03:00.0: DRM: DCB conn 00: 00101064 > [4.318520] nouveau :03:00.0: DRM: DCB conn 01: 00202165 > [4.329488] nouveau :03:00.0: DRM: MM: using COPY for buffer copies > [4.336261] stackdepot: allocating hash table of 1048576 entries via > kvcalloc > ... > > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >
Re: [PATCH drm-misc-next] nouveau/dmem: fix copy-paste error in nouveau_dmem_migrate_chunk()
On Sat, Aug 5, 2023 at 6:00 PM Danilo Krummrich wrote:
>
> Fix call to nouveau_fence_emit() with wrong channel parameter.
>
> Fixes: 7f2a0b50b2b2 ("drm/nouveau: fence: separate fence alloc and emit")
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> index 4ad40e42cae1..61e84562094a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -678,7 +678,7 @@ static void nouveau_dmem_migrate_chunk(struct nouveau_drm
> *drm,
> }
>
> if (!nouveau_fence_new())
> - nouveau_fence_emit(fence, chunk->drm->dmem->migrate.chan);
> + nouveau_fence_emit(fence, drm->dmem->migrate.chan);
> migrate_vma_pages(args);
> nouveau_dmem_fence_done();
> nouveau_pfns_map(svmm, args->vma->vm_mm, args->start, pfns, i);
>
> base-commit: 82d750e9d2f5d0594c8f7057ce59127e701af781
> --
> 2.41.0
>
Reviewed-by: Karol Herbst
[PATCH] drm/nouveau/disp: Revert a NULL check inside nouveau_connector_get_modes
The original commit adding that check tried to protect the kenrel against
a potential invalid NULL pointer access.
However we call nouveau_connector_detect_depth once without a native_mode
set on purpose for non LVDS connectors and this broke DP support in a few
cases.
Cc: Olaf Skibbe
Cc: Lyude Paul
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/238
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/245
Fixes: 20a2ce87fbaf8 ("drm/nouveau/dp: check for NULL
nv_connector->native_mode")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index f75c6f09dd2af..a2e0033e8a260 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -967,7 +967,7 @@ nouveau_connector_get_modes(struct drm_connector *connector)
/* Determine display colour depth for everything except LVDS now,
* DP requires this before mode_valid() is called.
*/
- if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
nv_connector->native_mode)
+ if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS)
nouveau_connector_detect_depth(connector);
/* Find the native mode if this is a digital panel, if we didn't
--
2.41.0
Re: nouveau bug in linux/6.1.38-2
On Fri, Aug 4, 2023 at 8:10 PM Olaf Skibbe wrote: > > Dear all, > > On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote: > > >>> 62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL > >>> fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode > >>> 90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device > >>> 5a144bad3e75 nouveau: fix client work fence deletion race > > > > mind retrying with only fb725beca62d and 62aecf23f3d1 reverted? Would > > be weird if the other two commits are causing it. If that's the case, > > it's a bit worrying that reverting either of the those causes issues, > > but maybe there is a good reason for it. Anyway, mind figuring out > > which of the two you need reverted to fix your issue? Thanks! > > The result is: > > Patch with commit fb725beca62d reverted: Graphics works. I attached the > respective patch again to this mail. > Mind checking if instead of reverting the entire commit that this is enough to fix it as well? https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/f99ae069876f7ffeb6368da0381485e8c3adda43.patch > Patch with commit 62aecf23f3d1 reverted: Screen remains black, error > message: > > # dmesg | grep -A 36 "cut here" > [2.921358] [ cut here ] > [2.921361] WARNING: CPU: 1 PID: 176 at > drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490 > [nouveau] > [2.921627] Modules linked in: sd_mod(E) t10_pi(E) crc64_rocksoft(E) > sr_mod(E) crc64(E) crc_t10dif(E) crct10dif_generic(E) cdrom(E) nouveau(E+) > mxm_wmi(E) i2c_algo_bit(E) drm_display_helper(E) cec(E) ahci(E) rc_core(E) > drm_ttm_helper(E) libahci(E) ttm(E) ehci_pci(E) crct10dif_pclmul(E) > crct10dif_common(E) ehci_hcd(E) drm_kms_helper(E) crc32_pclmul(E) > firewire_ohci(E) sdhci_pci(E) cqhci(E) libata(E) e1000e(E) sdhci(E) > psmouse(E) crc32c_intel(E) lpc_ich(E) ptp(E) i2c_i801(E) scsi_mod(E) > i2c_smbus(E) firewire_core(E) scsi_common(E) usbcore(E) crc_itu_t(E) > mmc_core(E) drm(E) pps_core(E) usb_common(E) battery(E) video(E) wmi(E) > button(E) > [2.921695] CPU: 1 PID: 176 Comm: kworker/u16:5 Tainted: GE > 6.1.0-0.a.test-amd64 #1 Debian 6.1.38-2a~test > [2.921701] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17 > 05/12/2017 > [2.921705] Workqueue: nvkm-disp nv50_disp_super [nouveau] > [2.921948] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922192] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 > 00 48 83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b > c1 e8 03 41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26 > [2.922196] RSP: 0018:c077c04dfd60 EFLAGS: 00010246 > [2.922201] RAX: 00041eb0 RBX: 9a8482624c00 RCX: > 00041eb0 > [2.922204] RDX: c0b47760 RSI: RDI: > c077c04dfcf0 > [2.922206] RBP: 0001 R08: c077c04dfc64 R09: > 5b76 > [2.922209] R10: 000d R11: c077c04dfde0 R12: > ffea > [2.922212] R13: 9a8517541e00 R14: 00044d45 R15: > > [2.922215] FS: () GS:9a85a3c4() > knlGS: > [2.922219] CS: 0010 DS: ES: CR0: 80050033 > [2.92] CR2: 55f660bcb3a8 CR3: 00019761 CR4: > 06e0 > [2.96] Call Trace: > [2.922231] > [2.922235] ? __warn+0x7d/0xc0 > [2.922244] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922487] ? report_bug+0xe6/0x170 > [2.922494] ? handle_bug+0x41/0x70 > [2.922501] ? exc_invalid_op+0x13/0x60 > [2.922505] ? asm_exc_invalid_op+0x16/0x20 > [2.922512] ? init_reset_begun+0x20/0x20 [nouveau] > [2.922708] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922954] nv50_disp_super_2_2+0x70/0x430 [nouveau] > [2.923200] nv50_disp_super+0x113/0x210 [nouveau] > [2.923445] process_one_work+0x1c7/0x380 > [2.923456] worker_thread+0x4d/0x380 > [2.923463] ? rescuer_thread+0x3a0/0x3a0 > [2.923469] kthread+0xe9/0x110 > [2.923476] ? kthread_complete_and_exit+0x20/0x20 > [2.923482] ret_from_fork+0x22/0x30 > [2.923493] > [2.923494] ---[ end trace ]--- > > (Maybe it's worth to mention that the LED back-light is on, while the > screen appears black.) > > Cheers, > Olaf > > P.S.: By the way: as a linux user for more than 20 years, I am very > pleased to have the opportunity to contribute at least a little bit to > the improvement. I'd like to use the chance to thank you all very much > for building and developing this great operating system.
Re: nouveau bug in linux/6.1.38-2
On Fri, Aug 4, 2023 at 2:48 PM Olaf Skibbe wrote: > > On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote: > > > mind retrying with only fb725beca62d and 62aecf23f3d1 reverted? > > I will do this later this day (takes some time, it is a slow machine). > > > Would be weird if the other two commits are causing it. If that's the > > case, it's a bit worrying that reverting either of the those causes > > issues, but maybe there is a good reason for it. Anyway, mind figuring > > out which of the two you need reverted to fix your issue? Thanks! > > I can do this. But if I build two kernels anyway, isn't it faster to > build each with only one of the patches applied? Or do you expect the > patches to interact (so that the bug would only be present when both are > applied)? > How are you building the kernel? Because normally from git reverting one of those shouldn't take long, because it doesn't recompile the entire kernel. But yeah, you can potentially just revert one of one for now and it should be fine. > Cheers, > Olaf >
Re: nouveau bug in linux/6.1.38-2
On Fri, Aug 4, 2023 at 2:02 PM Thorsten Leemhuis
wrote:
>
> Hi!
>
> On 02.08.23 23:28, Olaf Skibbe wrote:
> > Dear Maintainers,
> >
> > Hereby I would like to report an apparent bug in the nouveau driver in
> > linux/6.1.38-2.
>
> Thx for your report. Maybe your problem is caused by a incomplete
> backport. I Cced the maintainers for the drivers (and the regressions
> and the stable list), maybe one of them has an idea, as they know the
> driver.
>
> If they don't reply in the next few days, please check if the problem is
> also present in mainline. If not, check if the latest 6.1.y. release
> already fixes this. If not, try to check which of the four patches you
> reverted to make things going is actually causing this (e.g. first only
> revert the one that was applied last; then the two last ones; ...).
>
> > Running a current debian stable on a Dell Latitude E6510 with a
> > "NVIDIA Corporation GT218M" graphic card, the monitor turns black
> > after the grub screen. Also switching to a console (Strg-Alt-F2) shows
> > just a black screen. Access via ssh is possible.
> >
> > ~# uname -r
> > 6.1.0-10-amd64
> >
> > demesg shows the following error message:
> >
> > [3.560153] WARNING: CPU: 0 PID: 176 at
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460
> > nvkm_dp_acquire+0x26a/0x490 [nouveau]
> > [3.560287] Modules linked in: sd_mod t10_pi sr_mod crc64_rocksoft
> > cdrom crc64 crc_t10dif crct10dif_generic nouveau(+) ahci libahci mxm_wmi
> > i2c_algo_bit drm_display_helper libata cec rc_core drm_ttm_helper ttm
> > scsi_mod e1000e drm_kms_helper ptp firewire_ohci sdhci_pci cqhci
> > ehci_pci sdhci ehci_hcd firewire_core i2c_i801 crct10dif_pclmul
> > crct10dif_common drm crc32_pclmul crc32c_intel psmouse usbcore mmc_core
> > crc_itu_t pps_core scsi_common i2c_smbus lpc_ich usb_common battery
> > video wmi button
> > [3.560322] CPU: 0 PID: 176 Comm: kworker/u16:5 Not tainted
> > 6.1.0-10-amd64 #1 Debian 6.1.38-2
> > [3.560325] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17
> > 05/12/2017
> > [3.560327] Workqueue: nvkm-disp nv50_disp_super [nouveau]
> > [3.560433] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau]
> > [3.560538] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37
> > 02 00 00 48 83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc
> > cc <0f> 0b c1 e8 03 41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26
> > [3.560541] RSP: 0018:9899c048bd60 EFLAGS: 00010246
> > [3.560542] RAX: 00041eb0 RBX: 88e0209d2600 RCX:
> > 00041eb0
> > [3.560544] RDX: c079f760 RSI: RDI:
> > 9899c048bcf0
> > [3.560545] RBP: 0001 R08: 9899c048bc64 R09:
> > 5b76
> > [3.560546] R10: 000d R11: 9899c048bde0 R12:
> > ffea
> > [3.560548] R13: 88e00b39e480 R14: 00044d45 R15:
> >
> > [3.560549] FS: () GS:88e123c0()
> > knlGS:
> > [3.560551] CS: 0010 DS: ES: CR0: 80050033
> > [3.560552] CR2: 7f57f4e90451 CR3: 00018141 CR4:
> > 06f0
> > [3.560554] Call Trace:
> > [3.560558]
> > [3.560560] ? __warn+0x7d/0xc0
> > [3.560566] ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
> > [3.560671] ? report_bug+0xe6/0x170
> > [3.560675] ? handle_bug+0x41/0x70
> > [3.560679] ? exc_invalid_op+0x13/0x60
> > [3.560681] ? asm_exc_invalid_op+0x16/0x20
> > [3.560685] ? init_reset_begun+0x20/0x20 [nouveau]
> > [3.560769] ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
> > [3.560888] nv50_disp_super_2_2+0x70/0x430 [nouveau]
> > [3.560997] nv50_disp_super+0x113/0x210 [nouveau]
> > [3.561103] process_one_work+0x1c7/0x380
> > [3.561109] worker_thread+0x4d/0x380
> > [3.561113] ? rescuer_thread+0x3a0/0x3a0
> > [3.561116] kthread+0xe9/0x110
> > [3.561120] ? kthread_complete_and_exit+0x20/0x20
> > [3.561122] ret_from_fork+0x22/0x30
> > [3.561130]
> >
> > Further information:
> >
> > $ lspci -v -s $(lspci | grep -i vga | awk '{ print $1 }')
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M]
> > (rev a2) (prog-if 00 [VGA controller])
> > Subsystem: Dell Latitude E6510
> > Flags: bus master, fast devsel, latency 0, IRQ 27
> > Memory at e200 (32-bit, non-prefetchable) [size=16M]
> > Memory at d000 (64-bit, prefetchable) [size=256M]
> > Memory at e000 (64-bit, prefetchable) [size=32M]
> > I/O ports at 7000 [size=128]
> > Expansion ROM at 000c [disabled] [size=128K]
> > Capabilities:
> > Kernel driver in use: nouveau
> > Kernel modules: nouveau
> >
> > I reported this bug to debian already, see
> > https://bugs.debian.org/1042753 for context.
> >
> > With support (thanks Diederik!) I managed to figure out that the cause
> > was a regression between upstream kernel version 6.1.27 and 6.1.38.
> >
>
Re: [PATCH] [RESEND] drm/nouveau: remove unused tu102_gr_load() function
On Thu, Aug 3, 2023 at 4:34 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> tu102_gr_load() is completely unused and can be removed to address
> this warning:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
> for 'nv50_display_create'
>
> Another patch was sent in the meantime to mark the function static but
> that would just cause a different warning about an unused function.
>
> Fixes: 1cd97b5490c8 ("drm/nouveau/gr/tu102-: use sw_veid_bundle_init from
> firmware")
> Link:
> https://lore.kernel.org/all/caco55tuanoyphhyb9+ygi9anxvuf49etsw7x2x5k5ietfna...@mail.gmail.com/
> Link: https://lore.kernel.org/all/20230417210310.2443152-1-a...@kernel.org/
> Signed-off-by: Arnd Bergmann
> ---
> I send this one back in April, and Lee Jones sent a similar patch in May.
> Please apply so we can enable the warning by default.
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> index 3b6c8100a242..a7775aa18541 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> @@ -206,19 +206,6 @@ tu102_gr_av_to_init_veid(struct nvkm_blob *blob, struct
> gf100_gr_pack **ppack)
> return gk20a_gr_av_to_init_(blob, 64, 0x0010, ppack);
> }
>
> -int
> -tu102_gr_load(struct gf100_gr *gr, int ver, const struct gf100_gr_fwif *fwif)
> -{
> - int ret;
> -
> - ret = gm200_gr_load(gr, ver, fwif);
> - if (ret)
> - return ret;
> -
> - return gk20a_gr_load_net(gr, "gr/", "sw_veid_bundle_init", ver,
> tu102_gr_av_to_init_veid,
> ->bundle_veid);
> -}
> -
> static const struct gf100_gr_fwif
> tu102_gr_fwif[] = {
> { 0, gm200_gr_load, _gr, _gr_fecs_acr,
> _gr_gpccs_acr },
> --
> 2.39.2
>
Reviewed-by: Karol Herbst
Will push to drm-misc in a sec
Re: [PATCH] drm/nouveau: fixup the uapi header file.
On Tue, Aug 1, 2023 at 5:15 PM Faith Ekstrand wrote:
> On Tue, Aug 1, 2023 at 4:37 AM Karol Herbst wrote:
>
>> On Mon, Jul 31, 2023 at 9:16 PM Dave Airlie wrote:
>> >
>> > From: Dave Airlie
>> >
>> > nouveau > 10 years ago had a plan for new multiplexer inside a
>> multiplexer
>> > API using nvif. It never fully reached fruition, fast forward 10 years,
>> > and the new vulkan driver is avoiding libdrm and calling ioctls, and
>> > these 3 ioctls, getparam, channel alloc + free don't seem to be things
>> > we'd want to use nvif for.
>> >
>> > Undeprecate and put them into the uapi header so we can just copy it
>> > into mesa later.
>> >
>> > Signed-off-by: Dave Airlie
>> > ---
>> > drivers/gpu/drm/nouveau/nouveau_abi16.h | 41 -
>> > include/uapi/drm/nouveau_drm.h | 48 +++--
>> > 2 files changed, 45 insertions(+), 44 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
>> b/drivers/gpu/drm/nouveau/nouveau_abi16.h
>> > index 27eae85f33e6..d5d80d0d9011 100644
>> > --- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
>> > +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
>> > @@ -43,28 +43,6 @@ int nouveau_abi16_usif(struct drm_file *, void
>> *data, u32 size);
>> > #define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
>> > #define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
>> >
>> > -struct drm_nouveau_channel_alloc {
>> > - uint32_t fb_ctxdma_handle;
>> > - uint32_t tt_ctxdma_handle;
>> > -
>> > - int channel;
>> > - uint32_t pushbuf_domains;
>> > -
>> > - /* Notifier memory */
>> > - uint32_t notifier_handle;
>> > -
>> > - /* DRM-enforced subchannel assignments */
>> > - struct {
>> > - uint32_t handle;
>> > - uint32_t grclass;
>> > - } subchan[8];
>> > - uint32_t nr_subchan;
>> > -};
>> > -
>> > -struct drm_nouveau_channel_free {
>> > - int channel;
>> > -};
>> > -
>> > struct drm_nouveau_grobj_alloc {
>> > int channel;
>> > uint32_t handle;
>> > @@ -83,31 +61,12 @@ struct drm_nouveau_gpuobj_free {
>> > uint32_t handle;
>> > };
>> >
>> > -#define NOUVEAU_GETPARAM_PCI_VENDOR 3
>> > -#define NOUVEAU_GETPARAM_PCI_DEVICE 4
>> > -#define NOUVEAU_GETPARAM_BUS_TYPE5
>> > -#define NOUVEAU_GETPARAM_FB_SIZE 8
>> > -#define NOUVEAU_GETPARAM_AGP_SIZE9
>> > -#define NOUVEAU_GETPARAM_CHIPSET_ID 11
>> > -#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
>> > -#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
>> > -#define NOUVEAU_GETPARAM_PTIMER_TIME 14
>> > -#define NOUVEAU_GETPARAM_HAS_BO_USAGE15
>> > -#define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
>> > -struct drm_nouveau_getparam {
>> > - uint64_t param;
>> > - uint64_t value;
>> > -};
>> > -
>> > struct drm_nouveau_setparam {
>> > uint64_t param;
>> > uint64_t value;
>> > };
>> >
>> > -#define DRM_IOCTL_NOUVEAU_GETPARAM DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)
>> > #define DRM_IOCTL_NOUVEAU_SETPARAM DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_NOUVEAU_SETPARAM, struct drm_nouveau_setparam)
>> > -#define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
>> > -#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE DRM_IOW (DRM_COMMAND_BASE
>> + DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
>> > #define DRM_IOCTL_NOUVEAU_GROBJ_ALLOCDRM_IOW (DRM_COMMAND_BASE
>> + DRM_NOUVEAU_GROBJ_ALLOC, struct drm_nouveau_grobj_alloc)
>> > #define DRM_IOCTL_NOUVEAU_NOTIFIEROBJ_ALLOC DRM_IOWR(DRM_COMMAND_BASE
>> + DRM_NOUVEAU_NOTIFIEROBJ_ALLOC, struct drm_nouveau_notifierobj_alloc)
>> > #define DRM_IOCTL_NOUVEAU_GPUOBJ_FREEDRM_IOW (DRM_COMMAND_BASE
>> + DRM_NOUVEAU_GPUOBJ_FREE, struct drm_nouveau_gpuobj_free)
>> > diff --git a/include/uapi/drm/nouveau_drm.h
>> b/include/uapi/drm/nouveau_drm.h
>> > index 853a327433d3..1cd97b3d8eda 100644
>> > --- a/include/uapi/drm/nouveau_drm.h
>> > +++ b/include/uapi/drm/nouve
Re: [PATCH] drm/nouveau: fixup the uapi header file.
> +
> + /* Notifier memory */
> + uint32_t notifier_handle;
> +
> + /* DRM-enforced subchannel assignments */
> + struct {
> + uint32_t handle;
> + uint32_t grclass;
> + } subchan[8];
> + uint32_t nr_subchan;
> +};
> +
> +struct drm_nouveau_channel_free {
> + int channel;
> +};
> +
> #define NOUVEAU_GEM_DOMAIN_CPU (1 << 0)
> #define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
> #define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
> @@ -126,10 +164,10 @@ struct drm_nouveau_gem_cpu_fini {
> __u32 handle;
> };
>
> -#define DRM_NOUVEAU_GETPARAM 0x00 /* deprecated */
> +#define DRM_NOUVEAU_GETPARAM 0x00
> #define DRM_NOUVEAU_SETPARAM 0x01 /* deprecated */
> -#define DRM_NOUVEAU_CHANNEL_ALLOC 0x02 /* deprecated */
> -#define DRM_NOUVEAU_CHANNEL_FREE 0x03 /* deprecated */
> +#define DRM_NOUVEAU_CHANNEL_ALLOC 0x02
> +#define DRM_NOUVEAU_CHANNEL_FREE 0x03
> #define DRM_NOUVEAU_GROBJ_ALLOC0x04 /* deprecated */
> #define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05 /* deprecated */
> #define DRM_NOUVEAU_GPUOBJ_FREE0x06 /* deprecated */
> @@ -188,6 +226,10 @@ struct drm_nouveau_svm_bind {
> #define NOUVEAU_SVM_BIND_TARGET__GPU_VRAM (1UL << 31)
>
>
> +#define DRM_IOCTL_NOUVEAU_GETPARAM DRM_IOWR(DRM_COMMAND_BASE +
> DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)
> +#define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
> DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
> +#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE DRM_IOW (DRM_COMMAND_BASE +
> DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
> +
> #define DRM_IOCTL_NOUVEAU_SVM_INIT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_NOUVEAU_SVM_INIT, struct drm_nouveau_svm_init)
> #define DRM_IOCTL_NOUVEAU_SVM_BIND DRM_IOWR(DRM_COMMAND_BASE +
> DRM_NOUVEAU_SVM_BIND, struct drm_nouveau_svm_bind)
>
> --
> 2.41.0
>
Reviewed-by: Karol Herbst
Re: [PATCH] drm/nouveau/nvkm/dp: Add hack to fix DP 1.3+ DPCD issues
On Fri, Jul 28, 2023 at 1:11 AM Karol Herbst wrote:
>
> On Thu, Jul 27, 2023 at 11:57 PM Lyude Paul wrote:
> >
> > On Sun, 2023-07-09 at 01:42 +0200, Karol Herbst wrote:
> > > On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul wrote:
> > > >
> > > > Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> > > > nouveau in order to read the DPCD of a DP connector, which makes sure
> > > > we do
> > > > the right thing and also check for extended DPCD caps. However, it turns
> > > > out we're not currently doing this on the nvkm side since we don't have
> > > > access to the drm_dp_aux structure there - which means that the DRM
> > > > side of
> > > > the driver and the NVKM side can end up with different DPCD capabilities
> > > > for the same connector.
> > > >
> > > > Ideally to fix this, we want to start setting up the drm_dp_aux device
> > > > in
> > > > NVKM before we've made contact with the DRM side - which should be
> > > > pretty
> > > > easy to accomplish (I'm already working on it!). Until then however,
> > > > let's
> > > > workaround this problem by porting a copy of drm_dp_read_dpcd_caps()
> > > > into
> > > > NVKM - which should fix this issue.
> > > >
> > > > Issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211
> > >
> > > Should a Fixes: or Cc: stable tag be added so it gets backported?
> >
> > JFYI I think not adding one is fine nowadays? The stable bot seems to be
> > pretty good at catching anything with the words fix/fixes in it
> >
>
> Yeah not sure.. I'd rather be specific and add it just to be sure.
> Anyway, it could also be done while pushing. I think the bigger
> question here was if this fix is good enough for stable or if you plan
> to rework it.
>
> > >
> > > > Signed-off-by: Lyude Paul
> > > > ---
> > > > drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 ++-
> > > > 1 file changed, 47 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > > index 40c8ea43c42f..b8ac66b4a2c4 100644
> > > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > > @@ -26,6 +26,8 @@
> > > > #include "head.h"
> > > > #include "ior.h"
> > > >
> > > > +#include
> > > > +
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(struct
> > > > nvkm_outp *outp)
> > > > return outp->dp.rates != 0;
> > > > }
> > > >
> > > > +/* XXX: This is a big fat hack, and this is just
> > > > drm_dp_read_dpcd_caps()
> > >
> > > Well.. maybe we should rephrase that _if_ we want to see it
> > > backported. But is this code really that bad? It kinda looks
> > > reasonable enough.
> > >
> > > > + * converted to work inside nvkm. This is a temporary holdover until
> > > > we start
> > > > + * passing the drm_dp_aux device through NVKM
> > > > + */
> > > > +static int
> > > > +nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp)
> > > > +{
> > > > + struct nvkm_i2c_aux *aux = outp->dp.aux;
> > > > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > > > + int ret;
> > > > +
> > > > + ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd,
> > > > DP_RECEIVER_CAP_SIZE);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + /*
> > > > +* Prior to DP1.3 the bit represented by
> > > > +* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> > > > +* If it is set DP_DPCD_REV at h could be at a value less
> > > > than
> > > > +* the true capability of the panel. The only way to check is to
> > > > +* then compare h and 2200h.
> > > > +*/
> > > > + if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > > > + DP_EXTENDED_RECEIV
Re: [PATCH] drm/nouveau/nvkm/dp: Add hack to fix DP 1.3+ DPCD issues
On Thu, Jul 27, 2023 at 11:57 PM Lyude Paul wrote:
>
> On Sun, 2023-07-09 at 01:42 +0200, Karol Herbst wrote:
> > On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul wrote:
> > >
> > > Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> > > nouveau in order to read the DPCD of a DP connector, which makes sure we
> > > do
> > > the right thing and also check for extended DPCD caps. However, it turns
> > > out we're not currently doing this on the nvkm side since we don't have
> > > access to the drm_dp_aux structure there - which means that the DRM side
> > > of
> > > the driver and the NVKM side can end up with different DPCD capabilities
> > > for the same connector.
> > >
> > > Ideally to fix this, we want to start setting up the drm_dp_aux device in
> > > NVKM before we've made contact with the DRM side - which should be pretty
> > > easy to accomplish (I'm already working on it!). Until then however, let's
> > > workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into
> > > NVKM - which should fix this issue.
> > >
> > > Issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211
> >
> > Should a Fixes: or Cc: stable tag be added so it gets backported?
>
> JFYI I think not adding one is fine nowadays? The stable bot seems to be
> pretty good at catching anything with the words fix/fixes in it
>
Yeah not sure.. I'd rather be specific and add it just to be sure.
Anyway, it could also be done while pushing. I think the bigger
question here was if this fix is good enough for stable or if you plan
to rework it.
> >
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 ++-
> > > 1 file changed, 47 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > index 40c8ea43c42f..b8ac66b4a2c4 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> > > @@ -26,6 +26,8 @@
> > > #include "head.h"
> > > #include "ior.h"
> > >
> > > +#include
> > > +
> > > #include
> > > #include
> > > #include
> > > @@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(struct nvkm_outp
> > > *outp)
> > > return outp->dp.rates != 0;
> > > }
> > >
> > > +/* XXX: This is a big fat hack, and this is just drm_dp_read_dpcd_caps()
> >
> > Well.. maybe we should rephrase that _if_ we want to see it
> > backported. But is this code really that bad? It kinda looks
> > reasonable enough.
> >
> > > + * converted to work inside nvkm. This is a temporary holdover until we
> > > start
> > > + * passing the drm_dp_aux device through NVKM
> > > + */
> > > +static int
> > > +nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp)
> > > +{
> > > + struct nvkm_i2c_aux *aux = outp->dp.aux;
> > > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > > + int ret;
> > > +
> > > + ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd,
> > > DP_RECEIVER_CAP_SIZE);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /*
> > > +* Prior to DP1.3 the bit represented by
> > > +* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> > > +* If it is set DP_DPCD_REV at h could be at a value less than
> > > +* the true capability of the panel. The only way to check is to
> > > +* then compare h and 2200h.
> > > +*/
> > > + if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > > + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
> > > + return 0;
> > > +
> > > + ret = nvkm_rdaux(aux, DP_DP13_DPCD_REV, dpcd_ext,
> > > sizeof(dpcd_ext));
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + if (outp->dp.dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> > > + OUTP_DBG(outp, "Extended DPCD rev less than base DPCD rev
> > > (%d > %d)\n",
> > > +outp->dp.dpcd[DP_DPCD_REV],
> > > dpcd_ext[DP_DPCD_REV]);
> > > + return 0;
Re: [PATCH] drm/nouveau/fifo:Fix Nineteen occurrences of the gk104.c error: ERROR: : trailing statements should be on next line
On Sat, Jul 15, 2023 at 1:07 AM Lyude Paul wrote:
>
> NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases
> corrected in the patch series here, we format the switch cases on single lines
> as it dramatically improves the readability of what is otherwise just a /long/
> list of slightly different static mappings. I don't believe we're the only
> part of the kernel to do this either.
>
I wished there was a place to document something like "patches whose
only reason is 'checkpatch.pl' said so" will be rejected.
I think following some checkpatch rules are sane, but then the
argument should be "makes code more clear" or "converts risky coding
practises to less risky ones". Or do we have such a place? Maybe we
should patch checkpatch.pl instead to throw a warning
> On Fri, 2023-07-14 at 14:58 +0800, huzhi...@208suo.com wrote:
> > Signed-off-by: ZhiHu
> > ---
> > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
> > 1 file changed, 29 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > index d8a4d773a58c..b99e0a7c96bb 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> > @@ -137,15 +137,29 @@ gk104_ectx_bind(struct nvkm_engn *engn, struct
> > nvkm_cctx *cctx, struct nvkm_chan
> > u64 addr = 0ULL;
> >
> > switch (engn->engine->subdev.type) {
> > -case NVKM_ENGINE_SW: return;
> > -case NVKM_ENGINE_GR: ptr0 = 0x0210; break;
> > -case NVKM_ENGINE_SEC : ptr0 = 0x0220; break;
> > -case NVKM_ENGINE_MSPDEC: ptr0 = 0x0250; break;
> > -case NVKM_ENGINE_MSPPP : ptr0 = 0x0260; break;
> > -case NVKM_ENGINE_MSVLD : ptr0 = 0x0270; break;
> > -case NVKM_ENGINE_VIC : ptr0 = 0x0280; break;
> > -case NVKM_ENGINE_MSENC : ptr0 = 0x0290; break;
> > -case NVKM_ENGINE_NVDEC :
> > +case NVKM_ENGINE_SW:
> > +return;
> > +case NVKM_ENGINE_GR:
> > +ptr0 = 0x0210;
> > +break;
> > +case NVKM_ENGINE_SEC:
> > +ptr0 = 0x0220;
> > +break;
> > +case NVKM_ENGINE_MSPDEC:
> > +ptr0 = 0x0250;
> > +break;
> > +case NVKM_ENGINE_MSPPP:
> > +ptr0 = 0x0260;
> > +break;
> > +case NVKM_ENGINE_MSVLD:
> > +ptr0 = 0x0270;
> > +break;
> > +case NVKM_ENGINE_VIC:
> > +ptr0 = 0x0280; break;
> > +case NVKM_ENGINE_MSENC:
> > +ptr0 = 0x0290;
> > +break;
> > +case NVKM_ENGINE_NVDEC:
> > ptr1 = 0x0270;
> > ptr0 = 0x0210;
> > break;
> > @@ -435,8 +449,12 @@ gk104_runl_commit(struct nvkm_runl *runl, struct
> > nvkm_memory *memory, u32 start,
> > int target;
> >
> > switch (nvkm_memory_target(memory)) {
> > -case NVKM_MEM_TARGET_VRAM: target = 0; break;
> > -case NVKM_MEM_TARGET_NCOH: target = 3; break;
> > +case NVKM_MEM_TARGET_VRAM:
> > +target = 0;
> > +break;
> > +case NVKM_MEM_TARGET_NCOH:
> > +target = 3;
> > +break;
>
> This one isn't very long, but I'd still say it's definitely a lot easier to
> read in the compact form. If anything, the only change I would make here is
> formatting the default: case to be on a single line as well
>
> > default:
> > WARN_ON(1);
> > return;
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
Re: [PATCH] drm/nouveau/iccsense:
On Thu, Jul 13, 2023 at 11:13 AM Karol Herbst wrote:
>
> On Mon, Jul 10, 2023 at 11:10 AM Bagas Sanjaya wrote:
> >
> > On Mon, Jul 10, 2023 at 03:06:47PM +0800, sunran...@208suo.com wrote:
> > > Fixed error: 'do not use assignment in if condition'
> > >
> > > This patch fixes error: 'do not use assignment in if condition'
> > > in drm/nouveau/iccsense
> >
> > I guess this is checkpatch fix, right?
> >
> > >
> > > Signed-off-by: Ran Sun
> > > ---
> > > drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > > index 8f0ccd3664eb..2428f3d6e477 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > > @@ -322,7 +322,8 @@ int
> > > nvkm_iccsense_new_(struct nvkm_device *device, enum nvkm_subdev_type
> > > type,
> > > int inst,
> > > struct nvkm_iccsense **iccsense)
> > > {
> > > -if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
> > > +*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL);
> > > +if (!*iccsense)
> > > return -ENOMEM;
> > > INIT_LIST_HEAD(&(*iccsense)->sensors);
> > > INIT_LIST_HEAD(&(*iccsense)->rails);
> >
> > Your patch is corrupted (tabs converted to spaces) because you're using
> > Roundcube. Please use git-send-mail(1) instead.
> >
>
> oh right, I didn't notice with the patches I reviewed already here.
> Yeah, none of them apply, please use git to send those patches.
>
also please send them all together in a single series the next time.
> > Thanks.
> >
> > --
> > An old man doll... just what I always wanted! - Clara
Re: [PATCH] drm/nouveau/iccsense:
On Mon, Jul 10, 2023 at 11:10 AM Bagas Sanjaya wrote:
>
> On Mon, Jul 10, 2023 at 03:06:47PM +0800, sunran...@208suo.com wrote:
> > Fixed error: 'do not use assignment in if condition'
> >
> > This patch fixes error: 'do not use assignment in if condition'
> > in drm/nouveau/iccsense
>
> I guess this is checkpatch fix, right?
>
> >
> > Signed-off-by: Ran Sun
> > ---
> > drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > index 8f0ccd3664eb..2428f3d6e477 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > @@ -322,7 +322,8 @@ int
> > nvkm_iccsense_new_(struct nvkm_device *device, enum nvkm_subdev_type type,
> > int inst,
> > struct nvkm_iccsense **iccsense)
> > {
> > -if (!(*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL)))
> > +*iccsense = kzalloc(sizeof(**iccsense), GFP_KERNEL);
> > +if (!*iccsense)
> > return -ENOMEM;
> > INIT_LIST_HEAD(&(*iccsense)->sensors);
> > INIT_LIST_HEAD(&(*iccsense)->rails);
>
> Your patch is corrupted (tabs converted to spaces) because you're using
> Roundcube. Please use git-send-mail(1) instead.
>
oh right, I didn't notice with the patches I reviewed already here.
Yeah, none of them apply, please use git to send those patches.
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
Re: [PATCH] drm/nouveau/i2c: do not use assignment in if condition
On Mon, Jul 10, 2023 at 9:23 AM wrote:
>
> Assignments in if condition are less readable and error-prone. Fixes
> also checkpatch warning:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
> index d063d0dc13c5..098051d3755c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
> @@ -209,7 +209,8 @@ nvkm_i2c_aux_new_(const struct nvkm_i2c_aux_func
> *func,
> struct nvkm_i2c_pad *pad, int id,
> struct nvkm_i2c_aux **paux)
> {
> -if (!(*paux = kzalloc(sizeof(**paux), GFP_KERNEL)))
> +*paux = kzalloc(sizeof(**paux), GFP_KERNEL);
> +if (!*paux)
> return -ENOMEM;
> return nvkm_i2c_aux_ctor(func, pad, id, *paux);
> }
>
Reviewed-by: Karol Herbst
Re: [PATCH] drm/nouveau/nvkm: do not use assignment in if condition
On Mon, Jul 10, 2023 at 9:23 AM wrote:
>
> Assignments in if condition are less readable and error-prone. Fixes
> also checkpatch warning:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by:Ran Sun
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> index 976539de4220..054fa42f1d04 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> @@ -286,7 +286,8 @@ nvkm_i2c_new_(const struct nvkm_i2c_func *func,
> struct nvkm_device *device,
>
> if (ccbE.share != DCB_I2C_UNUSED) {
> const int id = NVKM_I2C_PAD_HYBRID(ccbE.share);
> -if (!(pad = nvkm_i2c_pad_find(i2c, id)))
> +pad = nvkm_i2c_pad_find(i2c, id);
> +if (!pad)
> ret = func->pad_s_new(i2c, id, );
> else
> ret = 0;
>
Reviewed-by: Karol Herbst
Re: [PATCH] drm/nouveau/pci: ERROR: "foo * bar" should be "foo *bar"
On Mon, Jul 10, 2023 at 9:23 AM wrote:
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
> index 6be87ecffc89..bc51987c5f5f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c
> @@ -147,7 +147,7 @@ gk104_pcie_set_link_speed(struct nvkm_pci *pci, enum
> nvkm_pcie_speed speed)
> }
>
> static int
> -gk104_pcie_init(struct nvkm_pci * pci)
> +gk104_pcie_init(struct nvkm_pci *pci)
> {
> enum nvkm_pcie_speed lnkctl_speed, max_speed, cap_speed;
> struct nvkm_subdev *subdev = >subdev;
>
Reviewed-by: Karol Herbst
Re: [PATCH] drm/nouveau/i2c: do not use assignment in if condition
Reviewed-by: Karol Herbst
On Mon, Jul 10, 2023 at 9:23 AM wrote:
>
> Assignments in if condition are less readable and error-prone. Fixes
> also checkpatch warning:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
> index 96bbdda0f439..a1cf406ff141 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/busgf119.c
> @@ -85,7 +85,8 @@ gf119_i2c_bus_new(struct nvkm_i2c_pad *pad, int id, u8
> drive,
> {
> struct gf119_i2c_bus *bus;
>
> -if (!(bus = kzalloc(sizeof(*bus), GFP_KERNEL)))
> +bus = kzalloc(sizeof(*bus), GFP_KERNEL);
> +if (!bus)
> return -ENOMEM;
> *pbus = >base;
>
Re: [PATCH] drm/nouveau/nvkm/dp: Add hack to fix DP 1.3+ DPCD issues
On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul wrote:
>
> Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> nouveau in order to read the DPCD of a DP connector, which makes sure we do
> the right thing and also check for extended DPCD caps. However, it turns
> out we're not currently doing this on the nvkm side since we don't have
> access to the drm_dp_aux structure there - which means that the DRM side of
> the driver and the NVKM side can end up with different DPCD capabilities
> for the same connector.
>
> Ideally to fix this, we want to start setting up the drm_dp_aux device in
> NVKM before we've made contact with the DRM side - which should be pretty
> easy to accomplish (I'm already working on it!). Until then however, let's
> workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into
> NVKM - which should fix this issue.
>
> Issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211
Should a Fixes: or Cc: stable tag be added so it gets backported?
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 ++-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> index 40c8ea43c42f..b8ac66b4a2c4 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> @@ -26,6 +26,8 @@
> #include "head.h"
> #include "ior.h"
>
> +#include
> +
> #include
> #include
> #include
> @@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(struct nvkm_outp
> *outp)
> return outp->dp.rates != 0;
> }
>
> +/* XXX: This is a big fat hack, and this is just drm_dp_read_dpcd_caps()
Well.. maybe we should rephrase that _if_ we want to see it
backported. But is this code really that bad? It kinda looks
reasonable enough.
> + * converted to work inside nvkm. This is a temporary holdover until we start
> + * passing the drm_dp_aux device through NVKM
> + */
> +static int
> +nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp)
> +{
> + struct nvkm_i2c_aux *aux = outp->dp.aux;
> + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> + int ret;
> +
> + ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd,
> DP_RECEIVER_CAP_SIZE);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +* Prior to DP1.3 the bit represented by
> +* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> +* If it is set DP_DPCD_REV at h could be at a value less than
> +* the true capability of the panel. The only way to check is to
> +* then compare h and 2200h.
> +*/
> + if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
> + return 0;
> +
> + ret = nvkm_rdaux(aux, DP_DP13_DPCD_REV, dpcd_ext, sizeof(dpcd_ext));
> + if (ret < 0)
> + return ret;
> +
> + if (outp->dp.dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> + OUTP_DBG(outp, "Extended DPCD rev less than base DPCD rev (%d
> > %d)\n",
> +outp->dp.dpcd[DP_DPCD_REV], dpcd_ext[DP_DPCD_REV]);
> + return 0;
> + }
> +
> + if (!memcmp(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext)))
> + return 0;
> +
> + memcpy(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext));
> +
> + return 0;
> +}
> +
> void
> nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
> {
> @@ -689,7 +735,7 @@ nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
> memset(outp->dp.lttpr, 0x00, sizeof(outp->dp.lttpr));
> }
>
> - if (!nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd,
> sizeof(outp->dp.dpcd))) {
> + if (!nvkm_dp_read_dpcd_caps(outp)) {
> const u8 rates[] = { 0x1e, 0x14, 0x0a, 0x06, 0 };
> const u8 *rate;
> int rate_max;
> --
> 2.40.1
>
Re: [PATCH] drm/nouveau/disp/g94: enable HDMI
On Fri, Jul 7, 2023 at 11:03 PM Lyude Paul wrote:
>
> Reviewed-by: Lyude Paul
>
> But seeing as I looked at this + some other patches yesterday I assume there's
> still more to this?
>
not really. All those patches are all independent and just a bunch of
fixes. I just figured this one out a bit later.
> On Fri, 2023-06-30 at 18:06 +0200, Karol Herbst wrote:
> > Cc: Ben Skeggs
> > Cc: Lyude Paul
> > Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire +
> > infoframe methods")
> > Signed-off-by: Karol Herbst
> > ---
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
> > index a4853c4e5ee3..67ef889a0c5f 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
> > @@ -295,6 +295,7 @@ g94_sor = {
> > .clock = nv50_sor_clock,
> > .war_2 = g94_sor_war_2,
> > .war_3 = g94_sor_war_3,
> > + .hdmi = _sor_hdmi,
> > .dp = _sor_dp,
> > };
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
[PATCH] drm/nouveau/disp/g94: enable HDMI
Cc: Ben Skeggs
Cc: Lyude Paul
Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire +
infoframe methods")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
index a4853c4e5ee3..67ef889a0c5f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/g94.c
@@ -295,6 +295,7 @@ g94_sor = {
.clock = nv50_sor_clock,
.war_2 = g94_sor_war_2,
.war_3 = g94_sor_war_3,
+ .hdmi = _sor_hdmi,
.dp = _sor_dp,
};
--
2.41.0
[PATCH 3/3] drm/nouveau/disp: verify mode on atomic_check
We have to verify the selected mode as Userspace might request one which
we can't configure the GPU for.
X with the modesetting DDX is adding a bunch of modes, some so far outside
of hardware limits that things simply break.
Sadly we can't fix X this way as on start it sticks to one mode and
ignores any error and there is really nothing we can do about this, but at
least this way we won't let the GPU run into any errors caused by a non
supported display mode.
However this does prevent X from switching to such a mode, which to be
fair is an improvement as well.
Seen on one of my Tesla GPUs with a connected 4K display.
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/199
Cc: Ben Skeggs
Cc: Lyude Paul
Cc: sta...@vger.kernel.org # v6.1+
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 22c42a5e184d..edf490c1490c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1114,6 +1114,25 @@ nouveau_connector_atomic_check(struct drm_connector
*connector, struct drm_atomi
struct drm_connector_state *conn_state =
drm_atomic_get_new_connector_state(state, connector);
+ /* As we can get any random mode from Userspace, we have to make sure
the to be set mode
+* is valid and does not violate hardware constraints as we rely on it
being sane.
+*/
+ if (conn_state->crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_crtc_state(state, conn_state->crtc);
+
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ if (crtc_state->enable && (crtc_state->mode_changed ||
+ crtc_state->connectors_changed)) {
+ struct drm_display_mode *mode = _state->mode;
+
+ if (connector->helper_private->mode_valid(connector,
mode) != MODE_OK)
+ return -EINVAL;
+ }
+ }
+
if (!nv_conn->dp_encoder || !nv50_has_mst(nouveau_drm(connector->dev)))
return 0;
--
2.41.0
[PATCH 2/3] drm/nouveau/disp: drop unused argument in nv50_dp_mode_valid
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dp.c| 3 +--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 3 +--
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1637e08b548c..6221eaaad1b7 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1127,7 +1127,7 @@ nv50_mstc_mode_valid(struct drm_connector *connector,
* MSTB's max possible PBN
*/
- return nv50_dp_mode_valid(connector, outp, mode, NULL);
+ return nv50_dp_mode_valid(outp, mode, NULL);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index f75c6f09dd2a..22c42a5e184d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1079,7 +1079,7 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
case DCB_OUTPUT_TV:
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
- return nv50_dp_mode_valid(connector, nv_encoder, mode, NULL);
+ return nv50_dp_mode_valid(nv_encoder, mode, NULL);
default:
BUG();
return MODE_BAD;
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d49b4875fc3c..6a4980b2d4d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -267,8 +267,7 @@ nouveau_dp_irq(struct work_struct *work)
* yet)
*/
enum drm_mode_status
-nv50_dp_mode_valid(struct drm_connector *connector,
- struct nouveau_encoder *outp,
+nv50_dp_mode_valid(struct nouveau_encoder *outp,
const struct drm_display_mode *mode,
unsigned *out_clock)
{
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index 70c1ad6c4d9d..bcba1a14cfab 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -143,8 +143,7 @@ enum nouveau_dp_status {
int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
bool nouveau_dp_link_check(struct nouveau_connector *);
void nouveau_dp_irq(struct work_struct *);
-enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
- struct nouveau_encoder *,
+enum drm_mode_status nv50_dp_mode_valid(struct nouveau_encoder *,
const struct drm_display_mode *,
unsigned *clock);
--
2.41.0
[PATCH 1/3] drm/nouveau/disp: fix HDMI on gt215+
Cc: Ben Skeggs
Cc: Lyude Paul
Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire +
infoframe methods")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c
index a2c7c6f83dcd..506ffbe7b842 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c
@@ -125,7 +125,7 @@ gt215_sor_hdmi_infoframe_avi(struct nvkm_ior *ior, int
head, void *data, u32 siz
pack_hdmi_infoframe(, data, size);
nvkm_mask(device, 0x61c520 + soff, 0x0001, 0x);
- if (size)
+ if (!size)
return;
nvkm_wr32(device, 0x61c528 + soff, avi.header);
--
2.41.0
Re: [PATCH 3/9] drm/ttm: use per BO cleanup workers
On Thu, Jun 15, 2023 at 1:19 PM Christian König wrote: > > Am 13.06.23 um 16:18 schrieb Karol Herbst: > > On Tue, Jun 13, 2023 at 3:59 PM Christian König > > wrote: > >> Am 13.06.23 um 15:05 schrieb Karol Herbst: > >>> On Mon, Dec 5, 2022 at 2:40 PM Christian König > >>> wrote: > >>>> Am 29.11.22 um 22:14 schrieb Felix Kuehling: > >>>>> On 2022-11-25 05:21, Christian König wrote: > >>>>>> Instead of a single worker going over the list of delete BOs in regular > >>>>>> intervals use a per BO worker which blocks for the resv object and > >>>>>> locking of the BO. > >>>>>> > >>>>>> This not only simplifies the handling massively, but also results in > >>>>>> much better response time when cleaning up buffers. > >>>>>> > >>>>>> Signed-off-by: Christian König > >>>>> Just thinking out loud: If I understand it correctly, this can cause a > >>>>> lot of sleeping worker threads when > >>>>> AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed > >>>>> at the same time. This happens e.g. when a KFD process terminates or > >>>>> crashes. I guess with a concurrency-managed workqueue this isn't going > >>>>> to be excessive. And since it's on a per device workqueue, it doesn't > >>>>> stall work items on the system work queue or from other devices. > >>>> Yes, exactly that. The last parameter to alloc_workqueue() limits how > >>>> many work items can be sleeping. > >>>> > >>>>> I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue > >>>>> is not about freeing ttm_resources but about freeing the BOs. But it > >>>>> affects freeing of ghost_objs that are holding the ttm_resources being > >>>>> freed. > >>>> Well if the BO is idle, but not immediately lockable we delegate freeing > >>>> the backing pages in the TT object to those workers as well. It might > >>>> even be a good idea to use a separate wq for this case. > >>>> > >>>>> If those assumptions all make sense, patches 1-3 are > >>>>> > >>>>> Reviewed-by: Felix Kuehling > >>>> Thanks, > >>>> Christian. > >>>> > >>> This patch causes a heap use-after-free when using nouveau with the > >>> potential of trashing filesystems, is there a way to revert it until > >>> we figure out a proper solution to the problem? > >> Uff I don't think so, we have quite some work based on top of this. But > >> let me double check. > >> > > yeah.. I already talked with Dave about fixing this issue as Dave has > > more knowledge on this part of the driver (I hope), so we might have a > > fix soonish, but the concerning part is, that it's already out to > > users, so might be better to be able to revert it if the fix takes a > > while to emerge. > > We at least can't revert easily. This was fixing issues where we have > seen OOM situations because TTM wasn't releasing resources fast enough. > > >> On the other hand have you tried running this with KASAN to catch use > >> after free errors? > > yes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213#note_1942777 > > > >> Since we now block for work to finish and not check every few > >> milliseconds to garbage collect memory will now be reclaimed much faster > >> after freeing it. > > yeah, that kinda makes sense. This entire issue feels like a race > > happening as I need to run the OpenGL CTS in parallel with 8+ threads > > to trigger it reliably. > > Yeah, from the bug report that's a classic use after free because of a race. > > Easiest would be to make sure everybody has a reference to the fence. > turns out nouveau was using `dma_fence_is_signaled_locked` without taking the lock. Fixing that seems to improve the situation by a lot, so I think we have a fix to resolve this problem. > Regards, > Christian. > > > > >> Regards, > >> Christian. > >> > >>> Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213 > >>> > >>> example trace on affected systems: > >>> > >>> [ 4102.946946] general protection fault, probably for non-canonical > >>> address 0x5f775ce3bd949b45: [#3] PREEMPT SMP NOPTI > >>> [ 4102.957794] CPU: 12 PID:
Re: [PATCH] nouveau: fix client work fence deletion race
On Thu, Jun 15, 2023 at 4:47 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This seems to have existed for ever but is now more apparant after
> 9bff18d13473a9fdf81d5158248472a9d8ecf2bd (drm/ttm: use per BO cleanup workers)
>
> My analysis:
> two threads are running,
> one in the irq signalling the fence, in dma_fence_signal_timestamp_locked,
> it has done the DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached
> the callbacks.
>
> second thread in nouveau_cli_work_ready, where it sees the fence is
> signalled, so then puts the
> fence, cleanups the object and frees the work item, which contains the
> callback.
>
> thread one goes again and tries to call the callback and causes the
> use-after-free.
>
> Proposed fix:
> lock the fence signalled check in nouveau_cli_work_ready, so either the
> callbacks are done
> or the memory is freed.
>
> Signed-off-by: Dave Airlie
Fixes: 11e451e74050 ("drm/nouveau: remove fence wait code from
deferred client work handler")
Is I think the most reasonable commit to tag to ensure backports.
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index cc7c5b4a05fd..1a45be769848 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -137,10 +137,16 @@ nouveau_name(struct drm_device *dev)
> static inline bool
> nouveau_cli_work_ready(struct dma_fence *fence)
> {
> - if (!dma_fence_is_signaled(fence))
> - return false;
> - dma_fence_put(fence);
> - return true;
> + unsigned long flags;
> + bool ret = true;
> + spin_lock_irqsave(fence->lock, flags);
> + if (!dma_fence_is_signaled_locked(fence))
> + ret = false;
> + spin_unlock_irqrestore(fence->lock, flags);
I agree with the code being always broken as
`dma_fence_is_signaled_locked` specifies: "This function requires
_fence.lock to be held."
> +
> + if (ret == true)
> + dma_fence_put(fence);
> + return ret;
> }
>
> static void
> --
> 2.40.1
>
regardless of the patch fixing the issue users have seen:
Reviewed-by: Karol Herbst
Re: [PATCH] drm/nouveau/kms/nv50-: Fix drm_dp_remove_payload() invocation
On Tue, Jun 13, 2023 at 11:05 PM Lyude Paul wrote:
>
> We changed the semantics for this in:
>
> e761cc20946a ("drm/display/dp_mst: Handle old/new payload states in
> drm_dp_remove_payload()")
>
> But I totally forgot to update this properly in nouveau. So, let's do that.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 5bb777ff13130..1637e08b548c2 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -909,15 +909,19 @@ nv50_msto_prepare(struct drm_atomic_state *state,
> struct nouveau_drm *drm = nouveau_drm(msto->encoder.dev);
> struct nv50_mstc *mstc = msto->mstc;
> struct nv50_mstm *mstm = mstc->mstm;
> - struct drm_dp_mst_atomic_payload *payload;
> + struct drm_dp_mst_topology_state *old_mst_state;
> + struct drm_dp_mst_atomic_payload *payload, *old_payload;
>
> NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
>
> + old_mst_state = drm_atomic_get_old_mst_topology_state(state, mgr);
> +
> payload = drm_atomic_get_mst_payload_state(mst_state, mstc->port);
> + old_payload = drm_atomic_get_mst_payload_state(old_mst_state,
> mstc->port);
>
> // TODO: Figure out if we want to do a better job of handling VCPI
> allocation failures here?
> if (msto->disabled) {
> - drm_dp_remove_payload(mgr, mst_state, payload, payload);
> + drm_dp_remove_payload(mgr, mst_state, old_payload, payload);
>
> nvif_outp_dp_mst_vcpi(>outp->outp,
> msto->head->base.index, 0, 0, 0, 0);
> } else {
> --
> 2.40.1
>
Re: [PATCH 3/9] drm/ttm: use per BO cleanup workers
On Tue, Jun 13, 2023 at 3:59 PM Christian König wrote: > > Am 13.06.23 um 15:05 schrieb Karol Herbst: > > On Mon, Dec 5, 2022 at 2:40 PM Christian König > > wrote: > >> Am 29.11.22 um 22:14 schrieb Felix Kuehling: > >>> On 2022-11-25 05:21, Christian König wrote: > >>>> Instead of a single worker going over the list of delete BOs in regular > >>>> intervals use a per BO worker which blocks for the resv object and > >>>> locking of the BO. > >>>> > >>>> This not only simplifies the handling massively, but also results in > >>>> much better response time when cleaning up buffers. > >>>> > >>>> Signed-off-by: Christian König > >>> Just thinking out loud: If I understand it correctly, this can cause a > >>> lot of sleeping worker threads when > >>> AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed > >>> at the same time. This happens e.g. when a KFD process terminates or > >>> crashes. I guess with a concurrency-managed workqueue this isn't going > >>> to be excessive. And since it's on a per device workqueue, it doesn't > >>> stall work items on the system work queue or from other devices. > >> Yes, exactly that. The last parameter to alloc_workqueue() limits how > >> many work items can be sleeping. > >> > >>> I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue > >>> is not about freeing ttm_resources but about freeing the BOs. But it > >>> affects freeing of ghost_objs that are holding the ttm_resources being > >>> freed. > >> Well if the BO is idle, but not immediately lockable we delegate freeing > >> the backing pages in the TT object to those workers as well. It might > >> even be a good idea to use a separate wq for this case. > >> > >>> If those assumptions all make sense, patches 1-3 are > >>> > >>> Reviewed-by: Felix Kuehling > >> Thanks, > >> Christian. > >> > > This patch causes a heap use-after-free when using nouveau with the > > potential of trashing filesystems, is there a way to revert it until > > we figure out a proper solution to the problem? > > Uff I don't think so, we have quite some work based on top of this. But > let me double check. > yeah.. I already talked with Dave about fixing this issue as Dave has more knowledge on this part of the driver (I hope), so we might have a fix soonish, but the concerning part is, that it's already out to users, so might be better to be able to revert it if the fix takes a while to emerge. > On the other hand have you tried running this with KASAN to catch use > after free errors? yes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213#note_1942777 > > Since we now block for work to finish and not check every few > milliseconds to garbage collect memory will now be reclaimed much faster > after freeing it. yeah, that kinda makes sense. This entire issue feels like a race happening as I need to run the OpenGL CTS in parallel with 8+ threads to trigger it reliably. > > Regards, > Christian. > > > > > Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213 > > > > example trace on affected systems: > > > > [ 4102.946946] general protection fault, probably for non-canonical > > address 0x5f775ce3bd949b45: [#3] PREEMPT SMP NOPTI > > [ 4102.957794] CPU: 12 PID: 89561 Comm: glcts Tainted: G D > > 6.3.5-200.fc38.x86_64 #1 > > [ 4102.966556] Hardware name: ASUS System Product Name/PRIME B660-PLUS > > D4, BIOS 0418 10/13/2021 > > [ 4102.974972] RIP: 0010:__kmem_cache_alloc_node+0x1ba/0x320 > > [ 4102.980362] Code: 2b 14 25 28 00 00 00 0f 85 74 01 00 00 48 83 c4 > > 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 41 8b 47 28 4d 8b 07 > > 48 01 f8 <48> 8b 18 48 89 c1 49 33 9f b8 00 00 00 48 0f c9 48 31 cb 41 > > f6 c0 > > [ 4102.999073] RSP: 0018:9764e0057b40 EFLAGS: 00010202 > > [ 4103.004291] RAX: 5f775ce3bd949b45 RBX: 0dc0 RCX: > > 0046 > > [ 4103.011408] RDX: 0002cf87600c RSI: 0dc0 RDI: > > 5f775ce3bd949b15 > > [ 4103.018528] RBP: 0dc0 R08: 000390c0 R09: > > 30302d6d > > [ 4103.025649] R10: 756c7473 R11: 20090298 R12: > > > > [ 4103.032767] R13: R14: 0046 R15: > > 8bda80042600 > > [ 4103.039887] FS: 7f386a85ef00() GS:8be1df70() > > knlGS: > > [
Re: [PATCH 3/9] drm/ttm: use per BO cleanup workers
On Mon, Dec 5, 2022 at 2:40 PM Christian König wrote: > > Am 29.11.22 um 22:14 schrieb Felix Kuehling: > > On 2022-11-25 05:21, Christian König wrote: > >> Instead of a single worker going over the list of delete BOs in regular > >> intervals use a per BO worker which blocks for the resv object and > >> locking of the BO. > >> > >> This not only simplifies the handling massively, but also results in > >> much better response time when cleaning up buffers. > >> > >> Signed-off-by: Christian König > > > > Just thinking out loud: If I understand it correctly, this can cause a > > lot of sleeping worker threads when > > AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed > > at the same time. This happens e.g. when a KFD process terminates or > > crashes. I guess with a concurrency-managed workqueue this isn't going > > to be excessive. And since it's on a per device workqueue, it doesn't > > stall work items on the system work queue or from other devices. > > Yes, exactly that. The last parameter to alloc_workqueue() limits how > many work items can be sleeping. > > > I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue > > is not about freeing ttm_resources but about freeing the BOs. But it > > affects freeing of ghost_objs that are holding the ttm_resources being > > freed. > > Well if the BO is idle, but not immediately lockable we delegate freeing > the backing pages in the TT object to those workers as well. It might > even be a good idea to use a separate wq for this case. > > > > > If those assumptions all make sense, patches 1-3 are > > > > Reviewed-by: Felix Kuehling > > Thanks, > Christian. > This patch causes a heap use-after-free when using nouveau with the potential of trashing filesystems, is there a way to revert it until we figure out a proper solution to the problem? Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213 example trace on affected systems: [ 4102.946946] general protection fault, probably for non-canonical address 0x5f775ce3bd949b45: [#3] PREEMPT SMP NOPTI [ 4102.957794] CPU: 12 PID: 89561 Comm: glcts Tainted: G D 6.3.5-200.fc38.x86_64 #1 [ 4102.966556] Hardware name: ASUS System Product Name/PRIME B660-PLUS D4, BIOS 0418 10/13/2021 [ 4102.974972] RIP: 0010:__kmem_cache_alloc_node+0x1ba/0x320 [ 4102.980362] Code: 2b 14 25 28 00 00 00 0f 85 74 01 00 00 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 41 8b 47 28 4d 8b 07 48 01 f8 <48> 8b 18 48 89 c1 49 33 9f b8 00 00 00 48 0f c9 48 31 cb 41 f6 c0 [ 4102.999073] RSP: 0018:9764e0057b40 EFLAGS: 00010202 [ 4103.004291] RAX: 5f775ce3bd949b45 RBX: 0dc0 RCX: 0046 [ 4103.011408] RDX: 0002cf87600c RSI: 0dc0 RDI: 5f775ce3bd949b15 [ 4103.018528] RBP: 0dc0 R08: 000390c0 R09: 30302d6d [ 4103.025649] R10: 756c7473 R11: 20090298 R12: [ 4103.032767] R13: R14: 0046 R15: 8bda80042600 [ 4103.039887] FS: 7f386a85ef00() GS:8be1df70() knlGS: [ 4103.047958] CS: 0010 DS: ES: CR0: 80050033 [ 4103.053692] CR2: 0493b868 CR3: 00014c3ba000 CR4: 00f50ee0 [ 4103.060812] PKRU: 5554 [ 4103.063520] Call Trace: [ 4103.065970] [ 4103.068071] ? die_addr+0x36/0x90 [ 4103.071384] ? exc_general_protection+0x1be/0x420 [ 4103.076081] ? asm_exc_general_protection+0x26/0x30 [ 4103.080952] ? __kmem_cache_alloc_node+0x1ba/0x320 [ 4103.085734] ? ext4_htree_store_dirent+0x42/0x180 [ 4103.090431] ? ext4_htree_store_dirent+0x42/0x180 [ 4103.095132] __kmalloc+0x4d/0x150 [ 4103.098444] ext4_htree_store_dirent+0x42/0x180 [ 4103.102970] htree_dirblock_to_tree+0x1ed/0x370 [ 4103.107494] ext4_htree_fill_tree+0x109/0x3d0 [ 4103.111846] ext4_readdir+0x6d4/0xa80 [ 4103.115505] iterate_dir+0x178/0x1c0 [ 4103.119076] __x64_sys_getdents64+0x88/0x130 [ 4103.123341] ? __pfx_filldir64+0x10/0x10 [ 4103.127260] do_syscall_64+0x5d/0x90 [ 4103.130835] ? handle_mm_fault+0x11e/0x310 [ 4103.134927] ? do_user_addr_fault+0x1e0/0x720 [ 4103.139278] ? exc_page_fault+0x7c/0x180 [ 4103.143195] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 4103.148240] RIP: 0033:0x7f386a418047 [ 4103.151828] Code: 24 fb ff 4c 89 e0 5b 41 5c 5d c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 ff ff ff 7f 48 39 c2 48 0f 47 d0 b8 d9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 91 cd 0f 00 f7 d8 64 89 02 48 [ 4103.170543] RSP: 002b:7ffd4793ff38 EFLAGS: 0293 ORIG_RAX: 00d9 [ 4103.178095] RAX: ffda RBX: 04933830 RCX: 7f386a418047 [ 4103.185214] RDX: 8000 RSI: 04933860 RDI: 0006 [ 4103.192335] RBP: 7ffd4793ff70 R08: R09: 0001 [ 4103.199454] R10: 0004 R11: 0293 R12: 04933834 [ 4103.206573] R13: 04933860 R14: ff60 R15: [ 4103.213695] [ 4103.215883]
Re: [RESEND 12/15] drm/nouveau/dispnv04/crtc: Demote kerneldoc abuses
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > drivers/gpu/drm/nouveau/dispnv04/crtc.c:629: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Lee Jones Reviewed-by: Karol Herbst > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > index a6f2e681bde98..7794902df17d5 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct > drm_display_mode *mode) > regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct > drm_framebuffer *old_fb) > return ret; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > -- > 2.41.0.162.gfafddb0af9-goog >
Re: [RESEND 09/15] drm/nouveau/nvkm/engine/gr/gf100: Demote kerneldoc abuse
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1044: warning: This comment > starts with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Lee Jones Reviewed-by: Karol Herbst > --- > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > index 5f20079c3660f..7d4c2264d3c05 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > @@ -1040,7 +1040,7 @@ gf100_gr_zbc_init(struct gf100_gr *gr) > } > } > > -/** > +/* > * Wait until GR goes idle. GR is considered idle if it is disabled by the > * MC (0x200) register, or GR is not busy and a context switch is not in > * progress. > -- > 2.41.0.162.gfafddb0af9-goog >
Re: [RESEND 10/15] drm/nouveau/nvkm/engine/gr/tu102: Staticify local function gf100_fifo_nonstall_block()
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous
> prototype for ‘tu102_gr_load’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones
Reviewed-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> index 3b6c8100a2428..10a7e59482a6f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> @@ -206,7 +206,7 @@ tu102_gr_av_to_init_veid(struct nvkm_blob *blob, struct
> gf100_gr_pack **ppack)
> return gk20a_gr_av_to_init_(blob, 64, 0x0010, ppack);
> }
>
> -int
> +static int
> tu102_gr_load(struct gf100_gr *gr, int ver, const struct gf100_gr_fwif *fwif)
> {
> int ret;
> --
> 2.41.0.162.gfafddb0af9-goog
>
Re: [RESEND 08/15] drm/nouveau/nvkm/subdev/volt/gk20a: Demote kerneldoc abuses
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:49: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:62: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones
Reviewed-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> index 8c2faa9645111..ccac88da88648 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c
> @@ -45,7 +45,7 @@ static const struct cvb_coef gk20a_cvb_coef[] = {
> /* 852 */ { 1608418, -21643, -269, 0,763, -48},
> };
>
> -/**
> +/*
> * cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0)
> */
> static inline int
> @@ -58,7 +58,7 @@ gk20a_volt_get_cvb_voltage(int speedo, int s_scale, const
> struct cvb_coef *coef)
> return mv;
> }
>
> -/**
> +/*
> * cvb_t_mv =
> * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) +
> * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale)
> --
> 2.41.0.162.gfafddb0af9-goog
>
Re: [RESEND 06/15] drm/nouveau/nvkm/subdev/acr/lsfw: Remove unused variable 'loc'
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c: In function > ‘nvkm_acr_lsfw_load_sig_image_desc_v2’: > drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable > ‘loc’ set but not used [-Wunused-but-set-variable] > > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: Gourav Samaiya > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c > index f36a359d4531c..bd104a030243a 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c > @@ -218,7 +218,7 @@ nvkm_acr_lsfw_load_sig_image_desc_v2(struct nvkm_subdev > *subdev, > const struct firmware *hsbl; > const struct nvfw_ls_hsbl_bin_hdr *hdr; > const struct nvfw_ls_hsbl_hdr *hshdr; > - u32 loc, sig, cnt, *meta; > + u32 sig, cnt, *meta; > > ret = nvkm_firmware_load_name(subdev, path, "hs_bl_sig", ver, > ); > if (ret) > @@ -227,7 +227,6 @@ nvkm_acr_lsfw_load_sig_image_desc_v2(struct nvkm_subdev > *subdev, > hdr = nvfw_ls_hsbl_bin_hdr(subdev, hsbl->data); > hshdr = nvfw_ls_hsbl_hdr(subdev, hsbl->data + > hdr->header_offset); > meta = (u32 *)(hsbl->data + hshdr->meta_data_offset); > - loc = *(u32 *)(hsbl->data + hshdr->patch_loc); Ben: should we do anything with this value or is it safe to ignore? > sig = *(u32 *)(hsbl->data + hshdr->patch_sig); > cnt = *(u32 *)(hsbl->data + hshdr->num_sig); > > -- > 2.41.0.162.gfafddb0af9-goog >
Re: [RESEND 07/15] drm/nouveau/nvkm/subdev/bios/init: Demote a bunch of kernel-doc abuses
On Fri, Jun 9, 2023 at 10:18 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting
> prototype for INIT_DONE(). Prototype was for init_done() instead
> [Snipped ~140 lines for brevity]
>
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones
Reviewed-by: Karol Herbst
> ---
> .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 136 +-
> 1 file changed, 68 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> index 1420794038642..b54f044c4483b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
> @@ -575,7 +575,7 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
> * init opcode handlers
>
> */
>
> -/**
> +/*
> * init_reserved - stub for various unknown/unused single-byte opcodes
> *
> */
> @@ -602,7 +602,7 @@ init_reserved(struct nvbios_init *init)
> init->offset += length;
> }
>
> -/**
> +/*
> * INIT_DONE - opcode 0x71
> *
> */
> @@ -613,7 +613,7 @@ init_done(struct nvbios_init *init)
> init->offset = 0x;
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PROG - opcode 0x32
> *
> */
> @@ -650,7 +650,7 @@ init_io_restrict_prog(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_REPEAT - opcode 0x33
> *
> */
> @@ -676,7 +676,7 @@ init_repeat(struct nvbios_init *init)
> init->repeat = repeat;
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PLL - opcode 0x34
> *
> */
> @@ -716,7 +716,7 @@ init_io_restrict_pll(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_END_REPEAT - opcode 0x36
> *
> */
> @@ -732,7 +732,7 @@ init_end_repeat(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_COPY - opcode 0x37
> *
> */
> @@ -759,7 +759,7 @@ init_copy(struct nvbios_init *init)
> init_wrvgai(init, port, index, data);
> }
>
> -/**
> +/*
> * INIT_NOT - opcode 0x38
> *
> */
> @@ -771,7 +771,7 @@ init_not(struct nvbios_init *init)
> init_exec_inv(init);
> }
>
> -/**
> +/*
> * INIT_IO_FLAG_CONDITION - opcode 0x39
> *
> */
> @@ -788,7 +788,7 @@ init_io_flag_condition(struct nvbios_init *init)
> init_exec_set(init, false);
> }
>
> -/**
> +/*
> * INIT_GENERIC_CONDITION - opcode 0x3a
> *
> */
> @@ -840,7 +840,7 @@ init_generic_condition(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_IO_MASK_OR - opcode 0x3b
> *
> */
> @@ -859,7 +859,7 @@ init_io_mask_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
> }
>
> -/**
> +/*
> * INIT_IO_OR - opcode 0x3c
> *
> */
> @@ -878,7 +878,7 @@ init_io_or(struct nvbios_init *init)
> init_wrvgai(init, 0x03d4, index, data | (1 << or));
> }
>
> -/**
> +/*
> * INIT_ANDN_REG - opcode 0x47
> *
> */
> @@ -895,7 +895,7 @@ init_andn_reg(struct nvbios_init *init)
> init_mask(init, reg, mask, 0);
> }
>
> -/**
> +/*
> * INIT_OR_REG - opcode 0x48
> *
> */
> @@ -912,7 +912,7 @@ init_or_reg(struct nvbios_init *init)
> init_mask(init, reg, 0, mask);
> }
>
> -/**
> +/*
> * INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
> *
> */
> @@ -942,7 +942,7 @@ init_idx_addr_latched(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_IO_RESTRICT_PLL2 - opcode 0x4a
> *
> */
> @@ -977,7 +977,7 @@ init_io_restrict_pll2(struct nvbios_init *init)
> trace("}]\n");
> }
>
> -/**
> +/*
> * INIT_PLL2 - opcode 0x4b
> *
> */
> @@ -994,7 +994,7 @@ init_pll2(struct nvbios_init *init)
> init_prog_pll(init, reg, freq);
> }
>
> -/**
> +/*
> * INIT_I2C_BYTE - opcode 0x4c
> *
> */
> @@ -1025,7 +1025,7 @@ init_i2c_byte(struct nvbios_init *init)
> }
> }
>
> -/**
> +/*
> * INIT_ZM_I2C_BYTE - opcode 0x4d
> *
> */
> @@ -1051,7
Re: [Nouveau] [PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs
On Fri, May 26, 2023 at 5:21 PM Ilia Mirkin wrote:
>
> On Fri, May 26, 2023 at 5:11 AM Karol Herbst wrote:
> >
> > 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> > was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
> >
> > We use the blit subchannel inside our vblank handling, so we should keep
> > at least this part.
> >
> > v2: Only do it for NV11+ GPUs
> >
> > Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
> > Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> > Signed-off-by: Karol Herbst
> > ---
> > drivers/gpu/drm/nouveau/nouveau_chan.c | 1 +
> > drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
> > drivers/gpu/drm/nouveau/nouveau_drm.c | 20 +---
> > 3 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
> > b/drivers/gpu/drm/nouveau/nouveau_chan.c
> > index e648ecd0c1a0..3dfbc374478e 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_chan.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
> > @@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
> > if (cli)
> > nouveau_svmm_part(chan->vmm->svmm, chan->inst);
> >
> > + nvif_object_dtor(>blit);
> > nvif_object_dtor(>nvsw);
> > nvif_object_dtor(>gart);
> > nvif_object_dtor(>vram);
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
> > b/drivers/gpu/drm/nouveau/nouveau_chan.h
> > index e06a8ffed31a..bad7466bd0d5 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_chan.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
> > @@ -53,6 +53,7 @@ struct nouveau_channel {
> > u32 user_put;
> >
> > struct nvif_object user;
> > + struct nvif_object blit;
> >
> > struct nvif_event kill;
> > atomic_t killed;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index cc7c5b4a05fd..9512f1c2f871 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
> > ret = nvif_object_ctor(>channel->user, "drmNvsw",
> >NVDRM_NVSW,
> > nouveau_abi16_swclass(drm),
> >NULL, 0, >channel->nvsw);
> > +
> > + if (ret == 0 && device->info.chipset >= 0x11) {
>
> Can you double-check that this is needed on NV15? IIRC there's some
> non-linearity of chipsets here which is why we had (some long time
> ago, not sure if it's still there), a chip class which would simplify
> such checks.
>
yeah, it's fine. The old code before 4a16dd9d18a0 had a
"device->info.chipset >= 0x11 ? 0x009f : 0x005f" check when creating
the blit object.
> Cheers,
>
> -ilia
>
Re: [PATCH v2] drm/nouveau: don't detect DSM for non-NVIDIA device
On Tue, May 23, 2023 at 11:12 PM Ratchanan Srirattanamet
wrote:
>
> The call site of nouveau_dsm_pci_probe() uses single set of output
> variables for all invocations. So, we must not write anything to them
> unless it's an NVIDIA device. Otherwise, if we are called with another
> device after the NVIDIA device, we'll clober the result of the NVIDIA
> device.
>
> For example, if the other device doesn't have _PR3 resources, the
> detection later would miss the presence of power resource support, and
> the rest of the code will keep using Optimus DSM, breaking power
> management for that machine.
>
> Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run
> this detection on a non-NVIDIA device anyway. Thus, check at the
> beginning of the detection code if this is an NVIDIA card, and just
> return if it isn't.
>
> This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-:
> wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and
> landed earlier, fixes runtime power management of the NVIDIA card in
> Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code
> will "timeout", sometimes hanging userspace.
>
> As a bonus, we'll also stop preventing _PR3 usage from the bridge for
> unrelated devices, which is always nice, I guess.
>
> Signed-off-by: Ratchanan Srirattanamet
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79
> ---
> V1 -> V2:
> - Update the changelog to indicate that it now actually fixes the issue.
> - Add 'Closes:' tag.
>
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index 8cf096f841a9..a2ae8c21e4dc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -220,6 +220,9 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev,
> acpi_handle *dhandle_out
> int optimus_funcs;
> struct pci_dev *parent_pdev;
>
> + if (pdev->vendor != PCI_VENDOR_ID_NVIDIA)
> + return;
> +
> *has_pr3 = false;
> parent_pdev = pci_upstream_bridge(pdev);
> if (parent_pdev) {
>
> base-commit: 5fe326b4467689ef3690491ee2ad25ff4d81fe59
> --
> 2.34.1
>
Reviewed-by: Karol Herbst
I'll add a Cc: when pushing the change as
I'll also think about how far in the past to get it applied. Though it
shouldn't hurt as it shouldn't make things worse on any system.
[PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs
1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
We use the blit subchannel inside our vblank handling, so we should keep
at least this part.
v2: Only do it for NV11+ GPUs
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 1 +
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 20 +---
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..3dfbc374478e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
if (cli)
nouveau_svmm_part(chan->vmm->svmm, chan->inst);
+ nvif_object_dtor(>blit);
nvif_object_dtor(>nvsw);
nvif_object_dtor(>gart);
nvif_object_dtor(>vram);
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..bad7466bd0d5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -53,6 +53,7 @@ struct nouveau_channel {
u32 user_put;
struct nvif_object user;
+ struct nvif_object blit;
struct nvif_event kill;
atomic_t killed;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index cc7c5b4a05fd..9512f1c2f871 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
ret = nvif_object_ctor(>channel->user, "drmNvsw",
NVDRM_NVSW, nouveau_abi16_swclass(drm),
NULL, 0, >channel->nvsw);
+
+ if (ret == 0 && device->info.chipset >= 0x11) {
+ ret = nvif_object_ctor(>channel->user, "drmBlit",
+ 0x005f, 0x009f,
+ NULL, 0, >channel->blit);
+ }
+
if (ret == 0) {
struct nvif_push *push = drm->channel->chan.push;
- ret = PUSH_WAIT(push, 2);
- if (ret == 0)
+ ret = PUSH_WAIT(push, 8);
+ if (ret == 0) {
+ if (device->info.chipset >= 0x11) {
+ PUSH_NVSQ(push, NV05F, 0x,
drm->channel->blit.handle);
+ PUSH_NVSQ(push, NV09F, 0x0120, 0,
+ 0x0124, 1,
+ 0x0128, 2);
+ }
PUSH_NVSQ(push, NV_SW, 0x,
drm->channel->nvsw.handle);
+ }
}
if (ret) {
- NV_ERROR(drm, "failed to allocate sw class, %d\n", ret);
+ NV_ERROR(drm, "failed to allocate sw or blit class,
%d\n", ret);
nouveau_accel_gr_fini(drm);
return;
}
--
2.40.1
Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays
I wouldn't be surprised if 4a16dd9d18a0 is the culprit and that it was always broken like this with drm fbdev. Anyway, the logs don't indicate we are actually doing anything wrong, It's just that the tty handling is a little bonkers as always. On Thu, May 25, 2023 at 1:37 PM Bagas Sanjaya wrote: > On 5/25/23 17:55, Bagas Sanjaya wrote: > > On 5/25/23 17:52, Bagas Sanjaya wrote: > >> Hi, > >> > >> I notice a regression report on Bugzilla [1]. Quoting from it: > >> > >>> Original Summary: > >>> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers > produce vast raster right and bottom borders on the larger resolution of > two displays > >>> > >>> To reproduce: > >>> 1-connect two unequal native resolution displays to a Tesla or Firmi > GPU > >>> 2-don't have plymouth in use (I don't ever have it installed, so don't > know whether it impacts) > >>> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines > >>> 4-boot Tumbleweed or Fedora 38 > >>> 5-switch to a vtty, e.g. Ctrl-Alt-F3 > >>> > >>> Actual behavior: > >>> 1-Both displays utilize the resolution (same pixel grid) of the lower > resolution display > >>> 2-Lower resolution display behaves as expected (light text on black > background) > >>> 3-Higher resolution display uses same pixels as lower resolution > display, with light text on black background, leaving right side and bottom > raster instead of black > >>> > >>> Expected behavior: > >>> 1-Both displays utilize the resolution (same pixel grid) of the lower > resolution display > >>> 2-Lower resolution display behaves as expected > >>> 3-Entire higher resolution display's background is black instead of > portions in raster > >>> > >>> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which > causes both displays to use the same nominal mode on the full display space. > >>> > >>> Typical other linu line options: > >>> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full > mitigations=none > >>> > >>> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 > displays. > >>> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 > displays. > >>> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with > 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with > 6.2.12 and 6.3.3 on Mageia 9. > >>> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD > Caicos (Terascale2) GPU, or with Intel Eaglelake GPU. > >>> Tested only on legacy booting (no UEFI support). > >>> Others might describe what I call "raster" as multicolored snow. > >> > >> See bugzilla for the full thread and attached dmesg. > >> > >> Anyway, I'm adding it to regzbot: > >> > >> #regzbot introduced: v6.1.12..v6.2.12 > >> #regzbot title: vast raster right and bottom borders on larger display > (two displays with inequal resolution) unless forcing resolution with > video= parameter > >> > > > > Oops, I forget to add bugzilla link: > > > > #regzbot introduced: v6.1.12..v6.2.12 > https://bugzilla.kernel.org/show_bug.cgi?id=217479 > > #regzbot from: Felix Miata > > > > Oops, again, I messed up the regzbot entry (reporter field still assigned > to me). Inconclusiving... > > #regzbot inconclusive: Wrong reporter assigned (from: doesn't take effect) > > Please ignore this thread as I will send a new one with proper regzbot > commands. > > Thanks. > > -- > An old man doll... just what I always wanted! - Clara > >
Re: [PATCH] drm/nouveau/acr: Abort loading ACR if no firmware was found
On Mon, May 22, 2023 at 10:18 PM Karol Herbst wrote:
>
> This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary
> firmware files couldn't be loaded.
>
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/212
> Fixes: 4b569ded09fd ("drm/nouveau/acr/ga102: initial support")
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> index 795f3a649b12..6388234c352c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
> @@ -224,7 +224,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *subdev)
> u64 falcons;
> int ret, i;
>
> - if (list_empty(>hsfw)) {
> + if (list_empty(>hsfw) || !acr->func->wpr_layout) {
Now thinking about this, it should probably also check acr->func...
> nvkm_debug(subdev, "No HSFW(s)\n");
> nvkm_acr_cleanup(acr);
> return 0;
> --
> 2.40.1
>
[PATCH] drm/nouveau/acr: Abort loading ACR if no firmware was found
This fixes a NULL pointer access inside nvkm_acr_oneinit in case necessary
firmware files couldn't be loaded.
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/212
Fixes: 4b569ded09fd ("drm/nouveau/acr/ga102: initial support")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
index 795f3a649b12..6388234c352c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c
@@ -224,7 +224,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *subdev)
u64 falcons;
int ret, i;
- if (list_empty(>hsfw)) {
+ if (list_empty(>hsfw) || !acr->func->wpr_layout) {
nvkm_debug(subdev, "No HSFW(s)\n");
nvkm_acr_cleanup(acr);
return 0;
--
2.40.1
Re: [PATCH] drm/nouveau/acr/ga102: set variable ga102_gsps storage-class-specifier to static
Reviewed-by: Karol Herbst
On Wed, May 17, 2023 at 3:31 PM Tom Rix wrote:
>
> smatch reports
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c:49:1: warning: symbol
> 'ga102_gsps' was not declared. Should it be static?
>
> This variable is only used in its defining file, so it should be static
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c
> index 525267412c3e..a3996ceca995 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ga102.c
> @@ -45,7 +45,7 @@ ga102_gsp_nofw(struct nvkm_gsp *gsp, int ver, const struct
> nvkm_gsp_fwif *fwif)
> return 0;
> }
>
> -struct nvkm_gsp_fwif
> +static struct nvkm_gsp_fwif
> ga102_gsps[] = {
> { -1, ga102_gsp_nofw, _gsp },
> {}
> --
> 2.27.0
>
Re: [PATCH] drm/nouveau: dispnv50: fix missing-prototypes warning
Reviewed-by: Karol Herbst
will merge soon
On Mon, Apr 17, 2023 at 11:03 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> nv50_display_create() is declared in another header, along with
> a couple of declarations that are now outdated:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
> for 'nv50_display_create'
>
> Fixes: ba801ef068c1 ("drm/nouveau/kms: display destroy/init/fini hooks can be
> static")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 +
> drivers/gpu/drm/nouveau/nv50_display.h | 4 +---
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 5bb777ff1313..9b6824f6b9e4 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -64,6 +64,7 @@
> #include "nouveau_connector.h"
> #include "nouveau_encoder.h"
> #include "nouveau_fence.h"
> +#include "nv50_display.h"
>
> #include
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.h
> b/drivers/gpu/drm/nouveau/nv50_display.h
> index fbd3b15583bc..60f77766766e 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.h
> +++ b/drivers/gpu/drm/nouveau/nv50_display.h
> @@ -31,7 +31,5 @@
> #include "nouveau_reg.h"
>
> int nv50_display_create(struct drm_device *);
> -void nv50_display_destroy(struct drm_device *);
> -int nv50_display_init(struct drm_device *);
> -void nv50_display_fini(struct drm_device *);
> +
> #endif /* __NV50_DISPLAY_H__ */
> --
> 2.39.2
>
[PATCH] drm/nouveau: bring back blit subchannel for pre nv50 GPUs
1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
We use the blit subchannel inside our vblank handling, so we should keep
at least this part.
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 1 +
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 19 ---
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..3dfbc374478e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
if (cli)
nouveau_svmm_part(chan->vmm->svmm, chan->inst);
+ nvif_object_dtor(>blit);
nvif_object_dtor(>nvsw);
nvif_object_dtor(>gart);
nvif_object_dtor(>vram);
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..bad7466bd0d5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -53,6 +53,7 @@ struct nouveau_channel {
u32 user_put;
struct nvif_object user;
+ struct nvif_object blit;
struct nvif_event kill;
atomic_t killed;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index cc7c5b4a05fd..59e040a93a41 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -369,15 +369,28 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
ret = nvif_object_ctor(>channel->user, "drmNvsw",
NVDRM_NVSW, nouveau_abi16_swclass(drm),
NULL, 0, >channel->nvsw);
+
+ if (ret == 0) {
+ u32 blit_class = device->info.chipset >= 0x11 ? 0x009f
: 0x005f;
+ ret = nvif_object_ctor(>channel->user, "drmBlit",
+ 0x005f, blit_class,
+ NULL, 0, >channel->blit);
+ }
+
if (ret == 0) {
struct nvif_push *push = drm->channel->chan.push;
- ret = PUSH_WAIT(push, 2);
- if (ret == 0)
+ ret = PUSH_WAIT(push, 8);
+ if (ret == 0) {
+ PUSH_NVSQ(push, NV05F, 0x,
drm->channel->blit.handle);
+ PUSH_NVSQ(push, NV09F, 0x0120, 0,
+ 0x0124, 1,
+ 0x0128, 2);
PUSH_NVSQ(push, NV_SW, 0x,
drm->channel->nvsw.handle);
+ }
}
if (ret) {
- NV_ERROR(drm, "failed to allocate sw class, %d\n", ret);
+ NV_ERROR(drm, "failed to allocate sw or blit class,
%d\n", ret);
nouveau_accel_gr_fini(drm);
return;
}
--
2.40.1
Re: [RFC] Plane color pipeline KMS uAPI
On Wed, May 10, 2023 at 9:59 AM Jonas Ådahl wrote: > > On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote: > > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote: > > > > > There are also other vendor side effects to having this in userspace. > > > > > > Will the library have a loader? > > > Will it allow proprietary plugins? > > > Will it allow proprietary reimplementations? > > > What will happen when a vendor wants distros to ship their > > > proprietary fork of said library? > > > > > > How would NVIDIA integrate this with their proprietary stack? > > > > Since all color operations exposed by KMS are standard, the library > > would just be a simple one: no loader, no plugin, no proprietary pieces, > > etc. > > > > There might be pipelines/color-ops only exposed by proprietary out of > tree drivers; the operation types and semantics should ideally be > defined upstream, but the code paths would in practice be vendor > specific, potentially without any upstream driver using them. It should > be clear whether an implementation that makes such a pipeline work is in > scope for the upstream library. > > The same applies to the kernel; it must be clear whether pipeline > elements that potentially will only be exposed by out of tree drivers > will be acceptable upstream, at least as documented operations. > they aren't. All code in the kernel needs to be used by in-tree drivers otherwise it's fair to delete it. DRM requires any UAPI change to have a real open source user in space user. Nvidia knows this and they went to great lengths to fulfill this requirement in the past. They'll manage. > > Jonas >
Re: Disabling -Warray-bounds for gcc-13 too
On Fri, Apr 28, 2023 at 1:27 AM Lyude Paul wrote:
>
> On Fri, 2023-04-28 at 00:50 +0200, Karol Herbst wrote:
> > On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
> > >
> > > Hey Linus, Kees. Responses below
> > >
> > > On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > > > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> > > > wrote:
> > > > > Kees,
> > > > > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > > > > in the process I got gcc-13 which is not WERROR-clean because we only
> > > > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > > > > has all the same issues.
> > > > >
> > > > > And I want to be able to do my arm64 builds with WERROR on still...
> > > > >
> > > > > I guess it never made much sense to hope it was going to go away
> > > > > without having a confirmation, so I just changed it to be gcc-11+.
> > > >
> > > > Yeah, that's fine. GCC 13 released without having a fix for at least
> > > > one (hopefully last) known array-bounds vs jump threading bug:
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> > > >
> > > > > And one of them is from you.
> > > > >
> > > > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > > > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > > > > changes
> > > > >
> > > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > > > >
> > > > > to
> > > > >
> > > > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8
> > > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > >
> > > > > and then does
> > > > >
> > > > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > > > >
> > > > > where that 'args.dp.dpcd' is a 16-byte array, and
> > > > > DP_RECEIVER_CAP_SIZE is 15.
> > > >
> > > > Yeah, it was an incomplete fix. I sent the other half here, but it fell
> > > > through the cracks:
> > > > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
> > >
> > > Thanks for bringing this to our attention, yeah this definitely just looks
> > > like it got missed somewhere down the line. It looks like Karol responded
> > > already so I assume the patch is in the pipeline now, but let me know if
> > > there's anything else you need.
> > >
> >
> > uhm, I didn't push anything, but I can push it through drm-misct asap,
> > just wanted to ask if somebody wants to pick a quicker route. But I
> > guess not?
>
> Ah whoops, I misunderstood! Yeah I would say we should just go ahead and push
> it since I don't see any indication here that anyone else has.
>
okay, will do so tomorrow then.
> >
> > > >
> > > >
> > > >
> > > > >
> > > >
> > > > > I think it's all entirely harmless from a code generation standpoint,
> > > > > because the 15-byte field will be padded out to 16 bytes in the
> > > > > structure that contains it, but it's most definitely buggy.
> > > >
> > > > Right; between this, that GCC 13 wasn't released yet, and I had no
> > > > feedback from NV folks, I didn't chase down landing that fix.
> > > >
> > > > >
> > > > > So that warning does find real cases of wrong code. But when those
> > > > > real cases are hidden by hundreds of lines of unfixable false
> > > > > positives, we don't have much choice.
> > > >
> > > > Yup, totally agreed. The false positives I've looked at all seem to be
> > > > similar to the outstanding jump threading bug, so I'm hoping once that
> > > > gets fixed we'll finally have a good signal with that warning enabled.
> > > > :)
> > > >
> > > > -Kees
> > > >
> > > >
> > >
> > > --
> > > Cheers,
> > > Lyude Paul (she/her)
> > > Software Engineer at Red Hat
> > >
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
Re: Disabling -Warray-bounds for gcc-13 too
On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
>
> Hey Linus, Kees. Responses below
>
> On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> > wrote:
> > > Kees,
> > > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > > in the process I got gcc-13 which is not WERROR-clean because we only
> > > limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> > > has all the same issues.
> > >
> > > And I want to be able to do my arm64 builds with WERROR on still...
> > >
> > > I guess it never made much sense to hope it was going to go away
> > > without having a confirmation, so I just changed it to be gcc-11+.
> >
> > Yeah, that's fine. GCC 13 released without having a fix for at least one
> > (hopefully last) known array-bounds vs jump threading bug:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
> >
> > > And one of them is from you.
> > >
> > > In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> > > nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> > > changes
> > >
> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > >
> > > to
> > >
> > > nvif_outp_acquire_dp(struct nvif_outp *outp, u8
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >
> > > and then does
> > >
> > >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> > >
> > > where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE is
> > > 15.
> >
> > Yeah, it was an incomplete fix. I sent the other half here, but it fell
> > through the cracks:
> > https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
>
> Thanks for bringing this to our attention, yeah this definitely just looks
> like it got missed somewhere down the line. It looks like Karol responded
> already so I assume the patch is in the pipeline now, but let me know if
> there's anything else you need.
>
uhm, I didn't push anything, but I can push it through drm-misct asap,
just wanted to ask if somebody wants to pick a quicker route. But I
guess not?
> >
> >
> >
> > >
> >
> > > I think it's all entirely harmless from a code generation standpoint,
> > > because the 15-byte field will be padded out to 16 bytes in the
> > > structure that contains it, but it's most definitely buggy.
> >
> > Right; between this, that GCC 13 wasn't released yet, and I had no feedback
> > from NV folks, I didn't chase down landing that fix.
> >
> > >
> > > So that warning does find real cases of wrong code. But when those
> > > real cases are hidden by hundreds of lines of unfixable false
> > > positives, we don't have much choice.
> >
> > Yup, totally agreed. The false positives I've looked at all seem to be
> > similar to the outstanding jump threading bug, so I'm hoping once that gets
> > fixed we'll finally have a good signal with that warning enabled. :)
> >
> > -Kees
> >
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
Re: Disabling -Warray-bounds for gcc-13 too
On Sun, Apr 23, 2023 at 10:24 PM Kees Cook wrote:
>
> On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> wrote:
> >Kees,
> > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> >in the process I got gcc-13 which is not WERROR-clean because we only
> >limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> >has all the same issues.
> >
> >And I want to be able to do my arm64 builds with WERROR on still...
> >
> >I guess it never made much sense to hope it was going to go away
> >without having a confirmation, so I just changed it to be gcc-11+.
>
> Yeah, that's fine. GCC 13 released without having a fix for at least one
> (hopefully last) known array-bounds vs jump threading bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
>
> >And one of them is from you.
> >
> >In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> >nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> >changes
> >
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> >
> >to
> >
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >
> >and then does
> >
> >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> >
> >where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE is 15.
>
> Yeah, it was an incomplete fix. I sent the other half here, but it fell
> through the cracks:
> https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
>
left a review on that patch. Any preferred way of getting it upstream?
I could push it through drm-misc, but the delay until it reaches
Linus' tree is a bit high.
>
>
> >
>
> >I think it's all entirely harmless from a code generation standpoint,
> >because the 15-byte field will be padded out to 16 bytes in the
> >structure that contains it, but it's most definitely buggy.
>
> Right; between this, that GCC 13 wasn't released yet, and I had no feedback
> from NV folks, I didn't chase down landing that fix.
>
> >
> >So that warning does find real cases of wrong code. But when those
> >real cases are hidden by hundreds of lines of unfixable false
> >positives, we don't have much choice.
>
> Yup, totally agreed. The false positives I've looked at all seem to be
> similar to the outstanding jump threading bug, so I'm hoping once that gets
> fixed we'll finally have a good signal with that warning enabled. :)
>
> -Kees
>
>
> --
> Kees Cook
>
Re: [PATCH] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
On Wed, Mar 22, 2023 at 10:40 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 2/4/23 12:43, Kees Cook wrote:
> > 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-devel@lists.freedesktop.org
> > Cc: nouv...@lists.freedesktop.org
> > Signed-off-by: Kees Cook
>
> Reviewed-by: Gustavo A. R. Silva
>
Reviewed-by: Karol Herbst
sorry for not seeing this earlier.
> Thanks!
> --
> Gustavo
>
> > ---
> > 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 eb99d84eb844..16d4ad5023a3 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 b7631c1ab242..4e7f873f66e2 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 4f0ca709c85a..fc283a4a1522 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;
>
Re: [PATCH 0/9] GPU-DRM-nouveau: Adjustments for seven function implementations
On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring wrote: > > Date: Sun, 16 Apr 2023 11:22:23 +0200 > > Several update suggestions were taken into account > from static source code analysis. > Reviewed-by: Karol Herbst > Markus Elfring (9): > debugfs: Move an expression into a function call parameter > in nouveau_debugfs_pstate_set() > debugfs: Move a variable assignment behind a null pointer check > in nouveau_debugfs_pstate_get() > debugfs: Use seq_putc() > in nouveau_debugfs_pstate_get() > debugfs: Replace five seq_printf() calls by seq_puts() > in nouveau_debugfs_pstate_get() > power_budget: Move an expression into a macro call parameter > in nvbios_power_budget_header() > clk: Move a variable assignment behind a null pointer check > in nvkm_pstate_new() > pci: Move a variable assignment behind condition checks > in nvkm_pcie_set_link() > pci: Move an expression into a function call parameter > in nvkm_pcie_set_link() > therm: Move an assignment statement behind a null pointer check > in two functions > > drivers/gpu/drm/nouveau/nouveau_debugfs.c | 19 ++- > .../nouveau/nvkm/subdev/bios/power_budget.c | 3 +-- > .../gpu/drm/nouveau/nvkm/subdev/clk/base.c| 2 +- > .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 7 +++ > .../drm/nouveau/nvkm/subdev/therm/fanpwm.c| 2 +- > .../drm/nouveau/nvkm/subdev/therm/fantog.c| 2 +- > 6 files changed, 17 insertions(+), 18 deletions(-) > > -- > 2.40.0 >
Re: [PATCH v3] drm/nouveau: fix incorrect conversion to dma_resv_wait_timeout()
On Mon, Apr 17, 2023 at 7:55 AM Christian König
wrote:
>
> Am 15.04.23 um 04:02 schrieb John Ogness:
> > Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
> > converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout().
> > However, dma_resv_wait_timeout() returns greater than zero on
> > success as opposed to ttm_bo_wait_ctx(). As a result, relocs
> > will fail and log errors even when it was a success.
> >
> > Change the return code handling to match that of
> > nouveau_gem_ioctl_cpu_prep(), which was already using
> > dma_resv_wait_timeout() correctly.
> >
> > Fixes: 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait")
> > Reported-by: Tanmay Bhushan <0070472...@gmail.com>
> > Link:
> > https://lore.kernel.org/lkml/20230119225351.71657-1-0070472...@gmail.com
> > Signed-off-by: John Ogness
>
> Reviewed-by: Christian König
>
Reviewed-by: Karol Herbst
will push shortly to drm-misc-fixes
> > ---
> > I just realized that the nouveau driver style prefers to scope
> > variables used only in loops.
> >
> > v3: Define @lret within the for-loop.
> >
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > index f77e44958037..ab9062e50977 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > @@ -645,7 +645,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> > struct drm_nouveau_gem_pushbuf_reloc *reloc,
> > struct drm_nouveau_gem_pushbuf_bo *bo)
> > {
> > - long ret = 0;
> > + int ret = 0;
> > unsigned i;
> >
> > for (i = 0; i < req->nr_relocs; i++) {
> > @@ -653,6 +653,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
> > struct drm_nouveau_gem_pushbuf_bo *b;
> > struct nouveau_bo *nvbo;
> > uint32_t data;
> > + long lret;
> >
> > if (unlikely(r->bo_index >= req->nr_buffers)) {
> > NV_PRINTK(err, cli, "reloc bo index invalid\n");
> > @@ -703,13 +704,18 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli
> > *cli,
> > data |= r->vor;
> > }
> >
> > - ret = dma_resv_wait_timeout(nvbo->bo.base.resv,
> > - DMA_RESV_USAGE_BOOKKEEP,
> > - false, 15 * HZ);
> > - if (ret == 0)
> > + lret = dma_resv_wait_timeout(nvbo->bo.base.resv,
> > + DMA_RESV_USAGE_BOOKKEEP,
> > + false, 15 * HZ);
> > + if (!lret)
> > ret = -EBUSY;
> > + else if (lret > 0)
> > + ret = 0;
> > + else
> > + ret = lret;
> > +
> > if (ret) {
> > - NV_PRINTK(err, cli, "reloc wait_idle failed: %ld\n",
> > + NV_PRINTK(err, cli, "reloc wait_idle failed: %d\n",
> > ret);
> > break;
> > }
> >
> > base-commit: 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d
>
Re: [PATCH -next] drm/nouveau/disp: make gv100_disp_core_mthd_base static
Reviewed-by: Karol Herbst
On Sat, Sep 24, 2022 at 10:00 AM ruanjinjie wrote:
>
> The symbol is not used outside of the file, so mark it static.
>
> Fixes the following warning:
>
> ./drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:591:1: warning:
> symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static?
>
> Signed-off-by: ruanjinjie
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> index 6b9d49270fa7..347c12a1fcb7 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> @@ -587,7 +587,7 @@ gv100_disp_curs = {
> .user = 73,
> };
>
> -const struct nvkm_disp_mthd_list
> +static const struct nvkm_disp_mthd_list
> gv100_disp_core_mthd_base = {
> .mthd = 0x,
> .addr = 0x00,
> --
> 2.25.1
>
Re: [PATCH] drm/nouveau/mc/ga100: make ga100_mc_device static
Reviewed-by: Karol Herbst
On Thu, Dec 29, 2022 at 4:52 PM Ben Dooks wrote:
>
> Make ga100_mc_device static as it isn't exported, to
> fix the following sparse warning:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c:51:1: warning: symbol
> 'ga100_mc_device' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> index 1e2eabec1a76..5d28d30d09d5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> @@ -47,7 +47,7 @@ ga100_mc_device_enabled(struct nvkm_mc *mc, u32 mask)
> return (nvkm_rd32(mc->subdev.device, 0x000600) & mask) == mask;
> }
>
> -const struct nvkm_mc_device_func
> +static const struct nvkm_mc_device_func
> ga100_mc_device = {
> .enabled = ga100_mc_device_enabled,
> .enable = ga100_mc_device_enable,
> --
> 2.39.0
>
[PATCH] drm/nouveau/fb: add missing sysmen flush callbacks
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/203
Fixes: 5728d064190e1 ("drm/nouveau/fb: handle sysmem flush page from common
code")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
index 76678dd60f93f..c4c6f67af7ccc 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf108.c
@@ -31,6 +31,7 @@ gf108_fb = {
.init = gf100_fb_init,
.init_page = gf100_fb_init_page,
.intr = gf100_fb_intr,
+ .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
.ram_new = gf108_ram_new,
.default_bigpage = 17,
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
index f73442ccb424b..433fa966ba231 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c
@@ -77,6 +77,7 @@ gk104_fb = {
.init = gf100_fb_init,
.init_page = gf100_fb_init_page,
.intr = gf100_fb_intr,
+ .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
.ram_new = gk104_ram_new,
.default_bigpage = 17,
.clkgate_pack = gk104_fb_clkgate_pack,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
index 45d6cdffafeed..4dc283dedf8b5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
@@ -59,6 +59,7 @@ gk110_fb = {
.init = gf100_fb_init,
.init_page = gf100_fb_init_page,
.intr = gf100_fb_intr,
+ .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
.ram_new = gk104_ram_new,
.default_bigpage = 17,
.clkgate_pack = gk110_fb_clkgate_pack,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
index de52462a92bf0..90bfff616d35b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm107.c
@@ -31,6 +31,7 @@ gm107_fb = {
.init = gf100_fb_init,
.init_page = gf100_fb_init_page,
.intr = gf100_fb_intr,
+ .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
.ram_new = gm107_ram_new,
.default_bigpage = 17,
};
--
2.39.2
Re: [PATCH] drm/nouveau/disp: Support more modes by checking with lower bpc
On Fri, Mar 31, 2023 at 12:39 AM Karol Herbst wrote:
>
> This allows us to advertise more modes especially on HDR displays.
>
> Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP
> adapter. Also fixes similiar issues for users running into this.
>
> Cc: sta...@vger.kernel.org # 5.10+
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 8 ---
> 2 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index ed9d374147b8d..f28e47c161dd9 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -363,6 +363,35 @@ nv50_outp_atomic_check_view(struct drm_encoder *encoder,
> return 0;
> }
>
> +static void
> +nv50_outp_atomic_fix_depth(struct drm_encoder *encoder, struct
> drm_crtc_state *crtc_state)
> +{
> + struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> + struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> + struct drm_display_mode *mode = >state.adjusted_mode;
> + unsigned int max_rate, mode_rate;
> +
> + switch (nv_encoder->dcb->type) {
> + case DCB_OUTPUT_DP:
> + max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw;
> +
> +/* we don't support more than 10 anyway */
> + asyh->or.bpc = max_t(u8, asyh->or.bpc, 10);
luckily I didn't push yet, but this has to be `min_t` :)
> +
> + /* reduce the bpc until it works out */
> + while (asyh->or.bpc > 6) {
> + mode_rate = DIV_ROUND_UP(mode->clock * asyh->or.bpc *
> 3, 8);
> + if (mode_rate <= max_rate)
> + break;
> +
> + asyh->or.bpc -= 2;
> + }
> + break;
> + default:
> + break;
> + }
> +}
> +
> static int
> nv50_outp_atomic_check(struct drm_encoder *encoder,
>struct drm_crtc_state *crtc_state,
> @@ -381,6 +410,9 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
> if (crtc_state->mode_changed || crtc_state->connectors_changed)
> asyh->or.bpc = connector->display_info.bpc;
>
> + /* We might have to reduce the bpc */
> + nv50_outp_atomic_fix_depth(encoder, crtc_state);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index e00876f92aeea..d49b4875fc3c9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -263,8 +263,6 @@ nouveau_dp_irq(struct work_struct *work)
> }
>
> /* TODO:
> - * - Use the minimum possible BPC here, once we add support for the max bpc
> - * property.
> * - Validate against the DP caps advertised by the GPU (we don't check these
> * yet)
> */
> @@ -276,7 +274,11 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> {
> const unsigned int min_clock = 25000;
> unsigned int max_rate, mode_rate, ds_max_dotclock, clock =
> mode->clock;
> - const u8 bpp = connector->display_info.bpc * 3;
> + /* Check with the minmum bpc always, so we can advertise better modes.
> +* In particlar not doing this causes modes to be dropped on HDR
> +* displays as we might check with a bpc of 16 even.
> +*/
> + const u8 bpp = 6 * 3;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
> --
> 2.39.2
>
[PATCH] drm/nouveau/disp: Support more modes by checking with lower bpc
This allows us to advertise more modes especially on HDR displays.
Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP
adapter. Also fixes similiar issues for users running into this.
Cc: sta...@vger.kernel.org # 5.10+
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +
drivers/gpu/drm/nouveau/nouveau_dp.c| 8 ---
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index ed9d374147b8d..f28e47c161dd9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -363,6 +363,35 @@ nv50_outp_atomic_check_view(struct drm_encoder *encoder,
return 0;
}
+static void
+nv50_outp_atomic_fix_depth(struct drm_encoder *encoder, struct drm_crtc_state
*crtc_state)
+{
+ struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
+ struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+ struct drm_display_mode *mode = >state.adjusted_mode;
+ unsigned int max_rate, mode_rate;
+
+ switch (nv_encoder->dcb->type) {
+ case DCB_OUTPUT_DP:
+ max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw;
+
+/* we don't support more than 10 anyway */
+ asyh->or.bpc = max_t(u8, asyh->or.bpc, 10);
+
+ /* reduce the bpc until it works out */
+ while (asyh->or.bpc > 6) {
+ mode_rate = DIV_ROUND_UP(mode->clock * asyh->or.bpc *
3, 8);
+ if (mode_rate <= max_rate)
+ break;
+
+ asyh->or.bpc -= 2;
+ }
+ break;
+ default:
+ break;
+ }
+}
+
static int
nv50_outp_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
@@ -381,6 +410,9 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
if (crtc_state->mode_changed || crtc_state->connectors_changed)
asyh->or.bpc = connector->display_info.bpc;
+ /* We might have to reduce the bpc */
+ nv50_outp_atomic_fix_depth(encoder, crtc_state);
+
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index e00876f92aeea..d49b4875fc3c9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -263,8 +263,6 @@ nouveau_dp_irq(struct work_struct *work)
}
/* TODO:
- * - Use the minimum possible BPC here, once we add support for the max bpc
- * property.
* - Validate against the DP caps advertised by the GPU (we don't check these
* yet)
*/
@@ -276,7 +274,11 @@ nv50_dp_mode_valid(struct drm_connector *connector,
{
const unsigned int min_clock = 25000;
unsigned int max_rate, mode_rate, ds_max_dotclock, clock = mode->clock;
- const u8 bpp = connector->display_info.bpc * 3;
+ /* Check with the minmum bpc always, so we can advertise better modes.
+* In particlar not doing this causes modes to be dropped on HDR
+* displays as we might check with a bpc of 16 even.
+*/
+ const u8 bpp = 6 * 3;
if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
return MODE_NO_INTERLACE;
--
2.39.2
Re: [PATCH 34/37] drm/nouveau/nvkm/engine/gr/tu102: Completely remove unused function ‘tu102_gr_load’
On Fri, Mar 17, 2023 at 9:23 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning:
> ‘tu102_gr_load’ defined but not used [-Wunused-function]
>
mhh, this looks a little fishy and might be a mistake not using this function.
Ben, is it safe to remove it? The code seems to be slightly different
things, but also looks like it needs to be rewritten a little anyway.
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> index 10a7e59482a6f..a7775aa185415 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c
> @@ -206,19 +206,6 @@ tu102_gr_av_to_init_veid(struct nvkm_blob *blob, struct
> gf100_gr_pack **ppack)
> return gk20a_gr_av_to_init_(blob, 64, 0x0010, ppack);
> }
>
> -static int
> -tu102_gr_load(struct gf100_gr *gr, int ver, const struct gf100_gr_fwif *fwif)
> -{
> - int ret;
> -
> - ret = gm200_gr_load(gr, ver, fwif);
> - if (ret)
> - return ret;
> -
> - return gk20a_gr_load_net(gr, "gr/", "sw_veid_bundle_init", ver,
> tu102_gr_av_to_init_veid,
> ->bundle_veid);
> -}
> -
> static const struct gf100_gr_fwif
> tu102_gr_fwif[] = {
> { 0, gm200_gr_load, _gr, _gr_fecs_acr,
> _gr_gpccs_acr },
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [PATCH 31/37] drm/nouveau/dispnv04/crtc: Demote kerneldoc abuses
nouveau changes up to here are: Reviewed-by: Karol Herbst On Fri, Mar 17, 2023 at 9:23 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > drivers/gpu/drm/nouveau/dispnv04/crtc.c:629: warning: This comment starts > with '/**', but isn't a kernel-doc comment. Refer > Documentation/doc-guide/kernel-doc.rst > > Cc: Ben Skeggs > Cc: Karol Herbst > Cc: Lyude Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > index a6f2e681bde98..7794902df17d5 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > @@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct > drm_display_mode *mode) > regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > @@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc, struct > drm_framebuffer *old_fb) > return ret; > } > > -/** > +/* > * Sets up registers for the given mode/adjusted_mode pair. > * > * The clocks, CRTCs and outputs attached to this CRTC must be off. > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Fri, Mar 10, 2023 at 10:26 AM Chris Clayton wrote: > > Hi. > > Is it likely that this fix will be sumbmitted to mainline during the ongoing > 6.3 development cycle? > yes, it's already pushed to drm-misc-fixed, which then will go into the current devel cycle. I just don't know when it's the next time it will be pushed upwards, but it should get there eventually. And because it also contains a Fixes tag it will be backported to older branches as well. > Chris > > On 20/02/2023 22:16, Ben Skeggs wrote: > > On Mon, 20 Feb 2023 at 21:27, Karol Herbst wrote: > >> > >> On Mon, Feb 20, 2023 at 11:51 AM Chris Clayton > >> wrote: > >>> > >>> > >>> > >>> On 20/02/2023 05:35, Ben Skeggs wrote: > >>>> On Sun, 19 Feb 2023 at 04:55, Chris Clayton > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 18/02/2023 15:19, Chris Clayton wrote: > >>>>>> > >>>>>> > >>>>>> On 18/02/2023 12:25, Karol Herbst wrote: > >>>>>>> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 15/02/2023 11:09, Karol Herbst wrote: > >>>>>>>>> On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > >>>>>>>>> (Thorsten Leemhuis) wrote: > >>>>>>>>>> > >>>>>>>>>> On 13.02.23 10:14, Chris Clayton wrote: > >>>>>>>>>>> On 13/02/2023 02:57, Dave Airlie wrote: > >>>>>>>>>>>> On Sun, 12 Feb 2023 at 00:43, Chris Clayton > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 10/02/2023 19:33, Linux regression tracking (Thorsten > >>>>>>>>>>>>> Leemhuis) wrote: > >>>>>>>>>>>>>> On 10.02.23 20:01, Karol Herbst wrote: > >>>>>>>>>>>>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking > >>>>>>>>>>>>>>> (Thorsten > >>>>>>>>>>>>>>> Leemhuis) wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 08.02.23 09:48, Chris Clayton wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I'm assuming that we are not going to see a fix for this > >>>>>>>>>>>>>>>>> regression before 6.2 is released. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Yeah, looks like it. That's unfortunate, but happens. But > >>>>>>>>>>>>>>>> there is still > >>>>>>>>>>>>>>>> time to fix it and there is one thing I wonder: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Did any of the nouveau developers look at the netconsole > >>>>>>>>>>>>>>>> captures Chris > >>>>>>>>>>>>>>>> posted more than a week ago to check if they somehow help to > >>>>>>>>>>>>>>>> track down > >>>>>>>>>>>>>>>> the root of this problem? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I did now and I can't spot anything. I think at this point it > >>>>>>>>>>>>>>> would > >>>>>>>>>>>>>>> make sense to dump the active tasks/threads via sqsrq keys to > >>>>>>>>>>>>>>> see if > >>>>>>>>>>>>>>> any is in a weird state preventing the machine from shutting > >>>>>>>>>>>>>>> down. > >
Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand wrote: > > On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote: > > On 08/03/2023 02.34, Björn Roy Baron wrote: > > > > +// SAFETY: This is just the ioctl > > > > argument, which hopefully has the right type > > > > +// (we've done our best checking the > > > > size). > > > > > > In the rust tree there is the ReadableFromBytes [1] trait which > > > indicates that it is safe to read arbitrary bytes into the type. > > > Maybe you could add it as bound on the argument type when it lands > > > in rust-next? This way you can't end up with for example a struct > > > containing a bool with the byte value 2, which is UB. > > > > There's actually a much bigger story here, because that trait isn't > > really very useful without a way to auto-derive it. I need the same > > kind > > of guarantee for all the GPU firmware structs... > > > > There's one using only declarative macros [1] and one using proc > > macros > > [2]. And then, since ioctl arguments are declared in C UAPI header > > files, we need a way to be able to derive those traits for them... > > which > > I guess means bindgen changes? > > It'd be cool to be able to auto-verify that uAPI structs are all > tightly packed and use the right subset of types. Maybe not possible > this iteration but it'd be cool to see in future. I'd like to see it > for C as well, ideally. > > ~Faith > I'm sure that with a macro you could verify that a struct definition doesn't contain any gaps, just not sure on how one would enforce that. Could add a trait which can only be implemented through a proc_macro? Maybe we can have a proc_macro ensuring no gaps? Would be cool tech to have indeed.
Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
On Wed, Mar 8, 2023 at 4:09 PM Christian König wrote: > > Am 08.03.23 um 15:43 schrieb Karol Herbst: > > [SNIP] > > "further"? There was no discussion at all, > > Yeah, well that is exactly what I wanted to archive. > > > you just started off like > > that. If you think somebody misses that connection, you can point out > > to documentation/videos whatever so the contributor can understand > > what's wrong with an approach. You did that, so that's fine. It's just > > starting off _any_ discussion with a "Well complete NAK" is terrible > > style. I'd feel uncomfortable if that happened to me and I'm sure > > there are enough people like that that we should be more reasonable > > with our replies. Just.. don't. > > > > We are all humans here and people react negatively to such things. And > > if people do it on purpose it just makes it worse. > > I completely see your point, I just don't know how to improve it. > > I don't stop people like this because I want to make them uncomfortable > but because I want to prevent further discussions on that topic. > > In other words how can I make people notice that this is something > fundamental while still being polite? > I think a little improvement over this would be to at least wait a few replies before resorting to those strong statements. Just before it becomes a risk in just wasting time. > >>>> This is clearly going against the idea of having jobs only depend on > >>>> fences and nothing else which is mandatory for correct memory management. > >>>> > >>> I'm sure it's all documented and there is a design document on how > >>> things have to look like you can point out? Might help to get a better > >>> understanding on how things should be. > >> Yeah, that's the problematic part. We have documented this very > >> extensively: > >> https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences > >> > >> And both Jason and Daniel gave talks about the underlying problem and > > fyi: > > s/Jason/Faith/g > > +1. I wasn't aware of that. > > >> try to come up with patches to raise warnings when that happens, but > >> people still keep coming up with the same idea over and over again. > >> > > Yes, and we'll have to tell them over and over again. Nothing wrong > > with that. That's just part of maintaining such a big subsystem. And > > that's definitely not a valid reason to phrase things like above. > > > >> It's just that the technical relationship between preventing jobs from > >> running and with that preventing dma_fences from signaling and the core > >> memory management with page faults and shrinkers waiting for those > >> fences is absolutely not obvious. > >> > >> We had at least 10 different teams from different companies falling into > >> the same trap already and either the patches were rejected of hand or > >> had to painfully reverted or mitigated later on. > >> > > Sure, but that's just part of the job. And pointing out fundamental > > mistakes early on is important, but the situation won't get any better > > by being like that. Yes, we'll have to repeat the same words over and > > over again, and yes that might be annoying, but that's just how it is. > > Well I have no problem explaining people why a solution doesn't work. > > But what usually happens is that people don't realize that they need to > back of from a design and completely start over. > > Regards, > Christian. > > > > >> Regards, > >> Christian. > >> > >>>> If the hw is busy with something you need to return the fence for this > >>>> from the prepare_job callback so that the scheduler can be notified when > >>>> the hw is available again. > >>>> > >>>> Regards, > >>>> Christian. > >>>> > >>>>> Signed-off-by: Asahi Lina > >>>>> --- > >>>>> drivers/gpu/drm/scheduler/sched_main.c | 10 ++ > >>>>> include/drm/gpu_scheduler.h| 8 > >>>>> 2 files changed, 18 insertions(+) > >>>>> > >>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c > >>>>> b/drivers/gpu/drm/scheduler/sched_main.c > >>>>> index 4e6ad6e122bc..5c0add2c7546 100644 > >>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c > >>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c &
Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
On Wed, Mar 8, 2023 at 2:47 PM Christian König wrote: > > Am 08.03.23 um 13:39 schrieb Karol Herbst: > > On Wed, Mar 8, 2023 at 9:46 AM Christian König > > wrote: > >> Am 07.03.23 um 15:25 schrieb Asahi Lina: > >>> Some hardware may require more complex resource utilization accounting > >>> than the simple job count supported by drm_sched internally. Add a > >>> can_run_job callback to allow drivers to implement more logic before > >>> deciding whether to run a GPU job. > >> Well complete NAK. > >> > > There hasn't even been any kind of discussion yet you already come > > around with a "Well complete NAK" > > > > First, this can be seen as rude behavior and me being part of the drm > > community I don't want to have to see this kind of thing. > > > > Obviously, any kind of strong "technical" review point is a nak until > > people settle with an agreement on what to land, there is no point in > > pointing out a "NAK", especially if that's the first thing you say. If > > you want to express your strong disagreement with the proposed > > solution, then state what your pain points are directly. > > > > If there is a long discussion and a maintainer feels it's going > > nowhere and no conclusion will be reached it might be this kind of > > "speaking with authority" point has to be made. But not as the starter > > into a discussion. This is unnecessarily hostile towards the > > contributor. And I wished we wouldn't have to see this kind of > > behavior here. > > > > Yes, some kernel maintainers do this a lot, but kernel maintainers > > also have this kind of reputation and people don't want to have to > > deal with this nonsense and decide to not contribute at all. So please > > just drop this attitude. > > Yes, you are completely right with that, but getting this message to the > recipient is intentional on my side. > > I give completely NAKs when the author of a patch has missed such a > fundamental technical connection that further discussion doesn't make sense. > > It's not meant to be in any way rude or offending. I can put a smiley > behind it if it somehow helps, but we still need a way to raise this big > red stop sign. > "further"? There was no discussion at all, you just started off like that. If you think somebody misses that connection, you can point out to documentation/videos whatever so the contributor can understand what's wrong with an approach. You did that, so that's fine. It's just starting off _any_ discussion with a "Well complete NAK" is terrible style. I'd feel uncomfortable if that happened to me and I'm sure there are enough people like that that we should be more reasonable with our replies. Just.. don't. We are all humans here and people react negatively to such things. And if people do it on purpose it just makes it worse. > >> This is clearly going against the idea of having jobs only depend on > >> fences and nothing else which is mandatory for correct memory management. > >> > > I'm sure it's all documented and there is a design document on how > > things have to look like you can point out? Might help to get a better > > understanding on how things should be. > > Yeah, that's the problematic part. We have documented this very > extensively: > https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#indefinite-dma-fences > > And both Jason and Daniel gave talks about the underlying problem and fyi: s/Jason/Faith/g > try to come up with patches to raise warnings when that happens, but > people still keep coming up with the same idea over and over again. > Yes, and we'll have to tell them over and over again. Nothing wrong with that. That's just part of maintaining such a big subsystem. And that's definitely not a valid reason to phrase things like above. > It's just that the technical relationship between preventing jobs from > running and with that preventing dma_fences from signaling and the core > memory management with page faults and shrinkers waiting for those > fences is absolutely not obvious. > > We had at least 10 different teams from different companies falling into > the same trap already and either the patches were rejected of hand or > had to painfully reverted or mitigated later on. > Sure, but that's just part of the job. And pointing out fundamental mistakes early on is important, but the situation won't get any better by being like that. Yes, we'll have to repeat the same words over and over again, and yes that might be annoying, but that's just how it is. > Regards, > Christian. > > > > >> If the hw is busy
Re: [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback
On Wed, Mar 8, 2023 at 9:46 AM Christian König wrote:
>
> Am 07.03.23 um 15:25 schrieb Asahi Lina:
> > Some hardware may require more complex resource utilization accounting
> > than the simple job count supported by drm_sched internally. Add a
> > can_run_job callback to allow drivers to implement more logic before
> > deciding whether to run a GPU job.
>
> Well complete NAK.
>
There hasn't even been any kind of discussion yet you already come
around with a "Well complete NAK"
First, this can be seen as rude behavior and me being part of the drm
community I don't want to have to see this kind of thing.
Obviously, any kind of strong "technical" review point is a nak until
people settle with an agreement on what to land, there is no point in
pointing out a "NAK", especially if that's the first thing you say. If
you want to express your strong disagreement with the proposed
solution, then state what your pain points are directly.
If there is a long discussion and a maintainer feels it's going
nowhere and no conclusion will be reached it might be this kind of
"speaking with authority" point has to be made. But not as the starter
into a discussion. This is unnecessarily hostile towards the
contributor. And I wished we wouldn't have to see this kind of
behavior here.
Yes, some kernel maintainers do this a lot, but kernel maintainers
also have this kind of reputation and people don't want to have to
deal with this nonsense and decide to not contribute at all. So please
just drop this attitude.
> This is clearly going against the idea of having jobs only depend on
> fences and nothing else which is mandatory for correct memory management.
>
I'm sure it's all documented and there is a design document on how
things have to look like you can point out? Might help to get a better
understanding on how things should be.
> If the hw is busy with something you need to return the fence for this
> from the prepare_job callback so that the scheduler can be notified when
> the hw is available again.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Asahi Lina
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 10 ++
> > include/drm/gpu_scheduler.h| 8
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 4e6ad6e122bc..5c0add2c7546 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -1001,6 +1001,16 @@ static int drm_sched_main(void *param)
> > if (!entity)
> > continue;
> >
> > + if (sched->ops->can_run_job) {
> > + sched_job =
> > to_drm_sched_job(spsc_queue_peek(>job_queue));
> > + if (!sched_job) {
> > + complete_all(>entity_idle);
> > + continue;
> > + }
> > + if (!sched->ops->can_run_job(sched_job))
> > + continue;
> > + }
> > +
> > sched_job = drm_sched_entity_pop_job(entity);
> >
> > if (!sched_job) {
> > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > index 9db9e5e504ee..bd89ea9507b9 100644
> > --- a/include/drm/gpu_scheduler.h
> > +++ b/include/drm/gpu_scheduler.h
> > @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> > struct dma_fence *(*prepare_job)(struct drm_sched_job *sched_job,
> >struct drm_sched_entity *s_entity);
> >
> > + /**
> > + * @can_run_job: Called before job execution to check whether the
> > + * hardware is free enough to run the job. This can be used to
> > + * implement more complex hardware resource policies than the
> > + * hw_submission limit.
> > + */
> > + bool (*can_run_job)(struct drm_sched_job *sched_job);
> > +
> > /**
> >* @run_job: Called to execute the job once all of the
> > dependencies
> >* have been resolved. This may be called multiple times, if
> >
>
Re: [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE]
On Tue, Mar 7, 2023 at 3:28 PM Asahi Lina wrote:
>
> Adds the Asahi GPU driver UAPI. Note: this API is not yet stable and
> therefore not ready for merging!
>
> Signed-off-by: Asahi Lina
> ---
> include/uapi/drm/asahi_drm.h | 556
> +++
> 1 file changed, 556 insertions(+)
>
> diff --git a/include/uapi/drm/asahi_drm.h b/include/uapi/drm/asahi_drm.h
> new file mode 100644
> index ..7b15b486d03d
> --- /dev/null
> +++ b/include/uapi/drm/asahi_drm.h
> @@ -0,0 +1,556 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright (C) The Asahi Linux Contributors
> + *
> + * Heavily inspired by xe_drm.h.
> + */
> +#ifndef _ASAHI_DRM_H_
> +#define _ASAHI_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +#define DRM_ASAHI_UNSTABLE_UABI_VERSION10006
> +
> +#define DRM_ASAHI_GET_PARAMS 0x00
> +#define DRM_ASAHI_VM_CREATE0x01
> +#define DRM_ASAHI_VM_DESTROY 0x02
> +#define DRM_ASAHI_GEM_CREATE 0x03
> +#define DRM_ASAHI_GEM_MMAP_OFFSET 0x04
> +#define DRM_ASAHI_GEM_BIND 0x05
> +#define DRM_ASAHI_QUEUE_CREATE 0x06
> +#define DRM_ASAHI_QUEUE_DESTROY0x07
> +#define DRM_ASAHI_SUBMIT 0x08
> +#define DRM_ASAHI_GET_TIME 0x09
> +
> +#define DRM_ASAHI_MAX_CLUSTERS 32
> +
> +struct drm_asahi_params_global {
> + __u32 unstable_uabi_version;
> + __u32 pad0;
> +
> + __u64 feat_compat;
> + __u64 feat_incompat;
> +
> + __u32 gpu_generation;
> + __u32 gpu_variant;
> + __u32 gpu_revision;
> + __u32 chip_id;
> +
> + __u32 num_dies;
> + __u32 num_clusters_total;
> + __u32 num_cores_per_cluster;
> + __u32 num_frags_per_cluster;
> + __u32 num_gps_per_cluster;
> + __u32 num_cores_total_active;
> + __u64 core_masks[DRM_ASAHI_MAX_CLUSTERS];
> +
> + __u32 vm_page_size;
> + __u32 pad1;
> + __u64 vm_user_start;
> + __u64 vm_user_end;
> + __u64 vm_shader_start;
> + __u64 vm_shader_end;
> +
> + __u32 max_syncs_per_submission;
> + __u32 max_commands_per_submission;
> + __u32 max_commands_in_flight;
> + __u32 max_attachments;
> +
> + __u32 timer_frequency_hz;
> + __u32 min_frequency_khz;
> + __u32 max_frequency_khz;
> + __u32 max_power_mw;
> +
> + __u32 result_render_size;
> + __u32 result_compute_size;
> +};
> +
> +/*
> +enum drm_asahi_feat_compat {
> +};
> +*/
> +
> +enum drm_asahi_feat_incompat {
> + DRM_ASAHI_FEAT_MANDATORY_ZS_COMPRESSION = (1UL) << 0,
> +};
> +
> +struct drm_asahi_get_params {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @param: Parameter group to fetch (MBZ) */
> + __u32 param_group;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +
> + /** @value: User pointer to write parameter struct */
> + __u64 pointer;
> +
> + /** @value: Size of user buffer, max size supported on return */
> + __u64 size;
> +};
> +
> +struct drm_asahi_vm_create {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @value: Returned VM ID */
> + __u32 vm_id;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +};
> +
> +struct drm_asahi_vm_destroy {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @value: VM ID to be destroyed */
> + __u32 vm_id;
> +
> + /** @pad: MBZ */
> + __u32 pad;
> +};
> +
> +#define ASAHI_GEM_WRITEBACK(1L << 0)
> +#define ASAHI_GEM_VM_PRIVATE (1L << 1)
> +
> +struct drm_asahi_gem_create {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @size: Size of the BO */
> + __u64 size;
> +
> + /** @flags: BO creation flags */
> + __u32 flags;
> +
> + /** @handle: VM ID to assign to the BO, if ASAHI_GEM_VM_PRIVATE is
> set. */
> + __u32 vm_id;
> +
> + /** @handle: Returned GEM handle for the BO */
> + __u32 handle;
> +};
> +
> +struct drm_asahi_gem_mmap_offset {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @handle: Handle for the object being mapped. */
> + __u32 handle;
> +
> + /** @flags: Must be zero */
> + __u32 flags;
> +
> + /** @offset: The fake offset to use for subsequent mmap call */
> + __u64 offset;
> +};
> +
> +enum drm_asahi_bind_op {
> + ASAHI_BIND_OP_BIND = 0,
> + ASAHI_BIND_OP_UNBIND = 1,
> + ASAHI_BIND_OP_UNBIND_ALL = 2,
> +};
> +
> +#define ASAHI_BIND_READ(1L << 0)
> +#define ASAHI_BIND_WRITE
Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
On Tue, Mar 7, 2023 at 3:48 PM Karol Herbst wrote:
>
> On Tue, Mar 7, 2023 at 3:27 PM Asahi Lina wrote:
> >
> > DRM drivers need to be able to declare which driver-specific ioctls they
> > support. This abstraction adds the required types and a helper macro to
> > generate the ioctl definition inside the DRM driver.
> >
> > Note that this macro is not usable until further bits of the
> > abstraction are in place (but it will not fail to compile on its own, if
> > not called).
> >
> > Signed-off-by: Asahi Lina
> > ---
> > drivers/gpu/drm/Kconfig | 7 ++
> > rust/bindings/bindings_helper.h | 2 +
> > rust/kernel/drm/ioctl.rs| 147
> >
> > rust/kernel/drm/mod.rs | 5 ++
> > rust/kernel/lib.rs | 2 +
> > 5 files changed, 163 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index dc0f94f02a82..dab8f0f9aa96 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -27,6 +27,13 @@ menuconfig DRM
> > details. You should also select and configure AGP
> > (/dev/agpgart) support if it is available for your platform.
> >
> > +# Rust abstractions cannot be built as modules currently, so force them as
> > +# bool by using these intermediate symbols. In the future these could be
> > +# tristate once abstractions themselves can be built as modules.
> > +config RUST_DRM
> > + bool "Rust support for the DRM subsystem"
> > + depends on DRM=y
> > +
> > config DRM_MIPI_DBI
> > tristate
> > depends on DRM
> > diff --git a/rust/bindings/bindings_helper.h
> > b/rust/bindings/bindings_helper.h
> > index 91bb7906ca5a..2687bef1676f 100644
> > --- a/rust/bindings/bindings_helper.h
> > +++ b/rust/bindings/bindings_helper.h
> > @@ -6,6 +6,7 @@
> > * Sorted alphabetically.
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -23,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
>
> might make more sense to add this chunk to the patch actually needing it
>
ehh, ignore this comment please :)
> > /* `bindgen` gets confused at certain things. */
> > const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> > diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> > new file mode 100644
> > index ..10304efbd5f1
> > --- /dev/null
> > +++ b/rust/kernel/drm/ioctl.rs
> > @@ -0,0 +1,147 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +#![allow(non_snake_case)]
> > +
> > +//! DRM IOCTL definitions.
> > +//!
> > +//! C header:
> > [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> > +
> > +use crate::ioctl;
> > +
> > +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> > +
> > +/// Construct a DRM ioctl number with no argument.
> > +pub const fn IO(nr: u32) -> u32 {
> > +ioctl::_IO(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a read-only argument.
> > +pub const fn IOR(nr: u32) -> u32 {
> > +ioctl::_IOR::(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a write-only argument.
> > +pub const fn IOW(nr: u32) -> u32 {
> > +ioctl::_IOW::(BASE, nr)
> > +}
> > +
> > +/// Construct a DRM ioctl number with a read-write argument.
> > +pub const fn IOWR(nr: u32) -> u32 {
> > +ioctl::_IOWR::(BASE, nr)
> > +}
> > +
> > +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro
> > to construct them.
> > +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> > +
> > +/// This is for ioctl which are used for rendering, and require that the
> > file descriptor is either
> > +/// for a render node, or if it’s a legacy/primary node, then it must be
> > authenticated.
> > +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> > +
> > +/// This must be set for any ioctl which can change the modeset or display
> > state. Userspace must
> > +/// call the ioctl through a primary node, while it is the active master.
> > +///
> > +/// Note that read-only modeset ioctl can also be called by
> > unauthenticated clients, or when a
> > +/// master is not the currently active one.
> > +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> > +
> >
Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction
On Tue, Mar 7, 2023 at 3:27 PM Asahi Lina wrote:
>
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. This abstraction adds the required types and a helper macro to
> generate the ioctl definition inside the DRM driver.
>
> Note that this macro is not usable until further bits of the
> abstraction are in place (but it will not fail to compile on its own, if
> not called).
>
> Signed-off-by: Asahi Lina
> ---
> drivers/gpu/drm/Kconfig | 7 ++
> rust/bindings/bindings_helper.h | 2 +
> rust/kernel/drm/ioctl.rs| 147
>
> rust/kernel/drm/mod.rs | 5 ++
> rust/kernel/lib.rs | 2 +
> 5 files changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index dc0f94f02a82..dab8f0f9aa96 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -27,6 +27,13 @@ menuconfig DRM
> details. You should also select and configure AGP
> (/dev/agpgart) support if it is available for your platform.
>
> +# Rust abstractions cannot be built as modules currently, so force them as
> +# bool by using these intermediate symbols. In the future these could be
> +# tristate once abstractions themselves can be built as modules.
> +config RUST_DRM
> + bool "Rust support for the DRM subsystem"
> + depends on DRM=y
> +
> config DRM_MIPI_DBI
> tristate
> depends on DRM
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 91bb7906ca5a..2687bef1676f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -6,6 +6,7 @@
> * Sorted alphabetically.
> */
>
> +#include
> #include
> #include
> #include
> @@ -23,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
might make more sense to add this chunk to the patch actually needing it
> /* `bindgen` gets confused at certain things. */
> const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
> diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> new file mode 100644
> index ..10304efbd5f1
> --- /dev/null
> +++ b/rust/kernel/drm/ioctl.rs
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +#![allow(non_snake_case)]
> +
> +//! DRM IOCTL definitions.
> +//!
> +//! C header:
> [`include/linux/drm/drm_ioctl.h`](../../../../include/linux/drm/drm_ioctl.h)
> +
> +use crate::ioctl;
> +
> +const BASE: u32 = bindings::DRM_IOCTL_BASE as u32;
> +
> +/// Construct a DRM ioctl number with no argument.
> +pub const fn IO(nr: u32) -> u32 {
> +ioctl::_IO(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-only argument.
> +pub const fn IOR(nr: u32) -> u32 {
> +ioctl::_IOR::(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a write-only argument.
> +pub const fn IOW(nr: u32) -> u32 {
> +ioctl::_IOW::(BASE, nr)
> +}
> +
> +/// Construct a DRM ioctl number with a read-write argument.
> +pub const fn IOWR(nr: u32) -> u32 {
> +ioctl::_IOWR::(BASE, nr)
> +}
> +
> +/// Descriptor type for DRM ioctls. Use the `declare_drm_ioctls!{}` macro to
> construct them.
> +pub type DrmIoctlDescriptor = bindings::drm_ioctl_desc;
> +
> +/// This is for ioctl which are used for rendering, and require that the
> file descriptor is either
> +/// for a render node, or if it’s a legacy/primary node, then it must be
> authenticated.
> +pub const AUTH: u32 = bindings::drm_ioctl_flags_DRM_AUTH;
> +
> +/// This must be set for any ioctl which can change the modeset or display
> state. Userspace must
> +/// call the ioctl through a primary node, while it is the active master.
> +///
> +/// Note that read-only modeset ioctl can also be called by unauthenticated
> clients, or when a
> +/// master is not the currently active one.
> +pub const MASTER: u32 = bindings::drm_ioctl_flags_DRM_MASTER;
> +
> +/// Anything that could potentially wreak a master file descriptor needs to
> have this flag set.
> +///
> +/// Current that’s only for the SETMASTER and DROPMASTER ioctl, which e.g.
> logind can call to force
> +/// a non-behaving master (display compositor) into compliance.
> +///
> +/// This is equivalent to callers with the SYSADMIN capability.
> +pub const ROOT_ONLY: u32 = bindings::drm_ioctl_flags_DRM_ROOT_ONLY;
> +
> +/// Whether drm_ioctl_desc.func should be called with the DRM BKL held or
> not. Enforced as the
> +/// default for all modern drivers, hence there should never be a need to
> set this flag.
> +///
> +/// Do not use anywhere else than for the VBLANK_WAIT IOCTL, which is the
> only legacy IOCTL which
> +/// needs this.
> +pub const UNLOCKED: u32 = bindings::drm_ioctl_flags_DRM_UNLOCKED;
> +
> +/// This is used for all ioctl needed for rendering only, for drivers which
> support render nodes.
> +/// This should be all new render drivers, and hence it should be always set
> for any ioctl with
> +/// `AUTH` set. Note though that
Re: [PATCH] drm/nouveau/fifo: set nvkm_engn_cgrp_get storage-class-specifier to static
Reviewed-by: Karol Herbst
will push in a moment
On Tue, Feb 28, 2023 at 11:15 PM Tom Rix wrote:
>
> smatch reports
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:33:18:
> warning: symbol 'nvkm_engn_cgrp_get' was not declared. Should it be static?
>
> nvkm_engn_cgrp_get is only used in runl.c, so it should be static
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> index b5836cbc29aa..93d628d7d508 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> @@ -30,7 +30,7 @@
> #include
> #include
>
> -struct nvkm_cgrp *
> +static struct nvkm_cgrp *
> nvkm_engn_cgrp_get(struct nvkm_engn *engn, unsigned long *pirqflags)
> {
> struct nvkm_cgrp *cgrp = NULL;
> --
> 2.27.0
>
Re: [PATCH] drm/nouveau/nvfw/acr: set wpr_generic_header_dump storage-class-specifier to static
Reviewed-by: Karol Herbst
will push in a moment
On Thu, Mar 2, 2023 at 1:48 PM Tom Rix wrote:
>
> gcc with W=1 reports
> drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: error: no previous
> prototype for ‘wpr_generic_header_dump’ [-Werror=missing-prototypes]
>49 | wpr_generic_header_dump(struct nvkm_subdev *subdev,
> | ^~~
>
> wpr_generic_header_dump is only used in acr.c, so it should be static
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
> b/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
> index 83a9c48bc58c..7ac90c495737 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
> @@ -45,7 +45,7 @@ wpr_header_v1_dump(struct nvkm_subdev *subdev, const struct
> wpr_header_v1 *hdr)
> nvkm_debug(subdev, "\tstatus: %d\n", hdr->status);
> }
>
> -void
> +static void
> wpr_generic_header_dump(struct nvkm_subdev *subdev, const struct
> wpr_generic_header *hdr)
> {
> nvkm_debug(subdev, "wprGenericHeader\n");
> --
> 2.27.0
>
Re: [PATCH] drm/nouveau/fifo: set gf100_fifo_nonstall_block_dump storage-class-specifier to static
Reviewed-by: Karol Herbst
will push in a moment
On Fri, Mar 3, 2023 at 2:27 PM Tom Rix wrote:
>
> gcc with W=1 reports
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: error:
> no previous prototype for ‘gf100_fifo_nonstall_block’
> [-Werror=missing-prototypes]
> 451 | gf100_fifo_nonstall_block(struct nvkm_event *event, int type, int
> index)
> | ^
>
> gf100_fifo_nonstall_block is only used in gf100.c, so it should be static
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
> index 5bb65258c36d..6c94451d0faa 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
> @@ -447,7 +447,7 @@ gf100_fifo_nonstall_allow(struct nvkm_event *event, int
> type, int index)
> spin_unlock_irqrestore(>lock, flags);
> }
>
> -void
> +static void
> gf100_fifo_nonstall_block(struct nvkm_event *event, int type, int index)
> {
> struct nvkm_fifo *fifo = container_of(event, typeof(*fifo),
> nonstall.event);
> --
> 2.27.0
>
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Mon, Feb 20, 2023 at 11:51 AM Chris Clayton wrote: > > > > On 20/02/2023 05:35, Ben Skeggs wrote: > > On Sun, 19 Feb 2023 at 04:55, Chris Clayton > > wrote: > >> > >> > >> > >> On 18/02/2023 15:19, Chris Clayton wrote: > >>> > >>> > >>> On 18/02/2023 12:25, Karol Herbst wrote: > >>>> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 15/02/2023 11:09, Karol Herbst wrote: > >>>>>> On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > >>>>>> (Thorsten Leemhuis) wrote: > >>>>>>> > >>>>>>> On 13.02.23 10:14, Chris Clayton wrote: > >>>>>>>> On 13/02/2023 02:57, Dave Airlie wrote: > >>>>>>>>> On Sun, 12 Feb 2023 at 00:43, Chris Clayton > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 10/02/2023 19:33, Linux regression tracking (Thorsten Leemhuis) > >>>>>>>>>> wrote: > >>>>>>>>>>> On 10.02.23 20:01, Karol Herbst wrote: > >>>>>>>>>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking > >>>>>>>>>>>> (Thorsten > >>>>>>>>>>>> Leemhuis) wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 08.02.23 09:48, Chris Clayton wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm assuming that we are not going to see a fix for this > >>>>>>>>>>>>>> regression before 6.2 is released. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yeah, looks like it. That's unfortunate, but happens. But there > >>>>>>>>>>>>> is still > >>>>>>>>>>>>> time to fix it and there is one thing I wonder: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Did any of the nouveau developers look at the netconsole > >>>>>>>>>>>>> captures Chris > >>>>>>>>>>>>> posted more than a week ago to check if they somehow help to > >>>>>>>>>>>>> track down > >>>>>>>>>>>>> the root of this problem? > >>>>>>>>>>>> > >>>>>>>>>>>> I did now and I can't spot anything. I think at this point it > >>>>>>>>>>>> would > >>>>>>>>>>>> make sense to dump the active tasks/threads via sqsrq keys to > >>>>>>>>>>>> see if > >>>>>>>>>>>> any is in a weird state preventing the machine from shutting > >>>>>>>>>>>> down. > >>>>>>>>>>> > >>>>>>>>>>> Many thx for looking into it! > >>>>>>>>>> > >>>>>>>>>> Yes, thanks Karol. > >>>>>>>>>> > >>>>>>>>>> Attached is the output from dmesg when this block of code: > >>>>>>>>>> > >>>>>>>>>> /bin/mount /dev/sda7 /mnt/sda7 > >>>>>>>>>> /bin/mountpoint /proc || /bin/mount /proc > >>>>>>>>>> /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log & > >>>>>>>>>> /bin/echo t > /proc/sysrq-trigger > >>>>>>>>>> /bin/sleep 1 > >>>>>>>>>> /bin/sync > >>>>>>>>>> /bin/sleep 1 > >>>>>>>>>> kill $(pidof dmesg) > >>>>>>>>>> /bin/umount /mnt/sda7 > >>>>>>>>>> > >>>>>>>>>> is executed immediately before /sbin/reboot is called as the final > >>>>
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton wrote: > > > > On 15/02/2023 11:09, Karol Herbst wrote: > > On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > > (Thorsten Leemhuis) wrote: > >> > >> On 13.02.23 10:14, Chris Clayton wrote: > >>> On 13/02/2023 02:57, Dave Airlie wrote: > >>>> On Sun, 12 Feb 2023 at 00:43, Chris Clayton > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 10/02/2023 19:33, Linux regression tracking (Thorsten Leemhuis) > >>>>> wrote: > >>>>>> On 10.02.23 20:01, Karol Herbst wrote: > >>>>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking (Thorsten > >>>>>>> Leemhuis) wrote: > >>>>>>>> > >>>>>>>> On 08.02.23 09:48, Chris Clayton wrote: > >>>>>>>>> > >>>>>>>>> I'm assuming that we are not going to see a fix for this > >>>>>>>>> regression before 6.2 is released. > >>>>>>>> > >>>>>>>> Yeah, looks like it. That's unfortunate, but happens. But there is > >>>>>>>> still > >>>>>>>> time to fix it and there is one thing I wonder: > >>>>>>>> > >>>>>>>> Did any of the nouveau developers look at the netconsole captures > >>>>>>>> Chris > >>>>>>>> posted more than a week ago to check if they somehow help to track > >>>>>>>> down > >>>>>>>> the root of this problem? > >>>>>>> > >>>>>>> I did now and I can't spot anything. I think at this point it would > >>>>>>> make sense to dump the active tasks/threads via sqsrq keys to see if > >>>>>>> any is in a weird state preventing the machine from shutting down. > >>>>>> > >>>>>> Many thx for looking into it! > >>>>> > >>>>> Yes, thanks Karol. > >>>>> > >>>>> Attached is the output from dmesg when this block of code: > >>>>> > >>>>> /bin/mount /dev/sda7 /mnt/sda7 > >>>>> /bin/mountpoint /proc || /bin/mount /proc > >>>>> /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log & > >>>>> /bin/echo t > /proc/sysrq-trigger > >>>>> /bin/sleep 1 > >>>>> /bin/sync > >>>>> /bin/sleep 1 > >>>>> kill $(pidof dmesg) > >>>>> /bin/umount /mnt/sda7 > >>>>> > >>>>> is executed immediately before /sbin/reboot is called as the final step > >>>>> of rebooting my system. > >>>>> > >>>>> I hope this is what you were looking for, but if not, please let me > >>>>> know what you need > >>> > >>> Thanks Dave. [...] > >> FWIW, in case anyone strands here in the archives: the msg was > >> truncated. The full post can be found in a new thread: > >> > >> https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > >> > >> Sadly it seems the info "With runpm=0, both reboot and poweroff work on > >> my laptop." didn't bring us much further to a solution. :-/ I don't > >> really like it, but for regression tracking I'm now putting this on the > >> back-burner, as a fix is not in sight. > >> > >> #regzbot monitor: > >> https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > >> #regzbot backburner: hard to debug and apparently rare > >> #regzbot ignore-activity > >> > > > > yeah.. this bug looks a little annoying. Sadly the only Turing based > > laptop I got doesn't work on Nouveau because of firmware related > > issues and we probably need to get updated ones from Nvidia here :( > > > > But it's a bit weird that the kernel doesn't shutdown, because I don't > > see anything in the logs which would prevent that from happening. > > Unless it's waiting on one of the tasks to complete, but none of them > > looked in any way nouveau related. > > > > If somebody else has any fancy kernel debugging tips here to figure > > out why it hangs, that would be very helpful.
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update (Thorsten Leemhuis) wrote: > > On 13.02.23 10:14, Chris Clayton wrote: > > On 13/02/2023 02:57, Dave Airlie wrote: > >> On Sun, 12 Feb 2023 at 00:43, Chris Clayton > >> wrote: > >>> > >>> > >>> > >>> On 10/02/2023 19:33, Linux regression tracking (Thorsten Leemhuis) wrote: > >>>> On 10.02.23 20:01, Karol Herbst wrote: > >>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking (Thorsten > >>>>> Leemhuis) wrote: > >>>>>> > >>>>>> On 08.02.23 09:48, Chris Clayton wrote: > >>>>>>> > >>>>>>> I'm assuming that we are not going to see a fix for this regression > >>>>>>> before 6.2 is released. > >>>>>> > >>>>>> Yeah, looks like it. That's unfortunate, but happens. But there is > >>>>>> still > >>>>>> time to fix it and there is one thing I wonder: > >>>>>> > >>>>>> Did any of the nouveau developers look at the netconsole captures Chris > >>>>>> posted more than a week ago to check if they somehow help to track down > >>>>>> the root of this problem? > >>>>> > >>>>> I did now and I can't spot anything. I think at this point it would > >>>>> make sense to dump the active tasks/threads via sqsrq keys to see if > >>>>> any is in a weird state preventing the machine from shutting down. > >>>> > >>>> Many thx for looking into it! > >>> > >>> Yes, thanks Karol. > >>> > >>> Attached is the output from dmesg when this block of code: > >>> > >>> /bin/mount /dev/sda7 /mnt/sda7 > >>> /bin/mountpoint /proc || /bin/mount /proc > >>> /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log & > >>> /bin/echo t > /proc/sysrq-trigger > >>> /bin/sleep 1 > >>> /bin/sync > >>> /bin/sleep 1 > >>> kill $(pidof dmesg) > >>> /bin/umount /mnt/sda7 > >>> > >>> is executed immediately before /sbin/reboot is called as the final step > >>> of rebooting my system. > >>> > >>> I hope this is what you were looking for, but if not, please let me know > >>> what you need > > > > Thanks Dave. [...] > FWIW, in case anyone strands here in the archives: the msg was > truncated. The full post can be found in a new thread: > > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > > Sadly it seems the info "With runpm=0, both reboot and poweroff work on > my laptop." didn't bring us much further to a solution. :-/ I don't > really like it, but for regression tracking I'm now putting this on the > back-burner, as a fix is not in sight. > > #regzbot monitor: > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > #regzbot backburner: hard to debug and apparently rare > #regzbot ignore-activity > yeah.. this bug looks a little annoying. Sadly the only Turing based laptop I got doesn't work on Nouveau because of firmware related issues and we probably need to get updated ones from Nvidia here :( But it's a bit weird that the kernel doesn't shutdown, because I don't see anything in the logs which would prevent that from happening. Unless it's waiting on one of the tasks to complete, but none of them looked in any way nouveau related. If somebody else has any fancy kernel debugging tips here to figure out why it hangs, that would be very helpful... > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > That page also explains what to do if mails like this annoy you. > > #regzbot ignore-activity >
