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