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