00:07 mwk: zerg rush of the mooches!
00:30 mooch: mwk: sorry about that, my internet was cutting in and out
00:40 mwk: *sigh*
00:41 mwk: I just modeled 3 more registers and of course everything is failing
01:09 nyef: ... What register is at offset 0x4c within the auxch structure?
01:10 nyef: (I don't know if it's even relevant to what I'm looking for, but I'm definitely seeing a hit on it from the blob.)
01:37 imirkin_: nyef: what does rnndb say?
01:39 nyef: Well, if I'm looking in the right place in github, https://github.com/envytools/envytools/blob/master/rnndb/io/pnvio.xml the last declared register in the array is at offset 0x40.
01:41 nyef: https://github.com/envytools/envytools/blob/master/rnndb/io/pnvio.xml#L491
01:41 imirkin_: full register
01:42 imirkin_: and then use rnn/lookup -a e7 400124 or whatever
01:42 imirkin_: doing it by hand will kill you
01:43 imirkin_: anyways, if it's not in there, it might be in the nouveau code
01:43 nyef: So, I should clone envytools and then try to figure out how to use it?
01:43 imirkin_: meh
01:43 imirkin_: that'd certainly be helpful for analyzing the mmiotrace ;)
01:43 imirkin_: rnn/demmio is quite nice.
01:44 nyef: Okay. I'll keep digging. (-:
01:45 imirkin_: i'm surprised you were able to get this far without it
01:47 nyef: Practice. Lots of practice.
01:48 imirkin_: demmio auto-looks up every read/write and decodes it
01:49 nyef: Not with mmiotrace itself, but this kind of tracking back and forth between raw I/O traces and hardware references, with a sideline in disassembled code and figuring out undocumented hardware from its behavior.
01:51 nyef: Admittedly, it's often in the context of trying to get an emulator working properly, but still...
02:01 nyef: nouveau_reg.h seems to have some of the auxch stuff, but even less of it than rnndb seems to... And nvkm/subdev/i2c/auxg94.c doesn't seem to be using the register constants?
02:08 imirkin_: yeah, that's common
02:08 imirkin_: easier to line up the code to traces
02:08 imirkin_: bbl
02:49 mwk: well that was ridiculously painful
12:18 treeNode: my computer keeps freezing .. think because of nouveau :(
12:30 treeNode: nouveau is buggy!
12:30 mwk: tell us something we don't know.
12:30 treeNode: lol
12:31 treeNode: I though there were nouveau developers here
12:32 mwk: there are, and they know exactly how buggy it is :p
12:33 treeNode: what does "nouveau: kernel rejected pushbuf: Device or resource busy" mean ? .. does some one know ?
12:34 treeNode: itas followed by "nouveau: ch7: krec 0 pushes 1 bufs 15 relocs 0" ...
17:03 nyef: Ah, that special rage, where you realize that you've outsmarted yourself somehow, and need to do yet another kernel build over NFS.
17:34 imirkin: nyef: perhaps i can interest you in cross-compilation?
17:34 imirkin: i compile everything locally and then serve stuff out over nfs
17:39 mwk: my experience with cross-compiled kernels is... bad
17:39 mwk: I have a funny feeling something went wrong with mismatched endianness somewhere
17:42 nyef: Oh, I cross-compile when I'm targetting MIPS. But in this case, it's more that my NFS server is dog slow as a filesystem, and is not my build machine.
17:45 imirkin: mwk: dunno. worksforme. do it for both arm and ppc64.
17:48 mwk: I failed horribly with ppc64
17:48 mwk: though somehow managed to produce a working kernel for ppc64le
17:52 mwk: alright, let's do a 2d test run and see what else explodes...
17:53 nyef: Are mmiotrace timestamps the same as dmesg timestamps? Can I cross-check between the two to keep my timeline straight?
17:54 mwk: hm, I'd guess so, but... no idea really
17:58 nyef: Failing that, can I have two tracers running into the same log?
19:44 imirkin: nyef: you can emit "MARK" statements into the mmiotrace log
19:44 imirkin: i forget how... you echo something somewhere
20:24 nyef: That I've been doing, but I can't do that while the system is in suspend.
20:24 nyef: I'm about to try again to get a trace + dmesg to see if they line up okay.
20:36 nyef: ... No lost events, mmiotrace starts at around 92.4 - 92.7, first remap is at 106.430535.
20:37 nyef: And the trace file says that the first map occurred at 106.430537. I think that that's a good enough match. (-:
20:46 imirkin: note that dmesg timestamps are not ntp-sync'd
20:46 imirkin: i.e. don't try to track long periods of time with them
20:46 imirkin: short ranges (or correlation) is fine
20:47 nyef: I'm looking to correlate data with less than five minutes of total system uptime. Possibly including the time spent in suspend.
20:47 imirkin: right, so that's fine ;) it gets inaccurate over days of time.
20:47 imirkin: (obv depends on your system clock...)
20:48 nyef: And, again, this is primarily to correlate events, not get an absolute timeline. (-:
20:53 nyef: Looks like the timer is paused while the system is asleep.
20:57 imirkin: yes, it is
20:57 nyef: That would make it even less accurate, long-term. (-:
21:03 nyef: Hrm. What's the significance of "video LNXVIDEO:00: Restoring backlight state"?
21:05 nyef: ... acpi_video stuff, huh?
21:11 nyef: Hrm. "[Firmware Bug]: ACPI(DGPU) defines _DOD but not _DOS"
21:18 nyef: Ah, might "just" be CONFIG_ACPI_DEBUG difference between kernels.
21:23 imirkin: or nvidia calls an acpi method that we don't
21:28 nyef: Okay, here's something: during suspend, between 226.516447 and 226.516762, the "sink present" signal for the panel aux ch disappears.
21:29 nyef: There are six writes in that gap.
21:30 nyef: 0xe06c = 0, 0x140 = 1, 0x144 = 1, 0x140 = 0, 0x144 = 0, and 0x88704 = 0.
21:30 imirkin: e06c sounds like GPIO
21:30 imirkin: 88704 is something in pci-land iirc
21:31 nyef: At 227.662244 it's back again.
21:31 imirkin: 0x140/144 are generally interrupt + intr mask registers
21:31 imirkin: note that with demmio it should tell you exactly what they are
21:32 imirkin: [by looking them up in rnndb]
21:34 imirkin: well, 88700 = GPU_RESET allegedly. 88704 could well be related.
21:34 imirkin: e06c = PNVIO.AUXCH_INTR, which sounds relevant. writing a 0 means clearing interrupt status usually.
21:35 nyef: So, that could be an HPD pulse acknowledge?
21:35 nyef: (Or something else, of course.)
21:36 imirkin: and 140/144 are ... PMC.INTR_EN_HOST / PMC.INTR_EN_NRHOST which do ... not 100% sure. something with intr routing. presumably to the host.
21:37 imirkin: yes, well, auxch communication acknowledge
21:38 nyef: At 229.195865, I see an auxch transaction to set the panel to sleep.
21:38 nyef: ... And then there are a few readbacks, for some reason.
21:38 imirkin: a lot of times it's a mask operation
21:38 imirkin: i.e. x = read; x &= mask; write(x);
21:39 imirkin: or x = (x&mask) | value, more generally
21:39 imirkin: in nouveau code, this is called nvkm_mask
21:39 imirkin: [which actually does (x&~mask)|value ]
21:40 nyef: Mmm. But I meant readbacks of the panel register over the auxch.
21:40 imirkin: dunno. could be to post a write?
21:40 imirkin: or could be the same masking logic, just done over auxch
21:41 nyef: Or could be sloppy coding, "if the panel isn't already set to sleep, set it to sleep", several times. (-:
21:41 imirkin: sure
21:41 imirkin: or sloppy panels which don't go to sleep without you asking a lot
21:45 nyef: Pre-sleep, the driver seems to read out various bits of auxch controller state, several times. Post-wake, one of the earlier things it does is write that state back in, blindly.
21:46 imirkin: interesting. there's probably a lesson in that.
21:46 nyef: Sets all the auxch config registers, sets e06c and e068, sets the auxch enable registers, and sets the auxch timeout registers.
21:47 nyef: And I know for a fact that at least one bit of the config register for the second auxch (index 1) gets cleared during sleep.
21:47 imirkin: if you want to add it to nouveau
21:48 imirkin: you can add it to the _fini and _init functions related to ... whatever owns auxch. disp i guess.
21:48 nyef: i2c, I think.
21:48 imirkin: hmmmmmm. that's dangerous.
21:48 nyef: Oh?
21:49 imirkin: well, you don't want the i2c module doing this sort of thing willy-nilly
21:49 imirkin: maybe you do?
21:49 nyef: auxch doubles as an i2c channel, and some models use hybrid pads.
21:50 imirkin: ok, so there's no auxch init/fini functions
21:50 nyef: The auxch code is in nvkm/subdev/i2c.
21:50 imirkin: yea i know
21:51 imirkin: gimme a minute... browsing some code
21:51 nyef: Anyway, as an initial test, I can "just" not load nouveau, suspend, resume, mmap() the mmio space from userland, poke at things, then load nouveau.
21:51 imirkin: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/outpdp.c#L195
21:51 imirkin: try sticking that into those init/fini functions
21:51 imirkin: note that fini is called on suspend as well as unload
21:51 imirkin: and init is called on resume as well as on load
21:51 imirkin: fini gets a "is this suspend" bool iirc
21:52 imirkin: outp->aux has a ref to the aux channel
21:53 imirkin: although if you mean it's the WHOLE AUX CONTROLLER, then it makes sense to do it in i2c
21:53 imirkin: and not stuff on the remote end of the aux channel
21:53 nyef: Yeah, the whole aux ch controller.
21:54 nyef: At 230.351471 (still during resume), the sink still doesn't register as present, but at 231.380231 it does.
21:54 nyef: There's rather a bit more going on between the two, though.
21:55 imirkin: maybe in i2c/pad.c or something?
21:55 imirkin: for auxch pads
21:55 imirkin: i dunno.
21:55 imirkin: or i2c/bus.c
21:56 imirkin: or share the trace with skeggsb and he'll be able to recommend something.
21:56 imirkin: and/or code it up for you, since it's basically his codebase
21:56 imirkin: which he knows inside and out
21:57 nyef: I won't learn as much by doing that, though. (-:
21:57 imirkin: (he has rewritten it a few too many for me to have kept track)
21:58 imirkin: either way, try to make use of his presence when he's around - he's a fountain of knowledge
21:58 nyef: Oh, absolutely.
21:58 imirkin: while i just talk, but my well has run dry long ago :)
21:59 nyef: Heh. I know that feeling, at times.
22:13 nyef: At 233.094633, the sink present signal is set, at 233.096561 it's gone again, same sequence as I found on the suspend side earlier. But by 234.119434 it's back again, and that's a much shorter sequence of operations to wade through.
23:00 mwk: happy nouveau year!
23:00 imirkin: happy nouveau year, UTC+1 :)
23:06 Tom^: happy new year