00:00mupuf: Lyude: yeah, we should land all of this at the same time as it is tightly coupled
00:00mupuf: however, let's first hide it behind a kernel param
00:00mupuf: and after one or two kernels and a decent amount of feedback, let's make it the default
00:01mupuf:would hate having users running into instability issues
00:08RSpliet: Heh, yes, because Kepler is so stable otherwise
03:11martikovski: i would encourage you all not to piss off bejesus!
10:28karolherbst: https://github.com/karolherbst/nouveau/commit/2567478e4ab1f29f4c963bfe0e25779308233bd0.patch :)
10:29karolherbst: maybe I should test corner cases before thinking it fixes anything...
12:46Lekensteyn: karolherbst: is it correct to call pci_restore_state after pci_enable_device? what if things like the MMIO base address is not correctly initialized, isn't it also the purpose of pci_restore_state to fix that?
12:47Lekensteyn: Documentation/sound/kernel-api/writing-an-alsa-driver.rst also suggests to use pci_restore_state before pci_enable_device
12:47karolherbst: can it be called before doing the switch to D0?
12:47karolherbst: then it seems to work out
12:47karolherbst: let me try that as wekk
12:47Lekensteyn: maybe you can also find some guidance in Documentation/PCI/pci.txt and Documentation/power/pci.txt
12:48karolherbst: anyway, it seems to work better in general
12:48karolherbst: not using that acpi rev hack
12:48karolherbst: the painful part is, as long as the power is connected it works really well
12:48karolherbst: if not, I get various fails
12:48karolherbst: sometimes the GPU is messed up
12:49Lekensteyn: I still have not seen your acpidump :>
12:49karolherbst: sometimes secboot fails, but the device is functional
12:53karolherbst: Lekensteyn: how can I send it to you?
13:03karolherbst: Lekensteyn: mhh, I guess you have no tricks to fixup secboot :p
13:07kherbst: Lekensteyn: will do a bit more of debugging....
13:11imirkin: skeggsb: can you push my LUT fixups?
13:12imirkin: ideally with stable cc's
13:34karolherbst: Lekensteyn: well, I am running out of ideas
13:34karolherbst: as long as the machine is on power, it seems to work
13:34karolherbst: but on battery, it is just a big pile of fail
14:06Lekensteyn: karolherbst: I got your acpidump, let me have a look. It's possible that some flag variable is flipped during AC -> battery that has some side-effects
14:07karolherbst: yeah well, kind of has to be, right?
14:07karolherbst: I am enabling that REV=5 hack again and see if this is any better
14:07karolherbst: I think it was actually, but mhhh
14:13karolherbst: Lekensteyn: yeah actually both ways are equally broken
14:13karolherbst: if you want me to dump any acpi vaues/method resuts, just ping me
14:18karolherbst: NHDA: Nvidia HDA?
14:20Lekensteyn: karolherbst: possibly, NVAF possibly refers to "PCI function 1" which is HDMI audio
14:20karolherbst: or NV Audio Function
14:21imirkin_: fyi, it's not hdmi audio, it's the hda codec. this in turn is passed through to hdmi and dp audio, but that's not where the name comes from.
14:22karolherbst: ACPI naming is plain weird anyway
14:23imirkin_: (just saying, HDA is not HDmi Audio.)
14:23imirkin_: it's high-def audio, i think
14:23imirkin_: or highly digital ;)
14:24karolherbst: should be high def
14:24Lekensteyn: ACPI names are limited to four characters, at least these were not called OEM1 or something useless like that
14:26karolherbst: at least bits like those are kind of obvious :) If ((VEID == 0x10DE))
14:26karolherbst: but that PGON function really kills me...
14:27Lekensteyn: karolherbst: XTBT refers to "PEG WorkAround" which calls PGWA which has code that looks like the one from PGON. Is possibly used for ThunderBolT
14:28karolherbst: yeah, TB isn't the problem
14:28Lekensteyn: (got there by searching for "PWRS" which is used in PGWA, but it refers to a different field)
14:28karolherbst: I always hate it, if something ends up being some memory address
14:29karolherbst: and if I poke into this address all kind of weird things happen
14:43karolherbst: the thing is, I don't even think that I run into runpm issues
14:43karolherbst: because the GPU "works"
14:43karolherbst: just secboot fails hard
14:44Lekensteyn: what is the implication?
14:44karolherbst: the gpu locksdown
14:44karolherbst: *goes into lockdown
14:45karolherbst: graph doesn't run a full init
14:45karolherbst: GPU can't do hw accell
14:45karolherbst: but regs can be read and everything
14:46karolherbst: but I actually thought I fixed that issue on my machine...
14:48karolherbst: it doesn't call gf100_gr_init_ on runtime resume? weird
17:31danboyd: ok.. i just compiled a kernel from the latest git and I'm still having the Firefox resize crash issue
17:34danboyd: so the issue happened between 4.13 and 4.14 and is still there. i'll see if I can figure out how to use git bisect :)
17:34Lyude: karolherbst: still need that nouveau question answered?
17:36Lyude: mupuf: so; "land all of this at the same time" == get maxwell1 working first before submitting?
17:38imirkin_: i'd land kepler first
17:38imirkin_: more people have them
17:38imirkin_: early feedback is good
18:40skeggsb: imirkin: as they currently stand, they don't help -- fbcon will still be black on module load
18:41skeggsb: rephrase: don't help fix that bug, they help the overall situation
18:46Lyude: danboyd: i'd first check the VMM rewrite nouveau had and make sure that isn't causing the problems
18:46imirkin_: skeggsb: well, the one that makes 30-bit work is nice coz it makes 30-bit work
18:47imirkin_: skeggsb: and yes, the other one isn't a full solution, but ... partial.
18:49skeggsb: imirkin_: i *almost* have the other half of the solution for that bug fwiw
18:49imirkin_: skeggsb: oh awesome
18:49imirkin_: is it "tell fbcon to not use C8"? :)
18:50skeggsb: no, it's "handle gamma properly under atomic"
18:50imirkin_: that's a much larger fix.
18:50imirkin_: that's like the remaining 9/10ths
18:51imirkin_: skeggsb: did you make use of the fancy new gamma/degamma stuff?
18:51imirkin_: and the CSC on kepler+?
18:51skeggsb: we're still using the legacy gamma hook, and fbcon uses the atomic property ;)
18:52imirkin_: i assume you haven't addressed the 256- vs 1024-sized lut?
18:52skeggsb: in theory that's what i'll do, but i think i can do a (slightly) simpler patch first that fixes that issue alone before switching to the full properties
18:52skeggsb: there's some.. awkwardness with that vs the hw
18:53imirkin_: the 1024 thing is horrible wrt legacy api
18:53skeggsb: ie. legacy lut sets gamma_lut, which corresponds to the output lut
18:53skeggsb: but with a C8 surface, the input lut needs to be set...
18:54imirkin_: there's a lot of nasty in there
18:54imirkin_: i'd like to do it in a backwards-compatible way somehow. hopefully.
18:54imirkin_: glad you're looking at it
18:54skeggsb: not to mention that the degamma lut is per-head, and the input luts are per-plane
18:54imirkin_: but i *would* politely request some docs at the top of nv50_display.c which explain what the various mnemonics are
18:55imirkin_: coz i still don't get it... asyv asyh ahys ayhs yahs
18:55imirkin_: (i assume they're mnemonics...)
21:00karolherbst: Lyude: iomem=relaxed
21:01Lyude: sweet, thanks!
21:11Lyude: this is weird, some of the blcg registers seem to actually read back on the nvidia blob but not on nouveau
21:11karolherbst: Lyude: enabled/disabled hw blocks
21:11Lyude: I figured it'd be something like that
21:36Lyude: also, preinit for subdevs in nvkm can be called more then once correct?
21:39karolherbst: uhm, no
21:40karolherbst: you use preinit to allocate memory or stuff like that
21:40Lyude: redoing the cg patches a tiny bit so we can actually turn cg back on after suspend/resume, something I didn't realize we needed to do
21:50karolherbst: Lyude: yeah, there are the do_suspend and do_resume methods for that :)
21:51skeggsb: no, preinit() is called on resume too
21:52Lyude: mhm; I have to make sure we call them at the right time though in case those hooks get called for the subdev too early (I don't know what too early is yet, waiting for the mmiotrace fixed kernel I just started building on another machine to finish so I can see)
21:52skeggsb: it's the "before DEVINIT is run" hook
21:52Lyude: alright, I figured it might be something like that
21:54karolherbst: skeggsb: uhm. right.. my fault, onceinit was that thing called once :)
23:26imirkin_: tagr: what's the effect of your change to nouveau_ttm_io_mem_reserve?
23:26imirkin_: i.e. besides being obviously wrong, who's it hurting?
23:27tagr: imirkin_: I'm running into this when trying to mmap a block-linear buffer
23:27tagr: an PRIME exported one
23:28imirkin_: and what's the (negative) effect?
23:28imirkin_: the map fails?
23:28tagr: well, it's returning -EINVAL because it's getting &argc (argc == 0) as data and argc == 0 as length for the IOCTL so the mmap() fails
23:29imirkin_: right, makes sense.
23:29tagr: well, actually it's not the mmap() that fails, mmap() succeeeds, but trying to access the pages in userspace gets you killed with SIGBUS
23:29imirkin_: ah. good one :)
23:29imirkin_: and no one has mmap'd these before?
23:29tagr: imirkin_: skeggsb says that's not usually a path that is taken, so it's pretty much untested
23:30tagr: imirkin_: running the DDX in wfb mode was skeggsb's test case that triggers this
23:30imirkin_: i don't even know what that is
23:31tagr: me neither, but I suspect it's a software rendering path (I vaguely recall seeing wfb in the context of a software rendering library in the X server)
23:31imirkin_: i've seen wfb before too
23:50Lyude: does anyone have any plans to eventually get reclocking working on fermi again?
23:51Lyude: (assuming it ever worked?)
23:51imirkin_: again is hard
23:51imirkin_: but ben has patches to make it work for the first time
23:51Lyude: alright; was just curious
23:51imirkin_: unfortunately incomplete, but allows partial reclocking
23:52imirkin_: at least one user can't reach the highest perf level
23:52imirkin_: i'm going to check it out on my GF108's, where i suspect it'll work swimmingly
23:52imirkin_: (except for the fact that those cards are crap, but that's not wholly the patches' fault)
23:52Lyude: maybe I should move all of the clkgate helpers back into fermi's subdevs then, since that's where nvidia introduced this
23:53Lyude: but i have no idea if the programming sequence on there actually needs anything extra that i didn't notice the last time I looked
23:53skeggsb: imirkin_: oh? what didn't it work on btw
23:53imirkin_: skeggsb: 0f
23:53imirkin_: skeggsb: talk to infinity0
23:53skeggsb: didn't catch up on logs from xmas/ny break
23:53imirkin_: (since he's the one with the hardware)
23:53skeggsb: yeah i mean, what hw
23:54imirkin_: same (physical) one that RSpliet was talking about earlier
23:54infinity0: 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)
23:54skeggsb: infinity0: mmiotrace of the binary driver would be awesome :)
23:54skeggsb: and vbios image
23:54imirkin_: skeggsb: RSpliet made them
23:54skeggsb: ah sweet
23:54imirkin_: he said they're "in the usual places"
23:54imirkin_: but i don't know where that is exactly
23:54imirkin_: i'd check mmio.dumps and the repo
23:58Lyude: hm, so if we are getting reclocking working again on fermi should I actually add a set of clkgate registers for fermi, then share them with kepler1 like I did with kepler2? ( https://github.com/Lyude/linux/commit/23ee0de279363397fd85518912e641f80720974c#diff-f00ab09bd33d6658fcd5155116baf437R176 vs
23:58Lyude: https://github.com/Lyude/linux/commit/68e85de1475d6fc8f8e518d63156c1e36b78d36b#diff-da875487ef61aed97828821b9c5feb78R160 )
23:59imirkin_: that's the usual way to go
23:59Lyude: I originally had them doing that, but ended up removing it when I realized I didn't actually have any way of properly testing it