01:12 imirkin: nouveau E[ PGRAPH][0000:02:00.0] M2MF 0x80000003
01:12 imirkin: do we know what this means?
01:54 AndrewR: ha, found default calibration values in nvclock sources!
01:55 huehner: Hi, i am playing wihh my gm206 nouveau again (4.3-rc4 kernel) and we some warnings when switching off/on again connected hdmi display (http://pastebin.com/raw.php?i=rA3LFQ0X), note only happens with hdmi not with vga connected to dvi
01:58 huehner: which seems to point to some locking issue:
01:58 huehner: WARN_ON(!mutex_is_locked(&mode_config->mutex) &&
01:58 huehner: !drm_modeset_is_locked(&mode_config->connection_mutex));
01:58 huehner: something known or should i report it?
02:01 imirkin: huehner: doesn't sound familiar
02:02 huehner: on the good side 4.2 -> 4.3-rc4 improved gm206 slightly even, before i had some vertical 1 pixel 'pink line' leftmost on hdmi which is now gone :)
02:03 imirkin: cool. that pink line is an issue that happens when we get the aviframe stuff wrong
02:03 imirkin: or, you know, totally forget about it
02:03 imirkin: which i think was the case for gm20x
02:16 huehner: imirkin: looks i'm too late for the locking warning https://bugs.freedesktop.org/show_bug.cgi?id=92307
02:16 AndrewR: http://www.fpaste.org/277534/ - does this looks sane? (nvclock used slightly different equation, correction was directly used, without this "-8", I hope nouveau code is more correct
02:16 imirkin: huehner: oh well, maybe next time
02:18 imirkin: huehner: perhaps chime in with a "me too" and mention that it's easily reproducible by doing XYZ?
02:19 huehner: just did that already
02:22 AndrewR: damn ...I forgot kernel will not allow float values :/ . lets round them ....
03:05 Wildefyr: what's the latest x version that works with nouveau?
03:27 AndrewR: hm, adding printk in constantly-called function was bad idea. But then, hacked-in values from nvclock apparently working.
03:30 karolherbst: mupuf: is there a way to feed pstate and cstate information into perf_init
03:31 AndrewR: http://www.fpaste.org/277555/ -current hack
03:32 karolherbst: AndrewR: slope is an int
03:32 karolherbst: that's why 792/1000 doesn't work
03:34 AndrewR: karolherbst, surprizingly-enough compilation with naive use of float types for both worked, but then I saw warnings at modpost, and recalled exacly recent talk here
03:34 karolherbst: yes, it will be 1 or 0
03:34 karolherbst: I am not sure which
03:34 karolherbst: but I think 0
03:37 karolherbst: AndrewR: is this a desktop gpu?
03:37 AndrewR: karolherbst, yes
03:38 karolherbst: 80°C is really hot
03:38 karolherbst: did you try to clean it?
03:38 karolherbst: or at least to check if it is really that hot?
03:39 karolherbst: sometimes the sensors can simply break
03:39 AndrewR: karolherbst, but at least this high temp not caused by non-working (non-rotating) fan ... I tried to change its speed and it responded :} sure, it needs some fixing, but for this I'll need to move things on table ..so, I prefer to use it at low clocks for now.
03:40 AndrewR: may be next week ...
03:40 karolherbst: ohh, so the fan doesn't get adjusted to temp?
03:41 AndrewR: karolherbst, under nvidia it says 'variable' or something like this (user-controllable in theory, but how??). Under nouveau I think it uses info from vbios, and this info says at any perf level it must be 100%
03:42 hakzsam: imirkin, cool, I'll have a look at the patches later today
03:42 karolherbst: AndrewR: coolbits
03:42 AndrewR: karolherbst, but may be this 'fan table parse failed' in my dmesg also hints at something
03:42 karolherbst: AndrewR: which driver version are you using?
03:42 karolherbst: for blob
03:42 hakzsam: imirkin, did you see the patch which fixes compute class for gf110, btw?
03:44 AndrewR: karolherbst, ah, ok, will play with this . libglx.so.304.88 - so I think 304.88 :) (surprizingly it survived xserver update 12.3 -> 14.3)
03:45 karolherbst: AndrewR: When "4" (Bit 2) is set in the "Coolbits" option value, the nvidia-settings Thermal Monitor page will allow configuration of GPU fan speed, on graphics boards with programmable fan capability.
03:46 AndrewR: karolherbst, ok, thanks
04:54 pmoreau: Ok, so now that I don't add inputs of size 0, nv50_compute_upload_input seems to take care of them :D
04:58 pmoreau: I guess I need to use the nv50_context.globals[x].handle as an offset to the input pointer
04:59 pmoreau: It should be similar to how inputs in GLSL are handled in the TGSI -> NV50 IR
05:22 Wildefyr: so am I to gather that the 970 isn't covered yet by nouvera? at least by the stable branch?
05:56 karolherbst: Wildefyr: 970 is second gen maxwell
06:08 Wildefyr: karolherbst, curenntly getting unknown chipset: NV124, the driver loads fine but it the reports the dreaded no screens
06:08 karolherbst: yeah, second gen maxwell needs signed firmware from nvidia
06:08 karolherbst: which aren't released yet
06:08 Wildefyr: oh wow
06:08 karolherbst: but basic modesetting should work
06:09 karolherbst: you will need a pretty recent driver for that kind of gpu
06:09 karolherbst: Wildefyr: linux 4.2 may be fine, but if not you can still compile from current master
06:10 karolherbst: you won't get hardware acceleration though
06:10 Wildefyr: karolherbst, no problems, I'm on linus kernel git tree and a source based distro
06:10 karolherbst: mhhh
06:10 karolherbst: that's weird
06:10 karolherbst: because linus kernel git tree should recognize the NV124 :/
06:10 karolherbst: what is your current version?
06:11 Wildefyr: 4.3.0-rc4 for kernel
06:11 Wildefyr: 1.0.11 for nouveau
06:11 karolherbst: the nouveau version looks really odd
06:11 karolherbst: it should be 1.3 for 4.3
06:11 Wildefyr: what's the latest?
06:12 Wildefyr: exactly
06:12 karolherbst: or do you mean the X driver?
06:12 Wildefyr: the x driver
06:12 Wildefyr: sorry
06:12 karolherbst: ohh no worries
06:12 karolherbst: do you get the error inside the X log?
06:12 Wildefyr: yeah, let me paste bin the output for you
06:12 karolherbst: no
06:12 karolherbst: you should use the modesetting driver
06:13 Wildefyr: which is where?
06:13 karolherbst: it is built in in the latest X release
06:13 Wildefyr: ah ok
06:13 karolherbst: just remove the nouveau driver
06:13 karolherbst: and if you use a X config, which you should not, replace nouveau with modesetting :D
06:13 Wildefyr: so get rid of the userland x nouveau driver?
06:13 karolherbst: yes
06:18 Wildefyr: hm, well this is isn't going smoothly ^^
06:27 derstrom: Hello. I'm on Debian 8 (Linux 3.16.x) which has pretty poor support for NV117. I installed the fglrx drivers to do an mmiotrace and moved the resulting firmware files into /lib/firmware/nouveau. I've reverted to the nouveau driver and the firmware is not being loaded. dmesg reports fuc409c as failing to load (-2).
06:27 derstrom: I'm not sure what to do at this point!
06:35 pmoreau: derstrom: You could upgrade to a newer kernel version
06:35 pmoreau: 4.1 should have acceleration support for your card
06:36 derstrom: I tried kernel 4.1.x that was available in Debian stable backports which was fine but it never let me go past the GNOME login screen.
06:38 derstrom: Sadly I might need to either wait until 2017 for the next Debian stable release or use the fglrx driver :-(.
06:38 pmoreau: You never got past the login, which means it crashed before? Do you have any logs from that test?
06:39 derstrom: Yes it crashes at the point of trying to login. The login screen actually displays fine but when attempting to login, that is when it crashes.
06:40 karolherbst: Wildefyr: what went wrong?
06:41 Wildefyr: karolherbst, I got it worked now, but I can't seem to open any rxvt-unicode windows
06:41 Wildefyr: or xterm windows
06:41 karolherbst: Wildefyr: how do you start X?
06:41 Wildefyr: xinit
06:42 karolherbst: mhh
06:42 karolherbst: you can always go a tty and start applications from there
06:42 karolherbst: you only need to set DISPLAY=:0
06:42 Wildefyr: I got dmenu2 working fine
06:43 Wildefyr: it just won't load them, nor sxhkc bindings work
06:43 pmoreau: derstrom: It could be great if you could grab the logs from when it crashed
06:43 karolherbst: Wildefyr: okay, but that isn't a nouveau issue anymore then :)
06:43 pmoreau: I don't recall if there were any fixes for GM1xx in 4.2 or 4.3
06:43 Wildefyr: haha perhaps not karolherbst
06:45 derstrom: pmoreau: yes I realise I should have grabbed some logs at the time. I'll look into getting those logs and filing a bug report.
06:46 pmoreau: Great
06:47 pmoreau: If you can't find 4.2 on debian repos, you can try some images here: https://nouveau.pmoreau.org/
06:47 derstrom: latest in backports is 4.1
06:54 Wildefyr: best way to get the temperator of the gpu karolherbst ?
06:56 karolherbst: Wildefyr: sensors
06:56 karolherbst: I mean the command ;)
07:17 karolherbst: mupuf: sadly I didn't found the file on reator :/
07:18 karolherbst: I bet I can use nvkm_pmu_send to retrieve some data
07:29 karolherbst: nice, it works :D
07:50 AndrewR: https://bugs.freedesktop.org/show_bug.cgi?id=92386
07:50 AndrewR: this time patch a bit more real
07:52 RSpliet: mupuf: ^
07:53 karolherbst: mupuf: if you want to take a look: https://github.com/karolherbst/nouveau/compare/8797739f79bd41fa9eaab4777078637b3677c7f3...master_karol
07:53 karolherbst: mupuf: this reports loads between 0 and 255
07:59 RSpliet: AndrewR: your VBIOS does not seem to contain this information you added "manually"
07:59 RSpliet: or, not where we expect it
08:00 RSpliet: possibly it takes hard-coding like you proposed, but the patch is likely to look slightly different
08:01 AndrewR: RSpliet, ok, thanks for looking into it
08:03 mupuf: RSpliet, karolherbst: i'm back
08:04 mupuf: AndrewR, RSpliet: We used to have hardcoded values
08:04 mupuf: but not anymore
08:05 mupuf: the guy who made nvclock did not get that those values wrong
08:05 mupuf: sorry, I mean, chip-dependent
08:05 mupuf: not chipset
08:05 AndrewR: mupuf, ah ....
08:05 mupuf: starting from nv84, nvidia started putting those values in fuses
08:06 mupuf: before that, each vbios was unique
08:06 mupuf: I guess what we need is to find the exact same coefficient as what the blob uses when there are no coefficients
08:07 mupuf: AndrewR: you do not have access to our vbios repo, right?
08:07 AndrewR: mupuf, no (nor I can use it in any meaningful way )
08:08 mupuf: well, we could look for an average values found on our vbioses
08:08 mupuf: and use that one as a default
08:08 AndrewR: mupuf, this was my plan, but in absence of any data I looked around and found nvclock :}
08:09 mupuf: right
08:10 AndrewR: mupuf, also, adding some one-time warning might be useful - I added printk and it spammed my console
08:11 mupuf: the kernel has this capacity already
08:16 AndrewR: mupuf, I just need to learn how to call it, or may be use those nvkm_ macro
08:16 mupuf: yep
08:18 AndrewR: mupuf, they not worked in 'random' places by default (completely understanable), so for quick debugging of my voltage problem I just used printk . In once-called parsing functions it worked ok.
08:32 mupuf: AndrewR: sorry, I'm back
08:33 mupuf: http://paste.pound-python.org/show/aEd5Nl5fhGtEyDhUwJaA/ <-- have fun
08:43 RSpliet: mupuf: is the offset num expected to be a large negative value in some cases?
08:43 mupuf: RSpliet: yep
08:44 mupuf: tested and verified
08:44 mupuf: the format changed on nv43 IIRC
08:44 karolherbst: mupuf: saw my stufF?
08:44 mupuf: karolherbst: yes!
08:44 mupuf: it looked ok
08:44 karolherbst: yeah
08:44 mupuf: as i said, in the end, the code looks kind of the same, doesn't it? :D
08:44 karolherbst: I disliked your approach to send multiple methods to the falcon just to get all counters
08:45 karolherbst: well, there are some API/ABI differences ;)
08:45 mupuf: hmm, I did not check that
08:45 karolherbst: but I got to lern how to code the falonc
08:45 karolherbst: basically I write into data[1]
08:45 karolherbst: masked
08:45 karolherbst: 0xff000000 pcie, 0x00ff0000 memory, ...
08:45 karolherbst: and just report the load on a 0-255 scale
08:46 mupuf: ... you should definitely not handle the communication this way :D
08:46 karolherbst: also I don't need your mul_32_32_64 function
08:46 mupuf: first, you need to poll the counters without the help of the host
08:46 karolherbst: I just shr 8 the ticks and div by that
08:47 karolherbst: mupuf: I do
08:47 mupuf: the host may want to read the values too
08:47 karolherbst: this is just for a debugfs interface
08:47 karolherbst: ohhh
08:47 karolherbst: mhhh
08:48 mupuf: and I think the way I handled this was just to let the host map the memory of the process, can't really remember
08:48 mupuf: since I can update atomically the entire word
08:48 mupuf: and that meant no back and forth
08:49 karolherbst: mhh okay
08:49 karolherbst: I just had the dyn reclock thing in mind while writing the code
08:49 karolherbst: I didn't thought of a reason, why the host wants to have the counter values directly
08:49 mupuf: yeah
08:49 karolherbst: I also need to send some pstate/cstate information to the falcon
08:49 mupuf: I really do not see what you could simplify in my code though
08:49 karolherbst: max pstates/cstates, max cstate for each pstate
08:50 mupuf: why would you?
08:50 mupuf: you do not need this information
08:50 karolherbst: because I can calculate the next pstate/cstate on the falcon
08:50 karolherbst: or should I just check some thresholds and let the host do that?
08:50 mupuf: just check the thresholds and send an IRQ when you need to upclock/downclock a perf domain
08:50 karolherbst: mhhh
08:51 mupuf: you definitely do not want to do anything more in assembly code :D
08:51 karolherbst: to be sure about that, I need at least the max amount of pstate/cstates
08:51 karolherbst: or I have to change my algo
08:51 karolherbst: :D
08:51 mupuf: nope
08:51 karolherbst: well my current algo needs that
08:51 karolherbst: cur_cstate += ((load_core - load_tar_core) * cstate_count) / (load_tar_core + (100 - load_tar_core) / 4);
08:51 mupuf: you just need to not send another irq until the host tells you that it changed the frequency
08:52 karolherbst: mhh right, I also need this
08:52 karolherbst: mhhhh
08:53 mupuf: what I suggest is to have a int8 that represents how far you are from the target (which has a histeresis)
08:53 mupuf: and let the host decide what to do
08:53 karolherbst: I could try to find an algo which doesn't need the max amount of pstates/cstates
08:53 karolherbst: mupuf: I don't want to bother the host every 0.1 secs though
08:53 mupuf: you can keep this algo in the kernel space
08:53 mupuf: of course you do not want that :)
08:54 mupuf: but as I said, you should not fire another IRQ unless there is an actual change
08:54 karolherbst: but I don't mind to code anything more complex in assembly :D
08:54 mupuf: do not send two times that you need to downclock one perf domain until the driver tells you : OK, I did change the performance of this domain
08:55 mupuf: so you say :D
08:55 karolherbst: have to cook some food, I will think about that, maybe I will get a really smart idea or so
08:55 mupuf: have fun!
08:55 karolherbst: mupuf: sometimes the load is pretty volatile
08:55 karolherbst: and we wait long time before we downclock
08:55 mupuf: spurous you mean?
08:55 karolherbst: no
08:55 karolherbst: volatile
08:56 karolherbst: like quick loading screens in game
08:56 mupuf: what do you mean by volatile?
08:56 karolherbst: stuff like that
08:56 mupuf: bursty?
08:56 karolherbst: not exactly bursty
08:56 karolherbst: maybe jumpy
08:56 karolherbst: unstable
08:56 mupuf: this is the typical case
08:56 karolherbst: like target is 70, and the load moves between 65 and 75
08:56 karolherbst: what should the falcon doi then?
08:57 karolherbst: request uplock, /downclock all the time?
08:57 mupuf: didn't I say hysteresis?
08:57 mupuf: nvidia definitely uses one
08:57 karolherbst: I really would like to see their algo :D
08:57 mupuf: and before coding too much, we need to create this test bench
08:58 mupuf:will NAK almost everything until we have it
08:58 mupuf: this is the most performance-critical thing we are working on, we need the proper tooling to actually check it
08:58 karolherbst: k
08:58 karolherbst: right
08:58 mupuf: and nvidia will kill us if we screw this up!
08:58 karolherbst: why? :D
08:59 mupuf: because we are not going to have thousands of algo
08:59 mupuf: and they want to support tegra
08:59 mupuf: on nouveau
08:59 karolherbst: I meant, why will nvidia kill us?
08:59 mupuf: because their customers would complain?
08:59 Wildefyr: do any of the nouveau devs get funded at all?
09:00 karolherbst: mupuf: you mean for tegra?
09:00 mupuf: Wildefyr: no, but we do work together
09:00 mupuf: karolherbst: yes
09:00 RSpliet: mupuf: is there a reason why (seemingly) all GPUs with no slope/offset values have a MAX 6649 listed in their EXTDEV table?
09:00 karolherbst: k
09:00 Wildefyr: mupuf, shame
09:00 Wildefyr: but alsa yay!?
09:00 mupuf: RSpliet: hehe, that sounds liek a reason :D
09:00 karolherbst: mupuf: I saw their current algo, and that one isn't that smart
09:01 mupuf: Wildefyr: they do pay one engineer to work on it almost full time
09:01 mupuf: karolherbst: it is one they proved on their testing rif
09:01 Wildefyr: well that's something I suppose
09:01 Wildefyr: 1 guy!
09:01 RSpliet: mupuf: now go and fix :-P
09:01 karolherbst: mupuf: the one in the nouveau tegra code
09:01 mupuf: karolherbst: I understand :)
09:02 mupuf: I don't mean to be rude or to slow you down, I just want you to understand the implication of your work
09:02 karolherbst: I know
09:02 mupuf: I really value your work and I want to thank you for it!
09:02 mupuf: but I will not accept cutting corners when it comes to this
09:03 karolherbst: no problem for me
09:03 karolherbst: I am only worried if there is no nitpick on my patches :D
09:03 Wildefyr: does anyone know what kernel the propietary driver was working on last? I want to just have a separate kernel to go to if I need to do something graphically intensive, although I think I will be using nouveau a lot more now
09:04 karolherbst: Wildefyr: you could always use bumblebee and a really nice config setup
09:04 mupuf: noooo!! I will have to head downtown to buy an hdmi cable for the jetson!
09:04 Wildefyr: karolherbst, no go if
09:04 karolherbst: Wildefyr: I have both (nvidia and nouveau) installed and can switch between them in seconds
09:04 Wildefyr: I want to have a git rolling kernel
09:05 karolherbst: but I also have a laptop, so that's cheating
09:05 Wildefyr: !
09:05 karolherbst: 4.1 works with blob
09:05 Wildefyr: although that's a pretty cool use of bumblebee there
09:05 karolherbst: Wildefyr: I don't use bumblebee for nouveau though
09:05 Wildefyr: oh
09:05 karolherbst: the daemon is still running, but it doesn't do much
09:05 Wildefyr: my mistake
09:06 karolherbst: the nouveau ddx driver is the part with the biggest pain to get that working
09:06 karolherbst: 1. dri3 only, 2. the x server isn't allowed to open any fd from the nouveau ddx
09:07 karolherbst: mupuf: but you have nothing against the idea to use 0-255 scale instead of 0-100?
09:07 karolherbst: it makes the assembly code much easier
09:08 karolherbst: though I could divide by 100 :/
09:08 karolherbst: but a shift is faster I assume
09:09 RSpliet: quite a bit faster, I don't think the falcon has a hardware divider
09:09 karolherbst: the doc says 30-33 cycles
09:09 karolherbst: for div
09:09 karolherbst: RSpliet: ohh div is since v3
09:10 RSpliet: ah right
09:11 karolherbst: I was wondering if there is a div SD S combination
09:11 mupuf: RSpliet: there is a divider
09:11 mupuf: it just takes 32 cycles
09:11 mupuf: all the other instructions take 1 cycle
09:11 mupuf: even mul u16*u16
09:11 karolherbst: mupuf: I do four divs :/
09:12 RSpliet: mupuf: v3+ only, I don't know if that includes Tesla
09:12 mupuf: karolherbst: why do you even care?
09:12 karolherbst: mupuf: don't know :D
09:12 karolherbst: it is assembly, you _have_to_ optimize it to the last :p
09:12 karolherbst: but that makes my code pretty unusable on tesla cards
09:12 karolherbst: RSpliet: fermi
09:13 RSpliet: karolherbst: 2nd gen Tesla
09:13 karolherbst: ohh right
09:13 karolherbst: I would need to change the code if I want to use that on 1st gen tesla
09:13 karolherbst: is it even possible?
09:14 RSpliet: no
09:14 mupuf: karolherbst: no
09:14 RSpliet: 1st gen doesn't have PDAEMON at all
09:15 karolherbst: k
09:16 mupuf: well, no hdmi cable == no fun with the jetson tonight!
09:16 karolherbst: mupuf: have some copper? :D
09:16 mupuf: I may work on wtrpm though, to be able to reboot the board
09:16 mupuf: ahah
09:17 karolherbst: I really would like to do stuff like div $r2 $r1
09:17 karolherbst: :D
09:18 karolherbst: mupuf: what would be reasons to change the period of the counter reads?
09:18 mupuf: consuming less power?
09:18 karolherbst: does the falcon draw that much?
09:21 mupuf: it does draw
09:25 karolherbst: mupuf: okay
10:52 karolherbst: mupuf: are there any good theories about creating good benchmarks for dyn reclocks?
10:53 mupuf: yes, we need to make apitraces of multiple benchmarks
10:53 mupuf: we may not need to for xonotic and unigine benchmarks
10:53 karolherbst: okay, and then just run them at max perf vs dyn perf?
10:53 mupuf: but we do not it for browsers
10:53 mupuf: yes
10:54 mupuf: we need to set how much we accept to lose
10:54 karolherbst: and if perf is like 0.5% different it is "okay"?
10:54 karolherbst: k
10:54 mupuf: but there is more to it
10:54 mupuf: we need to also track how much power we save
10:54 karolherbst: mhh
10:54 mupuf: and that is hard
10:54 karolherbst: couldn't we just track which cstate is selected?
10:55 mupuf: I guess we could use the voltage as an indicator
10:55 mupuf: and only use this one
10:55 karolherbst: mhh
10:55 karolherbst: maybe we could also use the load as a factor
10:55 mupuf: you can't
10:55 karolherbst: they are some boards for which we can messure the power though
10:55 mupuf: because the load depends on the frequency
10:56 karolherbst: yeah I know
10:56 mupuf: yes, for long benchmarks, it would work, you are right
10:56 karolherbst: but on lower load we draw less power
10:56 mupuf: yeah, let's do that
10:56 mupuf: well, what is better, higher freq but lower load or lower freq and higher load?
10:56 karolherbst: do you know if the gpu can collect the power consumption over time somehow?
10:56 mupuf: if you can model that, you are the kind of the world :D
10:56 karolherbst: mupuf: we don't really know
10:57 mupuf: you'll need to integrate it
10:57 karolherbst: mhhh
10:57 mupuf: I know we cannot know
10:57 karolherbst: in the second version maybe, I don't want to factor also the power consumption in really
10:57 karolherbst: we can just assume to be stupid and say: lower cstate less pwoer
10:57 karolherbst: lower load, less power
10:57 mupuf: not without the RTL and characteristics of the transistors used
10:58 mupuf: the load is constant, we make sure of this by making apitraces
10:58 mupuf: or using fixed-time benchmarks like xonotic
10:59 mupuf: or we should cap the rendering
10:59 mupuf: but it is imperfect
10:59 karolherbst: we also need benchmarks with high cpu load
10:59 mupuf: for example, in the browser case, we really need to have a real time test
10:59 karolherbst: where the gpu load is not 100%
11:00 mupuf: I wonder if we should not use another method involving downloading the content of a website in local
11:00 mupuf: then putting the browser full screen
11:00 karolherbst: there are cases, where the gpu will run on like lower cstate, highest pstate and still can't get more perf out of an applicatio
11:00 mupuf: and recording the actions of the user
11:00 karolherbst: n
11:00 mupuf: and then replay them when we plan on testing the consumption
11:01 karolherbst: we should really get the power consumption into the kernel somehow :/
11:01 mupuf: yes, but let's use the actual power usage that we integrate to get the average power consumption throughout the benchmark
11:01 mupuf: yes, we will need it
11:01 mupuf: let's add a kernel-space version of it this week end?
11:01 karolherbst: at least I have patches for core voltage already :D
11:02 mupuf: I will be plugging the jetson to wtrpm tonight and tomorrow I can work on finishing up my patches to expose the inaXXXX on nouveau
11:02 karolherbst: I also planned to add memory voltage, but is this even possible?
11:02 mupuf: no, we won't need all this
11:02 karolherbst: just say no, I remove that and you could add your stuf fon top of mine :D
11:03 mupuf: we will only run the benchmark on devices that have power readers
11:03 karolherbst: yeah, but I also want to add support for the vore voltage, unrelated to this
11:03 karolherbst: just for debugging
11:03 karolherbst: because there are just too many cards where this stuff is semi broken somehow
11:03 mupuf: to read it bck?
11:03 karolherbst: to have it in perfmon
11:04 mupuf: oh, sweet idea, being able to track the frequency in the gallium HUD
11:04 mupuf: freq, voltage and other parameters
11:04 mupuf: hakzsam is going to love the idea ... NOT :D
11:04 karolherbst: :D
11:04 mupuf: those are cpu-synchronised anyway, so polling it from the userspace is enough
11:04 karolherbst: https://gist.github.com/karolherbst/b20bc4c8183a7277646a *cough*
11:05 karolherbst: power is a fake value though
11:05 mupuf: yes, you are right, we should expose it through sysfs
11:05 karolherbst: any idea how to get the memory voltage?
11:05 mupuf: it is a gpio
11:05 karolherbst: I know
11:05 karolherbst: but I don't kow which voltages are mapped to it
11:05 mupuf: that's all we know
11:05 karolherbst: k
11:05 karolherbst: so I remove that
11:06 mupuf: well, find the datasheet of GDDR5 and see if there are 2 voltages specified
11:06 mupuf: pretty sure you will get the info there
11:06 mupuf: good luck finding doc on them
11:06 karolherbst: mupuf: fyi I need this: https://github.com/karolherbst/nouveau/commit/877a9aac4087ec3a2712e00d84c9a88b8ccb39f2
11:06 karolherbst: otherwise voltage is too low
11:07 karolherbst: I mean, it still works in like 99% of all cases
11:07 mupuf: in the mean time, /me found how to start/stop the jetson with gpios
11:07 karolherbst: but this is much more safe
11:07 mupuf: and read the power state
11:07 mupuf: just need to plug that into wtrpm
11:07 mupuf: I hope it works because the voltages are MUCH lower than on ibm-compatible computers
11:08 mupuf: the power LED should be fine
11:10 karolherbst: mupuf: will you need this? https://github.com/karolherbst/nouveau/commit/ff9fe00939fd2e52ea3a51ce93aec8ad1acfb826 :D
11:12 mupuf: yes, I will
11:13 karolherbst: I have something more usefull though
11:16 karolherbst: mupuf: I did the hwmon bits for the power consumption already here (+ this patch + core voltage in hwmon): https://github.com/karolherbst/nouveau/commits/hwmon
11:18 mupuf: ok, I can take those
11:18 karolherbst: the hwmon interface is a bit too implicit for me :/ you just have to know how to name those files :D
11:28 mupuf: don't get me started on hwmon
11:40 mupuf: ok, so I can boot the jetson from wt-rpm ... but the LED state is not updated
11:40 mupuf: let's see if I can make this work by changing a resistor :s
11:42 mupuf: yeepee!!! the jetson is working as expected!
11:43 mupuf: I just plugged the led input to the wrong pins
11:44 karolherbst: :D
11:45 karolherbst: oh maybe I should do something with my arm dev board here
11:54 mupuf: ok, can't go any further without an hdmi cable, it would seem
11:55 karolherbst: mupuf: do you know any way to check if nouveau supports reading out the core voltage before doing so?
11:55 mupuf: if the volt subdev is there, then it is supported
11:56 karolherbst: mhhh, I would like to say yes, but it is not the case, at least not for the card in use
11:56 karolherbst: chipset yes, card maybe
11:56 karolherbst: like on my card I also had a volt subdev even though pwm voltage wasn't supported
11:57 karolherbst: mhh
11:57 karolherbst: I could juse call nvkm_volt_get
11:57 karolherbst: and if the result is an error, the driver can't do that
11:57 karolherbst: before actually adding the hwmon entries
11:59 karolherbst: but this is kind of ugly
11:59 karolherbst: would be nice to have some kind of check, which can also be called inside init, and on failure we could print a warning or something
12:00 mupuf: yes, you can try to read the voltage
12:00 mupuf: I do that for reclocking too
12:01 mupuf: hmm, there is a serial console!
12:01 karolherbst: :)
12:01 karolherbst: yay
12:01 mupuf:will be able to make something of this board even without the hdmi cable
12:01 karolherbst: pmoreau: there?
12:01 pmoreau: karolherbst: Nope
12:01 pmoreau: :D
12:02 karolherbst: :(
12:02 pmoreau: What can I do for you?
12:02 karolherbst: you are lucky you have the same color as mupuf has :D
12:02 karolherbst: pmoreau: just test if the voltage entry doesn't show up for on of your gpus
12:02 pmoreau: Interesting! :-)
12:02 pmoreau: In sensors?
12:03 karolherbst: yes
12:03 imirkin: Wildefyr: GM20x modesetting has been supported since 3.19 -- if you're seeing unsupported chipset NV124 then you're booting a kernel older than that.
12:03 karolherbst: you hade one gpu with N/A
12:03 karolherbst: imirkin: the message was in the X log
12:04 karolherbst: does 1.0.11 ddx still support gm20x?
12:04 pmoreau: karolherbst: And using which version of Nouveau?
12:04 imirkin: no ddx supports it. use modesetting.
12:04 pmoreau: Cause right now, I have nothing related to voltage in sensors. Not even N/A
12:04 imirkin: which it should fall back on automatically btw
12:05 pmoreau: imirkin: He was using 3.15 or 3.16 iirc :-)
12:05 karolherbst: imirkin: his X started to start after the nouveau ddx was removed
12:05 karolherbst: he just had some X problems after that
12:05 karolherbst: like xterm not starting automatically
12:05 imirkin: ah ok
12:05 pmoreau: Oh, no, I mixed with someone else
12:06 karolherbst: pmoreau: these patches: https://github.com/karolherbst/nouveau/commits/hwmon
12:06 karolherbst: the last two
12:07 karolherbst: maybe I should switch the order of them :/
12:07 karolherbst: mhhh
12:08 pmoreau: Ok. I need to continue working on some project, but I'll test those before going to sleep.
12:08 karolherbst: okay, thanks
12:08 pmoreau: Just want to progress on some things, and then make sure to save everything before reloading Nouveau
12:09 pmoreau: (though it should work, without any troubles, and I could do it right now, but... computers sometimes...
12:12 karolherbst: okay, so I've updated the branch
12:12 karolherbst: pmoreau: you only need this now: https://github.com/karolherbst/nouveau/commit/a36204c43374d34fde84db2fe2e0ef0a599b1fa2
12:13 karolherbst: pmoreau: though it was more likely that my older version crashed your kernel :D
12:14 pmoreau: :D
12:14 pmoreau: I'm happy I waited before testing it! ;-)
12:14 karolherbst: you already did
12:14 mupuf: ok, serial console time now
12:14 karolherbst: guess why I know you can only read out voltage on one gpu
12:14 mupuf: let's go and dig the serial to usb adapter from the graveyard of electronics
12:15 karolherbst: mupuf: I have some of these number leds if you need some :D
12:15 karolherbst: ohh wait, even a 4x6 dot matrix
12:15 mupuf: that would not be too helpful :p[
12:16 karolherbst: sorry, it is a 5x7 one :D
12:16 karolherbst: and a rgp led!
12:16 karolherbst: *rgb
12:17 karolherbst: I bought a lot of stuff, because I was htinking someday I will play with it....
12:17 karolherbst: even a pressure and a light sensor...
12:21 karlmag: number leds? 7-segments?
12:21 karolherbst: right
12:22 karolherbst: wow, even found some shift registers
12:22 karlmag: hook up a couple to read out the voltage? *ducks*
12:22 karlmag: 595?
12:22 karolherbst: yeah
12:23 karolherbst: 74HC595N
12:23 karlmag: quite standard
12:23 mupuf: so typical :p
12:23 karolherbst: :D
12:23 karolherbst: I even have an ATMEGA328 :p
12:24 karlmag: think I have a tube or two of the 595s :-P
12:25 karlmag: hehe.... no arduino around it?
12:25 karolherbst: mhhh
12:25 karolherbst: right, then I have two
12:25 karolherbst: but the one is without the arduino
12:26 karlmag: *nods*
12:26 karolherbst: ahh there is my arm board
12:26 mupuf:has fancy hw here, sw-defined radios :D
12:26 karlmag: rpi? *ducks*
12:28 karolherbst: MSP430
12:30 karolherbst: I think
12:30 karolherbst: not sure
12:30 mupuf: ah, good stuff!
12:30 mupuf: I have a bunch of those
12:30 karolherbst: :D
12:31 mupuf: I started writing an OS for them, mostly based on macros
12:31 mupuf: so as the generated code would be as small as possible
12:31 karolherbst: I have such a serial to usb adapter by the way:p
12:31 mupuf: function calls are horrible :s
12:31 mupuf: and all the setup does not deserve it
12:31 karolherbst: :D
12:31 mupuf: you could change the clocks on the fly with it :D
12:31 karolherbst: I just were coding my C on that stuff
12:31 karolherbst: yeah
12:31 karolherbst: fun times
12:32 mupuf: yep, a very very simple hw
12:32 mupuf: but veru well designed one!
12:32 mupuf: the cc430 was a tad harder
12:32 mupuf: because of the radio
12:32 mupuf: but gosh is it good
12:32 mupuf: if I had time for this, I would spend hours on it!
12:32 karolherbst: :D
12:33 karolherbst: sadly the board doesn't have that many gpios :/
12:34 karolherbst: I tried to built that into a mp3 player or something
12:34 karolherbst: but it is a lot of work
12:34 hakzsam: imirkin, I'm not sure if the GF110 really supports that 0x91c0 class. Did you see that dmesg fail btw? Instead, I would prefer to make a patch which forces GF110 to use that NVC0_COMPUTE_CLASS in the first time, do you agree?
12:34 imirkin: hakzsam: did you rebuild your kernel/
12:34 hakzsam: sure
12:34 imirkin: hakzsam: kernel has to know about the class
12:35 imirkin: maybe it really is 92c0 then :)
12:35 hakzsam: yes, I know
12:35 hakzsam: but I'm sure I updated my kernel
12:35 hakzsam: I'll try with 92c0
12:36 hakzsam: mupuf, are you using reator?
12:36 mupuf: nope, still need to plug what you asked me to
12:36 mupuf: gf110 + kepler/
12:36 mupuf: ?
12:36 hakzsam: yes
12:36 mupuf: ok
12:37 imirkin: hakzsam: make sure to update your kernel as well
12:37 hakzsam: I'll double check
12:38 mupuf: hakzsam: done
12:38 hakzsam: mupuf, let me known when reator is ready
12:38 hakzsam: very fast :)
12:38 hakzsam: thanks
12:38 mupuf: yeah, it only took me 2h
12:38 mupuf: or let's say 1
12:39 hakzsam: that's good ;)
12:40 karolherbst: a thing I was always wondering about: do all these windows nvidia vbios overclocking hacky tools have any relation to nouveau?
12:46 hakzsam_: mupuf, did you forget to plug the GF110? because I only see the kepler
12:47 mupuf: nope, it's there
12:47 mupuf: let's try again
12:49 hakzsam_: okay
12:50 mupuf: done
12:50 hakzsam_: okay, fixed
12:53 mupuf: well, that is dumb
12:53 mupuf: they indeed have a serial port on the jetson
12:53 mupuf: but ... it is a male connector!
12:54 mupuf: why is it male? The typical one is female!
12:54 mlankhorst: serial port is male..
12:54 mlankhorst: http://www.misco.co.uk/product/173076/StarTech-com-10-ft-DB9-RS232-Serial-Null-Modem-Cable-F-F
12:56 mupuf: so, we are supposed to have a cable to connect to the serial-to-usb adapter?
12:56 mupuf: it looks like you are right though
12:56 mlankhorst: yes
12:56 mupuf: that sucks :D
12:57 mlankhorst: a null modem cable probably to connect it. :P
12:57 mupuf: well, I guess I will have to make one then...
12:57 hakzsam: imirkin, so, what do you think of using 0x90c0 for all Fermi chipsets?
12:57 imirkin: hakzsam: fine by me
12:58 mlankhorst: mupuf: I think I came to the same conclusion a few months ago :)
12:58 mupuf: hehe
12:58 mupuf: I only have one female connector here though
12:58 karolherbst: mupuf: one thing: nouveau tries to set my fan, allthough it doesn't change anything. I doubt that the gpu can control its fan, but there is this fan GPIO
12:59 mupuf: so I will have to improvise with single female-male wirses
12:59 mupuf: karolherbst: if the vbios says it has the fan, how nouveau can know if it is plugged or not?
13:00 karolherbst: can't the gpio tell?
13:01 imirkin: karolherbst: gpio isn't some magic thing. just lets you set voltage high or low :)
13:02 imirkin: (or to read in whether voltage is high or low)
13:03 karolherbst: mhh right
13:06 pmoreau: Ok, time to test those patches
13:06 mupuf: Linux tegra-ubuntu 3.10.24-g6a2d13a #1 SMP PREEMPT Fri Apr 18 15:56:45 PDT 2014 armv7l armv7l armv7l GNU/Linux
13:06 mupuf: here we go
13:07 pmoreau: 3.10 ???
13:07 hakzsam: imirkin, http://pastebin.com/raw.php?i=SYKtBPAV R-b ?
13:09 karolherbst: pmoreau: android kernel I think
13:09 karolherbst: these are kind of "old"
13:09 pmoreau: Wow! It's at least equivalent to a debian ultra-stable
13:10 imirkin: hakzsam: sure
13:10 karolherbst: there is good stuff in the android kernel though
13:10 imirkin: at least that's the new one
13:10 karolherbst: but you don't want to pick that, because that means porting them :D
13:10 imirkin: and not the older 3.4 one
13:10 karolherbst: :D
13:10 karolherbst: right, my phone is still on 3.4
13:10 mupuf: pmoreau: you mean, debian-ultra-dusty?
13:10 pmoreau: mupuf: Ssshhhhhhh! ;)
13:11 imirkin: mine too =/ and as a result won't be getting an android 6 upgrade because they're lazy sob's
13:11 hakzsam: imirkin, thks
13:11 mupuf: they should rename stable into dusty :D
13:11 karolherbst: imirkin: aren't you using cm?
13:11 imirkin: karolherbst: no, but even if i were, that wouldn't change the situation
13:11 karolherbst: mhh right, the cm guys are also kind of lazy :D
13:12 imirkin: karolherbst: it's a ton of vendor drivers that would need porting
13:12 karolherbst: at least your "system" will only take 20% of the space it does with stock rom
13:12 imirkin: meh. seems to fit just fine for now
13:12 hakzsam: imirkin, and what about the patch which fixes the wrong value of NVC8_COMPUTE_CLASS? I know we don't use it anymore but this could prevent some future fails if someone wants to use it and if the value is still 0x92c0..
13:12 karolherbst: :D
13:12 karolherbst: I really hate those stock roms
13:12 karolherbst: fully reminds me on bought windows computer/laptops
13:12 imirkin: hakzsam: we need to determine if the right value is 91c0 or 92c0
13:12 karolherbst: it is just worse on a phone
13:13 imirkin: karolherbst: meh, the nexus 4 stock rom is fine
13:13 karolherbst: ohh right
13:13 imirkin: and my policy is to never touch the onboard storage of arm devices :)
13:13 karolherbst: :D
13:13 karolherbst: why not
13:13 karolherbst: it is a lot of fun
13:13 imirkin: easy to brick
13:13 imirkin: and i need this thing to work
13:13 karolherbst: ohh okay
13:14 hakzsam: imirkin, well, pretty sure it's 0x91c0 but we need to make sure of it before using it
13:15 hakzsam: imirkin, otherwise, the patch which makes use of 90c0 should be mesa-stable, right?
13:16 imirkin: hakzsam: if it'll make you feel better. i don't think anyone enables NVC0_COMPUTE=1 :)
13:17 hakzsam: yeah, except me :p
13:17 imirkin: hence "if it'll make you feel better" :)
13:26 karolherbst: any other stuff you always wanted to have exposed via hwmon? :D
13:26 karolherbst: despite power consumption there is nothinhg which comes into my mind
13:35 pmoreau: Ok, got the patched version running
13:37 pmoreau: karolherbst: I have a power1 for both cards, and a GPU core only on the discrete (G96)
13:37 karolherbst: pmoreau: you used my branch right?
13:37 pmoreau: Yes
13:38 karolherbst: okay, nice, then it seems to work
13:38 karolherbst: the volage changes depending on the pstate I guess?
13:38 pmoreau: Probably, I should test :D
13:40 pmoreau: Reclocking failed O.O
13:40 karolherbst: wut?
13:41 karolherbst: pmoreau: my branch isn't based on upstream master
13:41 pmoreau: Oh!!! You only took the pci patches but not the ones before!
13:41 pmoreau: So you don't have the patch from Roy fixing the reclocking regression
13:41 karolherbst: right
13:42 karolherbst: You could simple use the one commit on top of your stuff :p
13:42 karolherbst: I am still at 4.1 kernel, and I can't really use nouveau master
13:49 karolherbst: pmoreau: okay, but at least the voltage entry doesn't show up for your other card, which means nouveau can't revolt that one
13:51 pmoreau: Oh, the integrated one? Then that means I also need Roy patches on top to reclock the discrete one
13:55 karolherbst: right
14:08 pmoreau: karolherbst: GPU core does change upon reclocking
14:08 pmoreau: :-)
14:09 karolherbst: nice
14:16 pmoreau: Anything more to test?
14:16 karolherbst: mhhh
14:17 karolherbst: pcie doesn't work on your cards, so no :p
14:27 mupuf: gnurou: thanks for your scripts to generate the image for the jetson!
14:28 mupuf: and thnaks for having support for arch!
14:29 mupuf: too bad it takes forever to clone all the repos
14:29 mupuf: and one is particularly slow, ~60kB/s
14:30 mupuf: given the size, I would say it is the linux kernel
14:31 imirkin: mupuf: fwiw he gave me a script to boot a kernel image directly over usb-otg
14:38 pmoreau: The EXT_TAG is also present in the PCIe v1 spec
14:38 pmoreau: Have to check in the PCI spec now
14:39 karolherbst: I should start to clean up my patches
14:39 karolherbst: and make a plan what I want to land when :D
14:40 pmoreau: :D
14:40 mupuf: imirkin: I wish my bios would run in 200ms like the tk1's
14:40 karolherbst: rc4 currently
14:40 karolherbst: mhh
14:40 karolherbst: when is drm merge window?
14:41 mupuf: karolherbst: you missed it
14:41 karolherbst: :O
14:41 karolherbst: for 4.4?
14:41 mupuf: rc5 is released tomorrow, and that is usually when dave airlie pressures ben to release his tree :D
14:41 karolherbst: :D
14:41 karolherbst: so for 4.4
14:41 mupuf: given he was very late for the last pull, I would sayhe will not do it again :D
14:41 karolherbst: mhhh
14:42 mupuf: and especially not for power management stuff :)
14:42 karolherbst: didn't plan anything for 4.4 except the gddr5 patch
14:42 mupuf: just work regardless of the linux cycles
14:42 mupuf: stuff will land whenever it will
14:42 karolherbst: I see
14:42 mupuf: the important part is that everything is in ben's repo
14:43 karolherbst: I still want to have some rough schedule for myself
14:44 mupuf: right
14:44 karolherbst: okay, what have I done anyway all the time :D
14:44 mupuf: gnurou: awake?
14:44 mupuf: it is a bit early for you to change nick ... on a sunday morning!
14:45 karolherbst: stop stalking him :p
14:45 mupuf: can't we stalk friends anymore? :o
14:46 karolherbst: that's exactly the problem, you _think_ he is your friend, that's why it is stalking :p
14:47 mupuf: ah ah
14:47 pmoreau: skeggsb_: I can't seem to find the EXT_TAG in the PCI spec, and according to Wikipedia there are some Tesla that are PCI only.
14:47 mupuf: not the same kind of worrysome behaviour I was pretending to have, but that's also a good one
14:48 pmoreau: skeggsb_: So, probably best to keep the check in the patch.
14:51 mupuf: at this download rate, it won't even be finished by the time I wake up ... let's move on to the power sensors
14:51 karolherbst: mupuf: +1
14:51 karolherbst: :D
14:52 karolherbst: I still need some volunteers for my pcie patches on tesla (g9x+)
14:52 karolherbst: I can somehow test fermi myself, but I also would like other to test on more fermi stuff
14:53 karolherbst: anyway that is the stuff I am working on somehow: https://gist.github.com/karolherbst/14d4b018899017ed9a70 if somebody wants to help with anything just ask :D
14:53 mupuf: karolherbst: you know you can request GPUs for reator, right?
14:53 mupuf: right now, there is a gf110
14:53 karolherbst: mupuf: I did :p
14:53 mupuf: which is quite a beast
14:54 karolherbst: is hakzsam still working on it?
14:54 mupuf: you asked and I did not plug it?
14:54 mupuf: nope, but I am now
14:54 karolherbst: k
14:54 mupuf: reator is for me first :p
14:54 karolherbst: :D
14:54 mupuf: and for every other dev the rest of the time
14:54 karolherbst: mhh I am not quite sure now, it was the time where you were a lot away, so
14:55 mupuf: oh, sure, I couldn't plug anything when I was in canada or france
14:55 mupuf: hehe
14:55 mupuf: reator 2 should have more slots
14:56 karolherbst: :)
14:56 mupuf: that should help with this kind of issues
14:56 mupuf: hey, I have been thinking a little
14:56 mupuf: it will be hard to run benchmarks on the jetson
14:57 mupuf: because X is not supported, only weston/wayland environments
14:57 karolherbst: and?
14:57 mupuf: I could use gnome 3 and xwlayland
14:57 karolherbst: since when do you need a proper DDX for xwayland?
14:57 mupuf: well, it has a perf impact :D
14:57 karolherbst: :D
14:58 mupuf: there is a massive difference between xwayland and native wayland :D
14:58 karolherbst: doesn't the jetson use kms?
14:58 mupuf: at least for xonotic
14:58 mupuf: not by default
14:58 karolherbst: mhhh
14:58 mupuf: they use their own kernel
14:58 karolherbst: maybe glamor and kms are good enough
14:58 karolherbst: ohhh
14:59 karolherbst: wait
14:59 karolherbst: wayland without kms?
14:59 mupuf: dom't worry, I am installing an upstream kernel
14:59 mupuf: the jetson recently got upstream support
14:59 mupuf: there is also the problem of having a driver for rendering and one for doisplay
14:59 mupuf: which makes it fun :p
15:00 mupuf: nouveau is only for rendering on the jetson
15:00 karolherbst: fun
15:00 mupuf: yep
15:01 mupuf: not sure how gnome will cope with this
15:01 karolherbst: it won't :p
15:03 mupuf: hehe
15:04 glennk: cooling shouldn't be much of an issue during finnish wintertime
15:07 karolherbst: mhh
15:07 karolherbst: well I am not living in finnland, but during winter my home is usually warmer than in spring or autumn :/
15:07 imirkin: mupuf: afaik mlankhorst made a good amount of progress with it
15:07 imirkin: mupuf: in theory, modesetting + glamor should work just fine
15:08 imirkin: mupuf: in practice, not sure
15:08 mupuf: imirkin: ack, good to hear
15:08 karolherbst: mupuf: so if you are nice enough, I need a tesla g9x+, maybe two of them
15:08 mupuf: glennk: you would be surprised how they overheat flats here
15:09 mupuf: so, before going to bed, I need to plug that
15:09 mupuf: ok
15:09 karolherbst: thanks
15:09 karolherbst: will do a lot of pcie fun then :D
15:09 glennk: mupuf, well, hang server from window
15:10 mupuf: glennk: hehe, I have a balconny that could serve that purpose
15:10 mupuf: balcony*
15:10 mupuf: speaking about this, I should probably not leave the rc plane on the balcony
15:10 mupuf: it is very cold now
15:11 karolherbst: I would like to merge this: https://github.com/envytools/envytools/pull/21/files because I doubt I will get mroe out of these regs
15:11 karolherbst: and I already use them in my pcie patches
15:12 karolherbst: ohh right, another point for my todo: pcie width changes - very low prio
15:18 mupuf: name of my patch to add power sensors support: 0001-giant-pile-of-shit.patch
15:19 karolherbst: :)
15:19 karolherbst: fair enough
15:20 mupuf: and, of course, I forgot to add the new files inside :D
15:20 karolherbst: :D
15:20 mupuf: well, at least one
15:20 mupuf: anyway, I was pretty-far along
15:20 mupuf: I had forgotten that I had to add support for 16-bits transactions over i2c for this
15:21 mupuf: the ina3221 requires it
15:21 karolherbst: you said something about a pdaemon script or so
15:21 mupuf: this version will be done without pdaemon
15:22 mupuf: whenever we introduce the pdaemon version, the kernel should refrain from polling on its own
15:22 mupuf: otherwise, fun happens
15:22 karolherbst: k
15:23 mupuf: IIRC, there is a way to physically disconnect the host from the i2c lines whenever pdaemon uses the gpios
15:23 karolherbst: :)
15:23 karolherbst: sounds good
15:23 mupuf: I mean, a GPIO port
15:23 mupuf: well, it is not good since the transaction will fail "D
15:24 karolherbst: mupuf: hwmon wants the power consumption in uW (for whatever reasons)
15:24 karolherbst: just that you know
15:34 mupuf: I know
15:34 mupuf: it is a good idea
15:56 karolherbst: mupuf: we could also implement an avarage value through hwmon, I just don't know if that's a good idea when the hardware can't do that
16:00 mupuf: it is not
16:02 karolherbst: mupuf: anyway, will go to bed now, will you push your changes on your freedesktop reporitory or somewhere else? I really would like to test it :D
16:03 mupuf: yes
16:03 mupuf: I will, tomorrow
16:04 karolherbst: okya, thanks :)
16:04 karolherbst: cya
23:33 AndrewR: imirkin, speaking about my mesa bug (GLexcess demo via wine on nv43). Sadly, I recompiled mesa with --enable-debug and got this on stdout: "Mismatched color and zeta formats, ignoring zeta."