2009/5/18 Luc Verhaegen :

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 :)

How intrusive is setting the engine clock?

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.

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.

So my case no. 2 and patch "b": set.engine.clock.b.patch 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 Yang: do you/we still need that "empty" RHDGetEngineClock(...); calls?

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

-- Rafał Miłecki

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 ;) -- Rafał Miłecki -- 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

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. You can pull my xrandr code from http://yangman.ca/git/xf86-video-radeonhd/ branch randr-pm -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

W dniu 19 maja 2009 18:19 użytkownik Yang Zhao napisał:

2009/5/19 Yang Zhao :

...

2009/5/19 Rafał Miłecki :

...

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.

I was sure rhdRestore touches only well-known registers. Thanks for explaining. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org