On Mon, May 18, 2009 at 02:26:16PM +0200, Rafa?? Mi??ecki wrote:

Currently we set engine clock only on starting X. After suspend & resume card is reseted to default state (including engine clock) and clock is on max speed again.

I see two solutions for this situation:

1) On every RHDEnterVT(...) we should check if engine clock changed, and if it did, set it again. We shouldn't just set it on every RHDEnterVT(...) because simple switching to console and back doesn't change engine clock. It would be great to "just know" if RHDEnterVT(...) was called after console switching or after resuming, but AFAIK we don't know it. 2) Set engine clock on every RHDEnterVT(...) and restore default speed on every RHDLeaveVT(...)

Second solution is probably nicer/cleaner. We keep engine clock in default state after switching from X, but do we actually want/need it?

Please comment, discuss :)

-- Rafa?? Mi??ecki

How intrusive is setting the engine clock? Whatever happens, when leaving the VT we must restore the original clock. There is absolutely no way around this, except when this ends up leaving the vt garbled (which is usually because of a lack of information or a lack of rather lengthy debugging on actual hw). Now, since we have to restore the original clock upon leaving the VT anyway, we also have to set the engine clock upon entering VT again. Just like everything else registerwise happens just the same with ScreenInit as with EnterVT, engine clock setting should happen this way as well and i would be amazed if this wasn't already happening like that. Luc Verhaegen. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On May 18, 09 15:02:50 +0200, Rafał Miłecki wrote:

Do you mean if changing it affects something? Don't really know that. I'm sure too low value will cause screen corruptions. In my case minimal value without corruptions is 168750Hz.

Actually, too low engine clocks can lock up the PCI bus... Been there, done that :-P

I'm afraid we currently don't restore engine clock on leaving VT (somehow, it doesn't cause any problems for me). With attached patch applied I get following output: (II) RADEONHD(0): Just leaved VT, engine clock is at 168750Hz, default is 680000Hz

Weird. We certainly should restore them. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/5/18 Rafał Miłecki :

2009/5/18 Luc Verhaegen :

...

On Mon, May 18, 2009 at 02:26:16PM +0200, Rafa?? Mi??ecki wrote: Whatever happens, when leaving the VT we must restore the original clock. There is absolutely no way around this, except when this ends up leaving the vt garbled (which is usually because of a lack of information or a lack of rather lengthy debugging on actual hw).

Now, since we have to restore the original clock upon leaving the VT anyway, we also have to set the engine clock upon entering VT again. Just like everything else registerwise happens just the same with ScreenInit as with EnterVT, engine clock setting should happen this way as well and i would be amazed if this wasn't already happening like that. ... I'm afraid we currently don't restore engine clock on leaving VT (somehow, it doesn't cause any problems for me). With attached patch applied I get following output: (II) RADEONHD(0): Just leaved VT, engine clock is at 168750Hz, default is 680000Hz

EngineClock seems to stay put after suspend/resume cycles, at least according to AtomBIOS. I have code that exposes engine and memory clock as output properties to xrandr. I *think* it's the register save/restore that's effectively doing the same thing. Not sure if this is different on a non-r7xx, though.

Yang: do you/we still need that "empty" RHDGetEngineClock(...); calls?

...

            /* Induce logging of new engine clock */             RHDGetEngineClock(rhdPtr);

That causes the new clock to be printed in the log, as per the comment. Return values from AtomBIOS calls are logged automatically, so this was just a cheap way to do it. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On May 18, 09 18:24:59 +0200, Rafał Miłecki wrote:

W dniu 18 maja 2009 18:06 użytkownik Matthias Hopf napisał:

...

...

I'm afraid we currently don't restore engine clock on leaving VT (somehow, it doesn't cause any problems for me). With attached patch applied I get following output: (II) RADEONHD(0): Just leaved VT, engine clock is at 168750Hz, default is 680000Hz

Weird. We certainly should restore them.

WIP locally, please don't take away that job from me ;)

Nope :) Thanks Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/5/19 Yang Zhao :

2009/5/19 Rafał Miłecki :

...

1) Switched to VT1, then VT7, then grep-ped Xorg.0.log (II) RADEONHD(0): Just entered VT, clock is now at 168750Hz

2) Switched to VT1, then VT7, then grep-ped Xorg.0.log (II) RADEONHD(0): Just entered VT, clock is now at 168750Hz

3) Switched to VT1, then VT7, then grep-ped Xorg.0.log (II) RADEONHD(0): Just entered VT, clock is now at 168750Hz

4) s2ram (for my machine it uses -p -m), then grep-ped Xorg.0.log (II) RADEONHD(0): Just entered VT, clock is now at 675000Hz

5) Switched to VT1, then VT7, then grep-ped Xorg.0.log (II) RADEONHD(0): Just entered VT, clock is now at 675000Hz

It's actually weird for me that you don't lose engine clock on suspend&resume. While machine is in suspend mode, only RAM should be powered, right? That would mean GPU doesn't get power and all registers are resetted to default values. Maybe suspending on your machine is broken? Maybe your GPU is still powered?

The kernel causes a VT switch to happen on suspend.

Ugh, that didn't answer your question at all. Sorry, I *just* got up. On LeaveVT, the driver takes a snapshot of certain ranges of registers which are restored on EnterVT; look at rhdSave() and rhdLoad(), respectively. The PLL-related registers are what controls the clocks, IIRC. Cheers, -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/5/18 Yang Zhao :

EngineClock seems to stay put after suspend/resume cycles, at least according to AtomBIOS. I have code that exposes engine and memory clock as output properties to xrandr. I *think* it's the register save/restore that's effectively doing the same thing. Not sure if this is different on a non-r7xx, though.

FYI, turns out I'm completely wrong here. Made an incorrect assumption about how RandR's getProperty works in 1.2, which was skewing with the numbers I was seeing. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org