00:33imirkin: hm. i guess it's time to nuke OP_SUB in nv50 ir and do an actual good job with ADD + modifier. should yield better results anyways...
01:29pmoreau: A bit late to the party, but Happy Nouveau Year!
01:30nyef: Three and a half hours go to here.
01:31nyef: ... I don't think I'm going to get this suspend thing figured out this year.
01:31mwk: /* Drunk. Fix later. */
01:33nyef: /* Not drunk enough. Fix later. */
01:33imirkin: /* Drunk just right. Fixing now! */
01:43nyef: Heh. "On a given board each GPIO is used for one specific purpose..." Clearly, whoever wrote the kernel documentation here hasn't run into some of the craziness that can be found with overloaded I/O pins.
01:54nyef: ... Hunh. It's generating an unplug on the eDP port?
02:01nyef: And what's this PPCI+0x704 that it keeps zeroing?
02:09nyef: ... A lot of monkeying about with interrupt controls, what looks to be GPIO 3, and that odd PPCI+0x704 location, then setting up something with PDISPLAY.SOR[0x2], more interrupt messing about, and suddenly there's a plug event.
02:09nyef: ... And this is while starting X.
02:36nyef: Ah, that 0x704 thing is to reset MSI interrupts.
03:16nyef: ... So, what if what's going on is the blob is sending a RESET signal to the panel, and nouveau isn't? Asserting RESET puts the panel to D0. De-asserting RESET puts the panel to either D1 (which is where we want to be) or to D0', where it waits to detect the source.
03:18nyef: I'm not too clear on how source detect works, but it could plausibly require setting up some sort of signal on the main lines to bring the panel out of D0' and into D1.
03:20nyef: Which means that my next step is to go through the mmiotrace again with this model in mind, and what I've managed to put together about IRQ handling.
03:50nyef: Right, *two* possibilities there. One is the RESET signal, and the other is the source detect.
13:09karolherbst: did anthing special happen the last one or two weeks? :D
13:12Yoshimo: 33c3 happened
13:15karolherbst: yeah, I know :D
13:15karolherbst: and I was there
13:15karolherbst: yesterday was fun :O
13:16karolherbst: Yoshimo: I guess you didn't see me there?
13:23karolherbst: mhh, and I even had a big badge....
13:55karolherbst: Yoshimo: also having PCD?
13:56Yoshimo: i am busy watching congress videos
13:56karolherbst: good idea
13:56karolherbst: I maybe watched like 6 talks in total there :D
13:56Yoshimo: ps4 linux is a great one
13:57karolherbst: the one space one is good
13:58karolherbst: Yoshimo: https://media.ccc.de/v/33c3-8406-the_moon_and_european_space_exploration
14:01Yoshimo: imho that space track is a waste of slots. Now to my next one. Would have been really nice to experience the atmosphere of the snowden appearance in person ;)
14:02karolherbst: watch that one talk
14:02karolherbst: it was the best of the space ones
16:53nyef: Well, I figured out how to turn the panel back on post-suspend.
16:53nyef: I don't know *why* it works, I don't know if there's *any* indication in the MXM or DCB that it should, but...
16:55nyef: (setf (sb-sys:sap-ref-32 *mmio-sap* #xe104) (logior #x7000 (logandc1 #xf000 (sb-sys:sap-ref-32 *mmio-sap* #xe104)))) does the trick. That's changing the state of GPIO 3, in PNVIO.GPIO_0, for the record.
16:57nyef: Oh, and that's for my test machine, which is running a GF114. My main machine is running a GK107, and I have no idea if it uses the same GPIO for this.
16:57karolherbst: check the vbios
16:58nyef: What am I looking for?
16:58karolherbst: the GPIO table
16:58nyef: I guess the first thing I'm looking for is GPIO 3 in the table, yeah.
17:03nyef: Found the table for the GK107, at least.
17:03nyef: #x20 entries, 5 bytes per entry.
17:05nyef: External GPIO Assignment Master Table is at #x73005898 ?
17:06karolherbst: are you using nvbios?
17:06karolherbst: and how did you extract your vbios
17:06nyef: Ah, no, misread the spec, it's at #x5898, and the 00 73 is part of the first GPIO entry.
17:07nyef: Enabled the ROM PCI resource via sysfs and copied it out.
17:07karolherbst: it would be easier to just read it out with nvbios
17:07nyef: I learn more this way.
17:07karolherbst: I mean to parse it
17:08karolherbst: well and you get only a fraction of the information as well
17:08karolherbst: I wouldn't even rely on the nvidia specs for most things because they are incomplete
17:09nyef: So noted. Clearly, I'll need to do things BOTH ways, then.
17:09karolherbst: in nvbios are most of the things also used by nouveau and a little more
17:09karolherbst: but if something is missing in nvbios, it most likely also is missing from nouveau
17:10karolherbst: but I kind of thought there were some backlight related patches in the last weeks/months
17:11karolherbst: ohh wait
17:11nyef: So, 03 01 81 00 4f. Pin 3, GPIO, initialize to "off". Panel power for LCD0.
17:12karolherbst: makes sense then
17:12nyef: I have the sudden urge to shake someone warmly by the throat.
17:12karolherbst: so we have to enable that pin on suspend
17:12karolherbst: I mean resume
17:13nyef: Ah! Okay, this actually lines up.
17:14nyef: Connector 8 with this VBIOS is the eDP port, DPAux/I2C-B, LCDID 0.
17:14nyef: So... why does the LVDS panel work?
17:14karolherbst: check the code
17:15karolherbst: maybe the GPIO defaults to on there or something like that
17:15karolherbst: or nouveau only enables it for LVDS
17:15karolherbst: or something else silly like that
17:15karolherbst: I have nearly no knowledge about the display code, so I can't say a lot about it
17:16nyef: ... Or connector 0 is the LVDS connector, and it's ALSO on LCDID 0.
17:18nyef: Now I have something to dig for in the kernel source. Thank you! (-:
17:29nyef: There's... basically nothing in here dealing with the lcdid on the connector table?
17:45nyef: ... And the GPIO is deliberately frobbed from nouveau_connector_ddc_detect(), in nouveau_connector.c, but it does so for the LCD0 panel control ONLY, without regard for the LCDID bits defined by the DCB.
17:45nyef: Does mention that LVDS power is handled by another mechanism, though.
17:47karolherbst: maybe mupuf_ knows about this?
17:47karolherbst: or pmoreau?
17:49pmoreau: I have no knowledge of what is happening in nouveau_connector.c, sorry. Or connectors in general in Nouveau.
17:51karolherbst: pmoreau: I thought you wrote some backlight code?
17:51karolherbst: or was that somebody else?
17:51pmoreau: Well… I did, but it was only to avoid Nouveau reusing the same interface name for all of them. :-D So no need to know how it works, just incr/decr a counter whenever a new interface is created/deleted.
17:52karolherbst: ohh I see
17:58nyef: So, I know why the process works for the LVDS panel, why it doesn't work for the eDP panel, and what step is missing. I know how to work around the issue from userland. I suspect a few things about what the hardware and the nvidia driver is doing that I might be able to confirm with an mmiotrace of suspend/resume with the LVS panel. I haven't a clue as to how to fix things, though.
17:58nyef: Especially, I haven't a clue as to how to fix things "properly".
18:01karolherbst: nyef: well, you know the answer already. you just need to enable that GPIO if there is a display connection for which this GPIO is important
18:02karolherbst: and this has to be done on resume as well
18:03nyef: Yes, that much.
18:24karolherbst: mupuf_: it would be nice to have a maxwell2 gpu in reator as much as possible. I have a few things to do on such a gpu
20:24nyef: My new year's resolution: 1920x1080.
20:25xen: Screen 0: minimum 320 x 200, current 7680 x 2520,
20:25xen: thanks to imirkin