03:18 effractur: RSpliet: it seems that that patch is already in 3.18
03:30 RSpliet: effractur: is it? I thought Ben just merged it a couple days ago in his dev tree 4 days ago
03:30 RSpliet: ( http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=7ca9e1d70f147945417c70cdc751acf4c5930c98 )
03:30 RSpliet: hmm... too many days ago, I should re-read sentences after revising them
03:30 RSpliet: anyway
03:31 effractur: wait let me chec
03:32 effractur: becaus also in my tree ther eis no nvkm folder
03:32 mlankhorst: RSpliet: weird, why is the second ioread32 needed?
03:33 RSpliet: mlankhorst: no idea, not my patch...
03:34 RSpliet: but it's powerpc, so expect "platform quirk"
03:35 effractur: RSpliet: a i see
03:35 effractur: the ioread32_.. was added
03:38 RSpliet: effractur: this tree is a "userspace" version of nouveau
03:38 RSpliet: useful for development (easy loading/unloading)
03:39 RSpliet: not aimed at end-users
03:39 RSpliet: but patches apply relatively cleanly against the Linux kernel tree
03:41 effractur: RSpliet: k
08:31 imirkin: mlankhorst: apparently on nv50+ the card takes a "while" to switch endian modes, the extra read ensures that the switch is "done"
09:27 mlankhorst: ah
12:02 hakzsam: Hey, does someone is able to run bin/nv_perfmon with the new build system without any errors?
13:01 hakzsam: okay, I tried to change the "driver" option, but still the same issue
13:02 hakzsam: skeggsb_, Hi, are you aware about this?
13:26 pmoreau: Could someone please explain me how EVO works? As far as I understand, evo_mthd sets the method to use and evo_data passes the data.
13:26 pmoreau: But what is the last argument of evo_mthd? And how do you choose to which channel you're speaking?
13:34 RSpliet: the last agrument of evo_mthd is the number of "parameters" that follows
13:34 pmoreau: Oh right, I should have looked a bit closer to evo_sync! :D
13:35 RSpliet: I always look at it as if it's MMIO
13:35 RSpliet: erm... I lost whether the second param is bytes or words, but assuming it's words
13:36 RSpliet: if you say evo_mthd(0x800,4), then followed by 4 evo_data(some int), you basically write some int to an offset 0x800, 0x804, 0x808, 0x80c
13:36 pmoreau: Ok
13:37 pmoreau: And which channel are you speaking on?
13:37 pmoreau: How do you choose / know?
13:37 RSpliet: that depends on what you want to make it do
13:37 RSpliet: but that's documented... somewhat
13:37 RSpliet: in rnn, but more detailed in the headers that NVIDIA released
13:39 pmoreau: I'm having a look at them, but I didn't understood how to select the channels, nor what the DMA opcodes are.
13:43 hakzsam: skeggsb_, it fails here http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/engine/device/base.c#n337 because mmio_base is not defined (ie. 0)
13:51 hakzsam: skeggsb_, nv_perfmon -b lib -a 0x00010000
13:51 hakzsam: this works fine
13:51 hakzsam: but I don't understand the meaning of -a here
14:49 pmoreau: What? dmac->ptr[1073741823] (in evo_wait) results in an "unable to handle kernel paging request"? I'm disappointed! :D
15:36 skeggsb_: hakzsam: fixed
15:39 imirkin: pmoreau: evo_mthd == BEGIN_NV04. evo_data = PUSH_DATA
15:39 imirkin: pmoreau: evo channel works just like a regular pushbuf
15:42 pmoreau: Ok
15:44 pmoreau: I'm trying to understand why I get this "unable to handle kernel paging request" error: http://pastebin.com/tytTi984
15:44 pmoreau: But I don't if I do a pci reset before hand on the G96 (still on my laptop MCP79+G96 :D )
15:45 pmoreau: Maybe one crtc's config which is off
15:45 skeggsb_: because there's something else completely hideously wrong and you're reading back bogus values from registers?
15:46 skeggsb_: in this case, 0x3fffffff... which i think might really be 0xffffffff.. probably indicating display never answered the priv reg read
15:47 pmoreau: Hum...
15:49 pmoreau: I'll try to find which crtc is involved
16:56 imirkin: RSpliet: what happened to your modifier-enablement patches? iirc i had asked you to split them up or something simple along those lines...
17:10 mjg59:
23:23 hakzsam: skeggsb_, s/nouveau/nvkm was wrong here, good catch :)