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