01:40 karolherbst: any idea what that might be? https://gist.github.com/karolherbst/a977aad7ff5afb335b8a
01:45 karolherbst: mhh
01:58 karolherbst: mupuf: the kepler you put in reator is kind of resistent :/ it falls of the bus after pcie reclock
01:58 karolherbst: the question is: does it really?
01:58 karolherbst: because nvapeek and stuff are still working
02:41 karolherbst: ohh this kepler card is gddr5 :D
02:41 karolherbst: this might explain my issues
02:44 mupuf: why would it be related?
02:46 karolherbst: because I reclock to 0d pstate
02:46 karolherbst: and then this happens
02:46 karolherbst: even without my pcie patches
02:47 karolherbst: pcie speed change works like a charm on the fermi card though
02:51 karolherbst: mupuf: I still have connection problems though :/
02:53 karolherbst: yay, my patch works on the kepler card :)
02:54 karolherbst: mhhh
02:55 karolherbst: maybe not that well
02:59 karolherbst: mupuf: do you think it is possible to power off the cards on reator without rebooting somehow?
03:02 karolherbst: mupuf: my counter patches are working on both cards, the kepler and the fermi one :)
03:02 karolherbst: if you set a wrong mask, the counter gets the same value as the ticks are getting
03:02 karolherbst: so this is a pretty good indicator :D
03:03 mupuf: karolherbst: I never found any way, no
03:03 karolherbst: nvm, the kepler card recovered after reloading nouveau
03:04 karolherbst: it seems to have a voltage issue
03:04 karolherbst: pstate 0d/0f are working at low cstates
03:04 mupuf: :)
03:04 karolherbst: intense perf though
03:04 karolherbst: glxgears 18506.750 fps
03:05 karolherbst: I need a faster cpu though :p
03:06 mupuf: ehe
03:06 karolherbst: 30st cstate crashed the card with glxspheres64
03:06 karolherbst: *30th :D
03:06 karolherbst: 10th was fine
03:07 karolherbst: anyway, pcie stuff works, core voltage read out works, couters are working on both cards, so I am done with these cards
03:07 karolherbst: I get the famous "gr: TRAP ch 3 [023f9e8000 Xorg[7839]]" error
03:07 karolherbst: and the ROP: gr: ROP0 80000000 80000001
03:07 mupuf: hhehe
03:07 karolherbst: these are always the same on voltage issues
03:08 karolherbst: even across cards
03:08 mupuf: yeah, of course
03:14 karolherbst: mupuf: would it be possible for you to put in some g9x cards, please :)
03:28 mupuf: yes, I can put them now, go to the online shop (yes, a physical shop is called like that in Helsinki) and grab what I need for the jetson
03:28 karolherbst: :D
03:31 karolherbst: they realls use OpenCV on the jetson?
03:31 karolherbst: I thought OpenCV was like dead?
03:32 mupuf: karolherbst: here you go, GT218 and G86
03:33 mupuf: I need to do some stuff before leaving, so tell me if both work and I can plug more
03:33 karolherbst: mhhh
03:33 karolherbst: I wanted a g9x though
03:33 karolherbst: the g8x can't do pcie 2.0 most likely
03:33 karolherbst: I tested some g8x of yours already
03:35 mupuf: oh, sorry
03:35 mupuf: will plug an nv92 then
03:35 mupuf: shut down reator
03:35 mupuf: going to fetch it
03:36 karolherbst: mupuf: do you think replacing gpus can be automated? :D
03:36 mupuf: karolherbst: no
03:37 karolherbst: mhh maybe to big of an effort
03:37 mupuf: yes
03:37 mupuf: so, do you still want the GT218?
03:37 mupuf: I can plug a nv92, 94, 96 or 98
03:37 karolherbst: yeah, it is nice
03:37 mupuf: ack
03:37 karolherbst: I can test the counters thre
03:37 mupuf: will plug a 92 then
03:37 karolherbst: k
03:38 karolherbst: thanks
03:38 mupuf: here you go
03:39 karolherbst: okay, seems okay
03:40 karolherbst: hehe the GT218 is funny
03:40 karolherbst: pcie 2.0 but only 2.5 speed
03:41 karolherbst: I think I will have some fun with both cards
03:42 karolherbst: yay
03:45 karolherbst: I even get the cap speed to 5.0
03:46 karolherbst: okay, lnkSta stays 2.5
04:13 mupuf: karolherbst: about to leave, want me to change the gpus?
04:13 karolherbst: nope
04:14 karolherbst: allthough
04:14 karolherbst: maybe the g92 one
04:14 karolherbst: I am done with that
04:14 karolherbst: yeah one of the other g9x would be nice
04:15 mupuf: ok, doing it niw
04:16 mupuf: I plugged the super-noisy G96
04:16 mupuf: hopefully, you will be done with it before I come back :p
04:17 karolherbst: :D
04:17 karolherbst: the g92 couldn't do any reclock I think :/
04:17 karolherbst: I really hav eto summarize stuff I am doing :D
04:18 mupuf: yes, taking notes in super important
04:19 karolherbst: okay, the gt218 failed to change pcie speed, but I need it for the counters, and g92 failed to change pcie speed, because it only supports 2.5 for whatever reasons
04:20 karolherbst: but my code didn't try something stupid, so I think it is fine for now :)
04:20 karolherbst: ohh wait nvm
04:23 karolherbst: RSpliet: do I need something for g9x reclocking support?
04:26 karolherbst: what super silly vbios :/
04:27 AndrewR: karolherbst, not sure if testing for this hang remotely is a good idea ... https://bugs.freedesktop.org/show_bug.cgi?id=82835
04:27 mupuf: karolherbst: welcome to the tesla family
04:28 mupuf: it was just a giant experiment for PM
04:28 karolherbst: mupuf: the g96 card has 2.5 for each pstate :/
04:28 AndrewR: I had theory this hang might be related to low clocks by default for vp2 ...
04:28 mupuf: karolherbst: well, want the last one then?
04:28 karolherbst: mupuf: doing some counters stuff first
04:28 mupuf: have fu
04:28 mupuf: n
04:29 mupuf: leaving now, hopefully I did not forget anything
04:29 karolherbst: nope, it is fine
04:30 karolherbst: I am stupid
04:30 karolherbst: I write such nice current_load debugfs interface
04:30 karolherbst: and then I still do nvapeeks :D
04:37 RSpliet: karolherbst: nothing in particular, although you might want to disable mem reclocking when playing with PCIe speed
04:37 RSpliet: it could work on GDDR3, I expect it to (when using my tree, Ben hasn't merged yet...)
04:38 RSpliet: but it's irrelevant for your tests I reckon
04:41 karolherbst: yeah
04:42 karolherbst: I have a patch to disable reclocking completly on pstate change
04:45 karolherbst: well
04:47 karolherbst: mhh pm_mode table Version 53 doesn't have pcie speed information?
05:12 karolherbst: mupuf: reator doesn't like me :/
07:02 mupuf: karolherbst: why>]\
07:03 mupuf: I spent way longer than I should have there. They had segways, occulus rifts, samsung vr and pianos :p
07:06 pmoreau: :D
07:17 mupuf: now, let's flash the jetson!
07:44 karolherbst: mupuf: because reboot on the blob partition gives me the blob partition
07:46 karolherbst: mupuf: anyway, I have to check some traces of g9x gpus and their vbios
07:46 karolherbst: so I won't need the reator until I figure that out
09:43 karolherbst: pmoreau: MacBook Air 4,2 is supported by coreboot, isn't that somehow close to your macbook?
09:44 pmoreau: Well, it also starts with MacBook, but... :D
09:44 pmoreau: I doubt it has the same GPUs inside
09:44 pmoreau: Could it only has an Intel one
09:45 karolherbst: yeah but still, motherboard support is more important for coreboot
09:45 karolherbst: all the other bits can be hacked in more easily
09:46 pmoreau: Maybe. I never looked at coreboot
09:47 karolherbst: sounds interessting
09:47 karolherbst: basically the idea is to do nothing in the bios and let the kernel initialize the hardware
09:47 karolherbst: and if something has to be initialized in the bios, let the kernel take over the state
09:48 pmoreau: Hum
09:48 karolherbst: it seems to be really fast
09:49 karolherbst: but well, not much is supported
09:49 pmoreau: If I had some time, I could give it a try. :/
09:56 karolherbst: I don't get it
09:57 karolherbst: why would be blob set a counter, which won't work
10:01 mupuf: this is becoming annoying
10:02 mupuf: still trying to get my jetson to boot
10:02 karolherbst: do you know what is wrong? :D
10:03 mupuf: yes, uboot does not want to detect that I have a valid kernel some place
10:03 karolherbst: uhhh
10:04 karolherbst: uboot
10:05 mupuf: took me a while to find out that the build script for the kernel failed
10:05 mupuf: YEAHHH!!!
10:05 mupuf: finally!
10:06 karolherbst: :D
10:07 karolherbst: ups, I somehow managed to did a "nvapoke 0x0 0x10a53c 0x0"
10:10 mlankhorst: has anyone tried to take their tegra outside?
10:10 karolherbst: I stopped tinkering with boot entries for a long time
10:10 karolherbst: better not touch these devilish parts
10:13 karolherbst: mupuf: did you notice something odd with the memory counter on the gt215+ cards?
10:14 pirea: hi
10:14 karolherbst: mupuf: neither 0x80 nor 0x100 bits are working
10:14 pirea: i have nvidia gt 840m and my graphic card still not working with kernel 4.2.2
10:14 karolherbst: pirea: what do you exactly mean by not working
10:15 mupuf: karolherbst: yes
10:15 mupuf: you need to enable the PFB mux for that
10:15 karolherbst: mupuf: where?
10:15 pirea: karolherbst http://pastebin.com/YfN0Wgyr
10:15 pirea: look
10:16 mupuf: karolherbst: nvapoke 110160 10
10:16 mupuf: that should do the trick
10:16 karolherbst: pirea: are you sure you have the 4.2.2 kernel?
10:16 mupuf:had to look for the right script :D
10:16 pirea: sure Linux e15 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux
10:17 karolherbst: mupuf: still it doesn't work
10:18 pirea: with kernel 4.1 i should add "case 0x118:" in g107m.c (something like that) and everything was right
10:18 mupuf: karolherbst: hmm
10:18 pirea: but file structure has changed
10:18 mupuf: can I reset the counters?
10:18 karolherbst: mupuf: what do you mean by "reset"?
10:18 karolherbst: I mean, the counter gets reset alright
10:19 karolherbst: but the value is always higher than the ticks
10:19 mupuf: /media/sda1/root/pdaemon_fb_counters.sh
10:19 mupuf: I guess you do not see any memory traffic most of the time because ... there is no screen plugged
10:20 karolherbst: well I see too much
10:20 karolherbst: :p
10:20 mupuf: run my script
10:20 karolherbst: the pmu does most of the stuff already
10:20 karolherbst: like reset and so on
10:20 karolherbst: only the 0x4 reg needs to be adjusted
10:20 mupuf: ack
10:20 karolherbst: yeah, 0x80 and 0x100 are odd
10:21 karolherbst: as you see :p
10:21 karolherbst: but the prop driver uses 0x100
10:21 mupuf: can I let you have a deeper look? I am in the middle of submitting some changes to the documentation of the jetson to get nouveau working on archlinux
10:22 karolherbst: pirea: drivers/gpu/drm/nouveau/nvkm/engine/device/gm100.c
10:22 karolherbst: wow, there is really no case 0x118
10:23 karolherbst: and in upstream it is also missing?
10:23 pirea: karolherbst: i told you :)
10:23 karolherbst: strange
10:23 karolherbst: you may want to create a bug for that
10:23 karolherbst: should be easily fixable
10:24 karolherbst: with 4.3 stuff gets different again :D
10:25 karolherbst: mupuf: do you know if there is something special about the GR counter?
10:25 karolherbst: or do I have to select all these GR_X counters too?
10:26 pirea: karolherbst look http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/device
10:26 pirea: there is no gm100.c
10:26 pirea: anyway is about gm107.c
10:29 karolherbst: this is for 4.3 already
10:30 mupuf: karolherbst: not sure what you mean by special
10:30 karolherbst: mupuf: like does GR select all GR_* counters
10:30 mupuf: btw, when you have a second, can we please shut down reator to get rid of this g96?
10:30 karolherbst: yes
10:30 mupuf: still not making sense
10:31 karolherbst: do I have to select all GR* counters ?
10:31 karolherbst: or is GR enough
10:31 mupuf: done, you can reboot
10:31 mupuf: ok, I clearly do not remember something
10:32 pirea: karolherbst now is about http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c where after line 2458 should be case 0x118
10:32 karolherbst: mupuf: I mean these https://github.com/envytools/envytools/blob/master/rnndb/pm/pdaemon.xml#L112-L115
10:32 mupuf: I see
10:32 karolherbst: pirea: you need to copy the nv117_chipset struct
10:32 mupuf: GR should be enough
10:32 karolherbst: mupuf: okay
10:32 mupuf: but check what the blob does
10:32 karolherbst: pirea: but this is 4.3
10:32 mupuf: I plugged a g94 btw
10:32 karolherbst: mupuf: it does select the others as well
10:33 mupuf: on the nva8? :o
10:33 karolherbst: at least sometimes
10:33 karolherbst: gt215: 0: { GR | GR_GPC | GR_ROP }
10:33 karolherbst: and this works
10:33 karolherbst: only GR_HUB is wrong
10:34 karolherbst: on kepler/fermi it selects { GR | PCOPY0 | PCOPY1 | PCOPY2 }
10:34 karolherbst: on maxweel it uses { GR | GR_HUB | GR_GPC | GR_ROP } and { GR | PCOPY0 | PCOPY2 }
10:35 karolherbst: pirea: and add an entry like case 0x117: device->chip = &nv117_chipset; break;
10:35 karolherbst: just rename all the stuff
10:35 pirea: i will do that, but when will be fixed in mainline? :)
10:35 karolherbst: you can write a patch for that :D
10:36 karolherbst: it is no magic and we can improve stuff later anyway
10:36 karolherbst: and ask skeggsb_ :p
10:36 karolherbst: maybe there is a good reason why there is no nv118
10:38 karolherbst: mupuf: it is odd, I don't know why the counter doesn't work on the nva8
10:38 karolherbst: I can't imagine that the blob uses a wrong counter
10:38 karolherbst: maybe they didn't care about memory usage back then
10:39 karolherbst: or it is just broken
10:41 mupuf: that's a new GPU
10:41 mupuf: no-one tested it, probably
10:41 mupuf: karolherbst: it is possible we need to enable another mux on tesla GPUs
10:41 mupuf: I honestly did not work too much on those
10:42 karolherbst: I never had to enable any mux on other gpus
10:42 mupuf: https://github.com/NVIDIA/tegra-nouveau-rootfs/pull/13 <-- done, let's try that mighty board now!
10:42 mupuf: well, this is tesla
10:42 karolherbst: right
10:43 karolherbst: this gt218 card is just sad in many ways :D
10:44 karolherbst: mhhhhh okay
10:45 karolherbst: my pci patches are somehow useless on g9x cards
10:45 karolherbst: well
10:45 karolherbst: the pcie version is changed to v2 alright
10:45 karolherbst: but
10:45 karolherbst: mhhh
10:47 karolherbst: mupuf: what should nouveau do, when there is no pcie speed in the pstates?
10:47 mupuf: nothing
10:47 mupuf: yeah, KMS is working
10:48 karolherbst: mupuf: well the cards support higher speeds :/
10:48 karolherbst: or maybe it is just a total mess on pre gt215 cards
10:49 karolherbst: I want to check the blob
10:50 karolherbst: I bet there might be a pcie speed part in the table
10:51 mupuf: what would it contain?
10:51 karolherbst: maybe either 0 or 1?
10:52 mupuf: to say if you can use it or not?
10:53 karolherbst: the traces seem to indicate, that the blob does change the pcie speed on g9x cards
10:53 karolherbst: but I don't know when it does it
10:55 mupuf: gnurou: I got the spining shaded cube, I guess I am all set!
11:00 karolherbst: I really find nothing :/
11:01 karolherbst: ohh wait
11:02 karolherbst: mupuf: I know that might sound stupid, but start+25 seems to contain something usable
11:02 karolherbst: 0 on low pstates, 2 on high
11:02 mupuf: that does not sound stupid at all
11:03 mupuf: but one needs to check!
11:03 mupuf: use nvafakebios to check if when you set 0, the blob uses a low pcie speed
11:03 karolherbst: will first check all the other vbios
11:03 mupuf: nvafakebios -e ADDR:value vbios.rom
11:04 karolherbst: sometimes the value stays 0 on high pstates
11:04 mupuf: maybe because they do not support it?
11:04 karolherbst: yeah may be
11:04 karolherbst: or they only support one
11:05 karolherbst: will have to check how common that is
11:05 karolherbst: mhhh
11:05 karolherbst: found some vbios with 4 on low and 0 on high
11:06 karolherbst: maybe it is a bit though
11:06 karolherbst: also found 4/6/2 combinations
11:06 karolherbst: which means 0x2 not set on 0x3 and 0x7, but set on 0x7 and 0xf
11:07 karolherbst: but not that many vbios have that
11:07 karolherbst: maybe 15%
11:07 karolherbst: okay, test it out
11:07 karolherbst: mupuf: how do I install an older blob? :D
11:08 mupuf: pacman -S nvidia-304
11:08 mupuf: or something like that
11:08 karolherbst: k
11:08 mupuf: yo uwill have to update the libgl too
11:14 karolherbst: mupuf: it is -304xx
11:14 mupuf: I was close-enough :D
11:17 karolherbst: mhh
11:17 karolherbst: the blob pushes your card straight to 5.0
11:17 karolherbst: and doesn't seem to drop it
11:17 karolherbst: mhhh
11:17 karolherbst: maybe I should try a card with multiple pstates
11:18 pmoreau: You could use -340xx, that's the last one supporting Tesla
11:19 pmoreau: Except if you want to test even older cards... :D
11:19 mupuf: oh, 304 was for geforce 7, oops
11:19 pmoreau: ;-)
11:19 karolherbst: yeah doesn't really matter though
11:20 karolherbst: the g94 only has one pstate
11:20 karolherbst: so
11:20 karolherbst: maybe the blob stays at max speed then
11:20 karolherbst: would be also fun to try out
11:33 karolherbst: mupuf: which high end g9x cards do you have?
11:34 mupuf: 9800 GTX is as high-end as it gets
11:34 karolherbst: vbios in the repo?
11:35 karolherbst: but I guess it will have multiple pstates
11:35 karolherbst: so this one would be fine
11:35 karolherbst: would you like to put it in reator? :)
11:35 mupuf: sure
11:35 mupuf: it was the first one you had
11:35 mupuf: the nv92
11:36 mupuf: it really is a beast
11:36 mupuf: it almost does not fit in my case
11:36 karolherbst: :D
11:37 karolherbst: and I thought today GPUs are like beasts
11:37 mupuf: http://hothardware.com/reviews/asus-en9800gtx-top-graphics-card
11:37 karolherbst: :D
11:37 mupuf: ASUS EN9800GTX --> that's the one I have
11:37 imirkin: those G92's were pretty massive
11:37 imirkin: G94's could be big too right
11:37 mupuf: the g94 I have is pretty standard :)
11:38 mupuf: it takes two slots though
11:38 karolherbst: all those OC cards :D
11:40 karolherbst: .....
11:40 karolherbst: I don't believe
11:40 karolherbst: it
11:40 karolherbst: mupuf: this card has 3 disabled pstates :/
11:41 mupuf: ah ah
11:41 karolherbst: do these cards run always at full power or what :D
11:41 mupuf: yeah, I do not think I have a ton of reclockable gpus
11:41 imirkin: skeggsb_: btw, feel free to dump my patch and take laurent's if you like his better
11:41 mupuf: nva0 is one though
11:41 karolherbst: mhhh
11:41 karolherbst: does nva0 uses the 0x35 pm_mode table version?
11:41 imirkin: karolherbst: mostly laptops had multiple levels in the g8x/g9x timeframe
11:42 mupuf: karolherbst: check it out in the vbios repo
11:42 imirkin: karolherbst: i do have a G98 with 2 (drastically different) levels
11:42 karolherbst: imirkin: yeah, I am slightly aware of that :/
11:42 mupuf: I do have a nv86 laptop
11:42 mupuf: but it does not fit your needs
11:43 karolherbst: mupuf: nice, your vbios in the repo has 3 perf levels
11:43 karolherbst: the nva0 one
11:43 mupuf: do you want it now?
11:43 karolherbst: it has this bit set to 0 though
11:43 karolherbst: yeah, let's try that one out
11:54 mupuf: my god, the integrated memory is SLOOOOOWWWW
11:54 karolherbst: :D
11:54 karolherbst: where
11:55 mupuf: I wonder if the SD card I bought today is faster!
11:55 mupuf: compiling nouveau takes 50s on the jetson, so the cpu are plenty fast
11:55 karolherbst: mupuf: is it a UHS-II one?
11:55 karolherbst: :p
11:56 mupuf: but trying to compile nouveau.ko, make takes at least 2 minutes before even trying to compile ANYTHING
11:56 karolherbst: :D
11:56 mupuf: by at least, I mean it still is running!
11:56 mupuf: UHS-I, 16 GB, 600x
11:56 karolherbst: these UC3 cards are pretty expensive though
11:57 karolherbst: mhh
11:57 karolherbst: UHS-1 is like 10MB/s
11:57 karolherbst: writing though
11:57 mupuf: it was faster, even through the usb
11:57 karolherbst: reading is always faster
11:57 karolherbst: and UHS-1 just states 10MB/s minimum
11:57 mupuf: it is rated for 25 MB/s
11:57 karolherbst: k
11:57 karolherbst: U3 is 30 MB/s min ;)
11:58 karolherbst: but 25 is nice
11:58 mupuf: wth, the jetson rebooted :D
11:58 karolherbst: :D
11:58 karolherbst: overheat! :D
12:03 mupuf: karolherbst: sorry, forgot to plug the a0
12:03 mupuf: here it is
12:03 mupuf: tell me when you are done, hakzsam wants access too :)
12:04 hakzsam_: mupuf, tomorrow will be good for now, have fun tonight
12:04 hakzsam_: *for me
12:04 mupuf: hakzsam_: ack
12:04 hakzsam_: mupuf, but don't forget to plug them before going to sleep, please :)
12:04 mupuf: mwk: do you mind if I try adding support for the jetson in envytools?
12:05 mupuf: karolherbst: please remind me to when you are done!
12:05 imirkin: mupuf: "adding support"?
12:05 mupuf: imirkin: nva
12:06 imirkin: mupuf: oh ok
12:06 mupuf: I wonder how I can do it though :p
12:06 mupuf: need to check the kernel source code
12:07 imirkin: mupuf: yeah... no BAR to map :)
12:07 mupuf: maybe it is just a fixed address
12:08 mupuf: and I just need to map it through /dev/mem
12:08 imirkin: robclark: --^
12:08 imirkin: any idea how to deal with that stuff? how does freedreno do it (if at all)
12:11 robclark: you can use devmem2 (basically nice wrapper around /dev/mem) to poke things from userspace.. or from kernel just ioremap.. no BAR to deal w/
12:11 robclark: for adreno there isn't much direct register writing going on other than to kick cmdstream and a bit of initial setup (although I can ioremap register space and dump things out, for example hangdebug..)
12:14 imirkin: robclark: and the address you get from DT?
12:15 mupuf: nouveau gets it from platform_get_resource
12:15 imirkin: or some other external thing... there's no concept of a "device"?
12:15 imirkin: oh, i wonder if it ends up in /proc/device-tree somewhere
12:15 mupuf: gnurou's patch talks about the platform bus
12:16 mupuf: let's hope it is exposed to the userspace!
12:16 imirkin: mupuf: well, it's def in /sys/class/bus
12:16 imirkin: er, make that /sys/bus/platform
12:16 robclark: imirkin, yeah.. devmem2 (/dev/mem) uses phys addresses..
12:17 imirkin: how do you know what address to use?
12:17 robclark: mupuf, platform_get_resource will come from dt, fwiw..
12:17 mupuf: robclark: ack, thanks!
12:17 robclark: np
12:18 robclark: fwiw, most of these built-in things on arm are platform_device's.. basically the its-not-a-bus bus..
12:18 mupuf: hardcoded phy addresses in the design?
12:19 mupuf: and exposed to the kernel through the dt?
12:19 robclark: yup
12:20 mupuf: hmm, this is annoying, I do not see the physical addresses in /proc/device-tree/gpu\@0\,57000000/
12:20 mupuf: /sys/bus/platform/devices/57000000.gpu/ does not seem to contain any interesting information either
12:20 robclark: 0x57000000 is prob the address ;-)
12:20 mupuf: hmm, why didn't I think of this :D
12:20 robclark: (well, that's the convention about how to name things anyways)
12:21 mupuf: ack, thanks!
12:21 robclark: np
12:21 robclark: sometimes devices might have multiple io spaces..
12:21 mupuf: let's have a look at devmem2
12:21 robclark: anyways, in DT it will be the regs and regnames properties..
12:22 mupuf: I see, it does what nva.c should do
12:22 mupuf: catting the file did not yield any result
12:22 mupuf: hmm, only reg exists
12:22 mupuf: and it returns WX
12:31 mupuf: btw, forgot to tell you were right robclark: Value at address 0x57000000 (0xb6f5c000): 0xEA000A1
12:32 mupuf: the jetson has a gk20a, codename nvea :)
12:38 robclark: ahh, working version registers even :-)
12:38 mupuf: yep :D
12:38 robclark: I think adreno has one too.. that seems to read back 0x00000000 on most devices :-P
12:45 mupuf: ah ah
12:51 mwk: mupuf: jetson?
12:51 mwk: not that I mind either way...
12:51 mupuf: jetson tk1
12:51 mupuf: tegra k1
12:51 mwk: that's GK20A, right?
12:51 mupuf: yes
12:52 mupuf: 0: ??? 0ea000a1 --> I'm getting there :)
12:52 mwk: sounds great, go ahead :)
12:54 mupuf: 0: GK20A 0ea000a1 --> Now I just need to de-hard-code the address and actually read it from /sys/bus/platform/devices/XXXXXXXX.gpu/
12:55 mupuf: mwk: what is the normal size of bar0? 0xffffff ?
12:56 mupuf: oh, and if you want to have fun with the jetson, it is connected to wtrpm :)
13:37 mupuf: robclark: is it ok if I check the modalias to check that the device actually is from nvidia?
13:38 robclark: mupuf, not sure I understand what you are trying to do?
13:38 mupuf: cat /sys/bus/platform/devices/57000000.gpu/modalias
13:38 mupuf: of:NgpuT<NULL>Cnvidia,gk20a
13:39 mupuf: i want to make sure that I am not listing a gpu that has not been produced by nvidia
13:39 robclark:wonders what other gpu's might be on a jetson board?
13:39 mupuf: right now, the only thing I look for is %x.gpu in /sys/bus/platform/devices/
13:39 robclark: oh..
13:40 mupuf: oh, I just don't want nvalist to return anything when running on... say a rasp pi
13:40 robclark: I think for platform devices we just get drmVersion..
13:41 mupuf: there is no way of getting who made the board?
13:41 mupuf: I really would like a vendor id somewhere :D
13:41 robclark: mupuf, if compatible string exposed by sysfs somewhere?
13:41 mupuf: well, I was thinking about using the modalias
13:41 mupuf: since it exposes "nvidia,gk20a"
13:42 robclark: I guess nvidia,gk20a is the compatible string in dt..
13:42 mupuf: that sounds good, given that it is found after a capital C :D
13:42 robclark: although not sure if it is guaranteed that modalias is "abi"..
13:42 mupuf: right, I was coming at it
13:43 mupuf: well, let's try
13:43 mupuf: envytools is not a user-facing tool anyway
13:44 robclark: mupuf, might not hurt to check w/ tagr to see if he knows whether modalias is treated as "abi" (ie. that format might not change in future kernel)..
13:44 robclark: since I'm not really sure about that..
13:44 robclark: the 'compatible' string in DT is treated as abi.. but not sure if it is exposed in a reliable way to userspace..
13:44 mupuf: gnurou ^^
13:44 mupuf: ack
13:45 mupuf: well, I guess I will just check if the string contains nvidia, that should take care of all the cases
13:45 mupuf: and who would install envytools on a non-nvidia SoC anyway :D?
13:45 robclark: yeah, I guess that should be reliable enough..
13:45 robclark: and I guess anyone using envytools would probably be able to figure out if it changed in the future
13:46 mupuf: and it won't be perfect anyway since it will work only on the upstream DT or a "compatible" one
13:46 mupuf: yep
13:46 robclark: (yeah, that is a whole different headache.. but hopefully downstream android kernels also have 'nvidia' in the compat name..)
13:46 mupuf: compatible == follows the address.cpu format
13:47 mupuf: well, I guess I could flash again the L4T
13:47 mupuf: and see if it works there
13:47 mupuf: but hey, that may be someone else's job :D
14:17 mupuf: karolherbst: still on reator?
14:26 karolherbst: mupuf: nope
14:27 mupuf: ack, I will plug the cards for hakzsam_ then
14:27 karolherbst: yeah
14:27 mupuf: hakzsam_: what did you want again?
14:27 mupuf: kepler and gf110?
14:30 karolherbst: mupuf: okay, the bit is totally unrelated anyway
14:30 karolherbst: there is something else the blob does
14:30 mupuf: :) More work, yeeeeeppeeeee :D
14:30 karolherbst: I don't know
14:31 karolherbst: but maybe the blob just says: 2.5 on lowest pstate, 5.0 on highest
14:31 karolherbst: how can I tell to which pstate the blob clocks in the trace?
14:32 karolherbst: I found a trace for a nv92 card with 4 pstates
14:32 karolherbst: and the blob changes the pcie speed bidirectional
14:36 mupuf: karolherbst: you would need to decode the clock tree to know for sure
14:36 mupuf: that sucks, right?
14:36 karolherbst: a little
14:36 karolherbst: I managed on kepler, but it took a little bit of time :D
14:37 karolherbst: uhh hwsq scripts
14:42 karolherbst: I got to bed, todays results are kind of sad :(
14:47 hakzsam_: mupuf, yeah
14:48 mupuf: hakzsam_: they are plugged
14:48 mupuf: if you want to check
14:48 hakzsam_: I'll
14:48 mupuf: don't check when I am away from the computer :p
14:49 hakzsam_: sure
14:52 hakzsam_: mupuf, it's the blob partition by default, still that grub issue?
14:53 hakzsam_: could you please just restore the nouveau partition instead?
14:53 mupuf: karol screwed up
14:53 hakzsam_: cards are okay
14:53 mupuf: there is a script in /root that resets
14:53 hakzsam_: ah right
14:54 mupuf: /root/reset_grub.sg
14:54 hakzsam_: done
14:54 hakzsam_: rebooting
14:54 hakzsam_: mupuf, looks fine now, thanks
14:57 mupuf: np
14:57 mupuf: my patch for nva also looks kind of OK
15:14 mupuf: tagr: hey, when you have time, could you please give me the value of the register 0 of all the tegras before the k1? I would like to add support for them in envytools
15:22 skeggsb_: mupuf: i have no idea if the non-"geforce" tegras even have a PMC_BOOT_0
15:22 mupuf: skeggsb_: I thought they were based on the geforce 7
15:22 mupuf: but maybe they did not use this part
15:23 imirkin: the shaders are based on geforcefx... that may be about it.
15:23 mupuf: ack
15:26 skeggsb_: i haven't looked in great detail, but i got the impression they're an entirely different beast
15:27 skeggsb_: imirkin: re the of patch, what'd be your preference?
15:27 mupuf: :)
15:27 skeggsb_: i'm happy to go either way
15:27 imirkin: skeggsb_: no real preference. i just want the damn thing to work. whatever you think is cleaner.
15:27 imirkin: skeggsb_: not a huge fan of the new "type" thing, and dunno if hardcoding NV30 as ignoring checksum is the right thing to do there
15:28 mupuf: well, in any case, I'm glad I got the jetson hooked up to wtrpm and then managed to boot an upstream kernel on it :)
15:28 imirkin: skeggsb_: at the same time, my of_size thing is a bit of a hack, but IMHO it's a bit cleaner
15:28 skeggsb_: yeah, your patch seems somewhat more explicit
15:28 imirkin: skeggsb_: or you can take the two patches and combine them.... and in the darkness bind them
15:28 skeggsb_:heads to mordor
15:28 imirkin: :)
15:29 mupuf: skeggsb_: is that how you call work?
15:29 mupuf: or the gym?
15:29 skeggsb_: mupuf: i still need to do that, i'd like to *attempt* to get the lib build of nvkm working on gk20a too for testing
15:30 skeggsb_: mupuf: haha, neither, perhaps my mother's house ;)
15:30 mupuf: well, if you don;t mind the latency, my jetson can be yours when you need it
15:31 skeggsb_: i've got one, but it seems like so much more work than x86 to get the damn thing up and running
15:31 mupuf: yes
15:31 mupuf: I did not have too many troubles following the guide from gnurou
15:31 skeggsb_: i've been abusing gnurou to test stuff on gk20a for me when it needs it :P
15:31 imirkin: skeggsb_: i can give you a gentoo chroot if you like
15:31 mupuf: here it is: https://github.com/mupuf/tegra-nouveau-rootfs
15:32 mupuf:fixed the archlinux case
15:33 mupuf: skeggsb_: don't forget the userspace of nvif though :p
15:34 imirkin: skeggsb_: my way boots over usb-otg and runs off nfsroot -- i find that to be a lot more manageable than their recommended way
15:34 skeggsb_: imirkin: that does sound somewhat more convenient
15:35 mupuf: In my case, I use it like an ARM-based pc
15:35 skeggsb_: mupuf: i haven't forgotten :)
15:35 mupuf: it compiles pretty fast, for an arm board!
15:35 mupuf: but the IOs are super slow
15:37 mupuf: will need to check if my sd card is faster
15:38 imirkin: i find my desktop's a lot faster ;)
15:39 mupuf: yep, but there is no way I give access to anyone to my main pc :D
15:40 mupuf: and using reator would be pretty dumb since someone else may want to use it at the same time
15:41 imirkin: yea
15:41 imirkin: for your use-case that makes sense
15:41 imirkin: you could attach a real disk to it over sata though
15:43 mupuf: yes
15:43 mupuf: at some point, I will need a case for this board :D
15:44 imirkin: hopefully it's some semi-standard size...
15:44 imirkin: might be mini-itx
15:44 mupuf: there are ton of cables going in and out (serial console, ethernet, wtrpm hw, )
15:44 mupuf: hdmi, soon some usb hub for the keyboard/mouse
15:45 imirkin: yeah, my arm boards are held together by cables
15:45 imirkin: the cables are a lot heavier than the boards themselves :)
15:45 mupuf: yep, especially the hdmi cable
15:45 mupuf: which I bought 5m of so as I could connect it to my main pc and play movies on the screen that is closer to what could be considered a TV (in front of the sofa)
15:50 mupuf: may the discussion begin
16:00 karlmag: heh... I connected a hdmi<->dvi cable (fairly rigid one) between rpi and a monitor today.. The cable kept pulling and tossing the rpi around, so I can fully relate to that story :-P
16:02 mupuf: mwk, skeggsb_, imirkin, hakzsam_, pmoreau, mlankhorst: the jetson is accessible using the same technique as for reator, except the port is 2223
16:03 pmoreau: Cool! :-)
16:03 mupuf: make sure to "force off" the power switch to really turn off the board. Same for reator, for some reason. I need to investigate for reator
16:04 mupuf: more fun to be had next week end!
16:05 imirkin: mupuf: thanks
20:12 skeggsb_: imirkin: btw, i've been running mesa 11.0.3 (with your fixes) since yesterday and have yet to witness the chrome issues that i'd been seeing
20:12 skeggsb_: it'd *usually* have happened in that time, but i'm not ready to think it's fixed yet :)
20:13 imirkin: skeggsb_: well, at least a positive sign
20:13 imirkin: or perhaps non-negative :)
20:13 skeggsb_: i'm feeling optimistic :)
20:13 imirkin: there are some additional fixes i just pushed, will hopefully be in 11.0.4 regarding fence screwups
20:14 imirkin: those situations should be *exceedingly* rare and would manifest as crashes in opt builds
21:53 gnurou: mupuf: playing with Jetson and the tegra-nouveau-rootfs? Nice!
21:54 gnurou: mupuf: I need to update it with Christian Gmeiner's latest Mesa patches, this will allow us to use more packaged software
21:54 gnurou: also need to make Arch Linux the default
22:22 imirkin: gnurou: is there any eta on getting secure fw loading on gm20x?
22:26 tagr: mupuf: it's quite likely that the I/O itself isn't your problem, the SDHCI driver that we have sucks big time
22:26 tagr: so even if you have a super expensive SD card, it won't do you any good
22:26 tagr: SATA is known to work much better
22:28 tagr: they're not as cheap as SD cards, but if you're planning on doing a lot of building on the Jetson TK1 itself might definitely be worth a try
22:28 tagr: (I can't speak much from first-hand experience because I never build on the target itself)
22:29 tagr: mupuf: also, per-TK1 doesn't have the version register, it's a completely different GPU
22:29 tagr: as for determining the physical address I suggest looking at the device tree
22:31 tagr: on recent kernels you can look at /sys/firmware/devicetree/base, which is a sysfs representation of the device tree (similar to what /proc used to have)
22:31 tagr: note that all the files are binary, so cat isn't going to be much help
22:33 tagr: to keep things simple it's probably enough to just look at the top-level compatible file and see what the last string in the string list is (it's a NUL-separated list of strings)
22:33 tagr: if it matches nvidia,tegra124 you know that the GPU must be at physical address 0x57000000
22:35 tagr: gnurou: have you tested the renderonly patches? do they have the same issue running wayland clients?
22:36 mlankhorst: mupuf: mine will actually do stuff soon >:D
22:36 gnurou: imirkin: nope, the next stage is not under my control unfortunately... we are active on it though
22:37 mlankhorst: power control + multicast webcam
22:37 gnurou: tagr: not yet, I won't have access to a board until tomorrow (public holiday here)
22:37 tagr: tsktsktsk
22:38 imirkin: gnurou: when you are able to release it, do you know if getting mesa working on it will be on the menu?
22:38 tagr: anyway, I've had a brief look at the renderonly driver and I see a couple of problems with it; I don't think it's going to work well for Tegra
22:39 gnurou: imirkin: from what I know it is kind of working already (well, excepted textures)... our plans regarding user-space are still the same, don't mess with it as much as possible
22:39 gnurou: imirkin: we will release kernel code to load the secured firmwares though
22:40 imirkin: gnurou: there are a lot of issues on maxwell afaik
22:40 imirkin: gnurou: although tbh i don't know first-hand
22:41 imirkin: gnurou: i'm avoiding maxwell altogether until gm20x becomes a thing with nouveau... got enough problems on my hands :)
22:41 gnurou: imirkin: sounds wise :)