Announcement

Collapse
No announcement yet.

More ATI Radeon KMS Power Management Fun

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • More ATI Radeon KMS Power Management Fun

    Phoronix: More ATI Radeon KMS Power Management Fun

    Power management support within the Linux kernel for the ATI Radeon DRM driver has been in development for months and gone through several revisions, but with the forthcoming Linux 2.6.34 kernel there is initial ATI KMS power management support. For making the power management situation even better, over the weekend Alex Deucher of AMD has been working on another set of patches...

    http://www.phoronix.com/vr.php?view=ODA2Mw

  • #2
    Linux Power Management

    How does it hook on Linux power management? Again, a super huge kernel abstraction kludge?

    I thought that from R700, power/fan management is done throught the ATOM bios tables/byte cdoe???

    Comment


    • #3
      To enable the power management code, just pass dynpm=1 as a module parameter when you load radeon. The ATOM tables are used for changing the clocks and eventually the voltage, but the algorithms for when to change power modes has to be implemented in the driver. Also, fan control and temperature monitoring is not available via ATOM, the bios just sets up the initial state. For driver control, you need to actually write the code and wire it up to some interface like hwmon.

      Right now the power management is all internal to the driver. there are no knobs exposed to userspace.

      Comment


      • #4
        ATOM fan control and temperature monitoring

        Originally posted by agd5f View Post
        To enable the power management code, just pass dynpm=1 as a module parameter when you load radeon. The ATOM tables are used for changing the clocks and eventually the voltage, but the algorithms for when to change power modes has to be implemented in the driver.
        You means that is not coupled properly with Linux power management internals? If you are still going the DRM kernel abstraction kludge, I bet power management abstraction code will be... well.. you guessed... (something like perl5's code... )

        Originally posted by agd5f View Post
        Also, fan control and temperature monitoring is not available via ATOM, the bios just sets up the initial state. For driver control, you need to actually write the code and wire it up to some interface like hwmon.
        Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.

        Comment


        • #5
          How would one go and use this with kernel 2.6.33?

          Comment


          • #6
            Originally posted by sylware View Post
            You means that is not coupled properly with Linux power management internals? If you are still going the DRM kernel abstraction kludge, I bet power management abstraction code will be... well.. you guessed... (something like perl5's code... )
            What Linux power management internals are you referring to? CPU governors are not a good fit for GPUs. The thermal monitoring and fan control chips could be hooked into the hwmon interface, but support for that isn't written yet. Plus, the hwmon stuff really only exposes knobs to userspace. Last I checked, it didn't really provide an interface for other kernel internals (like the drm) to use the data.

            What are you referring to as the drm "kludge"? Currently the driver changes the power state on the fly based on the GPU load and display conditions which only the driver is capable of knowing. How is this a kludge?

            Originally posted by sylware View Post
            Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.
            Nope. There are not any atom command tables to do this. There are command tables for changing the clocks and setting up the initial thermal profile, perhaps that is what you were thinking of.

            Comment


            • #7
              Originally posted by sylware View Post
              Hu? Need to backlog on radeon IRC channel. I remember bridgman telling me that from R7xx fan control and temperature monitoring is available through ATOM bios methods.
              Are you sure ? I remember saying that the information was in AtomBIOS (data tables describing the hardware and how it is connected/accessed) but don't remember saying it was accessed through methods aka command tables.

              Comment


              • #8
                Originally posted by agd5f
                What Linux power management internals are you referring to?
                In pm.h:
                Code:
                struct dev_pm_ops {
                  int (*prepare)(struct device *dev);
                  void (*complete)(struct device *dev);
                  int (*suspend)(struct device *dev);
                  int (*resume)(struct device *dev);
                  int (*freeze)(struct device *dev);
                  int (*thaw)(struct device *dev);
                  int (*poweroff)(struct device *dev);
                  int (*restore)(struct device *dev);
                  int (*suspend_noirq)(struct device *dev);
                  int (*resume_noirq)(struct device *dev);
                  int (*freeze_noirq)(struct device *dev);
                  int (*thaw_noirq)(struct device *dev);
                  int (*poweroff_noirq)(struct device *dev);
                  int (*restore_noirq)(struct device *dev);
                  int (*runtime_suspend)(struct device *dev);
                  int (*runtime_resume)(struct device *dev);
                  int (*runtime_idle)(struct device *dev);
                };
                And of course the /sys user space nobs.

                Abstracting all that for:
                - Windows
                - MacOSX
                - *BSD
                - Linux
                will very probably end up as a kludge (common sense).
                Originally posted by agd5f
                ...and setting up the initial thermal profile...
                In my mind, settings up thermal profile means ATOM is able to setup power states and fan speed, doesn't it?
                Originally posted by bridgman
                Are you sure ? I remember saying that the information was in AtomBIOS (data tables describing the hardware and how it is connected/accessed) but don't remember saying it was accessed through methods aka command tables.
                Well, as far as I can remember, I think I understood it that way.

                Comment


                • #9
                  Originally posted by sylware View Post
                  In pm.h:
                  Code:
                  struct dev_pm_ops {
                    int (*prepare)(struct device *dev);
                    void (*complete)(struct device *dev);
                    int (*suspend)(struct device *dev);
                    int (*resume)(struct device *dev);
                    int (*freeze)(struct device *dev);
                    int (*thaw)(struct device *dev);
                    int (*poweroff)(struct device *dev);
                    int (*restore)(struct device *dev);
                    int (*suspend_noirq)(struct device *dev);
                    int (*resume_noirq)(struct device *dev);
                    int (*freeze_noirq)(struct device *dev);
                    int (*thaw_noirq)(struct device *dev);
                    int (*poweroff_noirq)(struct device *dev);
                    int (*restore_noirq)(struct device *dev);
                    int (*runtime_suspend)(struct device *dev);
                    int (*runtime_resume)(struct device *dev);
                    int (*runtime_idle)(struct device *dev);
                  };
                  And of course the /sys user space nobs.

                  Abstracting all that for:
                  - Windows
                  - MacOSX
                  - *BSD
                  - Linux
                  will very probably end up as a kludge (common sense).
                  The drm already hooks in suspend and resume functions which are mainly what those are for. There aren't any common dynamic power management interfaces as far as I know because it tends to be device, or at least subsystem specific (i.e., USB power saving stuff). Perhaps we could implement some common drm dynamic pm functionality once some other drm drivers add similar features.

                  Originally posted by sylware View Post
                  In my mind, settings up thermal profile means ATOM is able to setup power states and fan speed, doesn't it?
                  It loads the profile as part of asic init, however, there are no tables to query the temp or fan speed. Those need to be implemented by the driver.

                  Originally posted by sylware View Post
                  Well, as far as I can remember, I think I understood it that way.
                  Well, for the record, there are no command tables to query that information. You can view the full list of command and data tables in atombios.h

                  Comment


                  • #10
                    Originally posted by agd5f View Post
                    The drm already hooks in suspend and resume functions which are mainly what those are for. There aren't any common dynamic power management interfaces as far as I know because it tends to be device, or at least subsystem specific (i.e., USB power saving stuff). Perhaps we could implement some common drm dynamic pm functionality once some other drm drivers add similar features.
                    Well, you mean having a non-sysfs power management interface like all the other sub-systems. So you would have a generalized DRM interface which generates proper sysfs entries on Linux and whatever are the proper interfaces on other kernels (window,MacOS,*BSD...).
                    I don't know, but does the DRM power management driver interface allow proper use of pm.h? Personnally, I doubt it. And imagining code that will cleanly fit all the other kernels power management interface at the same time... sorry I don't buy it: it will be kludgy naughty code. I don't even think it will fit the "quality requiered" to get into *BSD kernels.

                    For me it's masochistic and a dangerous path.

                    Let me add a layer on top of it: a generalized instrumentation framework for performance measurements that will fit the native instrumentation interfaces of all kernels?

                    All that kernel abstraction stuff seems quite unreasonable, but I think you got my point.

                    Originally posted by agd5f View Post
                    It loads the profile as part of asic init, however, there are no tables to query the temp or fan speed. Those need to be implemented by the driver.
                    Well, for the record, there are no command tables to query that information. You can view the full list of command and data tables in atombios.h
                    Well that one is for me... "one day" I might have brain time to dive for good into AMD GPU driver code... to avoid such questions.

                    Comment


                    • #11
                      Originally posted by sylware View Post
                      Well, you mean having a non-sysfs power management interface like all the other sub-systems. So you would have a generalized DRM interface which generates proper sysfs entries on Linux and whatever are the proper interfaces on other kernels (window,MacOS,*BSD...).
                      I don't know, but does the DRM power management driver interface allow proper use of pm.h? Personnally, I doubt it. And imagining code that will cleanly fit all the other kernels power management interface at the same time... sorry I don't buy it: it will be kludgy naughty code. I don't even think it will fit the "quality requiered" to get into *BSD kernels.

                      For me it's masochistic and a dangerous path.

                      Let me add a layer on top of it: a generalized instrumentation framework for performance measurements that will fit the native instrumentation interfaces of all kernels?

                      All that kernel abstraction stuff seems quite unreasonable, but I think you got my point.
                      Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

                      pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

                      What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

                      Comment


                      • #12
                        Originally posted by agd5f View Post
                        Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

                        pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

                        What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

                        pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
                        But... then you tell me the minor power management state machines are coded internally in the driver.
                        The end result will be:
                        - the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
                        - the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

                        And that story will map for all the other kernel services!

                        Ok, I stop there, but do not be surprised if a few people do not agree with that approach. And I don't even talk about the licensing issue. I wish you luck on that road... if one day I have brain time to join seriously AMD GPU driver coding, that will be on a parallel twin road.

                        Comment


                        • #13
                          sylware, I'm not sure what you are recommending here. If the Linux power management system doesn't handle arbitrary device power states, doesn't that essentially require the kind of split implementation agd5f was describing ?

                          Comment


                          • #14
                            sylware, you know this radeon DRM module is the Linux, and just Linux, one, right?
                            Probably I just misunderstood your posts, sorry if that's the case.

                            Comment


                            • #15
                              Originally posted by sylware View Post
                              pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
                              But... then you tell me the minor power management state machines are coded internally in the driver.
                              The end result will be:
                              - the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
                              - the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

                              And that story will map for all the other kernel services!
                              You're not making sense. The interface in pm.h doesn't apply to any of the pm state in question. How would I use it for that?

                              The driver handles it's internal state properly so that it will do the right thing when the higher level s/r routines are called.

                              Why would the kernel version matter other than for distros that may patch in/out functionality? The radeon drm lives in the kernel and it's tied to the interfaces in the kernel.

                              ???

                              Comment

                              Working...
                              X