Re: [PATCH] drm/nouveau/i2c: rename aux.c and aux.h to nvkm_i2c_aux.c and nvkm_i2c_aux.h
On Sun, Jun 2, 2024 at 1:01 AM Szőke Benjamin wrote:
>
> s=20181004; d=freemail.hu;
>
> h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding;
> l=8472; bh=iw0a2TUtlt0KIetu+spJR9WLW1F3MPSfBbxxiBBkhDM=;
> b=1oSo+wfGjIoAfhgzfBaxNDoTN0TmXW/jadL52HL5ZAyzWMk15XqSBLjBkAd//Bh9
> u1d+ypo+idz4sTys/CYP5oS8lb8fepRTYBFboPsOAnbHQg6tR0QizBnjyYGq1iMYD02
> GmZWamFVQ/I9kT0XMOMhoKNp1jmr3tFr0iaoS+PqyGv5aNFi6tmiFSJT5fnNaf8/Bct
> XgidaouR1QSqrB6vgHDUjd13+165V+RoCh/CflqZroE132r01M9mxZU5bk4M4uMO38l
> HwZjS8YTSOmTA49PcLYbh+hr+e+GVFHP+X1wgmd/93wqlySRgqM7N1fh84jucg03IMS
> D/tvbePTzg==
> Content-Transfer-Encoding: quoted-printable
>
> 2024. 06. 02. 0:12 keltez=C3=A9ssel, Karol Herbst =C3=ADrta:
> > On Sat, Jun 1, 2024 at 11:33=E2=80=AFPM wrote:
> >>
> >> s=3D20181004; d=3Dfreemail.hu;
> >> h=3DFrom:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-T=
> ype:Content-Transfer-Encoding;
> >> l=3D6462; bh=3DCnHSqkRX34kqCWN2/oPtvm9wm8HJCe8QhPwQypdpi3w=3D=
> ;
> >> b=3DJDlDB9yOQDBY7EDnRMrt8qYnWfH8J/LKYKb90434FH1tuOL04za+3TXXS=
> bU0uvs0
> >> hWYDYjpbob4XGgUcd1s+lCkerOgDwkpWJWKFW8N5j6WENAKdR/hWJgcma2JED=
> DotXZ0
> >> cisYRrLsQBfjyKkBWw0qv/5PDe7vliytix5oP2piBPJC+uR3pN8OKck/+zLBG=
> lJY4za
> >> qywwOiMNzHAdyOJT5kCg0yd+k186Oa1jX93iCpiRk5mxJQqJJcAxfW8rYbKRX=
> i5QQTl
> >> SymDGdZ72wK5PkHxGgpZ9qXZtFV3eH4+95xNzpoPowMkXFkBy1uMClZzxv1oB=
> mRo8o6
> >> CXPcfsWUsQ=3D=3D
> >> Content-Transfer-Encoding: quoted-printable
> >>
> >> From: Benjamin Sz=3DC5=3D91ke
> >>
> >> The goal is to clean-up Linux repository from AUX file names, because
> >> the use of such file names is prohibited on other operating systems
> >> such as Windows, so the Linux repository cannot be cloned and
> >> edited on them.
> >>
> >=20
> > something went horribly wrong with encoding so the patch is pretty much=
> invalid.
> >=20
> >> Signed-off-by: Benjamin Sz=3DC5=3D91ke
> >> ---
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild | 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c | 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c| 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c | 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 2 =
> +-
> >> .../gpu/drm/nouveau/nvkm/subdev/i2c/{aux.c =3D3D> nvkm_i2c_aux.c} =
> | 2 +-
> >> .../gpu/drm/nouveau/nvkm/subdev/i2c/{aux.h =3D3D> nvkm_i2c_aux.h} =
> | 0
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padg94.c| 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgf119.c | 2 =
> +-
> >> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgm200.c | 2 =
> +-
> >> 11 files changed, 10 insertions(+), 10 deletions(-)
> >> rename drivers/gpu/drm/nouveau/nvkm/subdev/i2c/{aux.c =3D3D> nvkm_i2=
> c_aux.=3D
> >> c} (99%)
> >> rename drivers/gpu/drm/nouveau/nvkm/subdev/i2c/{aux.h =3D3D> nvkm_i2=
> c_aux.=3D
> >> h} (100%)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild b/drivers/=
> gpu=3D
> >> /drm/nouveau/nvkm/subdev/i2c/Kbuild
> >> index 819703913a00..c488dfce4392 100644
> >> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
> >> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
> >> @@ -25,7 +25,7 @@ nvkm-y +=3D3D nvkm/subdev/i2c/busnv50.o
> >> nvkm-y +=3D3D nvkm/subdev/i2c/busgf119.o
> >> nvkm-y +=3D3D nvkm/subdev/i2c/bit.o
> >> =3D20
> >> -nvkm-y +=3D3D nvkm/subdev/i2c/aux.o
> >> +nvkm-y +=3D3D nvkm/subdev/i2c/nvkm_i2c_aux.o
> >> nvkm-y +=3D3D nvkm/subdev/i2c/auxg94.o
> >> nvkm-y +=3D3D nvkm/subdev/i2c/auxgf119.o
> >> nvkm-y +=3D3D nvkm/subdev/i2c/auxgm200.o
> >> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c b/drive=
> rs/=3D
> >> gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> >> index dd391809fef7..30bf84e77db9 100644
> >> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> >> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> >> @@ -24,7 +24,7 @@
> >> #define anx9805_pad(p) container_of((p), struct anx9805_pad,
Re: [PATCH] drm/nouveau/i2c: rename aux.c and aux.h to nvkm_i2c_aux.c and nvkm_i2c_aux.h
On Sat, Jun 1, 2024 at 11:33 PM wrote:
>
> s=20181004; d=freemail.hu;
>
> h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding;
> l=6462; bh=CnHSqkRX34kqCWN2/oPtvm9wm8HJCe8QhPwQypdpi3w=;
> b=JDlDB9yOQDBY7EDnRMrt8qYnWfH8J/LKYKb90434FH1tuOL04za+3TXXSbU0uvs0
> hWYDYjpbob4XGgUcd1s+lCkerOgDwkpWJWKFW8N5j6WENAKdR/hWJgcma2JEDDotXZ0
> cisYRrLsQBfjyKkBWw0qv/5PDe7vliytix5oP2piBPJC+uR3pN8OKck/+zLBGlJY4za
> qywwOiMNzHAdyOJT5kCg0yd+k186Oa1jX93iCpiRk5mxJQqJJcAxfW8rYbKRXi5QQTl
> SymDGdZ72wK5PkHxGgpZ9qXZtFV3eH4+95xNzpoPowMkXFkBy1uMClZzxv1oBmRo8o6
> CXPcfsWUsQ==
> Content-Transfer-Encoding: quoted-printable
>
> From: Benjamin Sz=C5=91ke
>
> The goal is to clean-up Linux repository from AUX file names, because
> the use of such file names is prohibited on other operating systems
> such as Windows, so the Linux repository cannot be cloned and
> edited on them.
>
something went horribly wrong with encoding so the patch is pretty much invalid.
> Signed-off-by: Benjamin Sz=C5=91ke
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c| 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/i2c/{aux.c =3D> nvkm_i2c_aux.c} | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/i2c/{aux.h =3D> nvkm_i2c_aux.h} | 0
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padg94.c| 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgf119.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/padgm200.c | 2 +-
> 11 files changed, 10 insertions(+), 10 deletions(-)
> rename drivers/gpu/drm/nouveau/nvkm/subdev/i2c/{aux.c =3D> nvkm_i2c_aux.=
> c} (99%)
> rename drivers/gpu/drm/nouveau/nvkm/subdev/i2c/{aux.h =3D> nvkm_i2c_aux.=
> h} (100%)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild b/drivers/gpu=
> /drm/nouveau/nvkm/subdev/i2c/Kbuild
> index 819703913a00..c488dfce4392 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/Kbuild
> @@ -25,7 +25,7 @@ nvkm-y +=3D nvkm/subdev/i2c/busnv50.o
> nvkm-y +=3D nvkm/subdev/i2c/busgf119.o
> nvkm-y +=3D nvkm/subdev/i2c/bit.o
> =20
> -nvkm-y +=3D nvkm/subdev/i2c/aux.o
> +nvkm-y +=3D nvkm/subdev/i2c/nvkm_i2c_aux.o
> nvkm-y +=3D nvkm/subdev/i2c/auxg94.o
> nvkm-y +=3D nvkm/subdev/i2c/auxgf119.o
> nvkm-y +=3D nvkm/subdev/i2c/auxgm200.o
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c b/drivers/=
> gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> index dd391809fef7..30bf84e77db9 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/anx9805.c
> @@ -24,7 +24,7 @@
> #define anx9805_pad(p) container_of((p), struct anx9805_pad, base)
> #define anx9805_bus(p) container_of((p), struct anx9805_bus, base)
> #define anx9805_aux(p) container_of((p), struct anx9805_aux, base)
> -#include "aux.h"
> +#include "nvkm_i2c_aux.h"
> #include "bus.h"
> =20
> struct anx9805_pad {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c b/drivers/g=
> pu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
> index 47068f6f9c55..9e07ba444ca8 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
> @@ -22,7 +22,7 @@
> * Authors: Ben Skeggs
> */
> #define g94_i2c_aux(p) container_of((p), struct g94_i2c_aux, base)
> -#include "aux.h"
> +#include "nvkm_i2c_aux.h"
> =20
> struct g94_i2c_aux {
> struct nvkm_i2c_aux base;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c b/drivers=
> /gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c
> index dab40cd8fe3a..8709b728c38b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgf119.c
> @@ -19,7 +19,7 @@
> * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> */
> -#include "aux.h"
> +#include "nvkm_i2c_aux.h"
> =20
> static const struct nvkm_i2c_aux_func
> gf119_i2c_aux =3D {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c b/drivers=
> /gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
> index 8bd1d442e465..f40c5709d217 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c
> @@ -22,7 +22,7 @@
> * Authors: Ben Skeggs
> */
> #define gm200_i2c_aux(p) container_of((p), struct gm200_i2c_aux, base)
> -#include "aux.h"
> +#include "nvkm_i2c_aux.h"
> =20
> struct gm200_i2c_aux {
> struct nvkm_i2c_aux base;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/sub
[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, &abi16->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, &abi16->channels, head) {
if (temp->chan->chid == req->channel) {
--
2.43.2
[Nouveau] [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, &args, 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: [Nouveau] [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-de...@lists.freedesktop.org > Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org > Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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 +
Re: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] 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 > > > > > > > > > > > > &
[Nouveau] [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->disp, nv_connector->base.name,
nv_connector->index,
&nv_connector->conn);
if (ret) {
- kfree(nv_connector);
- return ERR_PTR(ret);
+ goto drm_conn_err;
}
ret = nvif_conn_event_ctor(&nv_connector->conn, "kmsHotplug",
@@ -1426,8 +1425,7 @@ nouveau_connector_create(struct drm_device *dev,
if (ret) {
nvif_event_dtor(&nv_connector->hpd);
nvif_conn_dtor(&nv_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: [Nouveau] 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
Re: [Nouveau] 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 !=
> &client->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 *)&stack].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 *)&stack].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
Re: [Nouveau] 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: [Nouveau] 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]
Re: [Nouveau] 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: [Nouveau] Problem with NVIDIA Quadro FX-2800m
On Sat, Aug 12, 2023 at 8:12 AM Wolfram Sauerteig wrote: > > Hello, > > since one of the last nouveau driver updates I've got a problem with my > Thinkpad W701. A couple of seconds after having started X11/KDE Plasma > the Desktop freezes, only the mouse pointer is still moveable. System ist > therefore unusable. > The Logs (/var/log/dmesg) show thousands of lines reading 'gr: TRAP_PROP - TP > 5 - Unknown CUDA fault at address ...', see log file appended. > > Linux without GUI starts and runs as well as Windows 10 on the same machine > without any problems. > > > Hardware: > LENOVO Thinkpad W701 model 25002EG/25002EG, BIOS 6KET60WW (1.30 ) 10/24/2012 > Core i7 920XM > 32 GB RAM > NVIDIA Quadro FX-2800M 1GB RAM > SSD 2Tb data (Samsung SSD 870) > SSD 512Mb system (Samsung SSD 850) > > Software: > Linux 6.1.41-gentoo #2 SMP PREEMPT_DYNAMIC Thu Aug 3 09:51:42 CEST 2023 > x86_64 Intel(R) Core(TM) i7 CPU X 920 @ 2.00GHz GenuineIntel GNU/Linux > X.Org X Server 1.21.1.8 > kde-plasma/plasma-meta-5.27.6:5::gentoo > sys-firmware/nvidia-firmware-340.32-r1::gentoo > x11-drivers/xf86-video-nouveau-1.0.17::gentoo > > Does anyone have an idea how to resolve the problem? > Might that be a hardware problem? > probably a kernel problem. As you seem to be on gentoo, would you feel comfortable to figure out what kernel version regressed it? You could use `git bisect` for that and it might take a while, but that's the best approach to help out fixing that bug. Do you still know what was the last good kernel? Maybe I can check the git log and see if anything stands out or to try out. > > Best regards > Wolfram
Re: [Nouveau] 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: [Nouveau] 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: [Nouveau] 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: [Nouveau] 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 t
Re: [Nouveau] 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] clo
Re: [Nouveau] 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: [Nouveau] [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(&fence))
> - 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(&fence);
> nouveau_pfns_map(svmm, args->vma->vm_mm, args->start, pfns, i);
>
> base-commit: 82d750e9d2f5d0594c8f7057ce59127e701af781
> --
> 2.41.0
>
Reviewed-by: Karol Herbst
[Nouveau] [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] 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] 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] 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: [Nouveau] [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,
> -&gr->bundle_veid);
> -}
> -
> static const struct gf100_gr_fwif
> tu102_gr_fwif[] = {
> { 0, gm200_gr_load, &tu102_gr, &gp108_gr_fecs_acr,
> &gp108_gr_gpccs_acr },
> --
> 2.39.2
>
Reviewed-by: Karol Herbst
Will push to drm-misc in a sec
Re: [Nouveau] [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
Re: [Nouveau] [PATCH] drm/nouveau: fixup the uapi header file.
f_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;
> +};
> +
> #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: [Nouveau] Powering down laptop GPU TU117GLM
On Sat, Jul 29, 2023 at 9:49 PM Karol Herbst wrote: > > On Sat, Jul 29, 2023 at 7:54 PM Ferenc Wágner wrote: > > > > Karol Herbst writes: > > > > > On Fri, Jun 23, 2023 at 12:12 AM Ferenc Wágner wrote: > > > > > >> Ferenc Wágner writes: > > >> > > >>> Sorry if I'm reaching the wrong forum, please advise if so. My question > > >>> is not about the main focus of this community, but I had no better idea > > >>> about where to look for the relevant expertise. > > >>> > > >>> So: this Dell Precision 5560 laptop is built with a "T1200 Laptop GPU", > > >>> and I suspect it draws power even though I don't ever use it, heating > > >>> the computer and shortening battery life. Is there a way to shut it > > >>> down for good? (Or to make sure it isn't causing my problems?) > > >> > > >> Looks like I chose the wrong forum after all. Shall I try the linux-pm > > >> list instead, or can you recommend a more approriate one for the above > > >> question? > > > > > > The GPU should be getting powered down automatically as long as > > > nouveau is loaded and nothing actively uses the GPU. > > > > Thanks for the tip, Karol! Letting the nouveau module load doubled my > > estimated battery time. Online PC10 residency is still low, but that > > must be a different issue. > > yeah.. the Intel stuff from that time is a bit buggy and even plugging > in USB devices can disable PC10. You should probably try enabling > runtime power management on all pcie devices (write "auto" into all > /sys/bus/pci/devices/*/power/control files, each device also has a > "status" file to tell if they are suspended or not) And maybe same > with USB devices or something... There are also tools like tlp who > automate that stuff, but they usually set less optimal settings when > on power. > > Anyway, enabling runtime power management usually helps a bit here. > I think there was also some sata/nvme stuff to toggle, but can't remember the details here. Might want to search for that. > > -- > > Thanks again, > > Feri. > >
Re: [Nouveau] Powering down laptop GPU TU117GLM
On Sat, Jul 29, 2023 at 7:54 PM Ferenc Wágner wrote: > > Karol Herbst writes: > > > On Fri, Jun 23, 2023 at 12:12 AM Ferenc Wágner wrote: > > > >> Ferenc Wágner writes: > >> > >>> Sorry if I'm reaching the wrong forum, please advise if so. My question > >>> is not about the main focus of this community, but I had no better idea > >>> about where to look for the relevant expertise. > >>> > >>> So: this Dell Precision 5560 laptop is built with a "T1200 Laptop GPU", > >>> and I suspect it draws power even though I don't ever use it, heating > >>> the computer and shortening battery life. Is there a way to shut it > >>> down for good? (Or to make sure it isn't causing my problems?) > >> > >> Looks like I chose the wrong forum after all. Shall I try the linux-pm > >> list instead, or can you recommend a more approriate one for the above > >> question? > > > > The GPU should be getting powered down automatically as long as > > nouveau is loaded and nothing actively uses the GPU. > > Thanks for the tip, Karol! Letting the nouveau module load doubled my > estimated battery time. Online PC10 residency is still low, but that > must be a different issue. yeah.. the Intel stuff from that time is a bit buggy and even plugging in USB devices can disable PC10. You should probably try enabling runtime power management on all pcie devices (write "auto" into all /sys/bus/pci/devices/*/power/control files, each device also has a "status" file to tell if they are suspended or not) And maybe same with USB devices or something... There are also tools like tlp who automate that stuff, but they usually set less optimal settings when on power. Anyway, enabling runtime power management usually helps a bit here. > -- > Thanks again, > Feri. >
Re: [Nouveau] [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] &
> > > > +
Re: [Nouveau] [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]);
> > &
Re: [Nouveau] [PATCH 3/3] drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP
On Wed, Jul 19, 2023 at 6:41 AM Ben Skeggs wrote: > > From: Ben Skeggs > > Fixes OOPS on boards with ANX9805 DP encoders. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c > b/drivers/gpu/drm/nouveau/dispnv50/disp.c > index 42e1665ba11a..1ecd3d63b108 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -1873,6 +1873,8 @@ nv50_pior_destroy(struct drm_encoder *encoder) > nvif_outp_dtor(&nv_encoder->outp); > > drm_encoder_cleanup(encoder); > + > + mutex_destroy(&nv_encoder->dp.hpd_irq_lock); > kfree(encoder); > } > > @@ -1917,6 +1919,8 @@ nv50_pior_create(struct drm_connector *connector, > struct dcb_output *dcbe) > nv_encoder->i2c = ddc; > nv_encoder->aux = aux; > > + mutex_init(&nv_encoder->dp.hpd_irq_lock); > + > encoder = to_drm_encoder(nv_encoder); > encoder->possible_crtcs = dcbe->heads; > encoder->possible_clones = 0; > -- > 2.41.0 > Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 2/3] drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts
On Wed, Jul 19, 2023 at 6:41 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> Fixes crash on boards with ANX9805 TMDS/DP encoders.
>
> Signed-off-by: Ben Skeggs
> ---
> .../gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 27 ---
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> index dad942be6679..46b057fe1412 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> @@ -81,20 +81,29 @@ nvkm_uconn_uevent(struct nvkm_object *object, void *argv,
> u32 argc, struct nvkm_
> return -ENOSYS;
>
> list_for_each_entry(outp, &conn->disp->outps, head) {
> - if (outp->info.connector == conn->index && outp->dp.aux) {
> - if (args->v0.types & NVIF_CONN_EVENT_V0_PLUG ) bits
> |= NVKM_I2C_PLUG;
> - if (args->v0.types & NVIF_CONN_EVENT_V0_UNPLUG) bits
> |= NVKM_I2C_UNPLUG;
> - if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ ) bits
> |= NVKM_I2C_IRQ;
> + if (outp->info.connector == conn->index)
> + break;
> + }
>
> - return nvkm_uevent_add(uevent, &device->i2c->event,
> outp->dp.aux->id, bits,
> - nvkm_uconn_uevent_aux);
> - }
> + if (&outp->head == &conn->disp->outps)
> + return -EINVAL;
> +
> + if (outp->dp.aux && !outp->info.location) {
> + if (args->v0.types & NVIF_CONN_EVENT_V0_PLUG ) bits |=
> NVKM_I2C_PLUG;
> + if (args->v0.types & NVIF_CONN_EVENT_V0_UNPLUG) bits |=
> NVKM_I2C_UNPLUG;
> + if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ ) bits |=
> NVKM_I2C_IRQ;
> +
> + return nvkm_uevent_add(uevent, &device->i2c->event,
> outp->dp.aux->id, bits,
> + nvkm_uconn_uevent_aux);
> }
>
> if (args->v0.types & NVIF_CONN_EVENT_V0_PLUG ) bits |= NVKM_GPIO_HI;
> if (args->v0.types & NVIF_CONN_EVENT_V0_UNPLUG) bits |= NVKM_GPIO_LO;
> - if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ)
> - return -EINVAL;
> + if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ) {
> + /* TODO: support DP IRQ on ANX9805 and remove this hack. */
> + if (!outp->info.location)
> + return -EINVAL;
> + }
>
> return nvkm_uevent_add(uevent, &device->gpio->event, conn->info.hpd,
> bits,
>nvkm_uconn_uevent_gpio);
> --
> 2.41.0
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 1/3] drm/nouveau/i2c: fix number of aux event slots
On Wed, Jul 19, 2023 at 6:41 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> This was completely bogus before, using maximum DCB device index rather
> than maximum AUX ID to size the buffer that stores event refcounts.
>
> *Pretty* unlikely to have been an actual problem on most configurations,
> that is, unless you've got one of the rare boards that have off-chip DP.
>
> There, it'll likely crash.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h | 4 ++--
> drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c| 11 +--
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
> index 40a1065ae626..ef441dfdea09 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
> @@ -16,7 +16,7 @@ struct nvkm_i2c_bus {
> const struct nvkm_i2c_bus_func *func;
> struct nvkm_i2c_pad *pad;
> #define NVKM_I2C_BUS_CCB(n) /* 'n' is ccb index */
> (n)
> -#define NVKM_I2C_BUS_EXT(n) /* 'n' is dcb external encoder type */ ((n) +
> 0x100)
> +#define NVKM_I2C_BUS_EXT(n) /* 'n' is dcb external encoder type */ ((n) +
> 0x10)
> #define NVKM_I2C_BUS_PRI /* ccb primary comm. port */
> -1
> #define NVKM_I2C_BUS_SEC /* ccb secondary comm. port */
> -2
> int id;
> @@ -38,7 +38,7 @@ struct nvkm_i2c_aux {
> const struct nvkm_i2c_aux_func *func;
> struct nvkm_i2c_pad *pad;
> #define NVKM_I2C_AUX_CCB(n) /* 'n' is ccb index */
> (n)
> -#define NVKM_I2C_AUX_EXT(n) /* 'n' is dcb external encoder type */ ((n) +
> 0x100)
> +#define NVKM_I2C_AUX_EXT(n) /* 'n' is dcb external encoder type */ ((n) +
> 0x10)
> int id;
>
> struct mutex mutex;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> index 976539de4220..731b2f68d3db 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
> @@ -260,10 +260,11 @@ nvkm_i2c_new_(const struct nvkm_i2c_func *func, struct
> nvkm_device *device,
> {
> struct nvkm_bios *bios = device->bios;
> struct nvkm_i2c *i2c;
> + struct nvkm_i2c_aux *aux;
> struct dcb_i2c_entry ccbE;
> struct dcb_output dcbE;
> u8 ver, hdr;
> - int ret, i;
> + int ret, i, ids;
>
> if (!(i2c = *pi2c = kzalloc(sizeof(*i2c), GFP_KERNEL)))
> return -ENOMEM;
> @@ -406,5 +407,11 @@ nvkm_i2c_new_(const struct nvkm_i2c_func *func, struct
> nvkm_device *device,
> }
> }
>
> - return nvkm_event_init(&nvkm_i2c_intr_func, &i2c->subdev, 4, i,
> &i2c->event);
> + ids = 0;
> + list_for_each_entry(aux, &i2c->aux, head)
> + ids = max(ids, aux->id + 1);
> + if (!ids)
> + return 0;
> +
> + return nvkm_event_init(&nvkm_i2c_intr_func, &i2c->subdev, 4, ids,
> &i2c->event);
> }
> --
> 2.41.0
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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, &pad);
> else
> ret = 0;
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [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 = &pci->subdev;
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [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 = &bus->base;
>
Re: [Nouveau] [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: [Nouveau] [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 = &g84_sor_hdmi,
> > .dp = &g94_sor_dp,
> > };
> >
>
> --
> Cheers,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
[Nouveau] [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 = &g84_sor_hdmi,
.dp = &g94_sor_dp,
};
--
2.41.0
[Nouveau] [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 = &crtc_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
[Nouveau] [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
[Nouveau] [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(&avi, 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: [Nouveau] Powering down laptop GPU TU117GLM
On Fri, Jun 23, 2023 at 12:12 AM Ferenc Wágner wrote: > > Ferenc Wágner writes: > > > Sorry if I'm reaching the wrong forum, please advise if so. My question > > is not about the main focus of this community, but I had no better idea > > about where to look for the relevant expertise. > > > > So: this Dell Precision 5560 laptop is built with a "T1200 Laptop GPU", > > and I suspect it draws power even though I don't ever use it, heating > > the computer and shortening battery life. Is there a way to shut it > > down for good? (Or to make sure it isn't causing my problems?) > > Looks like I chose the wrong forum after all. Shall I try the linux-pm > list instead, or can you recommend a more approriate one for the above > question? > -- > Thanks, > Feri. > The GPU should be getting powered down automatically as long as nouveau is loaded and nothing actively uses the GPU.
[Nouveau] [PATCH v2] drm/nouveau/gr: enable memory loads on helper invocation on all channels
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
v2: drop code for gm200 and newer.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c | 4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 1 +
6 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
index 00dbeda7e346..de161e7a04aa 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -117,6 +117,7 @@ void gk104_grctx_generate_r418800(struct gf100_gr *);
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
index 94233d0119df..52a234b1ef01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -906,7 +906,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
index 4391458e1fb2..3acdd9eeb74a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf100_gr *gr)
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -854,4 +863,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
index 7b9a34f9ec3c..5597e87624ac 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
@@ -103,4 +103,5 @@ gk110b_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
index c78d07a8bb7d..612656496541 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c
@@ -568,4 +568,5 @@ gk208_grctx = {
.dist_skip_table = gf117_grctx_generate_dist_skip_table,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
index beac66eb2a80..9906974ac3f0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -988,4 +988,5 @@ gm107_grctx = {
.r406500 = gm107_grctx_generate_r406500,
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r419e00 = gm107_grctx_generate_r419e00,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
--
2.41.0
Re: [Nouveau] [PATCH 10/10] drm/nouveau/kms: don't call drm_dp_cec_set_edid() on TMDS
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> RM complains very loudly at the aux transaction attempts.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 086b66b60d91..4c0cb32f6f2c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -619,7 +619,10 @@ nouveau_connector_detect(struct drm_connector
> *connector, bool force)
>
> nouveau_connector_set_encoder(connector, nv_encoder);
> conn_status = connector_status_connected;
> - drm_dp_cec_set_edid(&nv_connector->aux, nv_connector->edid);
> +
> + if (nv_encoder->dcb->type == DCB_OUTPUT_DP)
> + drm_dp_cec_set_edid(&nv_connector->aux,
> nv_connector->edid);
> +
> goto out;
> } else {
> nouveau_connector_set_edid(nv_connector, NULL);
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 09/10] drm/nouveau/nvif: fix potential double-free
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> DRM cleanup paths unconditionally call nvif_mmu_dtor() for clients,
> which would result in a double-free if nvif_mmu_ctor()'d previously
> failed.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nvif/mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvif/mmu.c
> b/drivers/gpu/drm/nouveau/nvif/mmu.c
> index 3709cbbc19a1..c9dd3cff49a0 100644
> --- a/drivers/gpu/drm/nouveau/nvif/mmu.c
> +++ b/drivers/gpu/drm/nouveau/nvif/mmu.c
> @@ -27,6 +27,9 @@
> void
> nvif_mmu_dtor(struct nvif_mmu *mmu)
> {
> + if (!nvif_object_constructed(&mmu->object))
> + return;
> +
nvif_mmu_ctor seems to be calling into this in its clean up path, so
this could now leaks memory in case nvif_mmu_ctor fails, no?
> kfree(mmu->kind);
> kfree(mmu->type);
> kfree(mmu->heap);
> --
> 2.40.1
>
Re: [Nouveau] [PATCH 08/10] drm/nouveau/fifo/ga100-: add per-runlist nonstall intr handling
gt; + return gr->func->nonstall(gr);
> +
> + return -EINVAL;
> +}
> +
> static int
> nvkm_gr_oneinit(struct nvkm_engine *engine)
> {
> @@ -177,6 +188,7 @@ nvkm_gr = {
> .init = nvkm_gr_init,
> .fini = nvkm_gr_fini,
> .reset = nvkm_gr_reset,
> + .nonstall = nvkm_gr_nonstall,
> .intr = nvkm_gr_intr,
> .tile = nvkm_gr_tile,
> .chsw_load = nvkm_gr_chsw_load,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ga102.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ga102.c
> index a5b5ac2755a2..00cd70abad67 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ga102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ga102.c
> @@ -137,8 +137,15 @@ ga102_gr_oneinit_intr(struct gf100_gr *gr, enum
> nvkm_intr_type *pvector)
> return &device->vfn->intr;
> }
>
> +static int
> +ga102_gr_nonstall(struct gf100_gr *gr)
> +{
> + return nvkm_rd32(gr->base.engine.subdev.device, 0x400160) &
> 0x0fff;
> +}
> +
> static const struct gf100_gr_func
> ga102_gr = {
> + .nonstall = ga102_gr_nonstall,
> .oneinit_intr = ga102_gr_oneinit_intr,
> .oneinit_tiles = gm200_gr_oneinit_tiles,
> .oneinit_sm_id = gv100_gr_oneinit_sm_id,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> index 29afec9a55bf..3648868bb9fc 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
> @@ -2494,12 +2494,24 @@ gf100_gr_gpccs_ucode = {
> .data.size = sizeof(gf100_grgpc_data),
> };
>
> +static int
> +gf100_gr_nonstall(struct nvkm_gr *base)
> +{
> + struct gf100_gr *gr = gf100_gr(base);
> +
> + if (gr->func->nonstall)
> + return gr->func->nonstall(gr);
> +
> + return -EINVAL;
> +}
> +
> static const struct nvkm_gr_func
> gf100_gr_ = {
> .dtor = gf100_gr_dtor,
> .oneinit = gf100_gr_oneinit,
> .init = gf100_gr_init_,
> .fini = gf100_gr_fini,
> + .nonstall = gf100_gr_nonstall,
> .reset = gf100_gr_reset,
> .units = gf100_gr_units,
> .chan_new = gf100_gr_chan_new,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> index 94ca7ac16acf..54f686ba39ac 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> @@ -147,6 +147,7 @@ struct gf100_gr_func_zbc {
> };
>
> struct gf100_gr_func {
> + int (*nonstall)(struct gf100_gr *);
> struct nvkm_intr *(*oneinit_intr)(struct gf100_gr *, enum
> nvkm_intr_type *);
> void (*oneinit_tiles)(struct gf100_gr *);
> int (*oneinit_sm_id)(struct gf100_gr *);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/priv.h
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/priv.h
> index 6ec8b94854c0..0884abc73a9d 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/priv.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/priv.h
> @@ -18,6 +18,7 @@ struct nvkm_gr_func {
> int (*init)(struct nvkm_gr *);
> int (*fini)(struct nvkm_gr *, bool);
> int (*reset)(struct nvkm_gr *);
> + int (*nonstall)(struct nvkm_gr *);
> void (*intr)(struct nvkm_gr *);
> void (*tile)(struct nvkm_gr *, int region, struct nvkm_fb_tile *);
> int (*tlb_flush)(struct nvkm_gr *);
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 07/10] drm/nouveau/fifo/ga100-: remove individual runlists rather than failing oneinit
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> We're adding better support for the non-stall interrupt, which will need
> to fetch the interrupt vector from the runlist's primary engine.
>
> NVKM doesn't support all target engines (ie. NVDEC etc), and it wouldn't
> be ideal to completely fail initialisation in this case.
>
> Instead. Remove runlists where we can't determine all the needed info.
>
> Signed-off-by: Ben Skeggs
> ---
> .../gpu/drm/nouveau/nvkm/engine/fifo/ga100.c | 46 ++-
> 1 file changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
> index 12a5d99d5e77..a729f8b7f0da 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
> @@ -429,7 +429,9 @@ static int
> ga100_runl_new(struct nvkm_fifo *fifo, int id, u32 addr, struct nvkm_runl
> **prunl)
> {
> struct nvkm_device *device = fifo->engine.subdev.device;
> + struct nvkm_top_device *tdev;
> struct nvkm_runl *runl;
> + struct nvkm_engn *engn;
> u32 chcfg = nvkm_rd32(device, addr + 0x004);
> u32 chnum = 1 << (chcfg & 0x000f);
> u32 chaddr = (chcfg & 0xfff0);
> @@ -437,26 +439,50 @@ ga100_runl_new(struct nvkm_fifo *fifo, int id, u32
> addr, struct nvkm_runl **prun
> u32 vector = nvkm_rd32(device, addr + 0x160);
> int i, ret;
>
> - runl = *prunl = nvkm_runl_new(fifo, id, addr, chnum);
> + runl = nvkm_runl_new(fifo, id, addr, chnum);
> if (IS_ERR(runl))
> return PTR_ERR(runl);
>
> + *prunl = runl;
> +
> for (i = 0; i < 2; i++) {
> u32 pbcfg = nvkm_rd32(device, addr + 0x010 + (i * 0x04));
> if (pbcfg & 0x8000) {
> runl->runq[runl->runq_nr] =
> nvkm_runq_new(fifo, ((pbcfg & 0x03fffc00) -
> 0x04) / 0x800);
> - if (!runl->runq[runl->runq_nr])
> + if (!runl->runq[runl->runq_nr]) {
> + RUNL_ERROR(runl, "runq %d", runl->runq_nr);
> return -ENOMEM;
> + }
>
> runl->runq_nr++;
> }
> }
>
> + nvkm_list_foreach(tdev, &device->top->device, head, tdev->runlist ==
> runl->addr) {
> + if (tdev->engine < 0) {
> + RUNL_DEBUG(runl, "engn !top");
> + return -EINVAL;
> + }
> +
> + engn = nvkm_runl_add(runl, tdev->engine, (tdev->type ==
> NVKM_ENGINE_CE) ?
> +fifo->func->engn_ce : fifo->func->engn,
> +tdev->type, tdev->inst);
> + if (!engn)
> + return -EINVAL;
> + }
> +
> + if (list_empty(&runl->engns)) {
> + RUNL_DEBUG(runl, "!engns");
> + return -EINVAL;
> + }
> +
> ret = nvkm_inth_add(&device->vfn->intr, vector & 0x0fff,
> NVKM_INTR_PRIO_NORMAL,
> &fifo->engine.subdev, ga100_runl_intr,
> &runl->inth);
> - if (ret)
> + if (ret) {
> + RUNL_ERROR(runl, "inth %d", ret);
> return ret;
> + }
>
> runl->chan = chaddr;
> runl->doorbell = dbcfg >> 16;
> @@ -514,15 +540,13 @@ ga100_fifo_runl_ctor(struct nvkm_fifo *fifo)
> runl = nvkm_runl_get(fifo, -1, tdev->runlist);
> if (!runl) {
> ret = ga100_runl_new(fifo, id++, tdev->runlist,
> &runl);
> - if (ret)
> - return ret;
> - }
> -
> - if (tdev->engine < 0)
> - continue;
> + if (ret) {
> + if (runl)
> + nvkm_runl_del(runl);
>
> - nvkm_runl_add(runl, tdev->engine, (tdev->type ==
> NVKM_ENGINE_CE) ?
> - fifo->func->engn_ce : fifo->func->engn,
> tdev->type, tdev->inst);
> + continue;
> + }
> + }
> }
>
> return 0;
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 06/10] drm/nouveau/fifo: return ERR_PTR from nvkm_runl_new()
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> Callers expect this - not NULL.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> index 93d628d7d508..454a481a0aef 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c
> @@ -399,7 +399,7 @@ nvkm_runl_new(struct nvkm_fifo *fifo, int runi, u32 addr,
> int id_nr)
> int ret;
>
> if (!(runl = kzalloc(sizeof(*runl), GFP_KERNEL)))
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> runl->func = fifo->func->runl;
> runl->fifo = fifo;
> @@ -419,7 +419,7 @@ nvkm_runl_new(struct nvkm_fifo *fifo, int runi, u32 addr,
> int id_nr)
> (ret = nvkm_chid_new(&nvkm_chan_event, subdev, id_nr, 0,
> id_nr, &runl->chid))) {
> RUNL_ERROR(runl, "cgid/chid: %d", ret);
> nvkm_runl_del(runl);
> - return NULL;
> + return ERR_PTR(ret);
> }
> } else {
> runl->cgid = nvkm_chid_ref(fifo->cgid);
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 05/10] drm/nouveau/fifo: remove left-over references to nvkm_fifo_chan
fo_chan *fifoch,
> - const struct nvkm_oclass *oclass,
> +nvkm_sw_cclass_get(struct nvkm_chan *fifoch, const struct nvkm_oclass
> *oclass,
>struct nvkm_object **pobject)
> {
> struct nvkm_sw *sw = nvkm_sw(oclass->engine);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.c
> index 834b8cbed51d..2bf45141de60 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.c
> @@ -74,7 +74,7 @@ nvkm_sw_chan = {
>
> int
> nvkm_sw_chan_ctor(const struct nvkm_sw_chan_func *func, struct nvkm_sw *sw,
> - struct nvkm_fifo_chan *fifo, const struct nvkm_oclass
> *oclass,
> + struct nvkm_chan *fifo, const struct nvkm_oclass *oclass,
> struct nvkm_sw_chan *chan)
> {
> unsigned long flags;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.h
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.h
> index 67b2e5ea93d9..c313aea16a17 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.h
> @@ -11,7 +11,7 @@ struct nvkm_sw_chan {
> const struct nvkm_sw_chan_func *func;
> struct nvkm_object object;
> struct nvkm_sw *sw;
> - struct nvkm_fifo_chan *fifo;
> + struct nvkm_chan *fifo;
> struct list_head head;
>
> #define NVKM_SW_CHAN_EVENT_PAGE_FLIP BIT(0)
> @@ -24,7 +24,7 @@ struct nvkm_sw_chan_func {
> };
>
> int nvkm_sw_chan_ctor(const struct nvkm_sw_chan_func *, struct nvkm_sw *,
> - struct nvkm_fifo_chan *, const struct nvkm_oclass *,
> + struct nvkm_chan *, const struct nvkm_oclass *,
> struct nvkm_sw_chan *);
> bool nvkm_sw_chan_mthd(struct nvkm_sw_chan *, int subc, u32 mthd, u32 data);
> #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.c
> index c3cf6f2ff86c..a0273baf4c67 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.c
> @@ -102,7 +102,7 @@ gf100_sw_chan = {
> };
>
> static int
> -gf100_sw_chan_new(struct nvkm_sw *sw, struct nvkm_fifo_chan *fifoch,
> +gf100_sw_chan_new(struct nvkm_sw *sw, struct nvkm_chan *fifoch,
> const struct nvkm_oclass *oclass,
> struct nvkm_object **pobject)
> {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.c
> index 4aa57573869c..8a1d112da894 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.c
> @@ -106,7 +106,7 @@ nv04_sw_chan = {
> };
>
> static int
> -nv04_sw_chan_new(struct nvkm_sw *sw, struct nvkm_fifo_chan *fifo,
> +nv04_sw_chan_new(struct nvkm_sw *sw, struct nvkm_chan *fifo,
> const struct nvkm_oclass *oclass, struct nvkm_object
> **pobject)
> {
> struct nv04_sw_chan *chan;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.c
> index e79e640ae535..742c75859569 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.c
> @@ -36,7 +36,7 @@ nv10_sw_chan = {
> };
>
> static int
> -nv10_sw_chan_new(struct nvkm_sw *sw, struct nvkm_fifo_chan *fifo,
> +nv10_sw_chan_new(struct nvkm_sw *sw, struct nvkm_chan *fifo,
> const struct nvkm_oclass *oclass, struct nvkm_object
> **pobject)
> {
> struct nvkm_sw_chan *chan;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.c
> index 9d7a9b7d5be3..99476d32c5af 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.c
> @@ -99,7 +99,7 @@ nv50_sw_chan = {
> };
>
> static int
> -nv50_sw_chan_new(struct nvkm_sw *sw, struct nvkm_fifo_chan *fifoch,
> +nv50_sw_chan_new(struct nvkm_sw *sw, struct nvkm_chan *fifoch,
> const struct nvkm_oclass *oclass, struct nvkm_object
> **pobject)
> {
> struct nvkm_disp *disp = sw->engine.subdev.device->disp;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/sw/priv.h
> b/drivers/gpu/drm/nouveau/nvkm/engine/sw/priv.h
> index d9d83b1b8849..8015afaba947 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/sw/priv.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/sw/priv.h
> @@ -15,7 +15,7 @@ struct nvkm_sw_chan_sclass {
> };
>
> struct nvkm_sw_func {
> - int (*chan_new)(struct nvkm_sw *, struct nvkm_fifo_chan *,
> + int (*chan_new)(struct nvkm_sw *, struct nvkm_chan *,
> const struct nvkm_oclass *, struct nvkm_object **);
> const struct nvkm_sw_chan_sclass sclass[];
> };
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 03/10] drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> Also exposes this for use by upcoming GSP-RM initialisation code.
>
> Signed-off-by: Ben Skeggs
> ---
> .../gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild | 1 +
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c | 12 +
> .../gpu/drm/nouveau/nvkm/subdev/fb/ga100.c| 3 +-
> .../gpu/drm/nouveau/nvkm/subdev/fb/gp102.c| 17 ++-
> .../gpu/drm/nouveau/nvkm/subdev/fb/gv100.c| 3 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h | 5 ++
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h | 1 +
> .../gpu/drm/nouveau/nvkm/subdev/fb/ramgp102.c | 50 +++
> .../gpu/drm/nouveau/nvkm/subdev/fb/tu102.c| 3 +-
> 10 files changed, 92 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp102.c
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
> index 01a22a13b452..1755b0df3cc1 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
> @@ -59,6 +59,7 @@ struct nvkm_fb {
> struct nvkm_memory *mmu_wr;
> };
>
> +u64 nvkm_fb_vidmem_size(struct nvkm_device *);
> int nvkm_fb_mem_unlock(struct nvkm_fb *);
>
> void nvkm_fb_tile_init(struct nvkm_fb *, int region, u32 addr, u32 size,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
> index 6ba5120a2ebe..11dbfc4a381a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild
> @@ -55,6 +55,7 @@ nvkm-y += nvkm/subdev/fb/ramgk104.o
> nvkm-y += nvkm/subdev/fb/ramgm107.o
> nvkm-y += nvkm/subdev/fb/ramgm200.o
> nvkm-y += nvkm/subdev/fb/ramgp100.o
> +nvkm-y += nvkm/subdev/fb/ramgp102.o
> nvkm-y += nvkm/subdev/fb/ramga102.o
> nvkm-y += nvkm/subdev/fb/sddr2.o
> nvkm-y += nvkm/subdev/fb/sddr3.o
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c
> index 0955340cc421..8a286a9349ac 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/base.c
> @@ -174,6 +174,18 @@ nvkm_fb_mem_unlock(struct nvkm_fb *fb)
> return 0;
> }
>
> +u64
> +nvkm_fb_vidmem_size(struct nvkm_device *device)
> +{
> + struct nvkm_fb *fb = device->fb;
> +
> + if (fb && fb->func->vidmem.size)
> + return fb->func->vidmem.size(fb);
> +
> + WARN_ON(1);
> + return 0;
> +}
> +
> static int
> nvkm_fb_init(struct nvkm_subdev *subdev)
> {
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c
> index a7456e786463..12037fd4fdf2 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ga100.c
> @@ -30,7 +30,8 @@ ga100_fb = {
> .init_page = gv100_fb_init_page,
> .init_unkn = gp100_fb_init_unkn,
> .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> - .ram_new = gp100_ram_new,
> + .vidmem.size = gp102_fb_vidmem_size,
> + .ram_new = gp102_ram_new,
> .default_bigpage = 16,
> };
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
> index 14d942e8b857..534553c64805 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
> @@ -40,6 +40,20 @@ gp102_fb_vpr_scrub_required(struct nvkm_fb *fb)
> return (nvkm_rd32(device, 0x100cd0) & 0x0010) != 0;
> }
>
> +u64
> +gp102_fb_vidmem_size(struct nvkm_fb *fb)
> +{
> + const u32 data = nvkm_rd32(fb->subdev.device, 0x100ce0);
Do we have any kind of documentation for this register?
> + const u32 lmag = (data & 0x03f0) >> 4;
> + const u32 lsca = (data & 0x000f);
> + const u64 size = (u64)lmag << (lsca + 20);
> +
> + if (data & 0x4000)
> + return size / 16 * 15;
> +
> + return size;
> +}
> +
> int
> gp102_fb_oneinit(struct nvkm_fb *fb)
> {
> @@ -59,9 +73,10 @@ gp102_fb = {
> .init_remapper = gp100_fb_init_remapper,
> .init_page = gm200_fb_init_page,
> .sysmem.flush_page_init = gf100_fb_sysmem_flush_page_init,
> + .vidmem.size = gp102_fb_vidmem_size,
> .vpr.scrub_required = gp102_fb_vpr_scrub_required,
> .vpr.scrub = gp102_fb_vpr_scrub,
> - .ram_new = gp100_ram_new,
> + .ram_new = gp102_ram_new,
> };
>
> int
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c
> index 4d8a286a7a34..f422564bee5b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gv100.c
> @@ -36,9 +36,10 @@ gv100_fb = {
> .init_page = gv100_fb_init_page,
>
Re: [Nouveau] [PATCH 02/10] drm/nouveau/nvkm: punt spurious irq messages to debug level
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> This can be completely normal in some situations (ie. non-stall intrs
> when nothing is waiting on them).
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nvkm/core/intr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/intr.c
> b/drivers/gpu/drm/nouveau/nvkm/core/intr.c
> index e20b7ca218c3..36a747f0039e 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/intr.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/intr.c
> @@ -212,8 +212,8 @@ nvkm_intr(int irq, void *arg)
> list_for_each_entry(intr, &device->intr.intr, head) {
> for (leaf = 0; leaf < intr->leaves; leaf++) {
> if (intr->stat[leaf]) {
> - nvkm_warn(intr->subdev, "intr%d:
> %08x\n",
> - leaf, intr->stat[leaf]);
> + nvkm_debug(intr->subdev, "intr%d:
> %08x\n",
> + leaf, intr->stat[leaf]);
> nvkm_intr_block_locked(intr, leaf,
> intr->stat[leaf]);
> }
> }
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [PATCH 01/10] drm/nouveau/nvkm: fini object children in reverse order
On Thu, May 25, 2023 at 2:31 AM Ben Skeggs wrote:
>
> From: Ben Skeggs
>
> Turns out, we're currently tearing down the disp core channel *before*
> the satellite channels (wndw, etc) during suspend.
>
> This makes RM return NV_ERR_NOT_SUPPORTED on attempting to reallocate
> the core channel on resume for some reason, but we probably shouldn't
> be doing it on HW either.
>
> Tear down children in the reverse of allocation order instead.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nvkm/core/object.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/object.c
> b/drivers/gpu/drm/nouveau/nvkm/core/object.c
> index 301a5e5b5f7f..7c554c14e884 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/object.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/object.c
> @@ -185,7 +185,7 @@ nvkm_object_fini(struct nvkm_object *object, bool suspend)
>
> nvif_debug(object, "%s children...\n", action);
> time = ktime_to_us(ktime_get());
> - list_for_each_entry(child, &object->tree, head) {
> + list_for_each_entry_reverse(child, &object->tree, head) {
> ret = nvkm_object_fini(child, suspend);
> if (ret && suspend)
> goto fail_child;
> --
> 2.40.1
>
Reviewed-by: Karol Herbst
Re: [Nouveau] [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(&mstm->outp->outp,
> msto->head->base.index, 0, 0, 0, 0);
> } else {
> --
> 2.40.1
>
Re: [Nouveau] [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-de...@lists.freedesktop.org > Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org > Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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: [Nouveau] [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-de...@lists.freedesktop.org > Cc: nouveau@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, > &hsbl); > 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: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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
> *
>
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(&chan->blit);
> > nvif_object_dtor(&chan->nvsw);
> > nvif_object_dtor(&chan->gart);
> > nvif_object_dtor(&chan->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(&drm->channel->user, "drmNvsw",
> >NVDRM_NVSW,
> > nouveau_abi16_swclass(drm),
> >NULL, 0, &drm->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: [Nouveau] [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.
[Nouveau] [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(&chan->blit);
nvif_object_dtor(&chan->nvsw);
nvif_object_dtor(&chan->gart);
nvif_object_dtor(&chan->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(&drm->channel->user, "drmNvsw",
NVDRM_NVSW, nouveau_abi16_swclass(drm),
NULL, 0, &drm->channel->nvsw);
+
+ if (ret == 0 && device->info.chipset >= 0x11) {
+ ret = nvif_object_ctor(&drm->channel->user, "drmBlit",
+ 0x005f, 0x009f,
+ NULL, 0, &drm->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: [Nouveau] 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: [Nouveau] [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(&acr->hsfw)) {
> + if (list_empty(&acr->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
>
[Nouveau] [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(&acr->hsfw)) {
+ if (list_empty(&acr->hsfw) || !acr->func->wpr_layout) {
nvkm_debug(subdev, "No HSFW(s)\n");
nvkm_acr_cleanup(acr);
return 0;
--
2.40.1
Re: [Nouveau] [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, &ga102_gsp },
> {}
> --
> 2.27.0
>
Re: [Nouveau] [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
>
[Nouveau] [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(&chan->blit);
nvif_object_dtor(&chan->nvsw);
nvif_object_dtor(&chan->gart);
nvif_object_dtor(&chan->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(&drm->channel->user, "drmNvsw",
NVDRM_NVSW, nouveau_abi16_swclass(drm),
NULL, 0, &drm->channel->nvsw);
+
+ if (ret == 0) {
+ u32 blit_class = device->info.chipset >= 0x11 ? 0x009f
: 0x005f;
+ ret = nvif_object_ctor(&drm->channel->user, "drmBlit",
+ 0x005f, blit_class,
+ NULL, 0, &drm->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: [Nouveau] 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: [Nouveau] 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: [Nouveau] 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: [Nouveau] [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-de...@lists.freedesktop.org
> > Cc: nouveau@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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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
>
[Nouveau] [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: [Nouveau] [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 = &asyh->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
>
[Nouveau] [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 = &asyh->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
[Nouveau] [PATCH] drm/nouveau/gr: enable memory loads on helper invocation on all channels
We have a lurking bug where Fragment Shader Helper Invocations can't load
from memory. But this is actually required in OpenGL and is causing random
hangs or failures in random shaders.
It is unknown how widespread this issue is, but shaders hitting this can
end up with infinite loops.
We enable those only on all Kepler and newer GPUs where we use our own
Firmware.
Nvidia's firmware provides a way to set a kernelspace controlled list of
mmio registers in the gr space from push buffers via MME macros.
Cc: Ben Skeggs
Cc: David Airlie
Cc: nouveau@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c | 4 +++-
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm200.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp100.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp102.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp104.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp107.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgv100.c | 10 ++
13 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c
index cb390e0134a23..950ab7c82582f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c
@@ -1332,6 +1332,8 @@ gf100_grctx_generate_floorsweep(struct gf100_gr *gr)
func->gpc_tpc_nr(gr);
if (func->r419f78)
func->r419f78(gr);
+ if (func->r419ba4)
+ func->r419ba4(gr);
if (func->tpc_mask)
func->tpc_mask(gr);
if (func->smid_config)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
index 00dbeda7e3464..f31303efbc0ff 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h
@@ -57,6 +57,7 @@ struct gf100_grctx_func {
void (*r406500)(struct gf100_gr *);
void (*gpc_tpc_nr)(struct gf100_gr *);
void (*r419f78)(struct gf100_gr *);
+ void (*r419ba4)(struct gf100_gr *);
void (*tpc_mask)(struct gf100_gr *);
void (*smid_config)(struct gf100_gr *);
/* misc other things */
@@ -117,6 +118,7 @@ void gk104_grctx_generate_r418800(struct gf100_gr *);
extern const struct gf100_grctx_func gk110_grctx;
void gk110_grctx_generate_r419eb0(struct gf100_gr *);
+void gk110_grctx_generate_r419f78(struct gf100_gr *);
extern const struct gf100_grctx_func gk110b_grctx;
extern const struct gf100_grctx_func gk208_grctx;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
index 94233d0119dff..52a234b1ef010 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c
@@ -906,7 +906,9 @@ static void
gk104_grctx_generate_r419f78(struct gf100_gr *gr)
{
struct nvkm_device *device = gr->base.engine.subdev.device;
- nvkm_mask(device, 0x419f78, 0x0001, 0x);
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0009, 0x);
}
void
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
index 4391458e1fb2f..3acdd9eeb74a7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c
@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf100_gr *gr)
nvkm_mask(device, 0x419eb0, 0x1000, 0x1000);
}
+void
+gk110_grctx_generate_r419f78(struct gf100_gr *gr)
+{
+ struct nvkm_device *device = gr->base.engine.subdev.device;
+
+ /* bit 3 set disables loads in fp helper invocations, we need it
enabled */
+ nvkm_mask(device, 0x419f78, 0x0008, 0x);
+}
+
const struct gf100_grctx_func
gk110_grctx = {
.main = gf100_grctx_generate_main,
@@ -854,4 +863,5 @@ gk110_grctx = {
.gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr,
.r418800 = gk104_grctx_generate_r418800,
.r419eb0 = gk110_grctx_generate_r419eb0,
+ .r419f78 = gk110_grctx_generate_r419f78,
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
index 7b9a34f9ec3c7..5597e87624acd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c
+++ b/drivers/gpu/drm/nouveau/nvk
Re: [Nouveau] [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-de...@lists.freedesktop.org
> Cc: nouveau@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,
> -&gr->bundle_veid);
> -}
> -
> static const struct gf100_gr_fwif
> tu102_gr_fwif[] = {
> { 0, gm200_gr_load, &tu102_gr, &gp108_gr_fecs_acr,
> &gp108_gr_gpccs_acr },
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
