01:52Misanthropos: i have been enjoying the nouveau driver on 4.4.x kernels on a gtx 650 ti using pstate 0f with a patched volt/base.c where info.min was replaced with info.max and it runs like a charm.
01:56Misanthropos: he only glitches i found so far is flickering in dota2 when presented the "treasure items" - it doesnt bother me but you wanted me to report any bugs i found :D
04:26karolherbst: mupuf: did you find some time to test the power sensor patches with the nve4?
04:34mupuf: karolherbst: sorry, left at midnight again yesterday
04:34mupuf: but I am still home today, I can plug one of the c8/ce if you want
04:35karolherbst: let me check
04:36karolherbst: your c8 has a ina219
04:36karolherbst: same for the ce
04:36karolherbst: I think the ina3221 is mostly a kepler thing
04:40karolherbst: mhh yeah only your nve4 and gm206 have a ina3221 besides the nve6
04:40karolherbst: pmoreau: do you have access to the gm200 gpu?
04:41karolherbst: mupuf: but adding support for the ina219 shouldn't be that hard, should it?
04:42mupuf: karolherbst: I don't have the GM200
04:42mupuf: yeah, the ina219 should be sort of trivial
04:42mupuf: just boilerplate code that you can copy from the ina3221
04:43mupuf: tell me which one you want and I will put it
04:45karolherbst: the nvce only has 0mohm power_rail entries
04:45karolherbst: mupuf: I think at first I will make the code like this: if ina3221 found, use the ina3221 driver, otherwise if ina219 is found, use the ina219 driver. We can improve the code later if we have to then
04:46karolherbst: thins it, there are usually more than one ina219 :/
04:47mupuf: there is one ina219 per rail
04:47karolherbst: or maybe I just do it the clean way upfront. there can be multiple devices and each gets it's own driver instance, and the iccsense subdev has a count API and indexed accessors
04:48mupuf: just make a function that reads the power per rail
04:48karolherbst: and then we can just push out one sensor into one hwmon power file
04:48mupuf: and it will call the right driver behind
04:48karolherbst: or one file per rail
04:48karolherbst: no idea what makes more sense
04:48mupuf: nope, keep it simple
04:49mupuf: you can expose the different values in debugfs, but not in hwmon
04:49mupuf: on GM2xx, we will have only one number out anyway
04:50karolherbst: mhh right, the hwmon code would get a bit more complicated when I support a file per sensors
04:50mupuf: yeah, don't do that
04:50karolherbst: anyway, the user is most likely only interested in the total power consumption anyway
04:50mupuf: to get the total power consumption, you will just read the sense table, find all the rails
04:51mupuf: then, if mohm > 0, call the right driver
04:51karolherbst: actually this approach makes much more sense
04:52karolherbst: currently the implementation is more based on the extdev table, like even if a dev has no usefull rail, it will still be added
04:52karolherbst: so I should rather iterate over the rails and if one is sane, get the extdev and build the driver
04:52mupuf: I know, it was a design I wrote a while ago, before having all this information
04:52mupuf: yep :) I can make sense sometimes
04:53karolherbst: okay, then I will just rework the patch and also split it up a bit
04:54mupuf: be my guest!
04:57karolherbst: why the name iccsense by the way? shouldn't it be i2csense or is there a good reason to keep it icc? Or does icc stand for something else?
04:58mupuf: yes, it means something else
04:58mupuf: Icc = input current
04:58mupuf: i2c == iic :p
04:59mupuf: Icc is commonly found in the datasheets of power sensors
04:59karolherbst: ahh oaky
04:59mupuf: pwrsense also makes sense,, but no idea why I ruled it out
04:59mupuf: that was a long time ago ...
05:02karolherbst: mupuf: do we need the nv_wr16i2cr function anytime soon?
05:03mupuf: I had issues with it IIRC
05:03mupuf: so I used the generic API, but this is probably a bad idea
05:14karolherbst: but why do we have to write to the i2c bus?
05:32mupuf: oh, right, sorry
05:32mupuf: well, we could write to set up the device
05:32mupuf: there are some parameters
05:32mupuf: but I guess we can leave the defaults for now
05:34karolherbst: and we would have to parse the write access rights to then
05:34karolherbst: though we don't even parse the read rights
05:43mupuf: a read requires a write on the i2c bus
05:43mupuf: you first need to write to the offset register
05:43mupuf: and then you can read from it
05:44karolherbst: ahh okay
05:45karolherbst: mhh there are some weird vbios out there, one with a INA3221, but no usable power_rail :/
05:45mupuf: karolherbst: And I would love to know what the blob does in this case
05:45karolherbst: ohh wait, I looked wrong
05:46karolherbst: the vbios wasn't the same for both tables .D
05:46mupuf: ah ah
05:46mupuf: but please check it out nonetheless on the kepler
05:46karolherbst: no, the vbios with the extdev has usable power_rails
05:46karolherbst: the other just had 0ed power_rails
05:46karolherbst: and no extdev
05:47mupuf: Ah, I like optimizing stuff, from 29 to 9.1 and then down to 1.1 seconds
05:47karolherbst: but if you play around too much with the vbios, the blob is pissed and won't load
05:47mupuf: I know, which is good information
05:47karolherbst: like if you disable all rails then it won't load
05:48mupuf: and you know that is the only expectation you can have on the vbios :p
05:48karolherbst: I am not sure what the 0x0 byte for 0x20 ver and 0x1 byte for 0x10 version really means, but if it's 0 it means disabled
05:48karolherbst: and for vers 0x20, 0x1 means, use this
05:48karolherbst: other than that, no clue
05:49mupuf: well, you know the drill, still at work
05:49mupuf: lately, I have at work all the bloody time though, I conceede you that
05:50karolherbst: like that: https://gist.github.com/karolherbst/42a9e95612fccba46316
05:50karolherbst: ohh okay
05:51karolherbst: prg: are you up to try something out?
05:52prg: karolherbst: um, maybe
05:52karolherbst: prg: are you using a selfcompiled kernel or nouveau module?
05:52prg: on 4.3 currently
05:53karolherbst: mhh shouldn't be a problem
05:53prg: could update, no problem
05:53karolherbst: would like to test if my power sensor patches work for you?
05:53karolherbst: your vbios is a bit more odd than the others, so I want to make sure my theory works
05:54prg: ok, how to test?
05:54karolherbst: go into drivers/gpu/drm/nouveau
05:55karolherbst: download this patch: https://github.com/karolherbst/nouveau/compare/master_4.4...karolherbst:power_sensor_old.patch
05:56karolherbst: check if it applies with patch -p1 --dry-run -i patch
05:56karolherbst: it should apply, but I want to make sure
05:56karolherbst: it could conflict in nouveau_hwmon.c though
05:58karolherbst: if there is a conflict try if that you can apply this patch cleanly first: https://github.com/karolherbst/nouveau/commit/7fa6d14799cbff62e259faa45badedbe711e9b08.patch
05:59karolherbst: if it's to much hazzle then you don't need to do it, I am pretty sure that I works, but I just want to confirm this :)
06:01prg: karolherbst: it seems to be missing drm/nouveau/include/nvkm/subdev/iccsense.h
06:01prg: kernel too old?
06:01karolherbst: this should be added by the patch
06:02prg: can't find file to patch at input line 633
06:02karolherbst: ohh github messed up
06:02karolherbst: k, then I will create a patch file
06:04karolherbst: prg: https://gist.githubusercontent.com/karolherbst/e4c9a9378f75e80cfb42/raw/660fbf39b9d719ba4342b2e446525e3717474d6d/tmp.patch
06:07prg: some failed hunks, got a bit better after applying https://github.com/karolherbst/nouveau/commit/7fa6d14799cbff62e259faa45badedbe711e9b08.patch but still https://paste.debian.net/396904/
06:09karolherbst: ahh engine
06:11prg: should i just compile the module from your power_sensors branch?
06:12karolherbst: it won't compile against 4.3
06:12prg: could update to 4.4
06:12karolherbst: ahh the pcie patches do the conflict
06:12karolherbst: I could rebase the stuff on 4.3 though
06:14karolherbst: this should compile fine out of tree against 4.3
06:14karolherbst: or I could just give you a big patch with all the changes :)
06:22prg: karolherbst: ok, what now?
06:22karolherbst: prg: try sensors
06:23prg: power1: 17.58 W
06:23prg: this is new?
06:23karolherbst: also the core voltage
06:23prg: GPU core: +0.86 V
06:24karolherbst: okay, thanks for trying it out :)
06:24karolherbst: anyway, the branch you compiled has also all the 4.5 features ,)
06:24prg: no problem
06:24prg: let's see how long it takes till i manage to make it lock up again...
07:25karolherbst: mupuf: current idea: https://gist.github.com/karolherbst/94b2a0d794524bdc9c4b and nvkm_iccsense_rail.read will be either nvkm_iccsense_ina3221_read or nvkm_iccsense_ina219_read
07:26prg: ok, display is frozen again. just started a game and waited a few minutes. nothing in dmesg yet, but xorg log is spewing the mieq thing
07:26mupuf: karolherbst: looks good
07:26prg: anything i can do to debug this, or should i just reboot into the blob again?
07:27karolherbst: prg: if you are up to, you could try out more patches
07:28karolherbst: but mhh ohh I have an idea!
07:28karolherbst: prg: you are running the blob dirver usually?
07:28karolherbst: ha, then you could try out my daemon I wrote
07:28karolherbst: switch to the blob and then I will give you instructions. It is a daemon wich compares the voltage set by nvidia with the one nouveau would set
07:29karolherbst: if my stuff is close enough it would be good and if not, I would also know this
07:30karolherbst: mupuf: ohhh I bet those power budgets are per rail...
07:31mupuf: Wait, what?
07:31karolherbst: it makes sense
07:31karolherbst: I have to rails with 5 mohm, also two power budgets with 80W, but only the first matters where also only my first rail matters
07:32karolherbst: or maybe only the second one, I have to investiage it a bit, but it could make sense
07:32prg_: karolherbst: back on blob
07:32karolherbst: prg_: k
07:33karolherbst: prg_: checkout master_karol_no_touchy
07:33karolherbst: and from the nouveau root (not drm)
07:33mupuf: karolherbst: makes no sense, the load balancing needs to be done in HW
07:33mupuf: and it cannot be any other way
07:34mupuf: so, why put anything in the vbios when it is the responsability of the board manufacturer to make this part work?
07:34karolherbst: well the power budget matter in the vbios
07:34karolherbst: if I reduce them, the driver clocks down on high power usage
07:35karolherbst: well maybe not the driver does it
07:35karolherbst: but I bet the driver configures it in some way
07:35mupuf: yes, but it is not per rail
07:35mupuf: that's what I meant
07:36karolherbst: it could be per sensor
07:36prg_: karolherbst: done
07:36mupuf: why would it be per sensor?
07:36karolherbst: no idea, just a thought
07:37karolherbst: prg_: sudo LD_LIBRARY_PATH=lib/ bin/nv_cmp_volt
07:37karolherbst: it will keeps printing when something changes
07:37karolherbst: you can run it for some time and just give me the entire output
07:37prg_: ok, it keeps printing stuff
07:38prg_: now run a game?
07:38karolherbst: yeah something, doesn't really matter though
07:38karolherbst: though the output with no load might be not good enough, because there is still something missing
07:38karolherbst: I don'T repstect the per pstate minimum voltage yet
07:42prg_: karolherbst: http://paste.debian.net/397082/
07:42karolherbst: it's even better than on my gpu
07:43karolherbst: prg_: but there wasn't much load on the gpu, was there?
07:43prg_: there was none
07:43karolherbst: k, then with some load now :)
07:44prg_: http://paste.debian.net/397093/ glxgears going 30k fps
07:44karolherbst: your gpu boost pretty high
07:45karolherbst: prg_: it was sold as 1032MHz base/1098MHz boost, right?
07:46prg_: some xonotic http://paste.debian.net/397095/
07:46prg_: nfi what it was sold as
07:47karolherbst: but this looks really good
07:47karolherbst: the "rel diff nouveau/nvidia" coloumn is what's important
07:47prg_: so why does it keep locking up?
07:47karolherbst: prg_: voltage too low with stock nouveau
07:47karolherbst: you could use this branch if you compile it against 4.4
07:47karolherbst: but there is a lot of other stuff in there too
07:47karolherbst: like dynamic reclocking and so on
07:48prg_: might try
07:48karolherbst: mupuf: on prgs card my volting fixes are between 99.7% and 100.8% :)
07:48mupuf: very nice!
07:49karolherbst: and his is also a nve6
07:49karolherbst: maybe some factors are just different for each chipset
07:50karolherbst: maybe we also find them in the vbios somewhere
07:50karolherbst: but I have no clue what I am looking for actually
07:50karolherbst: but then again, we have multiple unk tables left
07:51karolherbst: prg_: this tool compares nouveau voltage based on my fixes with nvidia. I ran that tool once with the original voltage calculated by nouveau and it was only 90% close to the blob instead of 99%
07:51karolherbst: and 10% lower voltage is a lot
07:52prg_: i'll update to 4.4, try the module from this branch and let you know if it helps
07:52karolherbst: you might encounter a lot of flickers though :/
07:52karolherbst: you can disable the dynamic reclocking bits
07:53karolherbst: prg_: revert 3b1b37d928958335fe8e696b88c2dd63cb2673b1
07:54karolherbst: the conflict is easily solved
07:54prg_: will first try and see how annoying it is
07:54karolherbst: it might lockup the dyn reclokcing thing though, but then you can simply reclock manucally
07:56karolherbst: mupuf: regarding "nvkm_i2c_bus_find(i2c, 2 /*extdev.bus*/);", there is a external Port bit in the extdev table which is either set to true or false, any idea if that's related?
07:59mupuf: karolherbst: related to what?
08:01karolherbst: second parameter of nvkm_i2c_bus_find
08:15prg_: yep, i'm getting that flickering
08:15prg_: but it isn't that often
08:21karolherbst: yeah only when the gpu reclocks (memory)
09:09karolherbst: prg_: and is it still running?
09:11karolherbst: prg_: also the content of the pstate file would be nice (/sys/kernel/debug/dri/0/pstate)
09:16prg: karolherbst: still busy testing, but seems stable so far. but then again it sometimes also took quite a while to lock up previously
09:16prg: trying now with running a game and watching a video at the same time
09:16prg: pstate: https://paste.debian.net/397244/
09:27karolherbst: nice, we even get the same max clock now
10:14karolherbst: ohh there is krealloc, this make things so much easier :)
11:19karolherbst: mupuf: do you know which regs I have to poll on the ina219?
11:27karolherbst: mupuf: are you currently on reator
11:42karolherbst: mupuf: anyway, the reworked stuff is here (only ina219 support missing): https://github.com/karolherbst/nouveau/commits/power_sensors
11:49prg_: karolherbst: is the card also supposed to be automatically downclocked again? it's now in 0d pstate and drawing almost 40W at 1.21V while idle
11:51imirkin_: skeggsb: should you do the init->offset += size irregardless? (re bios/devinit: properly handle unknown generic conditions)
11:53karolherbst: prg_: it could be that the pmu is stuck
11:53karolherbst: prg_: try to manually downclock it
11:53karolherbst: prg_: there are multikple files in /sys/kernel/debug/dri/0 now
11:53karolherbst: pstate, cstate and current_load
11:54prg_: ah, it's at 17W, .86V now again
11:55prg_: load is at core, mem, vid, pci: 0x00, 0x44, 0x00, 0x00
11:55prg_: but still didn't want to downclock
11:56karolherbst: prg_: cat pstate and cstate
11:56prg_: went to 0f with glxgears automatically again
11:57karolherbst: prg_: well you have some memory load as you see
11:57prg_: and now it's down to 0a
11:57karolherbst: yeah and nvidia also didn*t clocked down to minimu
11:57prg_: now it decided to go down to 0a by itself
11:58prg_: 07 seems to work fine if i set it manually
11:58karolherbst: blob stayed at 0xf all the time ;)
11:58karolherbst: and 15th cstate
11:58prg_: yeah, it did that since i plugged in a third monitor
11:59karolherbst: right, I don't respect the pixel clock stuff yet
11:59imirkin_: skeggsb: erm... so... how does the copy engine work on kepler? i'm looking at the fuc and it has the src x/y/z all separate, but afaik on kepler it doesn't use that fuc and it's all baked in. is the api effectively different there?
11:59karolherbst: but for the memory load there is some strange mapping going on
11:59karolherbst: prg_: basically memory load should be around 30%...
12:00karolherbst: if its more, the driver clocks up
12:00karolherbst: also nvidia
12:00karolherbst: 0x4c in hex
12:00prg_: currently at pstate 07, load 0x03, 0x82, 0x00, 0x00
12:00karolherbst: yeah, you see the memory load just skyrocketed
12:01prg_: is this bad? seems to work fine so far
12:01karolherbst: it isn't really bad
12:01karolherbst: but usually it may impact performance by a bit
12:02karolherbst: and as long as the power consumption doesn't increase too much, it's fine
12:02prg_: well i'll just upclock again when i'm going to play a game
12:02karolherbst: ohh nouveau will do that on it's own
12:02prg_: k, great
12:02karolherbst: the thing about dynamic reclocking is, that you shouldn't deal with it yourself ;)
12:03prg_: seems like i still need to downclock after exiting a game
12:03karolherbst: I think I set it to 20 seconds
12:03prg_: it was stuck at 0d for longer than that
12:04karolherbst: 0d is because of your memory load
12:04karolherbst: ohh wait, 0d...
12:04karolherbst: I think I wait 20 seconds again after a downclock
12:04karolherbst: not quite sure
12:04prg_: next time i tried glxgears it went up to 0f, then down to 0a when i quit
12:05karolherbst: let me check
12:05karolherbst: well it depends on several factors though
12:05karolherbst: you won't get higher perf in every workload just by pushing up your pstate
12:05karolherbst: sometimes it is enough to just have a high core clock
12:06karolherbst: it shouldn't matter in the end what clocks are used
12:06karolherbst: as long as it has the same performance as full clocks, but uses less power, we are happy
12:06karolherbst: like you also don't want to run the gpu at full speed, just because you run a game stbale at 60 fps, maybe half clocks are totally enough for this
12:11karolherbst: _prg_: did you managed to hang the gpu? :D
12:13prg_: karolherbst: no, connection issue
12:13karolherbst: ohh good
12:14karolherbst: prg_: so it seems with the voltage fix nouveau runs the gpu more stable in general, or would you need more time to actually say this?
12:17prg_: karolherbst: not quite sure yet. i often got a lockup within minutes when i tried recently, but i think i can remember multi-hour uptimes with nouveau a while ago
12:17prg_: but it always locked up sooner or later
12:18karolherbst: well it shouldn't happen with the voltage fixes anymore
12:18prg_: will keep testing
12:18karolherbst: and if it happens
12:18karolherbst: I am really interessting in what dmesg throws out
12:19karolherbst: well we also have to take care of the flickers while reclocking, but that has lower priority at the moment and I can't test it
12:19prg_: feel free to ask if you need anything tested
12:20karolherbst: I mean we somehow know what is missing, somebody would just need to find some time to RE it :/
12:20karolherbst: but for this you need a desktop gpu and I don't have that :D
12:20prg_: i do. but no idea how to RE something like that
12:22prg_: mmiotrace the blob while it reclocks?
12:22prg_: guess that has already been done
12:22karolherbst: basically you need envytools and a time :D (and luck or good guesses
12:22prg_: got the former
12:23karolherbst: well basically there is a buffer which holds parts of the displays and then there is a difference if you have multiple displays
12:23karolherbst: and it doesn't hold the entire screen, but only some lines
12:25prg_: hm, medium difficulty in trello if i look at the right thing
12:32karolherbst: I never looked into that, so I have no idea
12:36prg_: so how does this buffer work? put a copy of current screen content into some separate piece of ram that stays accessible during reclock, then flip some switch to display that for a while?
12:37prg_: once reclock is done, flip switch back and display from vram again?
12:37karolherbst: no, while reclokcing vram there is no vram
12:37karolherbst: ohh separate piece you said
12:38karolherbst: well it is a buffer
12:38karolherbst: and with a while we are talking here about <1ms
12:38prg_: isn't that a piece of ram?
12:39karolherbst: any kind of ram is most likely too slow for this
12:39karolherbst: mayb it isn't
12:39karolherbst: it's more like a cache
12:39karolherbst: or maybe not, no clue
12:39karolherbst: it's not even big
12:39karolherbst: maybe around 1MB
12:40prg_: won't fit a single monitor then
12:40karolherbst: no, that's why it is called a "linebuffer"
12:41karolherbst: for buffering lines
12:41prg_: so just enough to gap the time till vram becomes accessible again
12:41karolherbst: something like that, yes
12:41prg_: so we'd also need to figure out which part of the screen needs to be saved
12:42prg_: for that we'd need to know exactly how long the reclock is going to take
12:42karolherbst: well that isn't a problem
12:42karolherbst: because reclocking is fast
12:42karolherbst: and we could just fill the buffer until it is full
12:42karolherbst: it's more a problem where to start
12:43prg_: any idea how it can be accessed at all?
12:43karolherbst: tracing the blob might help with that
12:44karolherbst: but who knows how that thing works
12:46prg_: doesn't sound like a great beginner task. guess i'm going to live with the flicker for now
12:47karolherbst: or you could disable the dynamic relcoking thing. I didn't add a switch to turn it off, but I will at some point
12:47karolherbst: prg_: you could just return 0; at the beggining of this function: https://github.com/karolherbst/nouveau/blob/master_karol_no_touchy/drm/nouveau/nvkm/subdev/clk/base.c#L630
12:48karolherbst: then it is basically disabled
12:48prg_: but it's convenient and i didn't mind the flickering too much yet
12:48karolherbst: the gpu will still bother your cpu sometimes, but it doesn't matter
12:48karolherbst: prg_: I think there might be no flicker with only a single monitor
12:48karolherbst: not sure though
12:49prg_: i really want to keep using multiple monitors
12:50karolherbst: it was just an assumption, I have no idea if it's better with a single monitor
13:23skeggsb: imirkin_: we made a fairly large mistake with copy engines on tesla/fermi by not sticking to nvidia's class definition, when they baked it in again, they became incompatible.. fortunately we don't have userspace that uses it, so we should perhaps fix that before we ever do
13:28karolherbst: hakzsam: ohh you are using reator?
13:28hakzsam: karolherbst, yep
13:28hakzsam: karolherbst, working on shared+atomics for kepler
13:28karolherbst: ahh I see
13:29karolherbst: I just need reator for about 5 minutes though, but before that I can still do some research :D
13:30karolherbst: I want to figure out how to read the power consumption out of the INA219 sensors from the fermi cards
13:30hakzsam: karolherbst, only the gk106 is currently plugged
13:30karolherbst: I thought mupuf also put a nvc8 in#
13:30hakzsam: I see only one card
13:30karolherbst: mhh okay
13:31karolherbst: okay, research done :D
13:31hakzsam: yeah, that's weird
13:32hakzsam: karolherbst, do you need reator for about ~5 minutes? :-)
13:32karolherbst: only if the nvc8 is there
13:32karolherbst: the nve6 has a INA3221
13:32karolherbst: which I have myself here
13:33karolherbst: well I could still check if my code still works though
13:33hakzsam: I don't why the c8 is not there
13:33hakzsam: [root@reator gles31]# nvalist
13:33hakzsam: 0: (pci) 0000:04:00.0 GK106 0e6000a1
13:33karolherbst: what about lspci | VGA ?
13:34hakzsam: only the gk106 is listed
13:34hakzsam: (as expected)
13:34hakzsam: maybe his c8 has a serious problem :)
13:35hakzsam: mupuf, ^^
13:35karolherbst: ohh the ina219 has a lot more stuff though
13:37karolherbst: funny, the ina219 can be configured to give us the power and current too
13:38AndrewR: imirkin, was this regression also affecting old nv50 chpsets? https://lists.freedesktop.org/archives/mesa-dev/2016-February/108052.html
14:00pmoreau: karolherbst: What do you want to test/get from the GM200?
14:02hakzsam: pmoreau, I want to test compute :p
14:02karolherbst: pmoreau: power sensor!
14:02pmoreau: hakzsam: Oh! :-) Well, I guess we could start with testing Nouveau first.
14:03pmoreau: karolherbst: What should I run then to get the information you need?
14:03hakzsam: pmoreau, that's a good start, indeed
14:03karolherbst: pmoreau: I don't think it works yet, because the i2c system has to be unlocked :/
14:04pmoreau: Too bad… :-(
14:05hakzsam: pmoreau, if by chance you get nouveau working on gm200, please try out this patch http://hastebin.com/utajedavif with NVF0_COMPUTE=1 and tell me if it breaks the universe or not ;)
14:06pmoreau: Ok, will try to have a look tomorrow morning.
14:06hakzsam: compute for GM200 seems like very close to GM107, so it should work
14:20karolherbst: okay, now I have to get the third voltage out of the sensors
14:27mooch: mwk: i need your help with something nv4 related
14:29mooch: basically, the drivers i'm having problems emulating keep writing to crtc reg 38h repeatedly and in quick succession
14:29mooch: without writing to the rma io space
14:30mooch: and i have no idea what they could be writing
14:31karolherbst: mupuf: do you know if the pga is changeable with the ina3221?
14:35imirkin_: skeggsb: ok. so the fuc doesn't match what kepler does. that's comforting...sorta.
14:35imirkin_: but doesn't explain why things aren't working =/
14:35karolherbst: mupuf: this 40, 80, 160, 320mV thing on the ina219
14:35karolherbst: mupuf: but I think I am done
14:36mooch: imirkin_: do you know anything about nv4
14:36imirkin_: mooch: i know it's old
14:36karolherbst: mupuf: did you know that the ina3221 values had to be >> 3?
14:36karolherbst: for some reasons the values for vshunt and vbus are differently stored on the ina219, but the same on the ina3221
14:37karolherbst: mupuf: https://github.com/karolherbst/nouveau/blob/7ff473f0dbd2152fe77a298b9862b0095afbe92d/drm/nouveau/nvkm/subdev/iccsense/base.c#L32-L68
14:37karolherbst: ohh old version..
14:37mupuf: karolherbst: sorry, board meeting
14:38imirkin_: skeggsb: are you aware of something in envytools that documents the kepler copy stuff?
14:39imirkin_: i'm seeing some weird thing with copies going wrong... but it might be something unrelated.
14:40karolherbst: mlankhorst: are you there with access to your nvc8?
14:40karolherbst: mwk: or you with your nve4?
15:01mooch: does anybody know what ports 3dch and 3deh do on nvidia cards?
15:06mooch: also 3d8h and 3d9h
15:06karolherbst: gnurou: could you ask which gpus have a ina209 power sensor?
15:08imirkin_: mooch: aren't those the standard vga i/o ports?
15:09mooch: imirkin_: nope
15:09mooch: but it's not the video card bios accessing them
15:09mooch: it's the motherboard bios...
15:10imirkin_: mooch: makes sense... coz it's trying to do vga things :)
15:14karolherbst: ... damn you FCC :/
15:41skeggsb: imirkin_: the nvidia binary driver has the class headers for DmaCopy, if you want to compare :P
15:41imirkin_: oh fun
15:47condret: is there anyone else getting freezes on shutdown with nouveau
15:47condret: when i remove it, shutdown does not freeze
15:48imirkin_: condret: what version?
15:52imirkin_: of the kernel
16:03karolherbst: hakzsam: ohh sorry, I didn't ask you if you are finished...
16:03karolherbst: you just shutdown the machine 10 minutes ago
16:03karolherbst: hakzsam: so do you still do something with reator?
16:06hakzsam: karolherbst, I'm done
16:08karolherbst: and I am now done too
20:27gnurou: mupuf: GM206 firmware pushed to https://github.com/Gnurou/linux-firmware/tree/secboot !
20:27gnurou: now all GM20X cards can boot on Nouveau
20:43airlied: skeggsb: you know if anything ever happened with, http://marc.info/?l=linux-kernel&m=144822351013978&w=2
20:44skeggsb: hrm, i remember it going past, but i don't believe so
20:48airlied: skeggsb: you have a RHEL bug the same thing :)
20:49skeggsb:adds it to the list
20:51airlied: I wonder if the width is less than 32, if so that function will definitely access bad things
20:52skeggsb: yeah, it's going to be something silly like that, need to put some effort into getting a reproducer to be sure
20:52skeggsb: job for monday i think!
21:36gnurou: skeggsb: btw, you can confirm that on GM20X the fans control registers are protected, right
21:36skeggsb: yes, i believe that was the case
21:36skeggsb: they're read-only from the host
21:37gnurou:found his next dragon to slay
21:37gnurou: guess that means PMU firmware is a must, eh
21:37skeggsb: another good reason to get pmu up eh? ;)
21:37skeggsb:has no complaints there
21:37gnurou: this would be great to get, agreed
21:38gnurou: this would also mean the current ACR will be rather short-lived if it happens quickly
21:38gnurou: still worthy to merge it and its kernel support for 4.6, right?
21:38gnurou: the ABIs between the current ACR and the PMU-enabled one will be slightly different
21:38skeggsb: what're the chances you guys can get pmu ready in the next couple of weeks? :P
21:39gnurou: based on past history? I think you can answer that question :)
21:39skeggsb: haha, yeah, i figured
21:39skeggsb: in any case, i'd still really prefer to merge *something* to support those boards asap
21:40gnurou: yeah, let's do that then
21:40gnurou: the firmware is not that big anyway
21:40gnurou: and support is already so good it would be a crime to not provide it to everyone
21:40gnurou: I was really impressed
21:41gnurou: X is pretty smooth with glamor
21:41skeggsb: well, on the kernel side i knocked off quite a bit using my host-based fecs/gpccs replacement, the class interface didn't change much, which meant userspace was already ok(ish) :P
21:41skeggsb: that helped