Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt wrote: >> radeonfb_setcolreg: INPLL >> radeonfb_setcolreg: OUTPLL >> radeonfb_setcolreg: OUTPLL >> ... last three lines repeated 63 times > > Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely > dumb, and calling the ioctl 64 times to set each palette entry instead > of doing a single call for the whole palette... > > Anyway. Except for maybe the double set-par on switch from X to console, > there isn't much more we can do here. We might be able to improve X but > there is a significant lag between a fix done to X.org HEAD appears in > any distro. The fact is, according to ATI, there is a HW bug on M6 taht > can cause lockups of the chip, and this 5ms workaround is necessary to > avoid it... But it's not specific to X11; I've applied the patch you posted and the same symptoms occur for pure tty switching as well, the delay has decreased a bit (it's hard to measure, but around a second), but it's still rather annoying to work with. Is it distinguishable which M6 models are buggy? I'm using my X31 for about a year now and have probably made some tens of thousands of switches without lockups, so presumably not all models cause lockups. Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt wrote: radeonfb_setcolreg: INPLL radeonfb_setcolreg: OUTPLL radeonfb_setcolreg: OUTPLL ... last three lines repeated 63 times Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely dumb, and calling the ioctl 64 times to set each palette entry instead of doing a single call for the whole palette... Anyway. Except for maybe the double set-par on switch from X to console, there isn't much more we can do here. We might be able to improve X but there is a significant lag between a fix done to X.org HEAD appears in any distro. The fact is, according to ATI, there is a HW bug on M6 taht can cause lockups of the chip, and this 5ms workaround is necessary to avoid it... But it's not specific to X11; I've applied the patch you posted and the same symptoms occur for pure tty switching as well, the delay has decreased a bit (it's hard to measure, but around a second), but it's still rather annoying to work with. Is it distinguishable which M6 models are buggy? I'm using my X31 for about a year now and have probably made some tens of thousands of switches without lockups, so presumably not all models cause lockups. Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
Benjamin Herrenschmidt wrote: > > 1. When resuming from S3 suspend and having switched off the backlight > > with radeontool the backlight isn't switched back on any more. > > I'm not sure what's up here, it's a nasty issue with backlight. Can > radeontool bring it back ? Before suspending I power down the backlight with "radeontool light off" and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. > > 2. I'm using fbcon as my primary work environment, but tty switching has > > become _very_ sloppy, it's at least a second now, while with 2.6.11 it > > was as fast as a few ms. Is this caused by the "proper PLL accesses"? > > Yes. Unfortunately. It's surprised it is that slow though, there > shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with > 5ms pause for each, that should still be very reasonable. It looks like > we are doing a lot more accesses which I don't completely understand. Can you tell me which function you have in mind, so that I can insert some printks to see how often it's called? Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
Benjamin Herrenschmidt wrote: 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. I'm not sure what's up here, it's a nasty issue with backlight. Can radeontool bring it back ? Before suspending I power down the backlight with radeontool light off and with 2.6.11 the display is properly restored. With 2.6.12rc2 the backlight remains switched off and if I switch it on with radeontool it becomes lighter, but there's still no text from the fbcon, just the blank screen. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Yes. Unfortunately. It's surprised it is that slow though, there shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with 5ms pause for each, that should still be very reasonable. It looks like we are doing a lot more accesses which I don't completely understand. Can you tell me which function you have in mind, so that I can insert some printks to see how often it's called? Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
Linus Torvalds wrote: > Benjamin Herrenschmidt: > o radeonfb: Implement proper workarounds for PLL accesses > o radeonfb: DDC i2c fix > o radeonfb: Fix mode setting on CRT monitors > o radeonfb: Preserve TMDS setting One of these patches introduced two regressions on my Thinkpad X31 with "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])": 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the "proper PLL accesses"? Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc2
Linus Torvalds wrote: Benjamin Herrenschmidt: o radeonfb: Implement proper workarounds for PLL accesses o radeonfb: DDC i2c fix o radeonfb: Fix mode setting on CRT monitors o radeonfb: Preserve TMDS setting One of these patches introduced two regressions on my Thinkpad X31 with ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]): 1. When resuming from S3 suspend and having switched off the backlight with radeontool the backlight isn't switched back on any more. 2. I'm using fbcon as my primary work environment, but tty switching has become _very_ sloppy, it's at least a second now, while with 2.6.11 it was as fast as a few ms. Is this caused by the proper PLL accesses? Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
Hi, In gmane.linux.kernel, you wrote: > With some pending security fixes it's time to for a -stable update. So, > here's 2.6.11.6, in the normal kernel.org places. This includes some > security fixes, esp. one which closes a local root exploit in bluetooth. Could you please add CAN IDs to the stable changelog for already assigned vulnerabilities? Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.6
Hi, In gmane.linux.kernel, you wrote: With some pending security fixes it's time to for a -stable update. So, here's 2.6.11.6, in the normal kernel.org places. This includes some security fixes, esp. one which closes a local root exploit in bluetooth. Could you please add CAN IDs to the stable changelog for already assigned vulnerabilities? Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
Martin Josefsson wrote: > I also have an X31 and I noticed that the e1000 has Wake-On-Lan enabled > by default and the S3 code doesn't disable that (kind of defeats the > purpose :) > Disabling that will make the e1000 driver power down the chip during S3. > > I've had mine suspended for 2-3 days at most, actually havn't left it > alone for longer than that in S3 so I'm not really sure how much power > it consumes, but I'd say it's 1-2 percent of the total capacity per > hour, so somewhere below 1000mW. I've got the e100 and with WOL disabled and Matthew's hacked radeontool power consumption decreases to 970 mWh. Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
Matthew Garrett wrote: > Radeons don't actually power down in D3 unless some registers are set, > and even then the kernel doesn't currently have any code that would put > the Radeon in D3. If you're willing to test something, could you try the > code at > > http://www.srcf.ucam.org/~mjg59/radeon/ > > immediately before putting the machine into suspend? Make sure that you > do this from something other than X. This reduces power consumption from ca. 1500 to ca. 1200 mWh, so it's already a huge improvement, but with 1.5 days of maximal suspend still pretty far away from a week. Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
Matthew Garrett wrote: Radeons don't actually power down in D3 unless some registers are set, and even then the kernel doesn't currently have any code that would put the Radeon in D3. If you're willing to test something, could you try the code at http://www.srcf.ucam.org/~mjg59/radeon/ immediately before putting the machine into suspend? Make sure that you do this from something other than X. This reduces power consumption from ca. 1500 to ca. 1200 mWh, so it's already a huge improvement, but with 1.5 days of maximal suspend still pretty far away from a week. Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Average power consumption in S3?
Martin Josefsson wrote: I also have an X31 and I noticed that the e1000 has Wake-On-Lan enabled by default and the S3 code doesn't disable that (kind of defeats the purpose :) Disabling that will make the e1000 driver power down the chip during S3. I've had mine suspended for 2-3 days at most, actually havn't left it alone for longer than that in S3 so I'm not really sure how much power it consumes, but I'd say it's 1-2 percent of the total capacity per hour, so somewhere below 1000mW. I've got the e100 and with WOL disabled and Matthew's hacked radeontool power consumption decreases to 970 mWh. Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Average power consumption in S3?
Hi, I'm using an IBM Thinkpad X31. With stock 2.6.11 and the additional radeontool to power-off the backlight in suspend, S3 works very well and reliable. During S3 I've measured a power consumption of 1400 to 1500 mWh (using 512 megabytes of RAM). Is there still room for optimization? What's the typical amount of energy required for suspend- to-ram? From friends using iBooks with MacOS X I've heard that they left the notebook in suspend when leaving for a week and could still use it after return. Cheers, Moritz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Average power consumption in S3?
Hi, I'm using an IBM Thinkpad X31. With stock 2.6.11 and the additional radeontool to power-off the backlight in suspend, S3 works very well and reliable. During S3 I've measured a power consumption of 1400 to 1500 mWh (using 512 megabytes of RAM). Is there still room for optimization? What's the typical amount of energy required for suspend- to-ram? From friends using iBooks with MacOS X I've heard that they left the notebook in suspend when leaving for a week and could still use it after return. Cheers, Moritz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
