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