robbat2: agd5f, airlied: I played with the registers as described in http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=95b492155ff380c74d6f1c5335512d0afb06de3a and only managed to hang my G5
robbat2: but I suspect a bug in them, that i'm working at still
mcgreg: olegfink: look at phoronix ... it's almost like somebody stole your idea ;)
robbat2: egbert, if you're around at some point, I've got a question about one of your commits. http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=95b492155ff380c74d6f1c5335512d0afb06de3a
egbert: robbat2: what's the question?
robbat2: the r500 stuff that is commented out by #ifdef NOTYET
robbat2: mainly where did you get it?
egbert: yes, it only works for the rv580 so far. i still need to look at the others.
egbert: robbat2: poke around.
robbat2: err, it doesn't work on my G5
robbat2: it totally locks the box
egbert: which chipset?
robbat2: X1900 Mac edition
robbat2: one sec, i'll give you the PCI id
robbat2: R580 [Radeon X1900] [1002:7240]
egbert: yeah, its an r580.
egbert: yeah, it may differ from card to card. i don't know, yet how to deal with this. therefore it's disabled.
libv: *cough* -> radeonhd ?
robbat2: also, reading it, you test SPLL_CHG_STATUS (and SPLL_BYPASS_EN) against CLOCK_CNTL_DATA, but the M56 docs shows those as parts of the SPLL_FUNC_CNTL register
egbert: especially the first bit is in the range of gpio registers.
robbat2: libv, it's relevant to all the drivers, because all of them need the bios for various things
robbat2: and esp. important if you followed my previous stuff on PPC, where the sysfs rom node seems to act weirdly
egbert: robbat2: i still don't have a solution for all r5xx.
robbat2: can you suggest some registers I should try myself?
egbert: robbat2: yeah, sysfs rom seems to have problems, too.
libv: robbat2: it still is the radeonhd driver
egbert: i've been poking ati for weeks and weeks to get info on how to read the rom. nothing. so i poked myself. r6xx seems to be ok. r5xx - not so good.
robbat2: libv, and similar code needs to go into the radeon driver (which is my personal preference), so asking the people that know is important regardless
robbat2: it's not like there is a lot of other noise in this channel
libv: robbat2: still.
robbat2: egbert, thanks anyway. i'll poke blindly at more registers and see
robbat2: all motivated by the search to find if the mac edition even has an AtomBIOS
agd5f: tilman: reveting 5d792b5673bbf4784eb0ec059221e9b57232a122 should fix r4xx on the atom branch. I should have it fixed soon
airlied: agd5f: oops.. I wonder try moving the init/restore inside IS_AVIVO_VARIANT in atombios_crtc_mode_set perhaps
agd5f: airlied: that path isn't called on legacy radeons
airlied: agd5f: I see a bug gimme a sec to see if helps.
agd5f: airlied: I think it's adjustmemmapregs()
agd5f: but I haven't had a chance to test it yet
airlied: agd5f: okay I've pushed an obviously broken thing but it may not affect it
mcgreg: agd5f: if you have added any code/changed for tv-out, could you please let me know then? (whenever that is)
agd5f: mcgreg: sure
agd5f: airlied: that seemed to do the trick
airlied: agd5f: excellent.. silly code path.. the only reason I added the flags was for it then I didn't fix it :-)
dli_: airlied, another dump diff, yesterday, I didn't realize I had an old pll patch applied for radeon, http://pastebin.ca/799625
airlied: dli_: is this the lateest radeon code clean?
glisse: agd5f, airlied: quick question you still need to program pll by your self with atombios ? :)
airlied: glisse: you needs to calculate it
airlied: glisse: then give the values to the bios to program.
glisse: btw cleaning up to use amd header file is quite painfull i hope i will finish that by this weekend and then push code publicly
dli_: airlied, yes, I just pulled in the git source and built
dli_: airlied, the screen looks like radeonhd with incorrect pll setting, but indeed, the settings are the same as radeonhd
airlied: dli_: yes the ppl is getting "deprogrammed" by something..
dli_: airlied, egbert has locate my slow radeonhd problem, so radeonhd runs as fast as avivo now. I will check whether radeon could be still faster
airlied: dli_: yeah mtrrs are kinda useful..
glisse: it was mtrr ?
dli_: glisse, yes, mtrr was off in xorg.conf (because fglrx howto says mtrr should be disabled)
glisse: airlied: btw for modesetting i guess i should look into that too ?
glisse: ie mtrr
airlied: glisse: what? the drm does mtrr already.. :)
dli_: glisse, so, radeonhd honors the mtrr config, and mtrr turned off
airlied: glisse: we hopefully will grow PAT support.
glisse: airlied: drm does it for us ? when asking for map ?
glisse: didn't know
airlied: glisse: yes it does it for the framebuffer map
airlied: glisse: but really mtrr is loss we need PAT..
glisse: PAT isn't available everywhere right ?
ajax: glisse: every 686 chip.
ajax: starting with the ppro
airlied: yah its busted on some of the earlier ones..
glisse: oh didn't think this was that old
ajax: it's _ancient_
ajax: we're just shit
glisse: ajax: come one we just are too busy watching glxgears
airlied: glisse: we need PAT for radeon pci gart ttm..
airlied: glisse: as otherwise we'll be slow as shit..
airlied: in fact we could do with PAT now for pci gart..
glisse: for flushing things i suppose
airlied: wonders if that is why radeon pci gart is so shit
airlied: glisse: no for speed..
ajax: airlied: could be!
airlied: ajax: I never thought about it before.. it explains a lot
airlied: as with AGP we mtrr the aperture and access everything via it
airlied: but with PCI there is no aperture and we just get uncached pages..
airlied: perrhaps there is life in my 7000 PCI card yet..
osiris_: what does PAT stand for?
glisse: osiris_: i guess it's Page Access Table
ajax: page attribute table
kdekorte: Has there been any progress with r500 and Laptop panels? Is it worth me retesting?
airlied: kdekorte: probably not..
airlied: kdekorte: do you know when you last tested it? like it mightn't be any harm in testing it again :-)
kdekorte: yesterday is when I last tried it
kdekorte: Xorg log is here http://dekorte.homeip.net/ati/Xorg.radeon
airlied: kdekorte: thanks nothing changed since then.. it looks like the pll value are getting deprogrammed by something else in the code.. need to take a closer look..
kdekorte: I have 3 different ati chipsets, r200, r300 and r500 so I have lots to test with
airlied: kdekorte: cool.. I have 11 different chipsets ATI chips herre I think :)
Magnade: airlied: which chipset do you like the most?
airlied: kdekorte: I have an equal share of hatred spread across all of them :-)
mcgreg: I've once had a radeon 7000, 7500, 8500 and 9200 .. now x1300
kdekorte: airlead, I feel your pain
airlied: kdekorte: I also have 4 nvidia cards, and 5 intel chipsets
airlied: kdekorte: so my main machine I sit in front off are intel and nvidia cards..
airlied: kdekorte: less chance I'll screw them up by "fixing" the ATI driver :)
kdekorte: I have a question... r300 chipset, drm from git, ati from git, when I enable my external monitor and disable my panel, the mouse disappears... going to console and back brings the mouse back... any ideas?
airlied: kdekorte: wierd.. I've never tried disabling the panel.. sounds like a randr 1.2 interaction problem.
airlied: kdekorte: have a look at xrandr --verbose before and after vt switch for differences maybe..
kdekorte: I have a small script that I run when I have my laptop at my desk...
kdekorte: xrandr --output LVDS --auto
kdekorte: xrandr --output VGA-0 --auto
kdekorte: xrandr --output VGA-0 --mode 1680x1050
kdekorte: xrandr --output LVDS --off
kdekorte: wonder if it is some type of HW mouse issue with it still being on the LVDS
agd5f: kdekorte: I wonder if it's something with the randr mouse handling in the server
airlied: agd5f: I don't suppose you have a crappy AGP chipset machine? (like a via os sis?)
agd5f: kdekorte: add some debugging messages to radeon_cursor.c and trace the cursor enable/disable
agd5f: airlied: yes
airlied: agd5f: I'm wondering if we regressed agp at some point.. I'm seeing more broken agp bugs than before.
agd5f: I'll have to dig it out though
airlied: my intel chipset seems fine.. but I'm finding it hard to blame the bugs since 6.6.3 mostly worked.
agd5f: all my current AGP boards are intel
agd5f: the via one is in a closet somewhere
airlied: agd5f: yeah I only have intel ones as well..
Magnade: playing with radeontool on a radeon 9200 and set stretch to auto or manual and the display looses signal setting it back to off or switching to console returns display
agd5f: I'll see if I can revive it later in the week
Magnade: could this happen to have something todo with the issue i see at first load of x with loosing signal?
agd5f: Magnade: what output?
agd5f: Magnade: rmx depending on some additional state in some cases
agd5f: using radeontool to mess with it is not ideal
Magnade: just tinkering trying to narrow down the inital load issue
Magnade: rather annoying to have to switch to console every power up to just see hwat your doing in x
agd5f: Magnade: you're the one with the mac mini?
agd5f: try commenting out RADEONRestoreDVOChip(pScrn, output); in radeon_mode_set() in radeon_output.c
agd5f: we don't know what tmds chip is in there and we may be touching it wrong
Magnade: aye ppc mini
Magnade: i got regs for when its displaying right and not you want me to attach that to the bug report?
Magnade: ill be back in a while got something to do first
agd5f: Magnade: please do
tormod: hi, are test reports/logs from trying atombios branch on an X700 (M26) of interest? leaves me with a black (off) screen
airlied: tormod: update to latest and try again... I screwed up..
airlied: tormod: if its still screwed up we care as it shouldn't regress legacy cards..
tormod: airlied: thanks, I'll try again :)
tormod: pardon my gitnorance, but why doesn't git pull work when I'm on the branch
airlied: tormod: what git version?
tormod: git version 22.214.171.124
airlied: so you did git checkout -b
airlied: and then git pull?
tormod: git checkout: branch atombios-support already exists
tormod: after git-checkout atombios-support I get Already on branch "atombios-support", ok
tormod: then git pull says "branch.atombios-support.merge" does not match any remote branch fetched.
airlied: tormod: wierd.. not really sure whats going on do you have an atombios-support branch in .git/config
tormod: no I haven't. Guess I'll start from scratch again...
airlied: so git clone, then do a git checkout -b atombios-support origin/atombios-support
airlied: and it should work from there on
tormod: thanks I did that. just for fun(?) if I then try git pull it says "no changes" as expected, but adds the same warning.
airlied: tormod: okay go back to maste, git branch -d atombios-support
airlied: tormod: then do git branch --track atombios-support origin/atombios-support
airlied: tormod: then git checkout atombios-support..
airlied: tormod: I think git 1.5.3 fixes this.
tormod: airlied: thanks, I'll try once the build is done.
tormod: I had to use -D. It seems to work, thanks.
tormod: would it be sufficient to try the driver on another tty (while keeping this session) or is that not a good enough test?
tormod: I guess I won't get for instance DRI on a second server, but apart from that?
airlied: tormod: I dislike doing that but it might work..
tormod: airlied: I'll do a full test before going to bed, now just a smoketest while I have the session running (yes I know I should use irssi or something)
tormod: lazy smoketest went bad: I got the melting screen / northern light effect
ScislaC: I just wanted to drop in an say I tried the -ati driver (I guess the AtomBios branch), and it worked nicely on my Mobility X1400 :)
damentz: hey airlied
damentz: will the r100/200/300 be optimized as amd releases more specs?
tormod: tried atombios-support (as only server), same "northern lights": http://nopaste.org/p/amxfO1sF8
damentz: tormod: how come you have like 10 different driver entries?
rx__: i don't think anyone is dropping support for r100/200/300 if that's what you're asking
airlied: damentz: maybe we already know how they work though..
tormod: damentz: what do you mean?
airlied: damentz: so there might be stability fixes more than perf enhacements..
damentz: airlied: well they are about half as fast as fglrx could be if amd released a legacy driver
airlied: damentz: yes but most users don't care about that stuff for standard things.. game players can be an exeception..
airlied: damentz: we aren't going to ever have the manpower to do targetted optimuisation..
damentz: happens to be one of those "game players"
airlied: damentz: like ATI surely have a team of > 50 ppl doing that stuff..
tormod: damentz: oh gotcha, I am running without xorg.conf so this is just made up by the server
airlied: just that stuff.
damentz: i was just curious, my laptop is some old compaq series with a radeon 7500 mobile
damentz: it can still play stuff like guildwars
damentz: its insane
damentz: tormod: ah, i see
airlied: damentz: the 7500 is probably as fast as it might get, though it might grow some more 3D featuers..
airlied: if we ever get the memory manger stuff sorted out ..
damentz: will exa improve performance generally?
damentz: when open source drivers adopt it?
damentz: as the default driver thing
damentz: oh btw if anyone asks, using exa + compiz fusion fixes slow 2d drawings
damentz: xaa + compiz fusion causes slow 2d rendering
airlied: damentz: we need new memory manager to get the best out of EXA really..
rx__: airlied; if i want to look through the vt switching bug.. it's just all the regs touched by EnterVT right?
damentz: airlied: maybe the guys making hte radeonhd driver could help?
tormod: by curiousity, what is causing the "northern light" on my LCD? Are the outputs disconnected but not disabled or something?
damentz: tormod: whats a northern light?
daniels: damentz: lcd blooming
damentz: oh that
airlied: tormod: lcd lacks power.. backlight still on..
daniels: tormod: backlight enabled, but pixels aren't being driven, so they're in a random state
tormod: damentz: the screen goes black then fades in white and some other colours
airlied: rx__: pretty much diff normal text mode and post text mode..
airlied: rx__: those log files..
damentz: tormod: ah that happens to me
airlied: rx__: the LVDS pll changes are what are screwing you up I think..
Magnade: bugger no wonder i think my system acts a bit slow did a gtkperf test as root and as user and root is 2x quicker for some reason :\
damentz: on my laptop, i have to press the power button for the lcd that is used when you close the laptop's lid
airlied: damentz: they are concetrating on modesetting so far..
damentz: modesetting is resolution/refresh rate stuff right?
tormod: daniels: so that's output disconnected from crtc? but backlight on for some reason?
airlied: damentz: yes just turning on outputs etc.. they haven't done any work yet on acceleration...
damentz: airlied: so its practically just as powerful as vesa?
daniels: tormod: pretty much, yes