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