Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28

Thread: Improved Memory Security For Radeon DRM

  1. #11
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    620

    Default

    Quote Originally Posted by bridgman View Post
    Here's the problem - additional power management support really needs to go in the kernel on top of KMS. The next real step in power management is dynamic adjustment of clocks and voltage, and that requires hooks into both modesetting and 2D/3D acceleration. The only place all that information comes together is in the kernel with KMS running, so that's where the power management code needs to go.

    It is certainly possible to build additional protocols to pass modesetting info from a userspace driver down to the kernel, but since KMS is already in progress none of the devs thing it's worth implementing a throw-away solution in userspace.
    I also realized this a few minutes after having written that post - so I guess both (KMS and better power management) will come soon

    thanks bridgman and of course also to the other devs working on this one



    Quote Originally Posted by bridgman View Post
    Are you already using ForceLowPowerMode and related options ?
    yes I am, I guess:

    Option "ForceLowPowerMode" "True"
    Option "DynamicPM" "True"
    Option "ClockGating" "True"
    should be enough ?

    I've read that dynamicclocks doesn't work on R600 or R700 or even leads to hardlocks so I've left that disabled ...

    kernel is 2.6.30 w. drm and radeon kernel-modules, driver is: xf86-video-ati and mesa (both latest from upstream)

    system: ~amd64 Gentoo

  2. #12
    Join Date
    Jan 2008
    Posts
    182

    Default

    Yeah, I'm happy to see power management go into the kernel, because that means it will be operating even if I boot up in text mode and never start the X server. (Which I do, quite often, because it still lets me get some work done faster...)

  3. #13
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    We may need to release some additional HW info in order to finish memory management (specifically interrupts), not sure but looking into it.

    It's probably safe to say "either 2.6.31 or 2.6.32" but hard to be more precise.
    Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.

  4. #14
    Join Date
    May 2008
    Location
    Germany/NRW
    Posts
    510

    Default

    Quote Originally Posted by kernelOfTruth View Post
    I've read that dynamicclocks doesn't work on R600 or R700 or even leads to hardlocks so I've left that disabled ...
    AFAIK ClockGating == DynamicClocks, it has just been renamed at some point to reflect more clearly what it does.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Quote Originally Posted by ssmaxss View Post
    Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.
    No ETA on the doc yet; I'm just checking status of patent applications.

    What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.

    Hardware enablement is always a bit different from other driver/kernel enhancements, since if it's done right the chance breaking existing functionality is essentially zero and the worst that would happen is that the code has problems on some of the new hardware - vs not working at all before. It's one of those "on the fence" cases we'll need to deal with more now that core graphics support is moving into the kernel just like all the other hardware.

  6. #16
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.
    So there is a chance that you can't release docs for interrupts due to some 3rdparty IP, and they are needed to make MM "nice" and OSS drivers end up with crippled MM?
    BTW: will we see Friday code drop for r6xx-rewrite today?

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Not third party patent applications, *our* patent applications

    It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.

    Richard tracked down the rendering problems with 6xx-rewrite last night to a problem in the new memory management code (in mesa, not in kernel); all we know right now is that if we bypass the memory manager the rest of the driver works.

    Next update will probably be when we find and fix the problem; might be today but I doubt it.

  8. #18
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    Not third party patent applications, *our* patent applications
    It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.
    Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?
    Good to know that r6xx-rewrite is moving forward . Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    Quote Originally Posted by ssmaxss View Post
    Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?
    We have already done that. The problem is that there are a number of different ways to use the hardware depending on which bits we can publicly expose first, so we need to get that sorted out before the devs can write anything more than prototype code.

    Quote Originally Posted by ssmaxss View Post
    Good to know that r6xx-rewrite is moving forward . Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?
    It's a core bug which should help in number of areas.
    Last edited by bridgman; 06-19-2009 at 12:21 PM.

  10. #20
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    620

    Default

    Quote Originally Posted by Zhick View Post
    AFAIK ClockGating == DynamicClocks, it has just been renamed at some point to reflect more clearly what it does.
    thanks !

    I just saw it in the logs:

    Static power management enable success
    (II) RADEON(0): Dynamic Clock Gating Enabled
    (II) RADEON(0): Dynamic Power Management Enabled
    (II) RADEON(0): Force Low Power Mode Enabled
    (II) RADEON(0): Power Mode Switch
    Dynamic Clock Gating == Dynamic Clocks (old) == ClockGating (new)

Posting Permissions

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