[PATCH 0/9] drm/radeon/kms: update pm code
2010/5/10 Andy Furniss : >> The module parameter is obsolete. you can enable it dynamically via >> sysfs (power_method). ?The default pm method is profile. > > OK, I know dynpm was removed - but this is dynclks are the two the same? dynclks is for disabling clocking unused blocks. It means you don't provide clock signal to blocks and save some power. It was the case in older hardware, newer don't use that command anymore. I believe newer hardware handles that automatically. -- Rafa?
[PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: > Send me a copy of your vbios, I may need to adjust the profile table > for rv670. As root: > cd /sys/bus/pci/devices/ > echo 1> rom > cat rom> /tmp/vbios.rom > echo 0> rom Sent >> One separate question - do I need to use the module param dynclks=1 or is it >> the default? >> > > The module parameter is obsolete. you can enable it dynamically via > sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same?
[PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: > The "profile" method exposes 4 profiles that can be selected from: > 1. "default" > 2. "auto" > 3. "low" > 4. "high" > Select the profile by echoing the selected profile to > /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 > /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 > /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info -> debug patch reverted I can't get echo low > /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default?
[PATCH 0/9] drm/radeon/kms: update pm code
On Mon, May 10, 2010 at 12:04 PM, Andy Furniss wrote: > Alex Deucher wrote: > >> The "profile" method exposes 4 profiles that can be selected from: >> 1. "default" >> 2. "auto" >> 3. "low" >> 4. "high" >> Select the profile by echoing the selected profile to >> /sys/class/drm/card-0/device/power_profile. > > Testing on a rv670 desktop it seems that low does not force the card to low > clock. > > Before these patches went in I could force low by > > echo 2.0 > /sys/class/drm/card0/device/power_state for 2 screens or > echo 1.0 > /sys/class/drm/card0/device/power_state for one screen. > > Though dmesg didn't always report setting it did work (using bench mark to > verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo > 2.0. > > Running current drt with the info -> debug patch reverted I can't get > > echo low > ?/sys/class/drm/card0/device/power_profile > > to lower the clock whatever I try - one screen, two screens forcing high > then low etc. (nothing in dmesg and benchmark gives full clock results) > Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom > dynpm works as before and I do get low clock in dpms with profile. > > One separate question - do I need to use the module param dynclks=1 or is it > the default? > The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. Alex
Re: [PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info - debug patch reverted I can't get echo low /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
On Mon, May 10, 2010 at 12:04 PM, Andy Furniss andy...@ukfsn.org wrote: Alex Deucher wrote: The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. Testing on a rv670 desktop it seems that low does not force the card to low clock. Before these patches went in I could force low by echo 2.0 /sys/class/drm/card0/device/power_state for 2 screens or echo 1.0 /sys/class/drm/card0/device/power_state for one screen. Though dmesg didn't always report setting it did work (using bench mark to verify) - I could also get dmesg to confirm by echo 2.0 echo 2.2 then echo 2.0. Running current drt with the info - debug patch reverted I can't get echo low /sys/class/drm/card0/device/power_profile to lower the clock whatever I try - one screen, two screens forcing high then low etc. (nothing in dmesg and benchmark gives full clock results) Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom dynpm works as before and I do get low clock in dpms with profile. One separate question - do I need to use the module param dynclks=1 or is it the default? The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
Alex Deucher wrote: Send me a copy of your vbios, I may need to adjust the profile table for rv670. As root: cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Sent One separate question - do I need to use the module param dynclks=1 or is it the default? The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
2010/5/10 Andy Furniss andy...@ukfsn.org: The module parameter is obsolete. you can enable it dynamically via sysfs (power_method). The default pm method is profile. OK, I know dynpm was removed - but this is dynclks are the two the same? dynclks is for disabling clocking unused blocks. It means you don't provide clock signal to blocks and save some power. It was the case in older hardware, newer don't use that command anymore. I believe newer hardware handles that automatically. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/radeon/kms: update pm code
On Sat, 8 May 2010 11:29:10 -0400 Alex Deucher wrote: > On Sat, May 8, 2010 at 7:14 AM, Klaus Doblmann B.A. > wrote: > > the profile setting works but I can't check which clock speeds are > > set as I don't get any feedback (dmesg) anymore (Someone have any > > input on this?). The temps are unaffected whether I use the low or high > > profile, the only way I can tell that some things are working is by a > > 2000 fps-difference when running glxgears (something like 4000 on low > > and 6000 on high). I also attached a wattmeter to my my machine and the > > wattage alternates but I think I'm getting something along the lines of > > a 10W decrease in power consumption - it's very hard to tell, though. > > dynpm is a bit more effective and I even get lower temps (just under > > 50? compared to over 53 with the profile settings) but it's unusable > > right now as I already mentioned. > > > > All in all very nice work so far (this goes for all of you who've > > worked on radeon KMS PM!) - with the latest set of patches this is the > > first "revision" of KMS PM that actually "works" on my machine :) > > > > Thanks for testing; we are definitely planning on further > improvements, this is just a step on the way. The power drops > further when your monitors go off so that will save additional power > when your machine is idle. If you want to see the state transitions, > revert this patch: > http://people.freedesktop.org/~agd5f/pm-drt/0009-drm-radeon-kms-pm-make-pm-spam-debug-only.patch > However, it will spam your kernel log. > > Alex > Hi Alex, thanks for the suggestion! It seems I spoke a bit too soon about everything working. I suspended my machine and now came back after a few hours and it seems the latest patches (well, I only could test the pm code in linus' tree of -34 up to now due to display corruptions so there's a lot of changes since then) in d-r-t killed suspend for me - the machine doesn't come back up and hardlocks. Too bad I can't find anything about it in my logs :( Klaus -- Klaus Doblmann B.A. - http://straightrazorguy.net - FSF member #7570 PGP-Key: http://www.doblmann.de/pgp_key.asc http://twitter.com/klausdoblmann A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
[PATCH 0/9] drm/radeon/kms: update pm code
On Sat, May 8, 2010 at 7:14 AM, Klaus Doblmann B.A. wrote: > On Fri, ?7 May 2010 17:16:11 -0400 > Alex Deucher wrote: > >> This set of patches applies on top of the code in drm-radeon-testing. >> >> I've been testing this code pretty hard this week and it's been solid. >> In addition to some fixes on top of what's in d-r-t, it also reworks >> the pm code to support two basic methods: >> >> 1. "dynpm" >> 2. "profile" >> >> You can select the methods via sysfs. ?Echo "dynpm" or "profile" to >> /sys/class/drm/card-0/device/power_method. >> >> The "dynpm" method dynamically changes the clocks based on the number of >> pending >> fences, so performance is ramped up when running GPU intensive apps, and >> ramped down when the GPU is idle. ?The reclocking is attemped during >> vertical blanking periods, but due to the timing of the reclocking >> functions, doesn't not always complete in the blanking period, which can >> lead to flicker in the display. ?Due to this, dynpm only works when a single >> head is active. > > Hi Alex, > > I just built a new version of d-r-t with your patches from yesterday > applied on top and wanted to share my experience with you and the list > (Radeon 2600XT mobile): > > Dynpm has gotten unusable for me as there's a noticeable effect on > mouse movement (getting sluggish) > >> >> The "profile" method exposes 4 profiles that can be selected from: >> 1. "default" >> 2. "auto" >> 3. "low" >> 4. "high" >> Select the profile by echoing the selected profile to >> /sys/class/drm/card-0/device/power_profile. >> > > the profile setting works but I can't check which clock speeds are > set as I don't get any feedback (dmesg) anymore (Someone have any > input on this?). The temps are unaffected whether I use the low or high > profile, the only way I can tell that some things are working is by a > 2000 fps-difference when running glxgears (something like 4000 on low > and 6000 on high). I also attached a wattmeter to my my machine and the > wattage alternates but I think I'm getting something along the lines of > a 10W decrease in power consumption - it's very hard to tell, though. > dynpm is a bit more effective and I even get lower temps (just under > 50? compared to over 53 with the profile settings) but it's unusable > right now as I already mentioned. > > All in all very nice work so far (this goes for all of you who've > worked on radeon KMS PM!) - with the latest set of patches this is the > first "revision" of KMS PM that actually "works" on my machine :) > Thanks for testing; we are definitely planning on further improvements, this is just a step on the way. The power drops further when your monitors go off so that will save additional power when your machine is idle. If you want to see the state transitions, revert this patch: http://people.freedesktop.org/~agd5f/pm-drt/0009-drm-radeon-kms-pm-make-pm-spam-debug-only.patch However, it will spam your kernel log. Alex > Klaus > > -- > Klaus Doblmann B.A. - http://straightrazorguy.net - FSF member #7570 > PGP-Key: http://www.doblmann.de/pgp_key.asc > http://twitter.com/klausdoblmann > > A: Because it messes up the order in which people normally read text. > ? See http://en.wikipedia.org/wiki/Posting_style > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: [PATCH 0/9] drm/radeon/kms: update pm code
On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote: auto selects between low and high power states based on the whether the system is on battery power or not. Even lower power states are selected when the monitors are in the dpms off state. Beyond the constraints imposed in terms of some modes not being available on battery, I'd prefer to leave the ac/battery decision up to userspace. Having it be default behaviour at the kernel level is plausibly confusing. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
On Fri, 7 May 2010 17:16:11 -0400 Alex Deucher alexdeuc...@gmail.com wrote: This set of patches applies on top of the code in drm-radeon-testing. I've been testing this code pretty hard this week and it's been solid. In addition to some fixes on top of what's in d-r-t, it also reworks the pm code to support two basic methods: 1. dynpm 2. profile You can select the methods via sysfs. Echo dynpm or profile to /sys/class/drm/card-0/device/power_method. The dynpm method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active. Hi Alex, I just built a new version of d-r-t with your patches from yesterday applied on top and wanted to share my experience with you and the list (Radeon 2600XT mobile): Dynpm has gotten unusable for me as there's a noticeable effect on mouse movement (getting sluggish) The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. the profile setting works but I can't check which clock speeds are set as I don't get any feedback (dmesg) anymore (Someone have any input on this?). The temps are unaffected whether I use the low or high profile, the only way I can tell that some things are working is by a 2000 fps-difference when running glxgears (something like 4000 on low and 6000 on high). I also attached a wattmeter to my my machine and the wattage alternates but I think I'm getting something along the lines of a 10W decrease in power consumption - it's very hard to tell, though. dynpm is a bit more effective and I even get lower temps (just under 50° compared to over 53 with the profile settings) but it's unusable right now as I already mentioned. All in all very nice work so far (this goes for all of you who've worked on radeon KMS PM!) - with the latest set of patches this is the first revision of KMS PM that actually works on my machine :) Klaus -- Klaus Doblmann B.A. - http://straightrazorguy.net - FSF member #7570 PGP-Key: http://www.doblmann.de/pgp_key.asc http://twitter.com/klausdoblmann A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/radeon/kms: update pm code
On Sat, 8 May 2010 11:29:10 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Sat, May 8, 2010 at 7:14 AM, Klaus Doblmann B.A. klaus.doblm...@gmail.com wrote: the profile setting works but I can't check which clock speeds are set as I don't get any feedback (dmesg) anymore (Someone have any input on this?). The temps are unaffected whether I use the low or high profile, the only way I can tell that some things are working is by a 2000 fps-difference when running glxgears (something like 4000 on low and 6000 on high). I also attached a wattmeter to my my machine and the wattage alternates but I think I'm getting something along the lines of a 10W decrease in power consumption - it's very hard to tell, though. dynpm is a bit more effective and I even get lower temps (just under 50° compared to over 53 with the profile settings) but it's unusable right now as I already mentioned. All in all very nice work so far (this goes for all of you who've worked on radeon KMS PM!) - with the latest set of patches this is the first revision of KMS PM that actually works on my machine :) Thanks for testing; we are definitely planning on further improvements, this is just a step on the way. The power drops further when your monitors go off so that will save additional power when your machine is idle. If you want to see the state transitions, revert this patch: http://people.freedesktop.org/~agd5f/pm-drt/0009-drm-radeon-kms-pm-make-pm-spam-debug-only.patch However, it will spam your kernel log. Alex Hi Alex, thanks for the suggestion! It seems I spoke a bit too soon about everything working. I suspended my machine and now came back after a few hours and it seems the latest patches (well, I only could test the pm code in linus' tree of -34 up to now due to display corruptions so there's a lot of changes since then) in d-r-t killed suspend for me - the machine doesn't come back up and hardlocks. Too bad I can't find anything about it in my logs :( Klaus -- Klaus Doblmann B.A. - http://straightrazorguy.net - FSF member #7570 PGP-Key: http://www.doblmann.de/pgp_key.asc http://twitter.com/klausdoblmann A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/radeon/kms: update pm code
On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote: > "auto" selects between low and high power states based on the whether the > system > is on battery power or not. Even lower power states are selected when the > monitors > are in the dpms off state. Beyond the constraints imposed in terms of some modes not being available on battery, I'd prefer to leave the ac/battery decision up to userspace. Having it be default behaviour at the kernel level is plausibly confusing. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 0/9] drm/radeon/kms: update pm code
On Fri, May 7, 2010 at 5:23 PM, Matthew Garrett wrote: > On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote: > >> "auto" selects between low and high power states based on the whether the >> system >> is on battery power or not. ?Even lower power states are selected when the >> monitors >> are in the dpms off state. > > Beyond the constraints imposed in terms of some modes not being > available on battery, I'd prefer to leave the ac/battery decision up to > userspace. Having it be default behaviour at the kernel level is > plausibly confusing. Sounds fine. Just have userspace switch between the low and high profiles for battery and ac rather than using auto. auto is useful as a user option in the interim while userspace gets updated. Alex
[PATCH 0/9] drm/radeon/kms: update pm code
This set of patches applies on top of the code in drm-radeon-testing. I've been testing this code pretty hard this week and it's been solid. In addition to some fixes on top of what's in d-r-t, it also reworks the pm code to support two basic methods: 1. "dynpm" 2. "profile" You can select the methods via sysfs. Echo "dynpm" or "profile" to /sys/class/drm/card-0/device/power_method. The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active. The "profile" method exposes 4 profiles that can be selected from: 1. "default" 2. "auto" 3. "low" 4. "high" Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. "default" uses the default clocks and does not change the power state. This is the default behavior. "auto" selects between low and high power states based on the whether the system is on battery power or not. Even lower power states are selected when the monitors are in the dpms off state. "low" forces the gpu to be in the low power state all the time. Even lower power states are selected when the monitors are in the dpms off state. "high" forces the gpu to be in the high power state all the time. Even lower power states are selected when the monitors are in the dpms off state. The "profile" method is not as agressive as "dynpm," but is currently much more stable and flicker free and works with multiple heads active. The default power management method is "profile" using the "default" profile. The default should eventaully be changed to "profile" "auto". For upstream, we may want to squash some of these. I'm open to suggestions. Everthing that's been added since drm-linus? Alex
[PATCH 0/9] drm/radeon/kms: update pm code
This set of patches applies on top of the code in drm-radeon-testing. I've been testing this code pretty hard this week and it's been solid. In addition to some fixes on top of what's in d-r-t, it also reworks the pm code to support two basic methods: 1. dynpm 2. profile You can select the methods via sysfs. Echo dynpm or profile to /sys/class/drm/card-0/device/power_method. The dynpm method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active. The profile method exposes 4 profiles that can be selected from: 1. default 2. auto 3. low 4. high Select the profile by echoing the selected profile to /sys/class/drm/card-0/device/power_profile. default uses the default clocks and does not change the power state. This is the default behavior. auto selects between low and high power states based on the whether the system is on battery power or not. Even lower power states are selected when the monitors are in the dpms off state. low forces the gpu to be in the low power state all the time. Even lower power states are selected when the monitors are in the dpms off state. high forces the gpu to be in the high power state all the time. Even lower power states are selected when the monitors are in the dpms off state. The profile method is not as agressive as dynpm, but is currently much more stable and flicker free and works with multiple heads active. The default power management method is profile using the default profile. The default should eventaully be changed to profile auto. For upstream, we may want to squash some of these. I'm open to suggestions. Everthing that's been added since drm-linus? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
