Comment 12 for bug 127252

(In reply to comment #11)
> Switching everything DRI to MMIO would be an awful lot of work, I don't think
> that's worth it. Originally, the radeon driver used to switch to MMIO on the fly
> for 2D, but that caused instabilities, so it was changed to use the CP
> exclusively when the DRI is enabled. This also allows accelerating more 2D
> operations and yields slightly better performance for some of the others.
>

O.K. I see. Instabilities are much worse than just a higher power consumption.
So, in this case I'd rather lower battery life than any system freezes...

> Even so, it might be possible to tweak the driver such that this issue can be
> avoided and power saving states entered when the X server is idle. But again,
> that requires knowing exactly what prevents that right now.

Would be great if this could be done.

However, there might be different interpretations about "being idle". I'm not
sure what Michael Kamper means in his comment 9, but in my case "idle" means:
KDE has started, some apps are running, e.g. Open Office. Maybe no scrolling,
but there is always some drawing, e.g. the blinking cursor, the clock on the
kicker app, etc.

Of course, one might think of the DPMS modes as potential hooks to allow the CPU
to enter c3, when the screen has been blanked (as Alex suggested). But I'm not
sure that the xserver is really idle in this case, either.

If it still would be possible to tweak the driver to avoid any "unnecessary" bus
mastering activity, then I will be happy to assist whereever I can, especially
with testing some patches (I don't have much experience with patching, but I
guess, I should be able to download, patch and compile the dri driver.)

Michael