03:57hansg: Hi all, so after needing to work on some nouveau stuff, I'm back to work at the blank window when vsync is enabled on NV46
03:58hansg: skeggsb said to look into the ddx first, last time downgrading to 1.0.10 worked, but a bisect pointed to the problem being that vsync is disabled by default in ddx 1.0.10, where as it is enabled by default in later versions
04:00hansg: So I've just started working on this again by trying "vblank_mode=3 glxgears" with 1.0.10, this yields a surprising result, things work this way, glxgears prints the message that it is syncing to vblank, but the fps display shows that it clearly is not ...
04:43night199uk: hrm, anyone know off hand what the register at mmio (0x680 + i2c index) << 5 … i.e. (0xd000, 0xd020, 0xd040) would be?
04:43night199uk: i don’t find it in nouveau
04:43night199uk: this is for kepler
04:53mupuf: night199uk: what do you mean?
04:53night199uk: i don’t see 0xd000 -> 0xd1ff listed in any of the mmio register ranges it http://envytools.readthedocs.org/en/latest/hw/mmio.html
04:53mupuf: this is PGPIO
04:53mupuf: in envytools
04:53night199uk: PGIO would make sense
04:53mupuf: have a look at rnndb instead
04:53hansg: mupuf, have you seen my question from a few lines up ?
04:54mupuf: hansg: yes, just saw it, will answer in a sec
04:54night199uk: is there an online rnndb?
04:54night199uk: otherwise i have ti build somewhere i guess
04:54night199uk: thanks :-)
04:54night199uk: is rnndb the most up-to-date source of registers?
04:55night199uk: i thought envytools.readthedocs.com was automatically updated from rnndb actually
04:56mupuf: night199uk: https://github.com/envytools/envytools/blob/master/rnndb/io/pnvio.xml#L129
04:56mupuf: rnndb != hwdocs
04:57mupuf: the point was that rnndb could be generated from hwdocs, but hwdocs never matured to that stage
04:57mupuf: readthedocs only displays the content of hwdocs
04:58mupuf: hansg: sync-to-vblank has always been buggy on nouveau
04:58mupuf: until Mario came and fixed it
04:58mupuf: IIRC, it only worked for videos
04:58night199uk: thanks mupuf
04:59hansg: mupuf, ok, so some of these fixes were probably in the ddx I guess ?
04:59mupuf: Mario Kleiner
05:00hansg: Right, so I guess I can bisect the ddx (not that much changes) testing with "vblank_mode=3 glxgears" and find the commit where the behavior changes from working but not actually syncing, to trying to actually sync and not working, that might yield an interesting result
05:01mupuf:doubts so. It possibly never worked
05:01mupuf: but I would trust skeggsb's hunch more than mine!
05:02hansg: Well the behavior has changed from not syncing (running at max fps) to not displaying anything (0 fps)
05:07hansg: I'm going to give this a try anyways, it is not that much work, and I'm stubborn :)
05:10night199uk: mupuf: any idea how this would be used in nouveau? i.e. where to look for ref?
05:11night199uk: since i don’t find 0xd000 in headers i’m guessing nouveau never uses it
05:12mupuf: night199uk: you cannot grep like that
05:13night199uk: yeah, i’m finding that. normally its a register like 0x619200 so this is easy to find
05:13mupuf: the headers are not used anymore
05:13night199uk: yeah, i noticed that too :-(
05:13mupuf: be compute the addresses ourselves
05:13mupuf: based on a ton of stuff
05:13night199uk: so any idea where the code for pgpio would be?
05:14night199uk: much appreciated
05:15mupuf: and https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gf110.c
05:15mupuf: look at the functions drive, sense, reset, intr_stat and intr_mask
05:16mupuf: that's how we have code reuse between generations
05:17night199uk: thanks - yeah, i normally find what i need
05:17night199uk: but this one eluded me for some reason
05:19mupuf: yeah, it is not typical do have so much object-oriented programming in C
05:19night199uk: try uefi :-(
05:19night199uk: same same
05:20mupuf: I'll try not :)
05:32night199uk: mupuf: i’m still missing it :-)
05:32night199uk: everything i see in the GPIO stuff reads/writes from higher regs
05:32night199uk: u32 inte1 = nv_rd32(gpio, 0x00dc88);
05:33night199uk: so the get / set seem to drive 0xd600 / 0xdc00 for everything
05:33night199uk: i don’t see anything driving 0xd000
05:35night199uk: any ideas?
05:35mupuf: ah right, you want the i2c
05:35mupuf: I don't think we use the hw-based bitbangers
05:35night199uk: yeah, i’m just looking through the i2c source again now
05:35mupuf: we use linux's implementation
05:36mupuf: which is a sw-based bitbanger
05:36mupuf: why do you care about 0xd000?
05:36night199uk: erm :-)
05:37night199uk: i see it used in some nvidia code
05:37night199uk: which i’m trying to figure out
05:38night199uk: it’s used as part of the kepler i2c implementation in their i2c init routines
05:39night199uk: which is very different from the fermi / pre-fermi stuff
09:23vivia: my problem was in troubleshooting, thanks to whoever put that together! (no EDID => 1024x768)
09:46rah: nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0000260000 [PTE] from GR/GPC0/PROP_0 on channel 0x007fb20000 [Xorg]
09:46rah: nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 2, recovering...
09:46rah: now this is getting annoying
13:02pmoreau: Oh yeah! It crashed!! Finally!
13:05pmoreau: Reverting the changes made by the PCI-reset on PPCI makes it crash again.
13:06pmoreau: So now let's find which value from PPCI do I need to reset to get the G96 to work... :-)
13:27pmoreau: And the winner is apparently: 8841c, aka. PPCI.CONFIG
13:57pmoreau: Looks like setting some of the bits between 7..0 to 1 is enough to make it unhappy.
13:58pmoreau: Too bad the default value, aka. not the one from PCI-reset, is the one that is written by the blob.
14:01mlankhorst: is PPCI.CONFIG one of the pci config registers or some config on the blob?
14:03pmoreau: I would say, not on the blob as the laptop will always default to the faulty value on power on.
14:03pmoreau: And the blob prefers to keep using it for some reason.
14:04pmoreau: It most likely enables some feature that we don't configure (or not properly at least).
14:05pmoreau: (Or that is not configured by my vbios, but will be on other computers)
14:55pmoreau: skeggsb: I'll split the commits tomorrow morning.
16:04newb123: Hi, I'm trying to get GPU passthrough working on a VM for bhyve (hypervisor). I have an ubuntu VM and I have a few errors that say "can't derive routing for PCI INT B, can't derive routing for PCI INT A". I'm trying to hunt down exactly what I need to fix in bhyve to get it working. Can someone tell me what the err messages mean?
16:15newb123: I have a GK106 card, I believe someone from the past told me that BAR1 wasn't being enumerated correctly. Is there a way to check that?