04:26shadow: RSpliet: FWIW I just tried to install Windows 10 Pro (build 2004) and the NVIDIA driver doesn't work at all on this same hardware; Debian buster fresh install with NVIDIA legacy drivers don't work either.
04:28imirkin_: it's just a weird monitor situation
04:28imirkin_: just needs a small bit of attention from someone who can dig into the details
04:29imirkin_: (you have the G92 + 100hz monitor, right?)
04:30imirkin_: can you test patches?
04:30shadow: yes I'm happy to do so
04:30imirkin_: ok. i might send some stuff tomorrow
04:30shadow: is there any particular OS I should install? I have a scratch hdd to isolate that process. Whatever makes it easier to test patches
04:31imirkin_: nope -- it's all inside the kernel
04:31shadow: oh okay :)
04:31imirkin_: as for compiling kernels, it's not really OS-dependent
04:31imirkin_: any even half-way major distro should include what's needed to build a kernel
05:06imirkin_: shadow: do you still have the gist where you had debug stuff enabled?
05:10shadow: imirkin_: https://gist.github.com/eshattow/f59ca06b1d41a852ea7811c4049ac0a2 and https://gist.github.com/eshattow/5969050adce1ae423954710e10c26c9e
05:12imirkin_: must not have had quite the right debug stuff
05:12imirkin_: could you boot with
05:12imirkin_: drm.debug=0x1e nouveau.debug=disp=trace
05:12imirkin_: and plug the monitor in
05:12imirkin_: and give me the logs from that
05:13imirkin_: (just dmesg)
05:28shadow: imirkin_: done. New gist for 'journalctl -b -1' is at https://gist.github.com/eshattow/458a78520b4817567003445524011fcb
05:29imirkin_: not what i was expecting...
05:29imirkin_: Jun 06 22:17:34 zontar kernel: [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -5
05:29imirkin_: btw, in the future, just run dmesg please
05:30imirkin_: actually yeah -- could you just run dmesg? then i don't have the other gunk in there
05:30shadow: right, looking
05:32shadow: imirkin_: okay updated https://gist.github.com/eshattow/458a78520b4817567003445524011fcb
05:33imirkin_: can you not just run "dmesg"?
05:33imirkin_: do you have to go through stupid journalctl?
05:33shadow: eh.. the system is frozen when this happens
05:33imirkin_: ah =/
05:33shadow: using journalctl for persistent logs is what I have available
05:38imirkin_: Jun 06 22:18:26 zontar kernel: nouveau 0000:01:00.0: DRM: maximum: 4x270000
05:38imirkin_: ok, so that's good. i think 4x2.7 is right for pre-DP1.2
05:41imirkin_: so based on the code, the claim is that it could do a 450mhz mode with DP 1.1? seems ... improbable.
05:44imirkin_: huh. improbable but accurate. ok. moving on...
05:50imirkin_: skeggsb: what does PIOR tend to get used for in practice?
06:18imirkin_: skeggsb: what is this for in nv50_pior_atomic_check? crtc_state->adjusted_mode.clock *= 2;
06:18imirkin_: (besides the obvious of doubling the clock...)
06:24imirkin_: oh. it's because of this guy in nv50_pior_clock: nvkm_mask(device, 0x614380 + poff, 0x00000707, 0x00000001);
09:03RSpliet: imirkin_, shadow: Apparently you can make journalctl show only kernel messages with the -k flag.
18:46imirkin: skeggsb: so the issue is ... the monitor advertises a mode with a clock of 319.75MHz. We end up picking 10bpc (which doesn't work on those GPUs, but that's a separate issue). This clock gets multiplied by 2, for a value of 639500 (aka 0x9c20c)
18:47imirkin: skeggsb: and then we get nouveau 0000:01:00.0: disp: ERROR 4 [INVALID_ARG] 84  chid 0 mthd 0c04 data 0089c20c
18:48imirkin: skeggsb: i'm wondering if we should stop doing the pior divider thing so that we just program in the clock directly?
19:50urkk: I don't know if I'm doing bisection right, as each bisection it takes about the same to compile
19:51urkk: Well, jumps are still large ~3000 commits, so that may be a factor
19:51skeggsb: imirkin: i guess you can try it... however. presumably there's some good reason nvidia did that
19:51ericonr: urkk: are you using ccache? otherwise i think the time should remain the same
19:52skeggsb: it was too long enough ago for me to remember if i tried that or not back when i wrote it
19:52imirkin: skeggsb: presumably the INVALID_ARG is because the value of the clock is too high?
19:52urkk: ericonr: damm, not yet :-)
19:54skeggsb: imirkin: yes, but i'm sure they're not just doubling it there for no good reason :P
20:01imirkin: skeggsb: what is PIOR used for?
20:01imirkin: in practice
20:02skeggsb: the only thin we use them for is a single (stupidly rare) off-chip tmds/dp encoder
20:02skeggsb: also used for SLI stuff, i believe
20:07imirkin: skeggsb: so you've seen HDMI and DVI as well as DP?
20:07imirkin: or just HDMI?
20:09skeggsb: i've tried all 3 on the single board i have that has it
20:10skeggsb: the code is unreliable as hell though, it broke at some point, and hasn't been fixed
20:16imirkin: skeggsb: hm ok. so PIOR doesn't quite work in the first place? :(
20:16imirkin: [in nouveau]
20:17skeggsb: it does sometimes :P
20:18imirkin: skeggsb: also it looks like pixel depth was only added in 837d
20:18imirkin: so i'm going to split that up ... or something
20:18imirkin: maybe make sure that "depth" gets set to 0 pre-837d
22:26kherbst: imirkin: any idea why LValue::ssa is.. pointless?
22:26kherbst: it's not used for anything
22:26kherbst: I just noticed today
22:26imirkin: yeah, i know
22:26imirkin: i think it may have been used at some point, before my time
22:27kherbst: I see
22:27kherbst: wondering if we should just clean it up then or keep both functions for "semantic"
22:28imirkin: yea wtvr
22:49imirkin: skeggsb: why does pior not have a ->update function while sor does?
22:49skeggsb: SOR's is called from MST encoder stuff too
22:50imirkin: ah. so that flow just doesn't happen for pior's?
22:50imirkin: i.e. the flow where ->udpate would get called
22:51imirkin: skeggsb: and were there any pre-G94's with SOR-based DP?
23:00RSpliet: imirkin: G94 might well have been the first NVIDIA GPU that supported DP at all. Wikipedia says "Nvidia first introduced support in the GeForce 9 series starting with the GeForce 9600 GT."
23:01imirkin: RSpliet: well, there's at least one user with DP via PIOR
23:01imirkin: on a G92
23:03RSpliet: Well, I could be pedantic and wonder whether G92 was pre-G94. But either way that'd be kind of irrelevant if it's the display class that matters!
23:03imirkin: the display class is before the G94 one
23:03imirkin: and G94 got a lot of DP support, yeah
23:04imirkin: (e.g. sorg94.c is all about DP stuff)
23:13imirkin: skeggsb: do the top two commits look reasonable? https://github.com/imirkin/nouveau/commits/pior
23:14RSpliet: Ah right. so note to self: "OR" stands for output resource, and "PI" for external. Most likely (but I guess skeggsb is the most likely to confirm that), chips prior to G94 would only support DP through an external interface
23:14imirkin: RSpliet: yes, that's correct.
23:14imirkin: skeggsb: hm, i'm missing some bit to clamp bpc to 8 actually, since otherwise the clock will still be fucked
23:15imirkin: although actually that's optional ... it's just for clock checking. so should be done, but not strictly necessary.
23:16imirkin: shadow: try the top 2 patches at the url above. you'll have to apply them from within the "drivers/gpu" directory
23:18shadow: imirkin: looking, thanks
23:21skeggsb: RSpliet: Parallel Input/Output Resource, Serial Output Resource
23:35skeggsb: imirkin: i have no idea what i think of those patches yet.. dubious about removing the doubling, as i said, nvidia probably don't do it for the fun of it
23:35skeggsb: i've also only ever seen one board with the external encoder
23:35skeggsb: that's some GM200
23:37imirkin: skeggsb: right, the nva0 with weird DP stuff
23:37imirkin: this is a laptop, i believe
23:38shadow: confirming Dell Precision M6500 laptop
23:46imirkin: shadow: well, let me know if it helps at all.
23:48shadow: imirkin: I will report within an hour or so thank you
23:51RSpliet: Oh interesting, G94 actually has a capability bit in HW named PIOR0_33_EXT_TMDS10BPC_ALLOWED (and similar) - which doesn't exist on the G92's display class. Perhaps this should be tested in nouveau_connector_mode_valid? Or would that somehow not apply to DP?
23:52RSpliet: (err... in. Through a few layers of indirection ofc)