01:06 imirkin: drbombay: you're on a ppc right?
01:16 hno: morning. At what times is tobijk usually here? Or anyone else around that want to help with trying to understand the source of my K2100M stability problems?
01:19 imirkin: hno: he's in GMT+2
01:53 CMEPTb: no sure if there needs to be some formal bug submitted/my observation.. using vdpau in smplayer, with nvidia-firmware installed, gives visible distortions in various parts of ffh256 video, broken squres in spots.. using the xv (0 nouveau nvidia geforce 8/9 textured video) plays fast, and doesn't peg my cpu to above 2.5ghz, staying mostly around 1.7-9
01:53 imirkin: CMEPTb: presumably ffh264vdpau?
01:54 CMEPTb: in file info, the video codec reported by smplayer is ffh264 ...
01:54 CMEPTb: not vdpau.
01:54 imirkin: CMEPTb: it's a known issue that h264 occasionally shows artifacts, and, unfortunately, for unknown reasons.
01:54 CMEPTb: aaaaaah.
01:54 imirkin: hmmm... not vdpau is odd
01:55 imirkin: with vdpau it's expected, but without vdpau it should display perfectly
01:55 CMEPTb: yea just ffh264, but hwne i use vdpau output i get artifacts..
01:55 CMEPTb: i noticed that before rarely in some other files, just thought they were damaged or bad encoding etc
01:56 CMEPTb: retrying now, and not using vdpau works *better*?
01:56 CMEPTb: i'm confused as far as all these dozens of codec options are i guess. just want heavy lifting done in hw :)
01:57 imirkin: CMEPTb: then you want vdpau... see the wiki for how to get that going
01:58 imirkin: (searching for "nouveau vdpau" in your favourite search engine should find it)
01:58 CMEPTb: err but with vdpau i get artifacts. when i chose another video output i don't... are you saying that xv (0 nouveau nvidia geforce 8/9 textured video) is software?
01:59 imirkin: well, eventually you have to go to hardware if you want to display anything
01:59 imirkin: with xv (and also vdpau, if you use ffh264 and not ffh264vdpau), the decoding happens in software, but the YUV -> RGB happens in hardware
01:59 CMEPTb: heh. i meant the gpu... offload everything that's possible so cpu doesn't have to do that work.
02:03 CMEPTb: imirkin, ohhh the file info in smplayer shows ffh264, when you select vdpau as video output. I thought that was reflective of the type of file this is. derp
02:04 CMEPTb: ffh264vdpau*
02:04 imirkin: well, it sort of is. that wouldn't work so hot on, say, a vc1 file :)
02:04 RSpliet: imirkin: are you aware of problems with h264 decode of video's that show very little movement (like zooming in on a photograph, or slowly moving through a nature scene) on NVAC?
02:04 CMEPTb: yea so artifacts is a known issue huh. and w/o having the nvidia-firmware dark blob, i can't use vdpau hw accel
02:04 imirkin: RSpliet: i'm aware of problems with h264 across all generations
02:05 RSpliet: ok :-)
02:05 imirkin: RSpliet: my observation in the past has been that it's actually very fast-moving scenes, but zooming in and out is a lot of very fast motion
02:05 imirkin: (if you think about it in mpeg terms)
02:05 RSpliet: heh, I'd have to learn the mpeg terms first to understand your statement, so for now I'll just nod and concur
02:07 imirkin: RSpliet: well, it's all done in 8x8 blocks
02:07 imirkin: RSpliet: and how those blocks change. when you zoom in/out, that means the whole scene ends up changing
02:07 CMEPTb: yea just noticed the artifact squares are usually on zooming things
02:07 imirkin: and you have motion vectors going every which way, along with a lot of updates
02:08 imirkin: (these are more mpeg2-y terms, but mpeg4 and h264 aren't that different)
02:08 RSpliet: right, well, I figured those would be lots of short motion vectors :-)
02:08 imirkin: RSpliet: but it's not just motion... if you're zooming in, the whole thing is changing
02:08 imirkin: there's no "move and zoom" primitive
02:09 RSpliet: oh right
02:10 RSpliet: is that stored in vectors from src to dst, or from dst to src?
02:10 CMEPTb: i just keep hoping that maybe tweaking some settings will finally get things to play w/o ugly burps. i went through the nouveau vpdpau wiki page.... all seems to be done as it says.
02:10 imirkin: RSpliet: don't remember tbh.
02:11 imirkin: CMEPTb: yeah, and note how it also says that visual issues with h264 are expected in some videos
02:11 imirkin: it used to be just movie trailors, but i'm seeing it more and more now
02:11 RSpliet: dst to src would let you do zoomey ops, although that would lead to lots of aliassing :-P
02:13 CMEPTb: selected gl (yuv) output and it's working seamlessly no artifacts (at least on this video will have to test this across the board). .. hmm hm
02:14 RSpliet: that probably just means you're not using VDPAU
02:15 imirkin: right. with mplayer, the only thing that uses vdpau is vdpau.
02:15 imirkin: and the error is in the video decoding aspect, not video displaying. so no amount of futzing with display options will fix it.
02:15 imirkin: i did stare a *ton* at why the corruption was happening, and came up empty
02:16 imirkin: that was like 2 years ago now... perhaps a fresh look wouldn't hurt
02:16 CMEPTb: anything i can do to help?
02:16 imirkin: yeah, if you could figure out why it's happening, that'd be super
02:16 CMEPTb: haha
02:17 CMEPTb: then i'd probably first fix that tear about a quarter inch from the top of the screen that never goes away when scene scrolls to either side
02:17 imirkin: CMEPTb: if you could come up with a *super* short video (ideally 1 second or less) that displays the issues, that would really help debug
02:18 CMEPTb: if i could i mean
02:18 imirkin: because then i could really dive into any differences between what the blob does and what nouveau does
02:18 imirkin: i'm sure it's something dumb with reference frames... but what :)
02:19 CMEPTb: ok let me see what i can do... been trying for a bit to get one of the video editing packages to actually work and not insta crash on loading a file. hopes on kdenlive atm
02:35 hno: imirkin, thanks.
02:49 mupuf: imirkin_: ah ah, now I understand what happened to reator
02:49 mupuf: well, at least I know a bit more
02:49 mupuf: maybe the fan was not blocked after all
02:50 mupuf: the atx cord extension ... burnt
02:51 mupuf: well, it was not the highest quality, but it worked for some time
02:51 mupuf: I have spare ones
02:55 imirkin: mupuf: oops :)
03:00 mupuf: imirkin_: as you said
03:01 karolherbst: mupuf: does it smell? :D
03:01 mupuf: karolherbst: not anymore, I guess :D
03:01 mupuf: Still some problems with the remote control system
03:01 karolherbst: but if you didn't noticed before, it isn't that bad I guess
03:03 mupuf: yeah, it is pretty localised
03:03 mupuf:whiches he had his osciloscope with him!
03:03 mupuf: will get it back soon!
03:05 karolherbst: is there a safe way to code on a kernel module without risking messing up the entire system?
03:06 karolherbst: or are there any nice kernel options I should enable to detect bad read/writes or anything like that?
03:11 airlied: karolherbst: inside a VM :)
03:11 airlied: though most people use two machines
03:12 karolherbst: but doing nouveua stuff inside a vm may be difficult
03:12 mupuf: imirkin_: back online!
03:12 airlied: yeah that's when it comes down to the two machines approach
03:13 RSpliet: and/or two hard drives
03:13 RSpliet: I do a lot of REing using a USB HDD with a bootable linux installation on it
03:14 karolherbst: CONFIG_DEBUG_STRICT_USER_COPY_CHECKS might be usefull for doing debugfs work
03:15 airlied: not really
03:15 airlied: it's most for copy to/from user checks
03:16 karolherbst: yeah
03:16 karolherbst: what I want to do in debugfs
03:16 karolherbst: moving pstate from sysfs to debugfs requires using it
03:16 karolherbst: as far as I know
03:17 airlied: no don't think you should have to do any copy to/from user in debugfs
03:17 karolherbst: mhh
03:18 karolherbst: for the read and write callbacks, there is a __user parameter for the buffer
03:19 airlied: ah yes some places can use it,
03:20 airlied: debugfs should grwo some nice interfaces :-)
03:20 airlied: nicer
03:20 karolherbst: I thought so, but well
03:20 karolherbst: mhh
03:20 karolherbst: maybe you know about the debugfs limitations from inside drm?
03:21 karolherbst: for me it seems like you can only read data while using the drm debugfs functions
03:21 karolherbst: and intel does some stuff to workaround this
03:23 airlied: yeah they just create their own files if they need more than the drm core interface
03:23 karolherbst: mhh yeah I know, nouveau does so for the vbios
03:23 karolherbst: but I meant something else
03:23 karolherbst: drm_debugfs_create_files seems to only work with read-only files
03:23 karolherbst: and intel uses debugfs_create_file for files with more fops
03:23 karolherbst: like write or open
03:24 karolherbst: and there is also this drm_add_fake_info_node functions used with debugfs_create_file
03:24 airlied: yes, initial drm debugfs support just mirroed its proc files
03:24 airlied: no writing was envisioned, not sure it's worth extending the core support
03:25 airlied: drivers can really do it themselves
03:25 karolherbst: okay
03:25 karolherbst: so if I follow the way intel does it, I am on the right path?
03:26 karolherbst: I just have my problems getting the drm_device pointer out of the struct file *file parameter :/
03:27 karolherbst: or do I have to first set the private data pointer inside the .open callbacks?
03:29 airlied: should work just like i915 code
03:30 karolherbst: yeah, but I don't really get much of the implicit stuff, especially becuase mostly own structs are used for each file
03:31 airlied: looks like you hook things up to file->private_data in the open callback
03:31 karolherbst: okay
03:31 karolherbst: everything I need inside the write/read functions
03:31 karolherbst: and inode->i_private seems to be drm_device
03:32 karolherbst: I think this is ensured through the stuff done in drm_add_fake_info_node ?
03:33 airlied: i_private is whatever you give to debugfs_create_file
03:33 airlied: 4'th arg
03:33 karolherbst: ahh okay
03:33 karolherbst: seems like this info_node thing is only there for .release
03:34 karolherbst: okay, I think I got it now
03:34 karolherbst: thanks for the info
03:45 imirkin: ohhhhhhhhhhhhhhhhh
03:45 imirkin: i think inputs in tcs are indexed by VILD output
03:45 imirkin: while outputs in tcs are indexed by $laneid
03:45 imirkin: that makes a TON more sense
03:48 imirkin: and also happens to explain why everything works great when input patch size == output patch size
03:51 karolherbst: meh ... the pstate file is still there after module unload :/
03:51 imirkin: probably not great
03:51 karolherbst: no
03:51 karolherbst: I missed something
03:52 karolherbst: anyway, I have to reboot I guess :(
03:52 karolherbst: or is there a way to remove these files now?
03:52 imirkin: not easily =/
03:52 karolherbst: as long as its faster than reboot I am fine
03:52 karolherbst: :D
03:52 imirkin: mupuf: you should give karolherbst access to reator :)
03:54 karolherbst: this doesn't make sense, I do the same i915 does ...
03:54 karolherbst: maybe intel will also leave the debugfs files on unload?
03:59 karolherbst: ahh yeah okay
04:14 karolherbst: imirkin: so do you know a way or just theoratically?
04:14 imirkin: if someone added a file, there must be a way to remove it
04:14 karolherbst: :D
04:14 imirkin: it's all in memory
04:14 karolherbst: yeah okay
04:15 imirkin: just modify the memory and you'll be good.
04:15 imirkin: aka "not easily"
04:15 karolherbst: mhh
04:15 karolherbst: then I'll reboot
04:34 karolherbst: mhh
04:38 karolherbst: ... "if (node = NULL) {" .... :/
04:39 karolherbst: next try
04:41 karolherbst: ahh nice
04:41 karolherbst: it works now
04:41 karolherbst: I think the hardest bits are done
04:41 imirkin: famous last words
04:44 karolherbst: https://github.com/karolherbst/nouveau/commit/234526a157a3865a347443334654dba78b9db518
04:48 imirkin: cool. although will probably want a bit more infra
04:57 karolherbst: what for example?
04:59 imirkin: like reasonable read/write fops
04:59 imirkin: bbl
04:59 karolherbst: this is possible with that
04:59 karolherbst: will add stuff later to simplyfy it a bit
05:04 karolherbst: ohh 2k max frame size in kernel?
05:04 karolherbst: anything bigger has to be kmalloced?
05:21 karolherbst: how can I get a nvkm_object from a nouveau_drm?
05:25 imirkin_: it's in there... ->cli or something? i forget.
05:26 karolherbst: "struct nouveau_cli client;" ?
05:26 imirkin_: sure, that sounds good
05:26 imirkin_: iirc the client is a nvkm object
05:27 imirkin_: or at least it was in an earlier incantation... i haven't caught up on this one
05:27 imirkin_: which seems like for the best, since it's about to go away :)
05:27 imirkin_: perhaps i can skip the next one too
05:29 karolherbst: there is a "nvkm_object_ref(NULL, (struct nvkm_object **)&device);" in nouveau_drm.c
05:29 imirkin_: ok, thats good
05:30 karolherbst: maybe nvkm_device_create tells me where the pointer is
05:50 karolherbst: :/ no clue how to get that nvkm_object
06:30 karolherbst: well, it won't stop printing the stuff now
06:30 karolherbst: oh no :/
06:30 karolherbst: that's stupid
06:32 karolherbst: imirkin_: nvxx_clk(drm->device) can be used
06:43 imirkin_: karolherbst: thanks again for your traces btw... helped me a lot in tracking down the last tess issues
06:45 karolherbst: no problem
06:45 karolherbst: btw: I am on the new nvidia blob now
06:45 karolherbst: but this shouldn't change anything yet
06:46 karolherbst: yeah
06:46 karolherbst: now I get how that works
06:47 karolherbst: I don't have to implement read myself at all
06:47 karolherbst: its quite easy if you know what to do
06:48 karolherbst: imirkin_: https://github.com/karolherbst/nouveau/commit/0ce1f81fd1c120579625684f06b56d5615d6714f#diff-6fc696de511b0108a1a7b4f8a0776021R301
06:48 karolherbst: just open the file and use single_open and req_read
06:48 karolherbst: *seq_read
06:48 imirkin_: cool
06:48 karolherbst: imirkin_: and nouveau_debugfs_pstate_get is pretty simple then
06:49 karolherbst: I totally forgot that read is used to read something which is already there :/
06:50 imirkin_: why'd you get rid of nvkm_control_mthd?
06:50 karolherbst: sould I leave it if somebody wants to use sysfs again?
06:51 imirkin_: what does it have to do with sysfs?
06:51 imirkin_: you just moved all the code
06:51 karolherbst: ahh didn't know that it is used somewhere else
06:52 imirkin_: presumably it's used by your new debugfs code
06:52 imirkin_: or would be, if you hadn't deleted it
06:52 karolherbst: I was thinking about moving it there
06:52 karolherbst: but I could also call the stuff like it was done in sysfs
06:53 imirkin_: don't change the API without reason
06:53 karolherbst: okay
06:53 imirkin_: if you think stuff is in the wrong place now that's fine, but make that a separate change
06:53 imirkin_: which can be discussed separately
06:53 karolherbst: this is a WIP commit, I plan to sperate the stuff later anyway
06:53 imirkin_: kk
06:53 karolherbst: so I should still use nvif_mthd inside the debugfs?
06:54 karolherbst: and remove the things later if its a good idea
06:54 imirkin_: i find it'e easier to do separate stuff as i go and then merge things later
06:54 imirkin_: splitting things up can be quite a pain, esp for multi-step things
06:54 karolherbst: yeah I know
06:55 karolherbst: but now I know what I have to do, so I think I will just throw the commit away and just call nvif_mthd. Seems to be easier anyway
06:55 imirkin_: :)
06:56 karolherbst: if I have a nvif_device I can easily get a nvif_object, right?
06:56 imirkin_: a nvif_device *is* a nvif_object
06:57 imirkin_: (hopefully)
06:57 karolherbst: I saw that the cast are rather simple, but didn't know if it works from/to _object
06:58 imirkin_: the macros tend to work
07:42 hno: My K2100M dmesg: http://paste.fedoraproject.org/249369/77204143
07:52 imirkin_: hno: "This paste is password protected"
07:52 drbombay: imirkin_, yes , G5
07:53 imirkin_: drbombay: i think "stuff" broke in more recent mesa's, try mesa 9.1
07:54 drbombay: okay , and thanks
07:54 imirkin_: it'll take someone to figure out wtf broke, and no one has the combination of hardware and time/knowledge to figure it out
07:56 RSpliet: imirkin_: I think effractur might have one of those too
07:56 RSpliet: (a Mac G5)
07:56 imirkin_: and insufficient time/knowledge to figure out what broke? :)
07:57 RSpliet: insufficient knowledge probably, but he polled here a while ago which led to a few fixes in the kernel I think
07:58 imirkin_: there was the guy who was trying to use a modern gpu in a big-endian box... that led to a small fix there
07:58 imirkin_: but apparently he was still getting psychodelic colors
07:59 imirkin_: the guess was that we needed to byteswap the LUT or something
08:00 RSpliet: oh, effractur got to the point where the kernel didn't go tits up
08:00 RSpliet: but no display
08:53 imirkin_: hm. this is disappointing. GK208 now hangs with unigine heaven. i thought it was DRI3/prime-related, but it even happens in a separate xserver.
08:54 imirkin_: it didn't *use* to die... just had tons of issues with tess
09:05 imirkin_: skeggsb: i'm seeing a CTXSW_TIMEOUT for the above issue btw. if you have any ideas, happy to try them out. this is a GK208 btw.
09:06 imirkin_: skeggsb: eventually we get an assert fail in libdrm because it doesn't properly handle running out of GEM handles, since commands keep piling up because the gpu has hung
09:06 imirkin_: but i'm not extremely worried about that fail
09:24 imirkin_: skeggsb: ftr, here are all the messages: http://hastebin.com/ejixuyidaf.css
10:45 karolherbst: imirkin_: should I leave the sysfs stub stuff?
10:46 imirkin_: karolherbst: nah
10:47 imirkin_: at least i wouldn't
10:47 karolherbst: but currently the kernel is messing with me
10:47 karolherbst: "cat: pstate: Function not implemented" :/
10:47 imirkin_: well, it's a ENOSYS error
10:48 imirkin_: (man 3 errno)
10:48 karolherbst: does nouveau returns it?
10:48 imirkin_: presumably either open() or read() returned it
10:48 karolherbst: allthough, wait
10:49 mlankhorst: it's mostly a difficulty test, if you can't fix it it's not for you ;-)
10:49 karolherbst: :D
10:50 karolherbst: ....
10:51 karolherbst: seriously?
10:51 karolherbst: mhhh
10:51 karolherbst: strace helps, but still I don't get what happens
10:52 imirkin_: nouveau can return enosys if you use nvif wrong
10:52 imirkin_: in general enosys is "the ioctl you tried to call isn't there"
10:53 karolherbst: I see
10:53 karolherbst: can I use it inside debugfs?
10:54 karolherbst: but the nvif stuff isn't even called
10:54 mlankhorst: git grep -ENOSYS in nouveau..
10:54 karolherbst: its comming from seq_read
10:54 karolherbst: open returns without issue
10:55 mlankhorst: ^
10:55 karolherbst: there is something really wrong
10:56 karolherbst: ohh wait
11:01 karolherbst: stupid me
11:01 karolherbst: the kernel seems to be really strict about \n
11:02 imirkin_: "the kernel"?
11:02 karolherbst: printk
11:02 imirkin_: when you write, you send it bytes... it passes them along
11:03 karolherbst: forgot \n at the end and nothing got printed to dmesg
11:03 karolherbst: or at least not immediatly
11:04 karolherbst: okay, I get -38 from nvif_mthd
11:04 imirkin_: right... why would you expect it to? :p
11:04 karolherbst: don't know
11:04 karolherbst: :D
11:04 karolherbst: I am not used to dev in C :/
11:04 mlankhorst: I once wrote a macro that forces a compiler error if you forgot the \n
11:05 mlankhorst: actually if you added it
11:05 karolherbst: okay, so nvif_mthd inside debugfs may cause troubles? will investiage
11:05 karolherbst: *gate
11:06 karolherbst: maybe nvkm_control_mthd_pstate_info returns it?
11:06 imirkin_: you're just calling it with the wrong args
11:06 imirkin_: or some other reason... trace it :)
11:07 mlankhorst: karolherbst: git grep..
11:12 karolherbst: where does return client->driver->ioctl(client->base.priv, client->super, data, size, hack); lead?
11:13 karolherbst: mhh, allthough this is obviouis
11:13 imirkin_: "deep into the guts"
11:18 karolherbst: ohh debug=trace helps :/
11:18 karolherbst: meh
11:24 karolherbst: well, nvif_unpack fails
11:28 karolherbst: this one: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c#L508
11:28 karolherbst: line 508
11:29 karolherbst: allthough
11:29 karolherbst: this doesn't make any sense
11:29 imirkin_: let's see your code.
11:33 karolherbst: https://github.com/karolherbst/nouveau/commit/9fa282396dae077924cc805ec33baa37bee46fbe
11:33 karolherbst: inside nouveau_debugfs_pstate_get
11:33 karolherbst: the first nvif_mthd call fails
11:33 karolherbst: maybe I just get the nvif object wrongly
11:33 imirkin_: NVIF_CONTROL_PSTATE_INFO that guy?
11:34 imirkin_: did you mean to use ctrl instead of dev?
11:35 imirkin_: [yes, you did... heh.]
11:39 karolherbst: I tried both
11:39 imirkin_: oh, also that's wrong
11:39 imirkin_: nvif_object *ctrl = nvif_object(dev);
11:39 imirkin_: you do want ctrl
11:39 imirkin_: but that is not ctrl.
11:40 imirkin_: https://github.com/karolherbst/nouveau/commit/9fa282396dae077924cc805ec33baa37bee46fbe#diff-fe9adbd3f3ebd602dda2f08a80a17117L191
11:40 imirkin_: you see that line? it's an important one.
12:05 karolherbst: yeah
12:06 karolherbst: so this one has to be called before I can actually do the nvif_mthd stuff?
12:08 imirkin_: yeah... you call methods on the ctrl object
12:08 imirkin_: you have to create the ctrl object first
12:09 karolherbst: so add nvif_object to nouveau_debugfs or something
12:09 karolherbst: and create it
12:09 imirkin_: same as the old sysfs thing that you removed
12:43 karolherbst: imirkin_: do you know if its save to do "struct nouveau_drm *drm = nouveau_drm(minor->dev);" ?
12:44 imirkin_: is that what nouveau_sysfs did?
12:44 imirkin_: if so, then yes
12:44 imirkin_: if not, then not
12:46 karolherbst: allthough intel also does "struct drm_device *dev = minor->dev;"
12:46 imirkin_: don't look at intel
12:46 imirkin_: look at nouveau_sysfs
12:46 karolherbst: the thing is, in debugfs you get a drm_minor not a drm_device
12:46 imirkin_: do what it did.
12:46 imirkin_: ok, and what's minor->dev? is it a drm_device?
12:46 imirkin_: or is it a device?
12:46 karolherbst: yeah
12:47 karolherbst: kdev is device
12:47 karolherbst: dev is drm_device
12:47 imirkin_: ok, so use that.
12:47 karolherbst: thins is, I got a NULL pointer somehow :/
12:47 karolherbst: have to restart X again anyway
12:53 karolherbst: yeah, debugfs init is called three times
12:53 karolherbst: once for each minor (1, 65 and 129 here)
12:53 imirkin_: makes sense.
13:24 karolherbst: yeah well, that idea backfired: minor->dev is NULL
13:24 imirkin_: probably need to set it somewhere
13:25 karolherbst: I think its done later
13:26 karolherbst: its fine to use it in the actual methods
13:26 karolherbst: but not in init
13:26 imirkin_: you want to create the ctrl object once
13:27 karolherbst: yeah
13:28 karolherbst: I could also do that in the open function
13:28 karolherbst: but thats kind of ugly
13:33 karolherbst: imirkin_: any good idea?
13:34 imirkin_: not offhand, would have to read code
13:35 karolherbst: maybe its a bad idea to do it over the ioctl. Is there a good reasons why I should use it in debugfs? (was there any in sysfs?)
13:36 imirkin_: yeah. debugfs is the thing for shit like this.
13:36 imirkin_: can't have it in sysfs
13:38 karolherbst: I could hack it a bit and just remove the "static" stuff and just call the methods, should work, is not clean, but we can clean up later
13:39 imirkin_: can't do that.
13:39 karolherbst: mhhh
13:40 karolherbst: that's a pitty :/ if I do that inside open, I have to mutex the creation :/
13:40 karolherbst: and this is messy
13:40 imirkin_: gr
13:41 imirkin_: you don't seem to be doing the thing i'm saying
13:41 imirkin_: you have to init the thing ONCE at create time, not once per open/etc
13:41 imirkin_: once per nouveau module load
13:41 imirkin_: same as it was done for sysfs
13:41 karolherbst: yeah I know, but I don't get the drm_device there
13:41 imirkin_: figure out a way to do it that way. that is the only actual way to do it.
13:41 imirkin_: ok, then think about what's going on and rseolve it
13:41 imirkin_: e.g. pass it in :)
13:42 karolherbst: the init function is called pretty early, even before the "nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0e6200a1" prints and so on
13:42 imirkin_: ok.
13:42 imirkin_: it worked for sysfs right?
13:43 karolherbst: yes, but there it was called much later
13:43 imirkin_: then call it much later.
13:43 karolherbst: isn't drm calling it?
13:44 karolherbst: there is this nice ".debugfs_init = nouveau_debugfs_init" inside driver_stub
13:48 karolherbst: uhh its called inside drm_dev_register :/
14:09 karolherbst: ohh I am stupid, minor->dev isn't NULL, minor->dev->dev_private is :/
14:16 karolherbst: yeah nouveau_drm_load is called after the debugfs thing :/
14:20 karolherbst: imirkin_: serisouly, I don't see a way how to do it without touching drm core itself :/ and moving nouveau_drm creating out of load somewhere earlier (if even possible) sounds a little insane to me
14:21 mupuf: imirkin_: what do you need in reator?
14:22 mupuf: hakzsam needs a fermi in reator. IIRC, you wanted both a nv50 and the GM107
14:22 hakzsam: I would like to keep the nv50 and plug a fermi, yes
14:23 hakzsam: at least the fermi if he really wants the nv50 :)
15:05 imirkin_: mupuf: G80 would be nice for a little longer
15:06 imirkin_: mupuf: the GM107 would be cool too, but can wait until I'm done with G80
15:06 imirkin_: don't want to hog the precious pcie slots, esp given how slowly i end up getting back to playing with it
15:27 karolherbst: what is like the longest thing you can write inside pstate?
15:28 imirkin_: 1 page is more than sufficient if that's what you're asking
15:29 karolherbst: I meante more like in bytes
15:29 karolherbst: *meant
15:29 karolherbst: but I meant also usfull stuff
15:29 karolherbst: I actually have to use copy_from_user in .write
15:30 karolherbst: and need a buffer on the stack, so I don't want it to be too big
15:30 imirkin_: 1 page = 4096 bytes
15:30 imirkin_: which is also the unit of allocation of pages
15:30 imirkin_: you can kmalloc smaller bits though
15:30 imirkin_: which come off of a slab
15:30 karolherbst: why should I use kmalloc for that?
15:31 imirkin_: just informing :)
15:31 karolherbst: yeah I know
15:31 karolherbst: but I thinkg char buf[16] is enough?
15:48 karolherbst: yay, it works
16:09 karolherbst: coding inside the kernel really shows strange stuff
16:37 skeggsb: hno: k2100m has a hw bug that needs working around, there's a WIP patch here: http://cgit.freedesktop.org/~darktama/nouveau/commit/?h=hack-gk106m
21:58 imirkin:hates nouveau hangs