Open ATI Driver To Receive PowerPlay Push?

[Loris]

Are you really getting such great improvement? I thought that the current state of the patches was basically providing the infrastructure, but that the actual decrease in clock frequency was minimal?

Anyway, the patches don't apply here on a vanilla kernel. Are they meant for a git checkout or am I doing something wrong?

GPU: Mobility Radeon 3470 (that's an RV620)
Notebook: Sony Vaio SR21M

With FGLRX I never had heat-related problems (32-33 degrees, don't remember exactly), but previously with the radeon open source DDX and DRM module it quickly went up as high as 46 degrees just a few minutes after boot, then 48 and 50 degrees. I wanted to test the development of the driver, so I always damned hell and all its demons in removing FGLRX, then really removing all of it, compiling new linux kernel, applying patches, then DDX, mesa... I was thinking I just was irreparably mad at testing the development of the driver on a notebook.
Then the gods, erh... the developers, wrote the code for the ForceLowPowerMode and DynamicPMOrSomething options for the DDX, and I was all hip and cool trying that in UMS. KMS was just heaven at the time.
Then these patches hath descended from the heavens, and now I can write on my notebook without burning it and my wrists to ashes. All while using KMS, and all that comes thereafter. Writing in a Firefox window, with a LAMP stack running in the background, I'm currently experiencing 37 celsius degrees.

Thank you all.

[obino]

I do have a decrease of 4-5 degree (C) which on my laptop is a difference between a noisy fan and just a blowing fan. I'm surely hoping for more once everything is in place (I tried long time ago fglrx and I think it did better than this) but this is a good start for my HD3200.

[pingufunkybeat]

Are you really getting such great improvement? I thought that the current state of the patches was basically providing the infrastructure, but that the actual decrease in clock frequency was minimal?

Anyway, the patches don't apply here on a vanilla kernel. Are they meant for a git checkout or am I doing something wrong?

[Loris]

Thank you: indeed they all applied and now my laptop is usable with KMS (it runs too hot wihtout power saving).

Great
I was surprised by how well these new patches keep the beast from overheating my notebook. A big thank you to all the devs, and gods and geniuses who are working on the open source drivers. Really.

I was wondering... are you using an rc3 or rc4 tarball of linux, or an updated git version? Did you apply 0001-drm-radeon-kms-use-wait-queue-events-for-VBLANK-sync.patch (another patch, different from the one you jumped before)?

Thank you.

[obino]

Thank you: indeed they all applied and now my laptop is usable with KMS (it runs too hot wihtout power saving).

[Loris]

these patches didn't apply to 2.6.33-rc2 and -rc3: is there a version which would work?

Don't apply

0001-drm-radeon-kms-add-definitions-for-v4-power-tables.patch

in 2.6.33, as I think this one already got in.

The other patches should apply correctly.

[obino]

The UMS drivers have basic support for lowering the engine clock and PCIE lanes either statically, or dynamically during DPMS on/off. The current KMS patches are here:
http://people.freedesktop.org/~agd5f/pm/
All radeons should be supported.

these patches didn't apply to 2.6.33-rc2 and -rc3: is there a version which would work?

[pvtcupcakes]

I always thought the DRM modules consisted of a generic drm module plus a specific radeon module (or nouveau-something, or intel-whatever, ...).

I've never seen a KMS driver, but a radeon drm module with KMS enabled.

But that's just me.

I mean the KMS option that's in the staging drivers. If these patches affect that code, I don't see any reason why Linus would try to stop those from being merged. That's the whole point of staging.

If it gets in now, it can be tested by a lot more people, so when .34 rolls around KMS could be ready to get out of staging.

But the radeon DRM module isn't in staging, so if it affects that, then I can see why it wouldn't be merged now.

[Loris]

Would the patches apply to the DRM module or the KMS driver? If it's the KMS driver, I thought you could add all the features you want in staging.

I always thought the DRM modules consisted of a generic drm module plus a specific radeon module (or nouveau-something, or intel-whatever, ...).

I've never seen a KMS driver, but a radeon drm module with KMS enabled.

But that's just me.

[piete]

Then you want to switch to testing or unstable, which are both rolling releases. Unstable is debian's version of bleeding edge, it's still horridly out of date compared to say Gentoo, but that is where stuff goes first for Debian. After 10 days if a package passes certain tests (like not having any new bugs) the package gets copied to testing, so things are a bit safer there and only a little more outdated.

I run Squeeze on my laptop, which is the current testing. Though I've got a self-built radeon stack from git code in there too. If you want a usable desktop rather than one that is years out of date I'd suggest switching to Squeeze.

Squeeze's fglrx version is already too new for my X1600 card. I'm perfectly happy with Lenny, I don't need the newest stuff and if I needed, I can always compile them (I know, I'd have to compile all the dependencies too...)

When I have more free time AND a faster internet, I may think about the "bleeding edge" again, but I'm sure I'm not alone settling with an "outdated" but stable system. I still like to read about the new stuff, though.