Page 4 of 18 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 180

Thread: More Radeon Power Management Improvements

  1. #31
    Join Date
    Jul 2009
    Posts
    82

    Default

    Quote Originally Posted by cklein View Post
    Hi,

    I just compiled a fresh Linux kernel on top of Ubuntu 10.04 from commit id 7a1ffce50373c177d3f6eecce52badc40c90e1dd from drm-radeon-next. When running on a ATI Radeon Mobility HD2400, I am experiencing some issues:
    1. The screen flickers while PM state changes.
    2. The GPU does not upclock.
    3. The system locks up.


    My dmesg shows messages like "[drm] GUI not idle!!!" and "not in vbl on entry / exit".

    Is there any way I could help debugging?
    You should actually _think_ a bit before compiling anything. The last commit in drm-radeon-next was done 3 (three!) month ago...

  2. #32
    Join Date
    Jul 2009
    Posts
    82

    Default

    @agd5f: Hey Alex, is the new power_state sysfs attribute supposed to work like that? You only seem to be able to select power state WITH clock entry, and not just the power state and letting the driver do dynamic pm with the clock entries of the state.

    What about allowing echoing just "x" (without the ".y") part into power_state, selecting the state?

  3. #33
    Join Date
    Jul 2009
    Posts
    82

    Default

    @cklein: Nevermind, since you obviously mean drm-radeon-testing (drm-radeon-next doesn't have a commit with hash 7a1ffce50373c177d3f6eecce52badc40c90e1dd)

  4. #34
    Join Date
    Nov 2009
    Posts
    45

    Default

    Quote Originally Posted by agd5f View Post
    The gui idle interrupt can be re-enabled for r6xx+; it works fine on those chips. Just older ones seem to be problematic. I just disabled it for testing on everything for testing. We should just switch to waiting on a fence. That will work on all asics.
    Could I get a patch for the r6xx? Or should I wait for a proper solution involinv the fence? If so, when could we expect it in drm-radeon-testing?

    The driver is supposed to switch to an appropriate power mode depending on the number of monitors attached, but there are likely still bugs in that area.
    It doesn't work for me. Regardless of plugging in VGA or HDMI cables, I'm still stuck with power state 1.0, which is for "single monitor" only. Might this be related to using vga_switcheroo somehow?

  5. #35
    Join Date
    Nov 2009
    Posts
    45

    Default

    Quote Originally Posted by LiquidAcid View Post
    @agd5f: Hey Alex, is the new power_state sysfs attribute supposed to work like that? You only seem to be able to select power state WITH clock entry, and not just the power state and letting the driver do dynamic pm with the clock entries of the state.

    What about allowing echoing just "x" (without the ".y") part into power_state, selecting the state?
    LOL... and I wondered what the .0 meant It seems I always switched manually to level 0 Thanks for the tip.

    Either way, being able to set only the power state for dynamic power level choosing, would be great!

  6. #36
    Join Date
    Jul 2009
    Posts
    82

    Default

    I was actually wondering why this was changed, since the pm2 patchset (see the drm-radeon-testing-pm2 branch) had two sysfs attributes for that (power_state and clock_mode) and only writing something to clock_mode disabled the dynamic pm. Or at least that's how I understood the code...

  7. #37
    Join Date
    Dec 2007
    Posts
    2,326

    Default

    For now we just want to get the code stable; for that we need a way to force a static state and to switch dynamically. Later we can decide on dynamic policy.

  8. #38
    Join Date
    Nov 2009
    Posts
    45

    Default

    Sounds reasonable. Any chances of having these patches included in 2.6.35?

    Also, some time ago I've heard that there was work on GPU freq governors a'la CPU governors. Will we get automatic policies like: conservative, on demand etc?

  9. #39
    Join Date
    Aug 2009
    Posts
    122

    Default

    looks like flickering is caused by memory reclocking

    when i go (manualy) 3.0 to 3.2 - no flickers

    [ 0.492679] [drm] State 1 Performance
    [ 0.492679] [drm] 16 PCIE Lanes
    [ 0.492680] [drm] Single display only
    [ 0.492681] [drm] 3 Clock Mode(s)
    [ 0.492682] [drm] 0 engine/memory: 500000/750000
    [ 0.492683] [drm] 1 engine/memory: 500000/750000
    [ 0.492684] [drm] 2 engine/memory: 625000/993000
    [ 0.492685] [drm] State 2
    [ 0.492686] [drm] 16 PCIE Lanes
    [ 0.492687] [drm] 3 Clock Mode(s)
    [ 0.492688] [drm] 0 engine/memory: 625000/993000
    [ 0.492689] [drm] 1 engine/memory: 625000/993000
    [ 0.492690] [drm] 2 engine/memory: 625000/993000
    [ 0.492691] [drm] State 3 Performance
    [ 0.492692] [drm] 16 PCIE Lanes
    [ 0.492693] [drm] 3 Clock Mode(s)
    [ 0.492694] [drm] 0 engine/memory: 500000/993000
    [ 0.492695] [drm] 1 engine/memory: 500000/993000
    [ 0.492696] [drm] 2 engine/memory: 625000/993000

  10. #40
    Join Date
    Aug 2009
    Posts
    122

    Default

    maybe there is a way to force it to use State 3 ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •