03:45imirkin: mupuf: did you see the notes that arnd or whoever was complaining about the build fail had about doing it that way?
03:45imirkin: mupuf: i don't remember all the details tbh
03:45mupuf: imirkin: I tried looking for it on the ML but could not find it
03:45mupuf: arnd was his nickname on irc?
03:45imirkin: ok sec
03:46imirkin: thread starting with "[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration" on dri-devel
03:46mupuf: ah, DRI-devel!
03:46imirkin: "Using 'select' on user-selectable symbols risks introducing circular dependencies" is what he said about doing "select LEDS_CLASS"
03:47imirkin: his final suggestion was to just use IS_REACHABLE
03:47imirkin: if you build nouveau=y and leds_class=m, you'll silently not get led support
03:47imirkin: which imo is fine - leds is a fringe feature
03:50mupuf: yeah, right. This is plain lovely
03:54mupuf: imirkin: thanks for having such a good memory
12:54ouned: is prime known to not work after hibernation?
12:56ouned: it doesnt turn off the dGPU and as soon as it tries to use the dgpu the whole system freezes
12:56ouned: suspend works fine though
13:05pmoreau: ouned: It seems that some clevo latpops have issues resuming, see https://bugs.freedesktop.org/show_bug.cgi?id=94725#c22 starting from comment 22
13:55ouned: nouveau 0000:01:00.0: fifo: read fault at 440f80c000 engine 0c [HOST5] client 06 [HOST] reason 00 [PDE] on channel 0 [017f763000 DRM]
13:56ouned: i also get this: [ 175.019727] Uhhuh. NMI received for unknown reason 2d on CPU 0.
13:56ouned: [ 175.019729] Do you have a strange power saving mode enabled?
13:56ouned: [ 175.019730] Dazed and confused, but trying to continue
15:21orbisvicis: hey, does 4.10 come with reclocking support ?
15:21orbisvicis: imirkin: anyway I built a debug 4.9-rc8 kernel with drm-next, but the logs are 15mb ...
15:22imirkin: ... either you built a 4.9-rc8 kernel or your built a drm-next kernel. can't do both.
15:23orbisvicis: imirkin: drm next
15:24imirkin: i've completely lost context on why i asked you to do that
15:24orbisvicis: black screen on resume
15:24orbisvicis: imirkin: http://superuser.com/questions/1153248/causes-failure-to-reinitialize-video-out-on-resume
15:26imirkin: and did drm-next help?
15:27imirkin: you're gonna need help from skeggsb
15:28orbisvicis: imirkin: anyway, it seems that drm-next supports dynamic reclocking ?
15:28orbisvicis: also, how do I upload this dmesg ?
15:28imirkin: it does not.
15:28orbisvicis: kernel: nouveau 0000:05:00.0: clk: 1516000 KHz
15:29orbisvicis: ^^ I have a bunch of lines like this, where clock changes
15:30orbisvicis: ok, probably just enumerating available frequencie
15:30imirkin: precisely that :)
15:37orbisvicis: skeggsb: I'd appreciate your help in debugging a GK208 issue: video-out dead after resume
15:38orbisvicis: skeggsb: more details @ http://superuser.com/questions/1153248/causes-failure-to-reinitialize-video-out-on-resume
15:38orbisvicis: skeggsb: anyway, I have the logs for drm-next, they actual seem to contain something useful (unlike last time), but they are 15Mb (too large to upload)
17:15RSpliet: orbisvicis: expect long round trip times for messages directed at skeggsb, they have to go all the way to Australia
17:15RSpliet: (where it's currently 3:15)
17:15NanoSector: comes to mind
17:26orbisvicis: if were doing the long-distance thing, I need to figure out how to upload this log
17:36RSpliet: orbisvicis: Your best bet is bugzilla; check the "reporting bugs" page on the nouveau wiki
17:38RSpliet: big logs can be compressed using xz and if they're still too large (...) you can send them to mmio.dumps at gmail and drop a notification of that in the bug report
17:44orbisvicis: heh, RSpliet: better solution:
17:44orbisvicis: skeggsb: for the log:
17:44orbisvicis: curl -s https://paste.fedoraproject.org/501132/81132565/raw/ | base64 -d | bunzip2 > log
18:31imirkin_: anyone with a GM20x + nvidia blob - can you do some traces with an application that futzes with glSubpixelPrecisionBiasNV to see how that's programmed? [this is a non-trivial task]
18:36orbisvicis: how non-trivial ?
18:37orbisvicis: https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt --> looks simple enough ?
18:37imirkin_: orbisvicis: this would be a mmt trace
18:37imirkin_: but step 1 would be to write an application which performs the relevant steps
18:38imirkin_: some GL knowledge necessary
18:38orbisvicis: heh nevermind, then
19:31pmoreau: imirkin_: GM20x + NVIDIA blob was tempting, but then I saw I would need to write the application as well… :-D Maybe over the weekend, if I haven’t forgotten and don’t feel lazy
19:32imirkin_: i already have some basic traces in https://trello.com/c/Zjm7vs5h/149-gm200-nv-conservative-raster
19:33imirkin_: but the person who made them didn't do the subpixel stuff
19:34pmoreau: Hum… I probably need to install an old version of the blob, which still works fine with mmt… and downgrade the kernel at the same time.
19:34pmoreau: I would have to do that anyway, but… it’s becoming even less tempting :-D
19:35imirkin_: new blob doesn't work with mmt?
19:36pmoreau: I don’t think so. It is preventing hakzsam from playing with my CUDA traces on Pascal
19:37imirkin_: but that's pascal
19:37imirkin_: what about with GM20x?
19:38pmoreau: I think it remains valid for other chipsets as well
19:38imirkin_: and by "valid" you mean "non-working"?
19:38pmoreau: Though I could be misremembering: it was some time ago :-D
19:42hakzsam: new blob only doesn't work with mmt for compute (cuda)
19:43hakzsam: no need to downgrade for tracing 3D like piglit tests
19:47pmoreau: Ah, good to know! :-)
21:01Marex: airlied: hey, regarding the MXSFB, PR for single patch or PR for the whole series (4 patches then) ?
21:04airlied: Marex: since I've already pulled, just the one fix
21:04Marex: airlied: roger, sorry for the trouble
21:11Marex: airlied: I am testing the suggestion from Stefan (add missing select DRM_PANEL) now, so expect patch in less than 1 hour
21:11imirkin_: Marex: you're probably looking for #dri-devel
21:12Marex: imirkin_: oh, yeah, that's better
21:12Marex: imirkin_: sorry for the unrelated noise
21:12imirkin_: no worries
21:13Marex: imirkin_: thanks though, I wasn't aware of that channel
21:44pmoreau: skeggsb: Ping on https://bugzilla.kernel.org/show_bug.cgi?id=153911#c3
21:45pmoreau: NV_* print macros are not affected by the actual log level and max level specified in the kernel config
21:47imirkin_: pmoreau: they're not supposed to be afaik
21:47imirkin_: they're wrappers around DRM_DEBUG which is a diff mechanism
21:47imirkin_: at least ... iirc
21:48pmoreau: Ah, ok
21:49pmoreau: What are the pros of using DRM_DEBUG over the regular kernel print interface?
21:49imirkin_: no clue.
21:49imirkin_: all the cool drivers do it!
21:49pmoreau: Eh eh :-D
21:50karolherbst: prefixing I guess
21:50karolherbst: printk doesn't print the pci address
21:50imirkin_: dev_printk does
21:50imirkin_: or pr_dev or whatever
21:50karolherbst: drm log levels for another thing
21:50pmoreau: nvkm_printk which uses dev_* does print the PCI address as well
21:51karolherbst: k sure
21:51karolherbst: but nvkm_printk is for nvkm only
21:53pmoreau: Sure, but it’s a bit counter-intuitive to, let's say, limit Nouveau logs to errors, and still get warning and info ones because NV_* doesn’t care about those limitations.
21:54karolherbst: but then we should change that
21:54karolherbst: shouldn't be a problem to add log leves there, or are there some already?
21:55pmoreau: I think there are some levels already, or at least it should be easy to as you have different macros
21:58karolherbst: so we replace NV_INFO with NV_DEBUG for the annoying stuff
21:59karolherbst: maybe we could add one NV_INFO for "card putting to sleep" and "waking up card"
22:02pmoreau: Is that needed as current information?
22:03pmoreau: If it is only happening when the laptop suspend/resume, then ok
22:03pmoreau: But for an Optimus setup, this can become quite noisy, even with just two messages per suspend/resume cycle
22:05karolherbst: pmoreau: might help some users
22:05karolherbst: pmoreau: 1 message is better then 10
22:06pmoreau: That’s for sure
22:06karolherbst: the ACPI warning is annoying though
22:06karolherbst: this should be debug as well
22:06karolherbst: well sure, we know that like all mother board uefis implemented that wrongly, but why should every user be annoyed with this
22:08pmoreau: Yeah… I went back to my PR, that somewhat addressed that, last summer, but… I didn’t really wanted to go back and have a look at the ACPI spec and so on
22:36pmoreau: Hum… PGRAPH is unhappy when resuming on my G96 now… will have to investigate that at some point (tm)
23:58pmoreau: skeggsb: Updated&tested version sent. I rebased it on top of your master branch as well, so there shouldn’t be any merge conflicts.