00:00 airlied: there are some rm api controls NV0073
00:02 airlied: which we appear to call
06:40 ad__: Lyude: issue created https://gitlab.freedesktop.org/drm/nouveau/-/issues/348
08:01 ad__: airlied: i may be completely wrong, but looks like nouveau uses nvif-> stuff for backlight access. From what i see. nvif is kind of system call (ioctl), so looks different stuff than nv0073
08:32 ad__: nouveau code is really new to me and wide, anyway, available to collaborate, or testing as needed
11:14 fdobridge: <a​huillet> (it's funny, I can't ping you from discord) -- I suggest you try to figure out what Nouveau does, and compare to openRM. https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia-modeset/src/nvkms.c#L6649
11:18 fdobridge: <m​ohamexiety> you can write the IRC username and they get an IRC ping I think, but this may vary from client to client
11:18 fdobridge: <a​huillet> oh wait, the implementation of that seems like it might not be done in GSP-RM actually?
11:19 fdobridge: <a​huillet> it seems that the blob writes to https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/inc/displayport/dpcd.h#L1181 to change the brightness (if I'm reading things properly)
11:21 fdobridge: <a​huillet> also this https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/inc/displayport/dpcd.h#L1105
12:20 fdobridge: <a​huillet> I may be very wrong (first time reading through this), but it seems that DRM passes the NV0073 ctrl to GSP, but I wonder if it is actually implemented by GSP -- seems like you need to write the DP register directly from the kernel, not through GSP (maybe?).
12:32 fdobridge: <m​arysaka> Yesterday I tried to do a full CTS run (without WSI) and it got stuck at some point then got a null pointer, is it the same issue on VMM that was discussed before? https://gist.github.com/marysaka/559a7659d9b6bef50cc94e7827925cfb
15:17 fdobridge: <g​fxstrand> Yeah, I'm pretty sure that one's been fixed. Grab my NVK branch. It's 6.8.2 + one patch.
15:18 fdobridge: <m​arysaka> Okay thank you!
16:16 fdobridge: <m​henning> Oh, it looks like that patch (" nouveau/uvmm: fix addr/range calcs for remap operations ") didn't make it into 6.8.3.
16:19 fdobridge: <g​fxstrand> :blobcatnotlikethis:
16:37 fdobridge: <m​henning> @airlied ^ was that patch supposed to hit stable? (I don't have a clear understanding of the kernel workflow.)
16:37 fdobridge: <a​irlied> It will eventually, it isn't sent to Linus yet
16:39 fdobridge: <m​henning> Okay, I'll be patient then. Thanks.
16:40 fdobridge: <!​DodoNVK (she) 🇱🇹> Is it CC'd to linux-stable though?
19:33 Lyude: btw - fixing some DP aux related issues with nouveau today that may have been making runtime PM flaky for some people :) (and also were the cause of all of the GSP error failure spam)
20:05 fdobridge: <a​huillet> what was the problem?
20:09 airlied: Lyude: btw have you seen the cursor plane bug?
20:10 Lyude: airlied: oh i haven't yet
20:11 Lyude: also ahuillet - the problem is that GSP just does not like when drivers try to do aux transactions on any kind of port that isn't actually connected and it can occasionally cause timeouts and also error spam from aux requests to GSP failing
20:12 Lyude: I've basically fixed it for the most part by just disabling aux transactions entirely when we think a connector isn't connected (and making sure to temporarily enable them during probing), along with more strictly enforcing that we don't probe eDP ports more then once ever
20:13 airlied: https://gitlab.freedesktop.org/drm/nouveau/-/issues/344
20:13 Lyude: though, now I've discovered we can also get some fun errors as a result of userspace racing with the connector probe status and trying to enable a display that isn't actually there anymore, so now I've gotta figure out a way to deal with that
20:13 airlied: Lyude: getting gsp timeouts is probably fine, as long as we don't report them
20:13 Lyude: TimurTabi: does NV_ERR_BROKEN_FB carry non-framebuffer related meaning? I'm noticing that seems to be the response we get if we attempt link training on a port that isn't actually there anymore
20:14 Lyude: airlied: it's not in this case, actually! we both do report them and I've seen it somehow cause runtime PM resume to time out
20:14 Lyude: and the errors are kind of nonsense (0xffff, so "generic error") that we can't really properly interpret as "this just failed because the connector isn't there)
20:15 Lyude: as for the other link training errors - they don't break anything but I'd like to at least know if we can reliably silence them somehow when we unplug something
20:15 Lyude: airlied: oh right i forgot about that issue sheesh
20:16 Lyude: I am taking a look at the backlight stuff that was mentioned yesterday today, so I can take some time to look at that as well
20:57 Lyude: oh hey - looks like nvidia's driver does the same thing I was thinking of having us do (e.g. disabling link training if the connector is marked as disconnected by GSP)
21:02 fdobridge: <r​inlovesyou> does this include DP audio? 👉 👈
22:12 Lyude: rinlovesyou: unfortunately no, for the time being this is just to keep current nouveau.ko in good shape until the messia^W^W^W^W^W^Wnew driver comes
23:48 fdobridge: <g​fxstrand> @karolherbst @marysaka I'd like your thoughts on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28587 when you get a few minutes
23:49 fdobridge: <g​fxstrand> It's not all that interesting. I just want to make sure folks are okay with the module structure since everything else we do with Rust will depend on it. Screwing that up too badly will make for a lot of refactoring in future.