00:28 imirkin: skeggsb: any thoughts on the color palette being off? i'm thinking that the palette stuff needs to be written as mmio32 so that the byteswapping can occur as expected.
02:34 imirkin: skeggsb: btw, looks like you dropped the agpmode param? oops?
03:27 obimod: What's up?!
03:28 xexaxo: mupuf: back in the days you could simulate mouse movements and (GUI) clicks by looking up the object (window, menu etc) handle :)
03:29 xexaxo: last I've tried it was with WinXP, so it might be gone for newer versions.
03:29 xexaxo: not something terribly fun to do though :\
04:47 hakzsam: xexaxo, it is faster to do it by hand :)
05:09 karolherbst: what are split/merge instructions exactly anyway?
08:55 saati_: hi
08:55 saati_: is an msi 750 gtx mmiotrace useful for anyone?
09:02 karolherbst: saati: depends
09:02 karolherbst: is there anything not working on your 750 gtx?
09:02 karolherbst: and what did you trace exactly
09:02 saati: nothing, i'm just asking if it's worth the trouble
09:03 karolherbst: if there is anything not working on your card yet, which bothers you, then it might be helpful
09:04 karolherbst: ohh, its a maxwell card
09:04 saati: i didn't actually check the driver, the feature matrix on the website said it's all WIP and TODO
09:05 karolherbst: yeah, maxwell is not in the best state currently
09:05 karolherbst: but there are already some traces from GM107 chips
09:05 Yoshimo: not the best, is quite an understatement karol
09:06 karolherbst: I know
09:06 karolherbst: even worse than fermi I assume?
09:07 Yoshimo: fermi has firmware as far as i know that is a big difference
09:07 saati: maxwells don't?
09:08 karolherbst: yeah, but fermi isn't as usefull currently, because pstate doesn't work
09:08 karolherbst: or did I miss something?
09:08 karolherbst: ohh actually, I am home now, so I could work on fermi reclocking...
09:09 karolherbst: or is there anybody working on it currently?
09:09 Yoshimo: not that i know
09:09 RSpliet: karolherbst: nope
09:10 RSpliet: if I had a Fermi card, I might have
09:10 RSpliet: but... nope
09:10 karolherbst: k
09:10 karolherbst: I have a ddr3 mobile here
09:11 karolherbst: GF108 or GF117, not sure
09:11 karolherbst: RSpliet: do you know which parts are missing for it to work?
09:15 RSpliet: karolherbst: pretty much all of the memory clock stuff
09:16 RSpliet: they scrambled around the memory timing registers quite heavily
09:16 karolherbst: mhh
09:16 RSpliet: but not the VBIOS tables until Kepler
09:17 karolherbst: sounds annoying
09:19 RSpliet: yes
09:19 RSpliet: I did some work on that years ago
09:19 RSpliet: when I had a roommate with an NVC1
09:19 RSpliet: but... never invested serious time in getting it to work
09:19 karolherbst: but core clocking should work?
09:20 RSpliet: I... think Ben took care of that yes
09:20 karolherbst: I see
09:20 RSpliet: although I don't know the details
09:20 karolherbst: I just know I can't write anything into pstate, just returns with no such device or something
09:51 Yoshimo: best luck karol with fermi
09:52 karolherbst1: I think I will finish the pci stuff first before starting another project...
09:53 karolherbst: "pci->pdev->slot" is 0 ?
09:53 karolherbst: how can that happen
09:54 RSpliet: starts counting from 0 I think?
09:54 karolherbst: its a pointer
09:54 karolherbst: to pci_slot
09:54 RSpliet: oh
09:54 karolherbst: I think I should use bus directly....
09:54 karolherbst: maybe slot is 0 if there is only one?
09:54 karolherbst: like on laptops
09:55 karolherbst: or PCI bus without slots at all and just devices?
09:55 karolherbst: dunno
09:56 karolherbst: does anybody want to try out the patches then? I think I will get it working for kepler today
09:57 karolherbst: mhh nice
09:57 karolherbst: I can really read the max speed from the bus. nice
10:04 karolherbst: mhhh
10:04 karolherbst: I don't like this enum: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/pci.h?id=refs/tags/v4.2-rc8#n210
10:04 karolherbst: this sounds like trouble
11:01 mlankhorst: why?
11:03 karolherbst: mlankhorst: how should I make the code compatible when 16_0 hits linux?
11:03 karolherbst: also I can't simply >= something
11:04 imirkin: Yoshimo, karolherbst: fyi, maxwell GM107 should work mostly ok with nouveau. GM200+ has no accel.
11:08 Yoshimo: unfortunately GM107 =! 980
11:08 Yoshimo: i know
11:10 Yoshimo: so i put my hopes up for the GF110 , which is likely to happen sooner than maxwell
11:13 karolherbst: mhh
11:13 karolherbst: currently I am suprised why kepler uses the nv40_pci stuff
11:14 karolherbst: what is meant by msi_rearm?
11:21 imirkin: Yoshimo: yeah, but the person coming in was asking about GTX 750, which is GM107
11:21 imirkin: karolherbst: don't worry about msi_rearm :)
11:21 imirkin: it works. leave it be.
11:21 karolherbst: yeah, but I wondered, why kepler uses the nv40 stuff
11:22 karolherbst: but fermi, fermi stuff
11:23 imirkin: fermi had a quirk in its msi rearming
11:23 imirkin: not all fermi, too
11:23 imirkin: just some
11:23 karolherbst: I see
11:25 karolherbst: is something like that right? https://github.com/karolherbst/nouveau/commit/2079dcbba5c52e70432491a26f47f74f0bbd6945
11:26 imirkin: certainly not wrong
11:34 karolherbst: okay, when my kernel doesn't crash now, kepler should work somehow unstable (tm)
11:34 karolherbst: nice
11:40 karolherbst: imirkin: should I add _pci2_rd/wr functions for the 0x08c000 reg range? "normal" pci is 0x088000
11:40 imirkin: errr
11:41 imirkin: i'd just do the nvkm_wr32 directly, but that's just me
11:42 imirkin: not sure what ben's idea for this was
11:42 karolherbst: mhhh
11:42 karolherbst: currently there is stuff like "nvkm_pci_wr08(pci, 0x0704, 0xff);"
11:42 imirkin: in the generic code, right?
11:42 karolherbst: no
11:43 karolherbst: gf100_pci_msi_rearm
11:43 imirkin: hm
11:43 karolherbst: but this will call nv40_pci_wr08
11:43 imirkin: right.
11:43 imirkin: i'd just do the nvkm_wr32
11:43 karolherbst: but this only writes into 0x088000 + offset
11:43 imirkin: and wait for ben to yell at you and propose a different solution
11:44 karolherbst: I can also give an offset of 0x4040 :D
11:44 imirkin: no.
11:44 karolherbst: but this pci2 range seems to be new on kepler+
11:45 karolherbst: mupuf came up with the name?
11:45 imirkin: or i dunno. your call. do something and stop worrying about it.
11:45 imirkin: when you have something working, we can address such trivial details
11:46 karolherbst: ohh there is an todo by mupuf "<!-- XXX: find a better name! -->"
11:47 imirkin: maybe it should even just be in the same section all under PPCI, who knows
11:47 imirkin: like i said... don't worry about it :)
11:47 karolherbst: yeah I know, but I rather to stuff a cleaner way know than later
11:48 imirkin: ok
11:48 karolherbst: but there isn't much going on in that range
11:48 karolherbst: CONFIG_LINK is pretty much over 75% already
11:49 karolherbst: will call it pci_2 and just add some new read/write functions for it, should be okay
11:52 mupuf: karolherbst: hehe
11:53 karolherbst: I don't need to dispatch them yet, because who else will use them?
11:53 karolherbst: mupuf: but do you have any idea what the other regs could be for?
11:53 karolherbst: there are only a handful
11:53 mupuf: not yet, no
11:53 mupuf: hence the super generic name
11:54 karolherbst: mhh
11:54 karolherbst: 0x08c1c0 looks suspicious
11:54 karolherbst: but no clue
11:54 karolherbst: is there something like rd04 and wr04? :D
11:55 imirkin: heh
11:55 mupuf: why would you want to read 4 bits?
11:56 imirkin: no, modern machines (like anything made in the past 30 years or so) tends to use 8-bit units
11:56 karolherbst: need them for kepler pcie link speed
11:56 karolherbst: :D
11:56 imirkin: PDP-11 (iirc) used 18-bit units and VAX used 36-bit
11:56 imirkin: but they're somewhat of an oddity
11:57 karolherbst: need to set bit 18 and 19
11:57 imirkin: right, but it's a 32-bit value
11:57 karolherbst: and 22 can contain stuff I should never change
11:57 imirkin: so you read the 32-bit value, and write a 32-bit value
11:57 imirkin: the operation you're looking for is a mask
11:57 karolherbst: mhhh, okay
11:58 imirkin: nv_mask in the old code
12:03 karolherbst: okay, here we go
12:07 karolherbst: wow, it works
12:08 karolherbst: mhhh
12:08 karolherbst: strange
12:08 karolherbst: "pbus->cur_bus_speed" always contains 2_5GT
12:08 karolherbst: but lspci reports the higher speed
12:11 imirkin: you might be missing some notification to linux to rescan that stuff
12:12 karolherbst: oihh, propably
12:12 imirkin: look at what radeon does
12:12 imirkin: and do the same thing ;)
12:14 karolherbst: mhhh
12:16 karolherbst: they don't read the current speed at all
12:16 karolherbst: maybe different
12:21 karolherbst: they do a spin_lock_irqsave and spin_lock_irqrestore though
12:21 karolherbst: but for every pci write
12:22 imirkin: don't worry about that
12:22 imirkin: worry about how they interact with the linux pci subsystem
12:22 karolherbst: mhh
12:22 karolherbst: currently searching for it
12:23 karolherbst: but it looks like they just set the speed through the gpu on init and are done with it
12:25 imirkin: yeah
12:25 imirkin: so i guess linux pci subsystem never finds out... wtvr
12:25 karolherbst: si_pcie_gen3_enable looks more promising though
12:26 karolherbst: pci_write_config_word for LNKCTL
12:27 karolherbst: they try to read the speed from LNKCTL2 though after setting it, but this is always 8.0 for me
12:28 karolherbst: also on blob
12:30 karolherbst: ohhhh
12:30 karolherbst: "00:01.0" also changes speed here
12:30 karolherbst: which is the pcie x16 controller
12:39 karolherbst: imirkin: okay, cur_bus_speed is only writtin at probe time
12:58 karolherbst: imirkin: found something out: LNKCAP gives us the value of all supported pci speeds
12:58 karolherbst: not jsut the highest speed
12:59 karolherbst: lspci is misleading there
13:31 mupuf: nope
13:32 karolherbst: mupuf: ?
13:32 Hoolootwo: yep
13:33 mupuf: Hoolootwo: yope :p
13:34 mupuf: Sorry though, wrong channel :p
13:34 karolherbst: oh wow, this API is really reliable :/ I think I do something wrong
14:53 karolherbst: imirkin: reg 0008c4f0 changes after speed change
14:55 karolherbst: 8.0: 0x556 5.0: 0x554 2.5: 0x443
15:00 karolherbst: okay, 000880a8 bit 0 and 1 are the LnkCtl2 bits
15:19 karolherbst: does somebody is working on a tesla card currently?
15:20 karolherbst: would like to check something about that reg
15:20 karolherbst: value 0 and 1 seem to be for 2.5, 2 for 5.0 and 3 for 8.0, at least this is on my kepler
15:20 imirkin: i have one plugged in
15:21 imirkin: let me know what you need
15:21 karolherbst: nvapeek 000880a8
15:21 karolherbst: and then lspci LNK_CTL2 speed
15:21 imirkin: 000880a8: 00000001
15:23 karolherbst: this is actually a requiernment for 8.0 lnk_sta speed, lnk_sta won't go any higher than lnk_ctl2
15:24 imirkin: well, tesla doesn't do pcie v3
15:24 karolherbst: imirkin: is this a nv9* or nva* tesla card?
15:24 imirkin: neither does fermi
15:24 imirkin: it's a nva3
15:24 karolherbst: k
15:24 karolherbst: if the reg is at 2.5, you can only go to 2.5
15:24 karolherbst: if its at 5.0, you can only do 5.0 ;)
15:24 karolherbst: so its already important for all 5.0 cards as well
15:25 karolherbst: imirkin: what does lspci say? 2.5 GT/s for LnkCtl2?
15:25 imirkin: yeah, 2.5
15:25 imirkin: but i can get it up to 5.0
15:25 karolherbst: mhh
15:25 karolherbst: without setting lnkCtl...
15:25 karolherbst: you could do this: nvapoke 000880a8 00000002
15:26 karolherbst: this should increase LnkCtl2 to 5.0
15:26 imirkin: https://paste.debian.net/309738/
15:26 imirkin: nope
15:26 karolherbst: mhh
15:26 karolherbst: maybe cap needs to go up first?
15:26 imirkin: and it still says 1
15:26 imirkin: maybe
15:27 karolherbst: whats the content of 0x00154c ?
15:30 imirkin: 0000154c: 0000023d
15:31 karolherbst: +0x80 should bump cap to 5.0
15:31 karolherbst: or rather to max, which is 5.0
15:32 karolherbst: would be nice to see if ctl2 does up after the cap is up
15:38 karolherbst: wow, the blob actually dropped this to 5.0 in mupufs kepler traces
15:42 karolherbst: and 0x08c1c0 reg 20 might indicate max speed of current configuration?
15:43 karolherbst: and reg 21
15:43 karolherbst: its 2 on 2.5 systems, 1 on 5.0 and 0 on 8.0
15:43 imirkin: airlied: do you have CONFIG_FB_FOREIGN_ENDIAN enabled in your config?
15:43 imirkin: airlied: for the g5 that is
15:57 airlied: imirkin: nope
15:57 imirkin: ok, didn't think i needed it either, but just hcecking
15:57 airlied: neither does the fedora configed kernel I normally use
15:58 imirkin: of course now i can't get linux to boot anymore :(
16:00 imirkin: gah. the new kernel still boots though
16:00 imirkin: so i just suck at building kernels
16:09 karolherbst: mhh
16:09 karolherbst: lnkCtl2 stays 2.5 on the fermi card here
16:10 karolherbst: but the blob just bumps this at loadig time and never touches it again, so
16:21 karolherbst: what's the best way to add a pci_init function to nouveau? just add nvkm_pci_init with dispatching + call to it inside nouveau_drm_load ?
16:23 karolherbst: ohh there is nvkm_pci_init already, stupid me
16:38 imirkin: skeggsb: btw, i need a patch like this: https://paste.debian.net/309744/ -- i'm surprised fbcon could have worked before.
16:38 imirkin: skeggsb: also the color issue only happens with fbaccel... if it uses the fallback methods it's all fine. very odd.
16:39 imirkin: skeggsb: i guess it writes the color in a somehow odd way, but i can't figure out what that is given the greenish hue
17:01 airlied: imirkin: not yellow?
17:01 airlied: yellow is the normal backwards color :)
17:02 skeggsb: airlied: is fbcon busted on your g5?
17:03 imirkin: airlied: no, it's off-color green
17:04 imirkin: airlied: skeggsb: https://drive.google.com/open?id=0B5tpwkyyHkokRGgzdU1INnUzYk0
17:04 imirkin: the above patch fixes the byteswap issue
17:04 imirkin: (it looks like the chars are swapped because the font is 8 pixels wide... fun issue)
17:04 skeggsb: i don't see anything wrong with that :P
17:05 skeggsb:wonders how this hasn't been noticed before
17:05 imirkin: i started out by assuming it was something broken at the tty layer
17:05 imirkin: since you know, how can something that worries about pixels swap the order of *chars* :)
17:06 imirkin: almost as much fun as a bug i tracked down that caused code that was written as foo("a","b") to print as foo("b","a")
17:06 imirkin: [due to RTL joy]
17:06 imirkin: skeggsb: well... one way would be is if we recently started twiddling more endian bits
17:07 imirkin: skeggsb: for example, it looks like the be/le thing is a per-context thing... were we not setting it before on the "system" context?
17:07 imirkin: although that seems like it would have caused a whole other pile of fail
17:08 imirkin: and for the life of me i can't figure out what's wrong with the colors. i tried swapping fb/bg, but that just made everything black. i tried printing out what they were, but turns out that printing in the middle of the routine that handles prints is... not smart
17:08 skeggsb: haha, i've made that mistake myself a couple of times :P
17:09 imirkin: and now i can't even get any older kernels to boot at all... 3.16 and 3.18 both don't print *anything* on the OF console
17:09 imirkin: 4.1.6 and 4.3.0 do though, but the nouveau in 4.1.6 is busted wrt OF
17:09 imirkin: skeggsb: btw, did you see my question RE of on the list?
17:09 imirkin: [for vbios]
17:10 imirkin: i should go back to 4.1.6 with a nouveau that matches and with OF fixed up... perhaps that'll show something itneresting
17:10 airlied: skeggsb: I turned off nouveau a while ago due to something broken
17:11 airlied: can't remember if it was due to the 208 being plugged in or fbcon failing
17:11 skeggsb: ah, that'd be the gk208 i suspect, it's been up there for ages now
17:11 imirkin: maybe i should try 3.13 -- airlied you said you were pretty sure it booted
17:13 karolherbst: skeggsb: for that pci stuff, what would you prefer: a design with mixed speed enum (AGP, PCI, PCIe inside one) or splitted ones?
17:13 karolherbst: allthough I don't know if I should care about anything pre PCIe anyway
17:13 skeggsb: no, just make it for pcie-only
17:13 skeggsb: it doesn't really make sense before then
17:14 karolherbst: k
17:14 karolherbst: will still name the stuff pcie_something, because I currently use pci_
17:16 imirkin: skeggsb: btw i guess we should refuse loading nouveau for NV10 and earlier, right?
17:16 imirkin: er, on BE that is
17:16 karolherbst: skeggsb: how much knowledge do you have about the Linux pci api? I tried to get several values from it, but some doesn't get updated or some are just 0
17:17 skeggsb: imirkin: hm, how come?
17:17 imirkin: skeggsb: no BE flip bit
17:18 imirkin: i guess i can double-check with my NV5 once i get this NV34 under control
17:18 imirkin: https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml#L53
17:19 imirkin: although the likelihood of a NV1A on a big endian cpu is somewhat unlikely
17:19 skeggsb: ah, i wasn't aware PMC_BOOT_1 didn't exist before then
17:19 skeggsb: *shrug*
17:20 skeggsb: karolherbst: probably no more than you :P
17:21 karolherbst: usually the card has enough regs for all kind of limits, but I was thinking maybe its a good idea to double check, but if that's so unreliable, maybe I just check against the regs of the gpu
17:22 airlied: imirkin: 3.14.0 should work
17:24 imirkin: powerpc64-unknown-linux-gnu-ld: warning: creating a DT_TEXTREL in object.
17:24 imirkin: is there a ppc channel of some sort?
17:26 airlied: no there is just benh :-P
17:26 benh: haha
17:26 benh: #mklinux and #ppc64 on freenode
17:27 benh: "This means that you are including an object in the shared library
17:27 benh: which was compiled without the -fpic option."
17:27 benh: wtf
17:27 benh: ?
17:28 imirkin: benh: i got that building g5_defconfig with 3.13
17:28 benh: what toolchain ?
17:28 imirkin: benh: nothing i try seems to boot on the g5 anymore :(
17:28 benh: haha
17:28 imirkin: benh: gcc 4.9
17:28 benh: 4.9.0 has known issues iirc
17:28 benh: 4.9.x is better
17:28 karolherbst: there are some nastly libraries forgetinng to add -fPIC
17:28 benh: does LD tells you which object caused that
17:28 benh: karolherbst: not in the kernel
17:28 imirkin: benh: the 4.1/4.3-pre kernels still boot, but nothing older does anymore
17:28 karolherbst: ohh
17:28 imirkin: benh: 4.9.3 is what i'm using
17:28 RSpliet: imirkin: would you know why PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED is disabled on NV50?
17:29 benh: imirkin: interesting
17:29 karolherbst: kernel
17:29 benh: imirkin: odd
17:29 benh: I wonder if it's a compiler issue
17:29 imirkin: RSpliet: it's a fairly meaningless cap iirc
17:29 imirkin: RSpliet: feel free to flip it on
17:29 imirkin: gah! compiler issue? i already have enough issues!
17:30 imirkin: benh: what's a safe compiler to use for ppc64?
17:30 imirkin: benh: i also have binutils 2.25.1
17:30 RSpliet: imirkin: I might do so later on, give it a test drive before proposing a patch
17:30 karolherbst: gcc-4.2.1+apple patches? :D
17:30 RSpliet: but I guess it is meaningless without GLSL 4.0 (is that a thing?)
17:30 RSpliet: _shader5 :-P
17:31 imirkin: RSpliet: ARB_gpu_shader5 or GLSL 4.00
17:31 RSpliet: none of which I expect NV50 to support anyway
17:31 imirkin: RSpliet: that's right
17:32 imirkin: if the green font color is coz of a compiler issue... that'll be quite annoying.
17:33 benh: imirkin: I'm curious to know what object is missing -fpic
17:33 karolherbst: what's the oldest chipset someone can use the pstate stuff with?
17:33 benh: imirkin: that's just plain weird
17:33 benh: imirkin: I assume the result doesn't boot ?
17:33 benh: imirkin: I use all sorts of 4., 4.9 and 5.x daily without problem
17:34 benh: imirkin: but *maybe* there was a kernel makefile bug that trips newer compiler ... not sure really, I don't remember ever hitting the problem you mentioned
17:34 benh: imirkin: maybe stale objects in the tree ? tried a hard clean ?
17:34 imirkin: benh: tried to clean, but not mrproper
17:35 imirkin: benh: about to test whether this 3.13 kernels boots or not
17:35 benh: imirkin: hard clean = git ls-files -o | xargs rm :)
17:35 imirkin: benh: i'm doing out-of-tree builds
17:35 benh: imirkin: also check 3.13.x
17:35 benh: just in case some shit slipped into .0
17:35 benh: to be honest, I've been bad at testing on g5 for a while
17:36 benh: since mine broke
17:36 benh: it could be that we had the odd breakage
17:36 benh: the sad thing is, I actually have another quad g5
17:36 benh: stored somewhere at home :)
17:36 imirkin: well, i got mine for $30 :) should be moderately easy to replace
17:36 benh: I could/should dig it out
17:36 benh: afaik it still works :)
17:36 imirkin: as long as you're willing to also get a hernia operation
17:36 airlied: imirkin: 3.19.0-rc3 from fedora fails ot load nouveau at all
17:36 benh: if you're going to fix nouveau, we can make a deal and I dig it out :)
17:36 airlied: unknown chipset
17:37 imirkin: airlied: yes, that's expected. skeggsb killed it.
17:37 imirkin: airlied: err.... not like that.
17:37 imirkin: benh: whoa, i dunno about "fix nouveau". how about "improve nouveau"?
17:37 imirkin: benh: 64k pages are def not entering into the scope of my improvements :)
17:38 skeggsb: imirkin: they are mine :P
17:38 airlied: 3.13-rc4 boots with perfect fbcon
17:39 imirkin: skeggsb: you can have 'em ;)
17:39 imirkin: airlied: ok, and that's on a NV40?
17:39 airlied: imirkin: yes nv44
17:40 imirkin: benh: still no go. i'm going to try to super-clean
17:40 airlied: 3.15.10 fedora kernel also boots with good fbcon
17:41 airlied: sorry nv43 6600
17:41 imirkin: airlied: might be a difference in how nv3x handles those values?
17:41 airlied: I got nothing between 3.15 and 3.19 to test
17:42 airlied: imirkin: there cuold be I suppose
17:42 airlied: or maybe AGP is eating you :)
17:42 imirkin: airlied: agp defaults to off for ppc
17:43 airlied: that concludes my current usefulness until drm-next is fixed and I can test it :)
17:43 imirkin: airlied: what if you plug an off-the-shelf NV34 in?
17:44 imirkin: afaik you guys have a pcie one of those
17:44 airlied: imirkin: not sure it'll boot properly
17:44 imirkin: OF won't be able to display anything
17:44 benh: imirkin: yours is a AGP ?
17:45 benh: imirkin: nv3x ?
17:45 benh: imirkin: mine is a PCIe nv 43
17:45 imirkin: benh: yes, agp nv34
17:45 imirkin: benh: it's a PowerMac7,3
17:45 benh: imirkin: I haven't tried the AGP shit for a LONG LONG TIME
17:45 airlied: imirkin: fbcon will always default to the boot card
17:45 imirkin: i would have preferred to have gotten a pcie one, but the price was right on this one
17:46 airlied: and I'm nearly sure it won't boot without the boot card being OF
17:46 imirkin: airlied: ah ok. i don't know much about OF/mac boot process
17:46 airlied: benh: what was the userspace app that hardcode 64k pages?
17:46 imirkin: i just know it doesn't work! :)
17:46 airlied: or at least couldn't work on a 4k pages kernel
17:46 benh: airlied: mozilla
17:46 benh: airlied: iirc
17:47 benh: airlied: well, one of the components of moz that a few other things use as well :)
17:47 benh: airlied: maybe mozjs, I don't remember
17:47 benh: airlied: it hard codes the page size at compile time
17:50 imirkin: benh: anyways, my idea was to figure out what the whole deal with mesa accel was on nouveau be, but first i figured i'd fix the fbcon issue
17:54 airlied: dang my remote console won't work with latest java webstart
18:04 benh: airlied: security ?
18:05 benh: airlied: I have a similar problem with AMI stuff, I have to add the machine name to the exclusion list in Java ControlPanel
18:05 karolherbst: does anybody know if pci_is_pcie(pci->pdev) can be true when AGP is used?
18:05 karolherbst: I really don't know much about the internals of AGP or how it work
18:06 benh: bbl
18:06 airlied: karolherbst: no it shouldn't be possible
18:07 airlied: since it reads PCIE caps
18:07 karolherbst: k
18:07 airlied: baring some crazy pcie/agp bridges :)
18:09 airlied: imirkin: you got a version of the bios/of fix on top of Ben's work?
18:10 airlied: oh ihnore me that patch you posted was out of tree
18:13 imirkin: airlied: yeah, that patch should work but note that i hardcoded the vbios size
18:13 imirkin: which isn't great if your vbios is of a different size, which it probably is
18:14 imirkin: (and it's whitespace-damaged... it was more of a demonstration of what i had to do than a real patch)
18:14 airlied: I should probably put the G5 on skeggsb's desk :-P
18:14 skeggsb: where will it fit!
18:15 imirkin: you could put it under the other gpu's ;)
18:15 imirkin: just... hope it's not a cheapo ikea desk, or it will break under the g5's heft
18:15 karolherbst: does anybody have an open-end pcie connector?
18:16 imirkin: karolherbst: you mean like an x4 slot that can fit longer cards?
18:16 karolherbst: yeah
18:16 karolherbst: I really want to know the different reg values for the same card, just with a lower system limit
18:17 imirkin: looks like i might...
18:17 karolherbst: nice
18:18 karolherbst: how many lanes?
18:18 imirkin: but... no kepler
18:18 karolherbst: mhh
18:18 karolherbst: no problem though
18:18 karolherbst: tesla+ is fine
18:18 imirkin: it'd also have to be a board with external power
18:18 karolherbst: sadly there are some regs outside 0x88000 range which are kind of usefull :/
18:19 imirkin: since x16 can do 75W while the others only 25W
18:19 karolherbst: ohhh right
18:19 imirkin: iirc the only such board i have is a nv42
18:19 karolherbst: :/
18:20 karolherbst: ohh wait
18:20 karolherbst: there are no power pins in the lanes
18:20 karolherbst: sure about that limitation?
18:20 imirkin: yes
18:21 imirkin: its not in the lanes, it's in the spec ;)
18:21 karolherbst: I meant the lane pins doesn't provide the power
18:22 karolherbst: its in pin 1-3, 8,9 and 10
18:22 imirkin: i understand what you mean
18:22 imirkin: and there's nothing preventing a motherboard from supplying more power to a smaller slot
18:22 imirkin: however the spec says that x16 slots are guaranteed 75W
18:22 karolherbst: yeah
18:22 karolherbst: and only for gpus
18:22 karolherbst: no other device is allowed to get more than 25W
18:23 karolherbst: even on x16 slots
18:23 imirkin: really?
18:23 karolherbst: yeah
18:23 imirkin: even a high-power laser?
18:23 karolherbst: you get the +50W from the 12V pins
18:23 imirkin: aka ethernet ;)
18:23 karolherbst: could be v2.0 only though
18:23 karolherbst: don't know if thats still in the newer specs
18:25 karolherbst: but x16 were 25W only at the beginning too
18:25 karolherbst: so
18:25 karolherbst: I think this 75W is more like a hack than what was intendet from the start
18:26 imirkin: unlike agp, which was a hack from the start ;)
18:26 karolherbst: :D
18:26 karolherbst: also the gpu has to drive at 25W first anyway
18:26 karolherbst: and then it can go into the high power mode
18:26 karolherbst: mhh
18:27 karolherbst: yeah, sounds like a hack :D
18:29 karolherbst: wow, I also have to check if the system supports v2...
18:29 karolherbst: how annyoing
18:29 imirkin: yeah, supporting multiple systems with a single code-base sure is annoying!
18:29 imirkin: look at what radeon does and do the same thing... you won't go wrong
18:30 imirkin: [and if you do, you'll at least have them to blame]
18:30 karolherbst: ohh wait, the blob just sets the card into v2 mode
18:30 karolherbst: and then reads the reg to try it again
18:30 karolherbst: I already looked and was annoyed, that they don't have something as nice as the nouveau pci subdev.....
18:31 karolherbst: no, they just push to the limits at probe time and forget about pci later
18:31 imirkin: not a terrible plan
18:31 karolherbst: yeah, if power consumption doesn't matter, but at least for laptops we should be nice
18:32 karolherbst: so instead of just pushing to the limits at module loading time and "we can always improve later", I just do it right now and nobody will complain, that nobody cares about it anymore :D
18:33 karolherbst: there are some drm_pcie functions though
18:34 karolherbst: ohh 4.2 is out
18:35 karolherbst: ohh drm_pcie_get_speed_cap_mask is inside drmP.h ....
18:35 karolherbst: mhhh
19:09 karolherbst: imirkin: currently reading how to get to 8.0 speed in the pcie 3.0 specs
19:09 karolherbst: fun
19:10 karolherbst: somehow I am happy, that the card is doing this for us
19:12 karolherbst: "The Target Link Speed field in the Link Control 2 register sets the upper bound for the Link speed." that would be LnkCtl2 speed
21:30 phillipsjk256: So I was just trouble-shooting my computer with a Knoppix live DVD (that appears to use Proprietary drivers by default). Tux racer appears to run 5x faster* than it does under nouveau with the same hardware.
21:31 phillipsjk256:The * is because I am currently using Xinerama, which has a performance penalty
21:31 imirkin: yeah, the penalty being that you get no performance
21:33 phillipsjk256: Assuming that I can get repeat the test with Direct rendering, does that imply I can quadruple the clock-sped on my card?
21:35 phillipsjk256: hmm old article says the reclocking support is for NV50 hardware.
21:39 phillipsjk256: I was disappointed to learn that the PCI-E slots are dead on this board. I *did* pull the system it came from from the trash. The previous card *did* have vented caps which appeared to cause enough of a short to damage the power supply.
21:42 phillipsjk256: is there a way to prevent programs from messing up the display layout with RANDR? I like xinerama because I don't have to mess with video modes and monitor layouts (more than once).
22:55 imirkin: skeggsb: so... thoughts on how to properly do the vbios size stuff for OF?
22:56 skeggsb: imirkin: i'll take a look shortly
22:57 imirkin: skeggsb: ok cool. hopefully on live hw ;)
22:57 skeggsb: well, i was figuring i'd take a look, and tell you my thoughts - then you could fix it :P
22:57 skeggsb: but, either way haha
22:57 imirkin: that works too
23:02 imirkin: skeggsb: btw it looks like at least my OF bios has an incorrect signature... i wonder if we should ignore bad sigs on OF
23:04 airlied: imirkin: don't think it has any signature
23:05 skeggsb: yeah, i'd bet it's got none of the usual markers a pci rom does
23:05 skeggsb: so, basically, we probably need to just take whatever image the OF call gives us as gospel
23:11 airlied: esp since its only a very cutdown copy
23:13 imirkin: s/signature/checksum/ of course
23:13 imirkin: but yes, i agree with that approach
23:13 imirkin: the current state of affairs is that even if i fix it to read the of one properly, it'll still pick the PCIROM one which is apparently there and passes checksums
23:13 imirkin: [and obviously contains garbage]
23:14 skeggsb: it'd be nice to have some way to know to *not* use the OF ROM if there's some other random board plugged in...
23:15 mjg59: Does OF still offer it if there's another card?
23:15 skeggsb: mjg59: i have no idea tbh, i just kinda assumed it'd be hardcoded - maybe it's not?
23:16 imirkin: mjg59: OF is tied to a particular pci device...
23:16 imirkin: although if you plug something else into that pci slot, dunno what happens
23:16 mjg59: imirkin: I think the question is whether if you swap out the device it still provides the built-in image
23:16 mjg59: Yeah
23:17 imirkin: sadly i don't have any AGP boards to find out
23:17 mjg59: skeggsb: I'd just use the OF one and let benh complain if it breaks his :p
23:17 imirkin: [other than the one in the machine]
23:17 benh: you can plug anything in that slots :)
23:17 benh: yeah well
23:18 benh: on PCIe at least
23:18 benh: you can flip the cards around etc
23:18 imirkin: benh: is the OF vbios rom still there though?
23:18 benh: on AGP I suppose things are a bit diff.
23:18 benh: it's on the card itself
23:18 imirkin: or does it "know" that it's a different card, and thus doesn't supply it
23:18 imirkin: [or it's somewhere in the option rom in the first place]
23:18 benh: it's in the option rom
23:19 imirkin: ah interesting. so one could craft an option rom that the OF firmware would retrieve properties from and make them available to the OS?
23:19 benh: sure
23:20 imirkin: neat. so like ACPI, but done before it existed, and better.
23:20 benh: you can even have macos drivers in the option rom :)
23:20 benh: well, you could ... I don't know if that still works with x86 macos x
23:20 benh: that's how we did to feed macos with paravirt drivers for MOL
23:20 benh: (maconlinux)
23:20 benh: well, OF isn't kept alive at runtime, so unlike ACPI in a way
23:21 benh: ACPI provides runtime stuff
23:21 benh: in *theory* OF is meant to be kept alive but only Sun ever did that
23:21 benh: afaik
23:21 imirkin: ah yeah, that was always nice that you could open up OF anytime
23:22 imirkin: [not that it got too much use]
23:24 imirkin: benh: btw, could 2.25.1 be a bad binutils for ppc64?
23:25 benh: imirkin: fedora ?
23:25 benh: imirkin: I know csmart has been having weird problems with the latest builds from dhowells
23:25 imirkin: benh: no, gentoo. using 'crossdev'
23:25 benh: but I am not aware of a *specific* bug
23:26 imirkin: weird problems like... 'kernel doesn't boot at all'? :)
23:28 imirkin: with the (newer) kernels that did boot, i've been getting lots of hangs, with no console output
23:32 benh: no, it didn't even link iirc
23:32 benh: that's strange
23:32 benh: we must have broken something ... but what ? hrm...
23:33 benh: did you try without any GPU driver ?
23:33 benh: in case it's AGP issues ?
23:33 benh: AGP on apple chipsets is .... challenged