Hi all, I've been sitting on some AtomBIOS based simple power management code for a while. Since similar code has been deemed safe enough to push to radeon, I figure I'd do the same for radeonhd. The attached set of patches adds ForceLowPowerMode and LowPowerModeEngineClock options. Set them in the Device section of your xorg.conf as usual. * ForceLowPowerMode statically sets the engine clock at initiation time to a low value; defaults to (default_engine_clock / 2). * If the above value isn't what you want, or breaks, specify a clock value to use with LowPowerModeEngineClock. See Catalyst for the range of what's considered safe by the OEM. The wait-for-idle code for radeonhd is more fine grained and is not actually exposed in its entirety, so the current RHDSetEngineClock() and RHDSetMemoryClock() do not work reliably outside of init time. This is why DPMS-driven downclocking was not implemented. As always, play with clock values at your own discretion. Cheers, -- Yang Zhao http://yangman.ca
On Apr 17, 09 16:40:34 -0700, Yang Zhao wrote:
The wait-for-idle code for radeonhd is more fine grained and is not actually exposed in its entirety, so the current RHDSetEngineClock() and RHDSetMemoryClock() do not work reliably outside of init time. This is why DPMS-driven downclocking was not implemented.
What would you need to actually implement this correctly? I'm asking
because we would probably want to increase the frequencies to maximum if
3D is active (unless some special use case is found, like composition
managers).
Also, did you implement voltage regulation functions as well?
Thanks
Matthias
--
Matthias Hopf
2009/4/21 Matthias Hopf
On Apr 17, 09 16:40:34 -0700, Yang Zhao wrote:
The wait-for-idle code for radeonhd is more fine grained and is not actually exposed in its entirety, so the current RHDSetEngineClock() and RHDSetMemoryClock() do not work reliably outside of init time. This is why DPMS-driven downclocking was not implemented.
What would you need to actually implement this correctly? I'm asking because we would probably want to increase the frequencies to maximum if 3D is active (unless some special use case is found, like composition managers).
rhdAllIdle() is internalized to rhd_driver.c, so it needs to be exposed. The name is actually inaccurate now as idling the CS needs to be done through other functions. IIRC, there's also no modularized code for bringing the CRTCs up again after rhdAllIdle() shuts them down. The non-CS idling code needs to be refactored in general to be more accomodating as there wasn't a need to have it callable from outside rhd_driver.c before.
Also, did you implement voltage regulation functions as well?
No. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 21, 09 10:34:40 -0700, Yang Zhao wrote:
2009/4/21 Matthias Hopf
: On Apr 17, 09 16:40:34 -0700, Yang Zhao wrote:
The wait-for-idle code for radeonhd is more fine grained and is not actually exposed in its entirety, so the current RHDSetEngineClock() and RHDSetMemoryClock() do not work reliably outside of init time. This is why DPMS-driven downclocking was not implemented.
What would you need to actually implement this correctly? I'm asking because we would probably want to increase the frequencies to maximum if 3D is active (unless some special use case is found, like composition managers).
rhdAllIdle() is internalized to rhd_driver.c, so it needs to be exposed. The name is actually inaccurate now as idling the CS needs to be done through other functions. IIRC, there's also no modularized code for bringing the CRTCs up again after rhdAllIdle() shuts them down. The non-CS idling code needs to be refactored in general to be more accomodating as there wasn't a need to have it callable from outside rhd_driver.c before.
I've pushed your patches for now - we will need to work a little on
them, including the changes for the infrastructure you mentioned above,
but even right now it's better than nothing.
BTW - I don't think the options are documented in the man page yet, and
I assume that they would be a likely candidate for RandR properties -
once we're able to switch them on the fly ;-)
Thanks
Matthias
--
Matthias Hopf
Hi, I just thought I would report some numbers on how much power this saves me on my laptop's radeon HD 3100. It saves me 100 mA of current so thats about 1/3 of a Watt. Of course it doesn't sound like much but this is on a laptop that is by nature optimized for low power operations. I estimate this will extend my battery life at least 10 minutes. Thank you very much for this patch. -- Conn Conn O. Clark Observation: In formal computer science advances are made by standing on the shoulders of giants. Linux has proved that if there are enough of you, you can advance just as far by stepping on each others toes. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Conn Clark
-
Matthias Hopf
-
Yang Zhao