[Patch] ACPI: ignore processors that doesn't support hot plug
Hi, Len,
will you please consider this patch as the fix for bug 8570,
rather than the one at http://bugzilla.kernel.org/show_bug.cgi?id=8570#c21 ?
is_processor_present is only called in the processor hotplug case,
and _STA method is mandatory at this time.
We should ignore those processors that are disabled in the MADT
and don't have _STA methods.
Because they will never exist in this system.
For the processors that don't physically exist but can be
hot plugged later, we still need this debug info.
http://bugzilla.kernel.org/show_bug.cgi?id=8570
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/acpi/processor_core.c
===
--- linux-2.6.orig/drivers/acpi/processor_core.c
+++ linux-2.6/drivers/acpi/processor_core.c
@@ -812,11 +812,20 @@ static int is_processor_present(acpi_han
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
- if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT)) {
- ACPI_EXCEPTION((AE_INFO, status, "Processor Device is not
present"));
- return 0;
- }
- return 1;
+
+ if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+ return 1;
+
+ /*
+* _STA is mandatory for a processor that supports hot plug
+*/
+ if (status == AE_NOT_FOUND)
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "Processor does not support hot plug\n"));
+ else
+ ACPI_EXCEPTION((AE_INFO, status,
+ "Processor Device is not present"));
+ return 0;
}
static
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The new thermal management sysfs class, and hwmon
Hi, all, Sorry for the late response as I'm on the Chinese New Year vacation. On Thu, 2008-02-14 at 22:08 +0800, Matthew Garrett wrote: > On Wed, Feb 13, 2008 at 04:10:50PM +0100, Thomas Renninger wrote: > > > Why do you want to still export the temperature via ACPI sysfs paths > > then? > > Once it is there and userspace progs make use of it, you will have > to > > maintain it forever and HAL is getting crazy and must take care > about: > > - How to find the ACPI thermal node > > - Find the hwmon node > > - Both interfaces provide temeratures > > - Parse different output of temperature values (totally crazy) > > > > Quite. There's still been no indication that anyone cares about fixing > this interface, and I'm upset that it was merged despite there being > clear and valid concerns about it. Do we have a commitment that it's > going to be cleaned up before final? If not, it should be pulled > before > userspace starts depending on it. The only hardware where this > currently > matters isn't going to be running 2.6.25 anyway. > Here is my understanding of the problem, please correct me if I say something wrong. :) It would be great if we can use the hwmon for ACPI thermal model. And it's also true that there are some gaps exist just as thomas had already listed. so let's make the problems clear one by one. Surely it would be great if we can solve all the problems so that we can use the hwmon. But if not, please let the new thermal sysfs class go upstream as we really need this functionality and we don't get any alternatives. Here is a typical thermal sys I/F for ACPI thermal zone. /sys/class/thermal: |thermal_zone1: |-type: ACPI thermal zone |-temp: 37 |-mode: kernel |trip_point_0_temp: 100 |-trip_point_0_type:critical |-trip_point_1_temp:80 |-trip_point_1_type:passive |-trip_point_2_temp:70 |-trip_point_2_type:active0 |-trip_point_3_temp:60 |-trip_point_3_type:active1 |-cdev0: --->/sys/class/thermal/cooling_device0 |-cdev0_trip_point: 1 /* used for passive */ |-cdev1:--->/sys/class/thermal/cooling_device1 |-cdev1_trip_point: 1 /* used for passive */ |-cdev2:--->/sys/class/thermal/cooling_device2 |-cdev2_trip_point: 2 /* used for active0 */ |-cdev3:--->/sys/class/thermal/cooling_device3 |-cdev3_trip_point: 2 /* used for active0 */ |-cdev4:--->/sys/class/thermal/cooling_device3 |-cdev4_trip_point: 3 /* used for active1*/ |thermal_zone2: |-type: ACPI thermal zone |-temp: 43 |-mode: kernel |-trip_point_0_temp:105 |-trip_point_0_type:critical |-trip_point_1_temp:65 |-trip_point_1_type:passive |-cdev0:--->/sys/class/thermal/cooling_device0 |-cdev0_trip_point: 1 /* used for passive */ |cooling_device0: |-type: Processor |-max_state:8 |-cur_state:0 |cooling_device1: |-type: Processor |-max_state:8 |-cur_state:0 |cooling_device2: |-type: Fan |-max_state:1 |-cur_state:0 |cooling_device3: |-type: Fan |-max_state:1 |-cur_state:0 The first problem is how to use hwmon for all cooling device. We need a uniform I/F for both fan and passive cooling devices. pwm[1-*]_enable, and pwm[1-*] and fan[1-*]_input can be used for fan control. The same I/F can work for acpi fan, even for all cooling devices, e.g pwm[1-*]_enable to enable/disable cooling device control via acpi thermal driver, pwm[1-*] to control the device cooling state, where 0 stands for no cooling and 255 stands for maximum cooling state. But it seems really ugly and it's a misuse of pwm[1-*] attribute, right? So we should either introduce new hwmon ABIs for cooling device control, just like what we've already done in the thermal sys class, or give up the idea of making them hwmon compatible. If we have generic hwmon ABIs for all cooling devices, let's go further. Hwmon also has the ABIs to support multiple trip points for fan device, i.e. pwm[1-*]_auto_point[1-*]_pwm and pwm[1-*]_auto_point[1-*]_temp. But in order to make this available for all cooling devices, we still need to introduce n
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 5:28 pm Linus Torvalds wrote: > On Thu, 21 Feb 2008, Jesse Barnes wrote: > > So the advantage of the kernel suspend/resume hooks for the DRM layer is > > that the kernel video drivers can do full state save/restore (which X > > usually doesn't do, and isn't really designed to do), so that if your > > platform *doesn't* do it all, you'll still end up with a usable machine > > in the end. > > Well, I'm also hoping that eventually we could even just not do the VT > switch at all, and the kernel can treat X as "just another user process" > that it freezes. Hell yes. > At least from a mode setting standpoint. > > We'd still want to make sure that X repaints the screen if the contents > were lost, of course. And this is going to depend very intimately on the > type of graphics card and whether the video RAM is saved by STR or not - > for the Intel integrated graphics kind of situation, the video RAM will be > refreshed along with all the other memory, but for other cards we may end > up having to do the VT switch not so much for modesetting reasons as just > a way to get X to save and restore all the *other* state. Drivers supporting kernel modesetting will have to stuff their VRAM somewhere, yeah. Hopefully X won't have much to do with it though... > How close is the i915 driver from not having to even signal X? Or is that > just a pipedream of mine? It's there in the modesetting tree (though the requisite changes to avoid VT notification aren't done, it should all work fine). Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 5:13 pm Jesse Barnes wrote:
> On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> > On Friday, 22 of February 2008, Linus Torvalds wrote:
> > > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > > - if (state.event == PM_EVENT_SUSPEND) {
> > > > + if (state.event == PM_EVENT_SUSPEND &&
> > > > !in_hibernation_power_off())
> > > > {
> > >
> > > I don't understand why hibernation just doesn't use a
> > > PM_EVENT_HIBERNATE, and be done with it?
> > >
> > > Why should it be called PM_EVENT_SUSPEND when it isn't?
> > >
> > > Adding some external global variables is absolutely the wrong way to
> > > fix this.
> > >
> > > It's not even like there are very many drivers who actually care about
> > > "state.event" anyway: a 'git grep' returns just 35 users in the whole
> > > tree, so if this was done this ugly way just to avoid double-chcking
> > > the other cases that compare against PM_EVENT_SUSPEND, then it really
> > > wasn't worth it.
> >
> > Please relax, we're debugging the thing right now and the patch doesn't
> > even seem to help on the other affected box.
>
> Actually, looks like I forgot to reboot between tests (just rmmod'd &
> modprobed i915), your patch actually does work.
>
> However, making new PM event messages might be a good thing anyway,
> assuming Linus takes it for 2.6.25, since it should make the migration to
> ->hibernate callbacks easier.
Rafael, I'd actually prefer these changes to the i915 driver. One is to avoid
the "green screen" problem and the other is to actually save state at
hibernate time in case we don't do a POST coming out of S4 (probably not
common but hey).
Jesse
Make sure hibernation works by not shutting down the video device during
hibernation power off. This is important because later stages of the
hibernation cycle end up touching the video device, which may cause a hang if
it was disabled early on. Also make sure the restoration correctly restores
the AR registers by flipping the ARX register into index mode before doing
anything.
Depends on Rafael's patch which exports hibernation state to drivers.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 35758a6..5e73869 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
*
*/
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
dev_priv->saveGR[0x18]);
/* Attribute controller registers */
+ inb(st01);
for (i = 0; i < 20; i++)
i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
inb(st01); /* switch back to index mode */
@@ -364,8 +366,8 @@ static int i915_suspend(struct drm_device *dev)
i915_save_vga(dev);
/* Shut down the device */
- pci_disable_device(dev->pdev);
- pci_set_power_state(dev->pdev, PCI_D3hot);
+ if (!in_hibernation_power_off())
+ pci_set_power_state(dev->pdev, PCI_D3hot);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
On 2/21/08, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote: > > On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote: > > > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote: > > > > Hi Andrew, > > > > > > > > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails > > > > to build on x86_64 machine > > > > > > > > CC drivers/acpi/osl.o > > > > drivers/acpi/osl.c:60:38: error: empty filename in #include > > > > drivers/acpi/osl.c: In function 'acpi_os_table_override': > > > > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in > this function) > > > > drivers/acpi/osl.c:399: error: (Each undeclared identifier is > reported only once > > > > drivers/acpi/osl.c:399: error: for each function it appears in.) > > > > make[2]: *** [drivers/acpi/osl.o] Error 1 > > > > make[1]: *** [drivers/acpi] Error 2 > > > > make: *** [drivers] Error 2 > > > > > > > > # > > > > # Automatically generated make config: don't edit > > > > # Linux kernel version: 2.6.25-rc2-mm1 > > > > # Sun Feb 17 08:07:17 2008 > > > > # > > > > > > > > > > CONFIG_ACPI_CUSTOM_DSDT=y > > > > CONFIG_ACPI_CUSTOM_DSDT_FILE="" > > > > > > > > > garbage in, garbage out. > > > > garbage explicitly *allowed* by Kconfig in this case, though. > > > > > If you don't give this build option a file name where AmlCode lives, > > > then the build will be unable to find AmlCode[]. > > > > > > http://www.lesswatts.org/projects/acpi/overridingDSDT.php > > > > So we have a .config option whose sole purpose is to use another > > .config option? That seems ... less than ideal. Is there not some > > Kconfig voodoo we can do to only require the one option? Maybe > > something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the > > Cc, in case he has any ideas. > > > Make sure STANDALONE is y for your randconfig builds. > See README for examples. Hrm, if this is needed for randconfig to work, perhaps randconfig itself should somehow be specifying it? > STANALONE is there exactly to prevent the above but we cannot > control randconfig. While setting STANDALONE does fix the above, it doesn't answer the more basic question I had -- do we really need both .config options in this case? If it's simply a case of "That's how it is, won't be fixed, there are higher priorities", that's good enough by me. Just seems a shame that we have an option to enable another option, which is required for the first option to be sensible -- seems like we should only need the second option... Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thu, 21 Feb 2008, Jesse Barnes wrote: > > So the advantage of the kernel suspend/resume hooks for the DRM layer is that > the kernel video drivers can do full state save/restore (which X usually > doesn't do, and isn't really designed to do), so that if your platform > *doesn't* do it all, you'll still end up with a usable machine in the end. Well, I'm also hoping that eventually we could even just not do the VT switch at all, and the kernel can treat X as "just another user process" that it freezes. At least from a mode setting standpoint. We'd still want to make sure that X repaints the screen if the contents were lost, of course. And this is going to depend very intimately on the type of graphics card and whether the video RAM is saved by STR or not - for the Intel integrated graphics kind of situation, the video RAM will be refreshed along with all the other memory, but for other cards we may end up having to do the VT switch not so much for modesetting reasons as just a way to get X to save and restore all the *other* state. How close is the i915 driver from not having to even signal X? Or is that just a pipedream of mine? Linus - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 9:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > The fact that you'd started running into problems since we merged this just > means your platform was taking care of it for you (lucky you) and that we > have some bugs in the hibernate code that we're just discovering. That's the main reason for moving to the X series. It's seems to work very well on Linux. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 4:52 pm Jeff Chua wrote: > On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > Your s2ram script is doing your STD also? Seems counterintuitive. > > Anyway, some machines also re-POST the GPU on resume from S3; maybe yours > > is doing that. > > It's s2ram to do STR, not STD. Sorry for the confusion. But the key > point is there's no GREEN for STR. Mr Green only appear with STD. Ah, ok that makes sense. So typically, what you'd see at suspend time is this ugly call chain: 1) user requests suspend or hibernate 2) kernel kicks users off VT 3) X calls LeaveVT function of X driver 4) X driver restores whatever video state it felt like saving when it started up 5) kernel calls suspend methods 6) machine goes to sleep then on resume: 1) user requests wakeup 2) kernel calls resume methods 3) X takes back the VT, calling driver EnterVT methods 4) X driver EnterVT routine runs, doing whatever it wants 5) you're back to where you were (on a good day anyway) So, on your machine, I suspect your firmware is doing enough that X doesn't have to save/restore full video state around Enter/Leave VT (the same functions called at VT switch time when you press ctl-alt-fx), otherwise you'd be missing things like your backlight or text consoles. So the advantage of the kernel suspend/resume hooks for the DRM layer is that the kernel video drivers can do full state save/restore (which X usually doesn't do, and isn't really designed to do), so that if your platform *doesn't* do it all, you'll still end up with a usable machine in the end. The fact that you'd started running into problems since we merged this just means your platform was taking care of it for you (lucky you) and that we have some bugs in the hibernate code that we're just discovering. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> On Friday, 22 of February 2008, Linus Torvalds wrote:
> > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > - if (state.event == PM_EVENT_SUSPEND) {
> > > + if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
> >
> > I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE,
> > and be done with it?
> >
> > Why should it be called PM_EVENT_SUSPEND when it isn't?
> >
> > Adding some external global variables is absolutely the wrong way to fix
> > this.
> >
> > It's not even like there are very many drivers who actually care about
> > "state.event" anyway: a 'git grep' returns just 35 users in the whole
> > tree, so if this was done this ugly way just to avoid double-chcking the
> > other cases that compare against PM_EVENT_SUSPEND, then it really wasn't
> > worth it.
>
> Please relax, we're debugging the thing right now and the patch doesn't
> even seem to help on the other affected box.
Actually, looks like I forgot to reboot between tests (just rmmod'd &
modprobed i915), your patch actually does work.
However, making new PM event messages might be a good thing anyway, assuming
Linus takes it for 2.6.25, since it should make the migration to ->hibernate
callbacks easier.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Friday, 22 of February 2008, Jeff Chua wrote: > On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> > > wrote: > > > > > Jeff, can you please test hibernation with the patch I've just sent to > > Jesse > > > (reproduced below for convenience)? > > > > Testing now. > > Great news. It works. STD (platform) does not hang at suspend. And the > annoying green is gone! STR still works. Great, thanks for testing. If Jesse confirms that it also works for him, I'll prepare a cleaner final fix tomorrow. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > Jeff, can you please test hibernation with the patch I've just sent to > Jesse > > (reproduced below for convenience)? > > Testing now. Great news. It works. STD (platform) does not hang at suspend. And the annoying green is gone! STR still works. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
>
> - if (state.event == PM_EVENT_SUSPEND) {
> + if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE,
and be done with it?
Why should it be called PM_EVENT_SUSPEND when it isn't?
Adding some external global variables is absolutely the wrong way to fix
this.
It's not even like there are very many drivers who actually care about
"state.event" anyway: a 'git grep' returns just 35 users in the whole
tree, so if this was done this ugly way just to avoid double-chcking the
other cases that compare against PM_EVENT_SUSPEND, then it really wasn't
worth it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Friday, 22 of February 2008, Linus Torvalds wrote:
>
> On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> >
> > - if (state.event == PM_EVENT_SUSPEND) {
> > + if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
>
> I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE,
> and be done with it?
>
> Why should it be called PM_EVENT_SUSPEND when it isn't?
>
> Adding some external global variables is absolutely the wrong way to fix
> this.
>
> It's not even like there are very many drivers who actually care about
> "state.event" anyway: a 'git grep' returns just 35 users in the whole
> tree, so if this was done this ugly way just to avoid double-chcking the
> other cases that compare against PM_EVENT_SUSPEND, then it really wasn't
> worth it.
Please relax, we're debugging the thing right now and the patch doesn't
even seem to help on the other affected box.
The issue appears to be more complicated than we initially thought.
Thanks,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > Your s2ram script is doing your STD also? Seems counterintuitive. Anyway, > some machines also re-POST the GPU on resume from S3; maybe yours is doing > that. It's s2ram to do STR, not STD. Sorry for the confusion. But the key point is there's no GREEN for STR. Mr Green only appear with STD. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote: > > Below is a patch that should work around the issue. Please try it and let > > me know if it helps. > > I ended up applying the below patch instead, so it would build, and > unfortunately it still hung at suspend time. I encountered the same patching problem, but realized that it was due to earlier patch that you had wanted me to test, so if you revert your patch back to the current git, Rafael's patch will apply and compile cleanly. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 4:42 pm Jeff Chua wrote: > On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > Your system (either your distro suspend/resume scripts or your platform) > > must be running the video BIOS at resume time, otherwise it would > > probably come back blank. > > But I don't think so, unless acpid is doing just that. In my > suspend/resume event script, it's just doing a simple s2ram (without > options), and exit after resume. Your s2ram script is doing your STD also? Seems counterintuitive. Anyway, some machines also re-POST the GPU on resume from S3; maybe yours is doing that. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > Jeff, can you please test hibernation with the patch I've just sent to Jesse > (reproduced below for convenience)? Testing now. Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > Your system (either your distro suspend/resume scripts or your platform) must > be running the video BIOS at resume time, otherwise it would probably come > back blank. But I don't think so, unless acpid is doing just that. In my suspend/resume event script, it's just doing a simple s2ram (without options), and exit after resume. Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 4:20 pm Jeff Chua wrote: > On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote: > > > > > Let's try to narrow it down to what the interaction is. Are you > > > > > using something like acpi_sleep=s3_bios or similar? > > > > > > > > No. Not additional command line option except for resume=/dev/sda3 > > > > reboot=bios > > > > > > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need > > > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with > > > echo mem > /sys/power/state. > > > > Cool, glad to hear at least one success report. :) > > STR is always working on my X60s. No green screen, no hang. Both s2ram > and "echo mem > /sys/power/state". It's STD that's having problem. > > But strange thing is I could even restore console after STD even > without agp and i915 module loaded, so I don't know how the console > vga got saved and restored. Your system (either your distro suspend/resume scripts or your platform) must be running the video BIOS at resume time, otherwise it would probably come back blank. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Friday, 22 of February 2008, Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> > > > > Let's try to narrow it down to what the interaction is. Are you using
> > > > > something like acpi_sleep=s3_bios or similar?
> > > >
> > > > No. Not additional command line option except for resume=/dev/sda3
> > > > reboot=bios
> > >
> > > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
> > > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
> > > echo mem > /sys/power/state.
> >
> > Cool, glad to hear at least one success report. :)
>
> STR is always working on my X60s. No green screen, no hang. Both s2ram
> and "echo mem > /sys/power/state". It's STD that's having problem.
>
> But strange thing is I could even restore console after STD even
> without agp and i915 module loaded, so I don't know how the console
> vga got saved and restored.
Jeff, can you please test hibernation with the patch I've just sent to Jesse
(reproduced below for convenience)?
Thanks,
Rafael
---
drivers/char/drm/i915_drv.c |5 +++--
include/linux/suspend.h |2 ++
kernel/power/disk.c | 10 +-
3 files changed, 14 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/char/drm/i915_drv.c
===
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
*
*/
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_
dev_priv->saveGR[0x18]);
/* Attribute controller registers */
+ inb(st01); /* switch back to index mode */
for (i = 0; i < 20; i++)
i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
inb(st01); /* switch back to index mode */
@@ -366,9 +368,8 @@ static int i915_suspend(struct drm_devic
i915_save_vga(dev);
- if (state.event == PM_EVENT_SUSPEND) {
+ if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
/* Shut down the device */
- pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
}
Index: linux-2.6/include/linux/suspend.h
===
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
#else /* CONFIG_HIBERNATION */
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
#endif /* CONFIG_HIBERNATION */
#ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
#include "power.h"
-
+static bool entering_sleep_state;
static int noresume = 0;
static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
if (!hibernation_ops)
return -ENOSYS;
+ entering_sleep_state = true;
/*
* We have cancelled the power transition by running
* hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
}
local_irq_enable();
+ entering_sleep_state = false;
/*
* We don't need to reenable the nonboot CPUs or resume consoles, since
* the system is going to be halted anyway.
@@ -427,6 +429,12 @@ int hibernation_platform_enter(void)
return error;
}
+bool in_hibernation_power_off(void)
+{
+ return entering_sleep_state;
+}
+EXPORT_SYMBOL(in_hibernation_power_off);
+
/**
* power_down - Shut the machine down for hibernation.
*
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Friday, 22 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue. Please try it and let
> > me know if it helps.
>
> I ended up applying the below patch instead, so it would build, and
> unfortunately it still hung at suspend time.
Hmm.
> So at this point, the known workarounds to the hang at suspend time are to
> remove the device power down call or to boot with 'no_console_suspend'.
> The 'screen turns green' problem is fixed by the extra 'inb' added in the
> patch below (at least for me).
That is suspicious (see below).
>
> diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
> index 35758a6..35b5a60 100644
> --- a/drivers/char/drm/i915_drv.c
> +++ b/drivers/char/drm/i915_drv.c
> @@ -27,6 +27,7 @@
> *
> */
>
> +#include
> #include "drmP.h"
> #include "drm.h"
> #include "i915_drm.h"
> @@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
> dev_priv->saveGR[0x18]);
>
> /* Attribute controller registers */
> + inb(st01); /* switch back to index mode */
> for (i = 0; i < 20; i++)
> i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
> inb(st01); /* switch back to index mode */
> @@ -249,6 +251,9 @@ static int i915_suspend(struct drm_device *dev)
> return -ENODEV;
> }
>
> + if (in_hibernation_power_off())
> + return 0;
> +
This thing should make i915_suspend() a noop in the last phase of hibernation,
so if it still only works when you remove the
pci_set_power_state(dev->pdev, PCI_D3hot), then I don't get it.
Can you please try the pach below instead?
Thanks,
Rafael
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> Below is a patch that should work around the issue. Please try it and let
> me know if it helps.
I ended up applying the below patch instead, so it would build, and
unfortunately it still hung at suspend time.
So at this point, the known workarounds to the hang at suspend time are to
remove the device power down call or to boot with 'no_console_suspend'.
The 'screen turns green' problem is fixed by the extra 'inb' added in the
patch below (at least for me).
Jesse
---
drivers/char/drm/i915_drv.c |5 +++--
include/linux/suspend.h |2 ++
kernel/power/disk.c | 10 +-
3 files changed, 14 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/char/drm/i915_drv.c
===
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
*
*/
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_
dev_priv->saveGR[0x18]);
/* Attribute controller registers */
+ inb(st01); /* switch back to index mode */
for (i = 0; i < 20; i++)
i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
inb(st01); /* switch back to index mode */
@@ -366,9 +368,8 @@ static int i915_suspend(struct drm_devic
i915_save_vga(dev);
- if (state.event == PM_EVENT_SUSPEND) {
+ if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
/* Shut down the device */
- pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
}
Index: linux-2.6/include/linux/suspend.h
===
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
#else /* CONFIG_HIBERNATION */
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
#endif /* CONFIG_HIBERNATION */
#ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
#include "power.h"
-
+static bool entering_sleep_state;
static int noresume = 0;
static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
if (!hibernation_ops)
return -ENOSYS;
+ entering_sleep_state = true;
/*
* We have cancelled the power trans
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote: > > > > Let's try to narrow it down to what the interaction is. Are you using > > > > something like acpi_sleep=s3_bios or similar? > > > > > > No. Not additional command line option except for resume=/dev/sda3 > > > reboot=bios > > > > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need > > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with > > echo mem > /sys/power/state. > > Cool, glad to hear at least one success report. :) STR is always working on my X60s. No green screen, no hang. Both s2ram and "echo mem > /sys/power/state". It's STD that's having problem. But strange thing is I could even restore console after STD even without agp and i915 module loaded, so I don't know how the console vga got saved and restored. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> Below is a patch that should work around the issue. Please try it and let
> me know if it helps.
I ended up applying the below patch instead, so it would build, and
unfortunately it still hung at suspend time.
So at this point, the known workarounds to the hang at suspend time are to
remove the device power down call or to boot with 'no_console_suspend'.
The 'screen turns green' problem is fixed by the extra 'inb' added in the
patch below (at least for me).
Jesse
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 35758a6..35b5a60 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
*
*/
+#include
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
dev_priv->saveGR[0x18]);
/* Attribute controller registers */
+ inb(st01); /* switch back to index mode */
for (i = 0; i < 20; i++)
i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
inb(st01); /* switch back to index mode */
@@ -249,6 +251,9 @@ static int i915_suspend(struct drm_device *dev)
return -ENODEV;
}
+ if (in_hibernation_power_off())
+ return 0;
+
pci_save_state(dev->pdev);
pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
@@ -364,7 +369,6 @@ static int i915_suspend(struct drm_device *dev)
i915_save_vga(dev);
/* Shut down the device */
- pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
return 0;
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 1d7d4c5..58d9f67 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t gfp_mask);
extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
#else /* CONFIG_HIBERNATION */
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_free(struct page *p)
{}
static inline void hibernation_set_ops(struct platform_hibernation_ops *ops)
{}
static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
#endif /* CONFIG_HIBERNATION */
#ifdef CONFIG_PM_SLEEP
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
index 859a8e5..d842bf0 100644
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -24,7 +24,7 @@
#include "power.h"
-
+static bool entering_sleep_state;
static int noresume = 0;
static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
if (!hibernation_ops)
return -ENOSYS;
+ entering_sleep_state = true;
/*
* We have cancelled the power transition by running
* hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
}
local_irq_enable();
+ entering_sleep_state = false;
/*
* We don't need to reenable the nonboot CPUs or resume consoles, since
* the system is going to be halted anyway.
@@ -427,6 +429,12 @@ int hibernation_platform_enter(void)
return error;
}
+bool in_hibernation_power_off(void)
+{
+ return entering_sleep_state;
+}
+EXPORT_SYMBOL(in_hibernation_power_off);
+
/**
* power_down - Shut the machine down for hibernation.
*
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote: > On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote: > > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote: > > > Hi Andrew, > > > > > > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails > > > to build on x86_64 machine > > > > > > CC drivers/acpi/osl.o > > > drivers/acpi/osl.c:60:38: error: empty filename in #include > > > drivers/acpi/osl.c: In function 'acpi_os_table_override': > > > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in this > > function) > > > drivers/acpi/osl.c:399: error: (Each undeclared identifier is reported > > only once > > > drivers/acpi/osl.c:399: error: for each function it appears in.) > > > make[2]: *** [drivers/acpi/osl.o] Error 1 > > > make[1]: *** [drivers/acpi] Error 2 > > > make: *** [drivers] Error 2 > > > > > > # > > > # Automatically generated make config: don't edit > > > # Linux kernel version: 2.6.25-rc2-mm1 > > > # Sun Feb 17 08:07:17 2008 > > > # > > > > > > > CONFIG_ACPI_CUSTOM_DSDT=y > > > CONFIG_ACPI_CUSTOM_DSDT_FILE="" > > > > > > garbage in, garbage out. > > garbage explicitly *allowed* by Kconfig in this case, though. > > > If you don't give this build option a file name where AmlCode lives, > > then the build will be unable to find AmlCode[]. > > > > http://www.lesswatts.org/projects/acpi/overridingDSDT.php > > So we have a .config option whose sole purpose is to use another > .config option? That seems ... less than ideal. Is there not some > Kconfig voodoo we can do to only require the one option? Maybe > something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the > Cc, in case he has any ideas. Make sure STANDALONE is y for your randconfig builds. See README for examples. STANALONE is there exactly to prevent the above but we cannot control randconfig. Sam - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Machine shutdown after resume from S3
Em Thursday 21 February 2008 14:46:45 Andrey Borzenkov escreveu:
> Herton Ronaldo Krzesinski wrote:
>
> > I have here an Intel Classmate hardware sample, and I have a weird problem
> > with suspend to ram, the machine does a power off when resuming.
> >
>
> Do you have acpid running? You may also be interested in this:
> http://qa.mandriva.com/show_bug.cgi?id=18998
> http://qa.mandriva.com/show_bug.cgi?id=23296
> http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup
>
>
> > I isolated the problem to the button acpi module, without loading it (or
> > just removing it before doing a s2ram) I don't get the problem. In the
> > specific machine I have here I can only resume it pressing the power
> > button, so I think this is related.
> >
>
> IIRC the issue was that button press that triggered resume was reported to
> user space. This apparently was fixed in the quoted patch; but may be this
> specific model goes via different code path?
In my case here is not an userspace issue. But the patch in the last link you
posted gave me an idea, to check code executed in resume, I managed to make
a quick hack that solved the issue:
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 293a1cb..2255434 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -156,6 +156,8 @@ static int acpi_pm_enter(suspend_state_t pm_state)
local_irq_save(flags);
acpi_enable_wakeup_device(acpi_state);
+ (void)
acpi_set_register(acpi_gbl_fixed_event_info[ACPI_EVENT_POWER_BUTTON].enable_register_id,
0);
+ (void)
acpi_set_register(acpi_gbl_fixed_event_info[ACPI_EVENT_POWER_BUTTON].status_register_id,
0);
switch (acpi_state) {
case ACPI_STATE_S1:
barrier();
For some reason with this I don't have the power off problem in resume.
I'll try to check more the code and acpi spec, but does this could indicate a
bug in bios?
--
[]'s
Herton
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > > > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes
> > > > > <[EMAIL PROTECTED]>
> > > >
> > > > wrote:
> > > > > > Ok, can you give this patch a try with the 'platform' method? It
> > > > > > should at least tell us what ACPI would like the device to do at
> > > > > > suspend time, but it probably won't fix the hang.
> > >
> > > It says "calling pci_set_power_state with 3". Then after all then it
> > > still hangs, and then resume with Mr Green.
> > >
> > > PM: Syncing filesystems ... done.
> > > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > > PM: Shrinking memory... ^H-^Hdone (0 pages freed)
> > > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> > > ACPI: Preparing to enter system sleep state S4
> > > Suspending console(s)
> > > sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > drm_sysfs_suspend
> > > ACPI: PCI interrupt for device :00:02.0 disabled
> > > calling pci_set_power_state with 3
> >
> > So it returns the right value.
> >
> > Jeff, Jesse, please check one thing for me.
Below is a patch that should work around the issue. Please try it and let me
know if it helps.
Thanks,
Rafael
---
drivers/char/drm/i915_drv.c |3 +++
include/linux/suspend.h |2 ++
kernel/power/disk.c |9 -
3 files changed, 13 insertions(+), 1 deletion(-)
Index: linux-2.6/include/linux/suspend.h
===
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
#else /* CONFIG_HIBERNATION */
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
#endif /* CONFIG_HIBERNATION */
#ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
#include "power.h"
-
+static bool entering_sleep_state;
static int noresume = 0;
static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
if (!hibernation_ops)
return -ENOSYS;
+ entering_sleep_state = true;
/*
* We have cancelled the power transition by running
* hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
}
local_irq_enable();
+ entering_sleep_state = false;
/*
* We don't need to reenable the nonboot CPUs or resume consoles, since
* the system is going to be halted anyway.
@@ -427,6 +429,11 @@ int hibernation_platform_enter(void)
return error;
}
+bool in_hibernation_power_off(void)
+{
+ return entering_sleep_state;
+}
+
/**
* power_down - Shut the machine down for hibernation.
*
Index: linux-2.6/drivers/char/drm/i915_drv.c
===
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -247,6 +247,9 @@ static int i915_suspend(struct drm_devic
return -ENODEV;
}
+ if (in_hibernation_power_off())
+ return 0;
+
pci_save_state(dev->pdev);
pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote: > > > Let's try to narrow it down to what the interaction is. Are you using > > > something like acpi_sleep=s3_bios or similar? > > > > No. Not additional command line option except for resume=/dev/sda3 > > reboot=bios > > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with > echo mem > /sys/power/state. Cool, glad to hear at least one success report. :) > This communication contains confidential information. It is for the > exclusive use of the intended addressee. If you are not the intended > addressee, please note that any form of distribution, copying or use of > this communication or the information in it is strictly prohibited by law. > If you have received this communication in error, please immediately notify > the sender by reply e-mail and destroy this message. Thank you for your > cooperation. Really? This contains confidential information? I'd better notify you and destroy this message now... :) Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > > > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes
> > > > > <[EMAIL PROTECTED]>
> > > >
> > > > wrote:
> > > > > > Ok, can you give this patch a try with the 'platform' method? It
> > > > > > should at least tell us what ACPI would like the device to do at
> > > > > > suspend time, but it probably won't fix the hang.
> > >
> > > It says "calling pci_set_power_state with 3". Then after all then it
> > > still hangs, and then resume with Mr Green.
> > >
> > > PM: Syncing filesystems ... done.
> > > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > > PM: Shrinking memory... ^H-^Hdone (0 pages freed)
> > > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> > > ACPI: Preparing to enter system sleep state S4
> > > Suspending console(s)
> > > sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > drm_sysfs_suspend
> > > ACPI: PCI interrupt for device :00:02.0 disabled
> > > calling pci_set_power_state with 3
> >
> > So it returns the right value.
> >
> > Jeff, Jesse, please check one thing for me.
> >
> > Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree)
> > with no_console_suspend and try to do the following:
> >
> > # echo 8 > /proc/sys/kernel/printk
> > # echo core > /sys/power/pm_test
> > # echo disk > /sys/power/state
> >
> > (that will run a test of the freeze/unfreeze code without creating the
> > image) and then
>
> That comes back for me, without creating the green screen. There's a long
> delay between it saying "entering S4" and actually resuming back to my
> console though.
There's an intentional 5 sec. wait. If the delay is longer that 5 sec., that's
a
bit strange.
> > # echo mem > /sys/power/state
> >
> > (that will run a test of the suspend/resume code without actually
> > suspending).
> >
> > I'd like to know if that works.
>
> This also works (after doing the echo disk > ...) above.
That's what I wanted to know, thanks.
> There's still a delay between "entering S3" and the resume to my console
> though.
If that's 5 sec., it's fine.
Please apply the appended patch and try to hibernate. I wonder if you get the
reboot or it hangs earlier.
Thanks,
Rafael
---
kernel/power/disk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
Index: linux-2.6/kernel/power/disk.c
===
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -405,11 +405,7 @@ int hibernation_platform_enter(void)
local_irq_disable();
error = device_power_down(PMSG_SUSPEND);
- if (!error) {
- hibernation_ops->enter();
- /* We should never get here */
- while (1);
- }
+ mdelay(1000);
local_irq_enable();
/*
@@ -424,6 +420,7 @@ int hibernation_platform_enter(void)
resume_console();
Close:
hibernation_ops->end();
+ kernel_restart(NULL);
return error;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thu, 2008-02-21 at 02:02 +0800, Jeff Chua wrote: > On Feb 21, 2008 1:52 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > Ahh. You're using the BIOS to re-initialize your video, aren't you? > > I don't know. Just pure simple "s2ram" without any options. Well, as far as I know, s2ram could be doing vbe save/restore for you. Even without parameter, if your laptop is in the whitelist. > > Let's try to narrow it down to what the interaction is. Are you using > > something like acpi_sleep=s3_bios or similar? > > No. Not additional command line option except for resume=/dev/sda3 reboot=bios My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with echo mem > /sys/power/state. Romano I imagine this will be received as blasphemy, but if only ndiswrapper were not horribly broken, this will be my day-by-day kernel. I just hope ath5k will arrive to my chipset soon... -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Machine shutdown after resume from S3
Matthew Garrett wrote: > On Thu, Feb 21, 2008 at 09:43:30PM +0300, Andrey Borzenkov wrote: > >> wait a bit; suspend to RAM is S1 not S3. > > Not on any even vaguely modern hardware, no. Yes, shame on me; I should not be doing several things at once. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Machine shutdown after resume from S3
On Thu, Feb 21, 2008 at 09:43:30PM +0300, Andrey Borzenkov wrote: > wait a bit; suspend to RAM is S1 not S3. Not on any even vaguely modern hardware, no. In any case, the Classmate reboots before entering userspace. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote: > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote: > > Hi Andrew, > > > > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails > > to build on x86_64 machine > > > > CC drivers/acpi/osl.o > > drivers/acpi/osl.c:60:38: error: empty filename in #include > > drivers/acpi/osl.c: In function 'acpi_os_table_override': > > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in this > function) > > drivers/acpi/osl.c:399: error: (Each undeclared identifier is reported > only once > > drivers/acpi/osl.c:399: error: for each function it appears in.) > > make[2]: *** [drivers/acpi/osl.o] Error 1 > > make[1]: *** [drivers/acpi] Error 2 > > make: *** [drivers] Error 2 > > > > # > > # Automatically generated make config: don't edit > > # Linux kernel version: 2.6.25-rc2-mm1 > > # Sun Feb 17 08:07:17 2008 > > # > > > > CONFIG_ACPI_CUSTOM_DSDT=y > > CONFIG_ACPI_CUSTOM_DSDT_FILE="" > > > garbage in, garbage out. garbage explicitly *allowed* by Kconfig in this case, though. > If you don't give this build option a file name where AmlCode lives, > then the build will be unable to find AmlCode[]. > > http://www.lesswatts.org/projects/acpi/overridingDSDT.php So we have a .config option whose sole purpose is to use another .config option? That seems ... less than ideal. Is there not some Kconfig voodoo we can do to only require the one option? Maybe something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the Cc, in case he has any ideas. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote: > On Thursday, 21 of February 2008, Jeff Chua wrote: > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote: > > > > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes > > > > <[EMAIL PROTECTED]> > > > > > > wrote: > > > > > Ok, can you give this patch a try with the 'platform' method? It > > > > > should at least tell us what ACPI would like the device to do at > > > > > suspend time, but it probably won't fix the hang. > > > > It says "calling pci_set_power_state with 3". Then after all then it > > still hangs, and then resume with Mr Green. > > > > PM: Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > > PM: Shrinking memory... ^H-^Hdone (0 pages freed) > > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s) > > ACPI: Preparing to enter system sleep state S4 > > Suspending console(s) > > sd 0:0:0:0: [sda] Synchronizing SCSI cache > > drm_sysfs_suspend > > ACPI: PCI interrupt for device :00:02.0 disabled > > calling pci_set_power_state with 3 > > So it returns the right value. > > Jeff, Jesse, please check one thing for me. > > Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree) > with no_console_suspend and try to do the following: > > # echo 8 > /proc/sys/kernel/printk > # echo core > /sys/power/pm_test > # echo disk > /sys/power/state > > (that will run a test of the freeze/unfreeze code without creating the > image) and then That comes back for me, without creating the green screen. There's a long delay between it saying "entering S4" and actually resuming back to my console though. > # echo mem > /sys/power/state > > (that will run a test of the suspend/resume code without actually > suspending). > > I'd like to know if that works. This also works (after doing the echo disk > ...) above. There's still a delay between "entering S3" and the resume to my console though. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Machine shutdown after resume from S3
Andrey Borzenkov wrote: > Herton Ronaldo Krzesinski wrote: > >> I have here an Intel Classmate hardware sample, and I have a weird >> problem with suspend to ram, wait a bit; suspend to RAM is S1 not S3. The mentined patch explicitly checks for S3 state and prevents power button event from reaching user space; but you are resuming from *S1*. Looks like this requires some sort of quirks to recognize this specific platform and apply the same workaround to S1. >> the machine does a power off when resuming. >> > > Do you have acpid running? You may also be interested in this: > http://qa.mandriva.com/show_bug.cgi?id=18998 > http://qa.mandriva.com/show_bug.cgi?id=23296 > http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup > > >> I isolated the problem to the button acpi module, without loading it (or >> just removing it before doing a s2ram) I don't get the problem. In the >> specific machine I have here I can only resume it pressing the power >> button, so I think this is related. >> > > IIRC the issue was that button press that triggered resume was reported to > user space. This apparently was fixed in the quoted patch; but may be this > specific model goes via different code path? > >> I started looking into the kernel code and did some tests. The first >> thing I tried just as a test was to disable the code in >> acpi_button_notify function. As expected it stopped to send the power >> button key events to /proc/acpi/event, but I still got the same s2ram >> issues. But if I disable acpi_install_fixed_event_handler calls in >> acpi_button_install_notify_handlers the power off issue in s2ram was >> gone, of course also with power button not notifying anything anymore :), >> but this was just a test. >> >> After this tests then I went further to try to track down the problem and >> I saw acpi_ev_fixed_event_dispatch, that is the function that will call >> acpi_button_notify_fixed. First thing I noted: the comment about >> acpi_ev_fixed_event_dispatch says it will return INTERRUPT_HANDLED or >> INTERRUPT_NOT_HANDLED, but acpi_button_notify_fixed return AE_OK, is this >> right (comment is outdated) or am I missing something? Anyway I changed >> AE_OK to ACPI_INTERRUPT_HANDLED but this didn't change nothing. In the >> end I stopped there, doesn't seem to be anything wrong with the code at >> all, I also took a look at acpi_ev_fixed_event_detect and other code >> related to the table of fixed events (acpi_gbl_fixed_event_handlers), but >> didn't got more clues. Could be this a bios issue, or there is some hints >> to what I can try to look and prove that it's bios or code related? >> >> PS.: with netconsole I don't get any message before power off after >> resume, I tried it to get more hints. >> >> -- >> []'s >> Herton >> - >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Machine shutdown after resume from S3
Herton Ronaldo Krzesinski wrote: > I have here an Intel Classmate hardware sample, and I have a weird problem > with suspend to ram, the machine does a power off when resuming. > Do you have acpid running? You may also be interested in this: http://qa.mandriva.com/show_bug.cgi?id=18998 http://qa.mandriva.com/show_bug.cgi?id=23296 http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup > I isolated the problem to the button acpi module, without loading it (or > just removing it before doing a s2ram) I don't get the problem. In the > specific machine I have here I can only resume it pressing the power > button, so I think this is related. > IIRC the issue was that button press that triggered resume was reported to user space. This apparently was fixed in the quoted patch; but may be this specific model goes via different code path? > I started looking into the kernel code and did some tests. The first thing > I tried just as a test was to disable the code in acpi_button_notify > function. As expected it stopped to send the power button key events > to /proc/acpi/event, but I still got the same s2ram issues. But if I > disable acpi_install_fixed_event_handler calls in > acpi_button_install_notify_handlers the power off issue in s2ram was gone, > of course also with power button not notifying anything anymore :), but > this was just a test. > > After this tests then I went further to try to track down the problem and > I saw acpi_ev_fixed_event_dispatch, that is the function that will call > acpi_button_notify_fixed. First thing I noted: the comment about > acpi_ev_fixed_event_dispatch says it will return INTERRUPT_HANDLED or > INTERRUPT_NOT_HANDLED, but acpi_button_notify_fixed return AE_OK, is this > right (comment is outdated) or am I missing something? Anyway I changed > AE_OK to ACPI_INTERRUPT_HANDLED but this didn't change nothing. In the end > I stopped there, doesn't seem to be anything wrong with the code at all, I > also took a look at acpi_ev_fixed_event_detect and other code related to > the table of fixed events (acpi_gbl_fixed_event_handlers), but didn't got > more clues. Could be this a bios issue, or there is some hints to what I > can try to look and prove that it's bios or code related? > > PS.: with netconsole I don't get any message before power off after > resume, I tried it to get more hints. > > -- > []'s > Herton > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:
> > OEMs that really want to modify the BIOS to recognize
> > OS interfaces that are in Linux should propose
> > new OSI strings that specify interfaces, not broad
> > categories of operating sytems; and in Linux we
> > shoudl use, or not use, those strings, as appropriate.
> > I've recently been in discussion with OEMs on exactly
> > this topic -- I'm sorry it didn't happen a year ago.
> So you mean "SLED 10 SP2", "UBUNTU supported version XY" strings?
No, no, no, no, no!
What part of "specify interfaces, not broad category of operating
sytems" didn't you understand?
So for example, if we if some vendor decides for some silly reason
that they must the Nvidia graphics chipsets, and Nvidia is the one
holdout which is lame about providing information so we can program
the video hardware correctly after a suspend/resume, maybe there is a
feature flag, OSI(LameNvidiaSuspendResume). The suppose 6 months
later, someone manages to disassemble the Nvidia driver in some legal
jurisdiction where there is no DMCA nonsense, and so Linux is now
capable of dealing with the video card itself. Now future kernels can
simply omit that very specific OSI string.
Just because we are saying that OSI(Linux) is bad, does not mean that
people are saying that OSI("SLED 10 SP2") is the right answer. Hell,
no! The right thing is something like OSI(LameNvidiaSusependResume).
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 100% C0 with 2.6.25-rc
On Thursday, 21 of February 2008, Jan Willies wrote: > Hi, > > Since 2.6.25-rc1 I have a lot of wakeups/s (≈134191,4) and spend 100% in C0. > It worked fine with 2.6.24 and commandline nolapic. Without nolapic I had 80k > wakeups/s after some time, but not right from the start like now. We have a regression from 2.6.24, apparently interrupts-related. > What useful information can I provide? Let's see what the experts say. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thursday, 21 of February 2008, Jeff Chua wrote: > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote: > > > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]> > > wrote: > > > > Ok, can you give this patch a try with the 'platform' method? It > > should > > > > at least tell us what ACPI would like the device to do at suspend time, > > > > but it probably won't fix the hang. > > It says "calling pci_set_power_state with 3". Then after all then it > still hangs, and then resume with Mr Green. > > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > PM: Shrinking memory... ^H-^Hdone (0 pages freed) > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s) > ACPI: Preparing to enter system sleep state S4 > Suspending console(s) > sd 0:0:0:0: [sda] Synchronizing SCSI cache > drm_sysfs_suspend > ACPI: PCI interrupt for device :00:02.0 disabled > calling pci_set_power_state with 3 So it returns the right value. Jeff, Jesse, please check one thing for me. Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree) with no_console_suspend and try to do the following: # echo 8 > /proc/sys/kernel/printk # echo core > /sys/power/pm_test # echo disk > /sys/power/state (that will run a test of the freeze/unfreeze code without creating the image) and then # echo mem > /sys/power/state (that will run a test of the suspend/resume code without actually suspending). I'd like to know if that works. Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote: > The bug is rather complicated to fix/workaround through the OS (E.g. suspend > reordering, AML bug, you simply misread the ACPI spec and it did work for > Windows (the ACPI kernel maintainer likes to add the "compatibility" hack, > but it's just too intrusive to backport into your stable kernel release you > support), ...). But a modification in the DSDT is a one-liner and an obvious > fix. > You desperately search for a flag to be able to make sure you do not risk to > break Windows... > Now they have to ignore the bug. Bad for the vendor, bad for the customer, > bad > for us (yet another complex "Windows compatibility" hack). And then later we fix the bug and the Linux workaround starts breaking things. The vendor is unhappy. You can't even just key it off kernel versions, since distributions will backport arbitrarily large chunks of code (and if you doubt this, take a look at the sata tree in the RHEL kernel some time). > A general Linux flag is the way to start, everything more specific will/can > get embedded into this flag later if it makes sense (without any risk for the > vendors to break Windows). There are (I expect most) cases where embedding > stuff into if(linux) makes a lot sense. But Henrique and others are probably > right that we need something more fine grained later (in rare cases, e.g. the > in-kernel graphics driver issues). There's no flag we can provide to indicate a desire for graphics POSTing. If vendors want to offer that, then they should provide an entry point that triggers it and a kernel driver that calls it. The policy for deciding whether or not to do this is far more complex than can be provided in-kernel. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, 21 Feb 2008, Sergio Monteiro Basto wrote: > On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 20 Feb 2008, Matthew Garrett wrote: > > > It doesn't punish them. They're the ones who are going to work with us > > > to ensure that Linux works on their hardware, and their needs are going > > > > And since when we have to work exactly like Windows (whatever version) does > > in THAT case? > > > > Also, why would one thing (proper replacement for OSI(Linux)) cause any sort > > of difference over the other (trying to be bug-to-bug compatible with > > Microsoft crap). > > > > I agree with Henrique. Since we have, in fact, more Windows cases than > Linux cases and for Linux, just announce that is recommended, > osi=linux. EH? I am *against* osi=Linux. I am for a proper *replacement* for OSI=Linux, *and* trying to be Windows-compatible where possible. > Also it is possible put Linuxs bios in a kind of white-list in kernel > code ... Linux-BIOS boxes *really* should not need ACPI for anything other than the very basic stuff, at all. Nor should them implement SMM handling, or any other such crap that always bite us back in the nether regions, with poisoined teeth. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ACPI: suspend: clear leftovers from S4BIOS.
On Thursday, 21 of February 2008, Alexey Starikovskiy wrote:
> S4BIOS is not supported, so there is no reason to expect
> it as input and try to do something wrong.
>
> Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Acked-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
>
> drivers/acpi/sleep/main.c |2 --
> drivers/acpi/sleep/proc.c |5 -
> 2 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
> index 293a1cb..3e85a68 100644
> --- a/drivers/acpi/sleep/main.c
> +++ b/drivers/acpi/sleep/main.c
> @@ -403,8 +403,6 @@ int acpi_suspend(u32 acpi_state)
>
> if (acpi_state < 6 && states[acpi_state])
> return pm_suspend(states[acpi_state]);
> - if (acpi_state == 4)
> - return hibernate();
> return -EINVAL;
> }
>
> diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c
> index f8df521..f530757 100644
> --- a/drivers/acpi/sleep/proc.c
> +++ b/drivers/acpi/sleep/proc.c
> @@ -60,11 +60,6 @@ acpi_system_write_sleep(struct file *file,
> if (copy_from_user(str, buffer, count))
> return -EFAULT;
>
> - /* Check for S4 bios request */
> - if (!strcmp(str, "4b")) {
> - error = acpi_suspend(4);
> - goto Done;
> - }
> state = simple_strtoul(str, NULL, 0);
> #ifdef CONFIG_HIBERNATION
> if (state == 4) {
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, 21 Feb 2008, Matthew Garrett wrote: > My concern with this is that until we know where we deviate from the > Windows behaviour, we don't know what strings we'd need to provide. And > once we *do* know where we deviate, we should fix that deviation rather > than provide an identifying string. IMO we should "fix" deviations *only* when it makes sense to do so (I bet at least one of the deviations we are going to find will be so hideously wrong and ugly when compared to the Right Thing, that we will be at a very unconfortable position if we need to implement it). We better reserve judgment of what deviations we should be fixing or not for when we find them in the first place. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thursday 21 February 2008 09:41:13 you wrote:
> Thomas,
> Thanks for the note.
> Please read the messages on linux-acpi with "dmi" in the subject
> for some background.
Can you be a bit more specific. Grepping for "dmi" is a bit verbose on the
linux-acpi list.
> yes, OSI(Linux) was enabled by default through 2.6.22
> and was disabled by default starting in 2.6.23.
>
> The reason it has come up recently is because
> it got into a reference BIOS -- and I'm sorry
> to admit that I was a party to that -- I
> wasn't thinking.
>
> Tomas Carnecky's reply is 100% correct.
> We can't support OSI(Linux) any more than we
> could support _OS="Linux", or Microsoft
> could support OSI(Windows) -- particularly
> on an OS that changes as fast as Linux does.
> To do so would in some cases put Linux at
> a permanent disadvantage to competing operating systems.
No, not providing an interface at all is a disadvantage, a permanent one.
You all look at this too much from the kernel point of view:
You are a vendor and you want to provide a BIOS update, because on the model
you sold with Linux on it, there is a bug. For some reason Linux is not 100%
compatible to Windows and the bug does only exist on Linux.
But you still have to support Windows on that machine and unfortunately this
machine got sold with Windows 10x more often than with Linux.
The bug is rather complicated to fix/workaround through the OS (E.g. suspend
reordering, AML bug, you simply misread the ACPI spec and it did work for
Windows (the ACPI kernel maintainer likes to add the "compatibility" hack,
but it's just too intrusive to backport into your stable kernel release you
support), ...). But a modification in the DSDT is a one-liner and an obvious
fix.
You desperately search for a flag to be able to make sure you do not risk to
break Windows...
Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad
for us (yet another complex "Windows compatibility" hack).
> Yes, we are attempting to close Pandora's box.
Too late and IMO there is nothing bad about it.
> I think we'll be successful, though we have to handle the
> Dell and Lenovo systems which actually use OSI(Linux)
> on purpose.
> Everybody else appears to be using it
> by mistake, sometimes with no effect,
> sometimes with negative effect.
Are you sure, they use it by mistake?
Again, think from a vendor's point of view...
What I expect happened here:
Vendors thought about better Linux support. Some already chose a distribution
which (most common should be Ubuntu here, It's Dell, already Acer? and
others?) They pre-load it with a specific, probably a rather stable release
and sell their laptops with it. And they have to provide support for it, at
least for the release they sold it with.
I expect the first thing they did when thinking about Linux support is that
they added something similar like:
Name (Linx, 0)
...
if (_OSI("Linux"))
Store(1, Linx)
to their BIOSes, the same they do for Windows'es they have to support.
They even may have verified it working... the "NOP".
Now if there pop up problems, they can and will use this to provide Linux
specific BIOS fixes with code that is only processed on Linux, because they
cannot risk to break Windows.
If you rip this out now you will see:
- white/black listed NOPs that break after a BIOS update with later
kernels
- No BIOS updates for Linux at all in this area (and this is what I mean
with permanent disadvantage)
> No, the DMI list is not large,
It is very confusing.
> it is mostly comments and it is __init.
That is not really important.
>
> I _strongly_ urge you to not fork from
> the .stable and mainline kernel in this area.
Matthew's arguments are quite interesting.
I still disagree with:
- simply ripping it out (at least do it soft)
- Remove all possibilities for vendors who want support Linux
to provide safe, only Linux affecting BIOS updates, just for
the sake of "being Windows compatible"
The strongest argument: I agree that they of course should contribute their
code and start working on the kernel, provide software updates etc.
But those guys do not have to share much, anyway:
(Some guessing now): Asus, Acer, Lenovo, Dell,...: have to make sure that they
buy and put hardware into their machines from companies that work on Linux
now. This is where we will see most advantages. They do not manufacture most
HW components themselves (network/wlan/sound/... cards). They manufacture or
at least have direct control over their BIOS, though. So this kind of hot-fix
is most convenient for them (or may be the only possibility for them).
> OEMs that really want to modify the BIOS to recognize
> OS interfaces that are in Linux should propose
> new OSI strings that specify interfaces, not broad
> categories of operating sytems; and in Linux we
> shoudl use, or not use, those strings, as appropriate.
> I've recently been in discussion with OEMs on exactly
> this topic -- I'm sorry it di
[PATCH] ACPI: suspend: clear leftovers from S4BIOS.
S4BIOS is not supported, so there is no reason to expect
it as input and try to do something wrong.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/main.c |2 --
drivers/acpi/sleep/proc.c |5 -
2 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 293a1cb..3e85a68 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -403,8 +403,6 @@ int acpi_suspend(u32 acpi_state)
if (acpi_state < 6 && states[acpi_state])
return pm_suspend(states[acpi_state]);
- if (acpi_state == 4)
- return hibernate();
return -EINVAL;
}
diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c
index f8df521..f530757 100644
--- a/drivers/acpi/sleep/proc.c
+++ b/drivers/acpi/sleep/proc.c
@@ -60,11 +60,6 @@ acpi_system_write_sleep(struct file *file,
if (copy_from_user(str, buffer, count))
return -EFAULT;
- /* Check for S4 bios request */
- if (!strcmp(str, "4b")) {
- error = acpi_suspend(4);
- goto Done;
- }
state = simple_strtoul(str, NULL, 0);
#ifdef CONFIG_HIBERNATION
if (state == 4) {
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Matthew Garrett wrote: On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote: How about WMI? Do you think that there will be some point in the future, when we could claim that our WMI implementation is the same as Windows + HW manufacturer private driver? When vendors require custom drivers, we're going to end up requiring a custom driver. That's true regardless of how the functionality is exposed. The solution there is to encourage vendors not to require custom drivers, not to get them to expose the same functionality in two different ways. It will always be two ways -- Windows way with WMI and other OSes way without it. The choice is there to place this non-Windows custom driver -- in C or in AML. This is their choice, right? If they choose to not create custom driver or have some concerns about complexity of its implementation in C rather than in AML, they should be allowed to choose AML. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
DMI Info Dell OptiPlex 745 Desktop model
Hello, I was instructed to send the following DMI info to this list, but the 2.6.23.16 kernel: ACPI: DMI System Vendor: Dell Inc. ACPI: DMI Product Name: OptiPlex 745 ACPI: DMI Product Version: ACPI: DMI Board Name: 0MM599 ACPI: DMI BIOS Vendor: Dell Inc. ACPI: DMI BIOS Date: 08/21/2007 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org Let me know if you need anything further (dmidecode output, etc). -- Coleman Kane IntelliTree Solutions llc - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote: > How about WMI? > Do you think that there will be some point in the future, > when we could claim that our WMI implementation is the > same as Windows + HW manufacturer private driver? When vendors require custom drivers, we're going to end up requiring a custom driver. That's true regardless of how the functionality is exposed. The solution there is to encourage vendors not to require custom drivers, not to get them to expose the same functionality in two different ways. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Matthew Garrett wrote: On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote: It would be much better if we define feature-specific OSI() strings that have well defined meanings for each place where Lenovo has to do something different than What Happens With Windows --- especially for stuff which is generic, since all laptop manufactuers need to interoperate with whatever cr*p Windows ship. At the end of the day, since Intel was originally too lazy to ship an ACPI conformance test suite, like it or not, Windows *has* become the APCI conformance test suite, and all laptop manufacturers (at least for today) must bow to the might and power which is the market share of Microsoft. My concern with this is that until we know where we deviate from the Windows behaviour, we don't know what strings we'd need to provide. And once we *do* know where we deviate, we should fix that deviation rather than provide an identifying string. How about WMI? Do you think that there will be some point in the future, when we could claim that our WMI implementation is the same as Windows + HW manufacturer private driver? Regards, Alex. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote: > It would be much better if we define feature-specific OSI() strings > that have well defined meanings for each place where Lenovo has to do > something different than What Happens With Windows --- especially for > stuff which is generic, since all laptop manufactuers need to > interoperate with whatever cr*p Windows ship. At the end of the day, > since Intel was originally too lazy to ship an ACPI conformance test > suite, like it or not, Windows *has* become the APCI conformance test > suite, and all laptop manufacturers (at least for today) must bow to > the might and power which is the market share of Microsoft. My concern with this is that until we know where we deviate from the Windows behaviour, we don't know what strings we'd need to provide. And once we *do* know where we deviate, we should fix that deviation rather than provide an identifying string. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 09:15:32AM +, Matthew Garrett wrote: > > Offering OSI(Linux) makes a statement about our implementation - we're > telling the firmware that it behaves in a certain way. That lets vendors > start depending on that behaviour, and if that behaviour turns out to be > different to Windows then we never get to fix that behaviour. Fine for > vendors that have special-cased their firmware, bad for the vast > majority of systems. Exactly, that's the problem. Suppose we put in an OSI(Linux), and Lenovo, thanks to the fact that they are working with Novell, puts in a special case hack just for whatever version of SLES they happen to be testing with. Well, great. Now suppose that three other laptops from different manufacturers (say, Sony, Fujitsu, and Asus) do things differently, the Windows way, and someone posts a patch to the ACPI drivers (and it might not and probably won't be the Thinkpad specific thinkpad_acpi.c file) which changes things so that it works for Sony, Fujitsu, et. al. --- and in the process, it breaks things for Lenovo, because the Lenovo is doing something special based on OSI(Linux) thanks to their special collaboration with Thomas Renniger and Novell. Oops. Now we have a mess, and we have to start having special DMI-based blacklists and whitelists, and life generally sucks. It would be much better if we define feature-specific OSI() strings that have well defined meanings for each place where Lenovo has to do something different than What Happens With Windows --- especially for stuff which is generic, since all laptop manufactuers need to interoperate with whatever cr*p Windows ship. At the end of the day, since Intel was originally too lazy to ship an ACPI conformance test suite, like it or not, Windows *has* become the APCI conformance test suite, and all laptop manufacturers (at least for today) must bow to the might and power which is the market share of Microsoft. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI patches for Linux-2.6.25-rc2
On Thursday 21 February 2008 06:18, Holger Macht wrote: > On Thu 21. Feb - 04:37:45, Len Brown wrote: > > sorry if this is a repeat. > > backing down to git 1.5.4 to see if it can send > > messages that vger.kernel.org likes... > > Any specific reason why the patch I sent one week ago should not not go > into 2.6.25-rc2? > > ACPI: Do not pass NULL to acpi_get_handle() when looking for _EJD > I didn't notice that one. it is on the test branch now. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.25-rc2
On Thu, Feb 21, 2008 at 07:17:16AM -0500, Len Brown wrote: > On Thursday 21 February 2008 04:54, Sam Ravnborg wrote: > > On Thu, Feb 21, 2008 at 03:57:07AM -0500, Len Brown wrote: > > > Hi Linus, > > > > > > please pull from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > release > > > > > > Fixes a pair of a boot regressions, and some churn mostly related > > > to some of the new thermal and thinkpad code that went into -rc1. > > > > > > This will update the files shown below. > > > > Hi Len. > > > > Any specific reason the two section mismatch patches that > > I posted a few days ago are not included? > > If they are buggy or questionable please let me know. > > > > I can resend if you like. > > they're still in the test branch. OK - thanks, Sam - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.25-rc2
On Thursday 21 February 2008 04:54, Sam Ravnborg wrote: > On Thu, Feb 21, 2008 at 03:57:07AM -0500, Len Brown wrote: > > Hi Linus, > > > > please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > release > > > > Fixes a pair of a boot regressions, and some churn mostly related > > to some of the new thermal and thinkpad code that went into -rc1. > > > > This will update the files shown below. > > Hi Len. > > Any specific reason the two section mismatch patches that > I posted a few days ago are not included? > If they are buggy or questionable please let me know. > > I can resend if you like. they're still in the test branch. -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] sony-laptop.c: fix off-by-one
On Tuesday 19 February 2008 18:27, Mattia Dongili wrote: > Acked-by: Mattia Dongili <[EMAIL PROTECTED]> applied. thanks, -len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
100% C0 with 2.6.25-rc
Hi, Since 2.6.25-rc1 I have a lot of wakeups/s (≈134191,4) and spend 100% in C0. It worked fine with 2.6.24 and commandline nolapic. Without nolapic I had 80k wakeups/s after some time, but not right from the start like now. What useful information can I provide? - Jan - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
dmidecode (Sony Vaio VGN-TX5MN)
Hi folks, hope I interpreted the boot message right. Find dmidecode output attached. Kind regards HHL # dmidecode 2.9 SMBIOS 2.4 present. 19 structures occupying 994 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: R0051N3 Release Date: 11/30/2006 Address: 0xE41F0 Runtime Size: 114192 bytes ROM Size: 1024 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported IEEE 1394 boot is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 5.1 Firmware Revision: 5.1 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Sony Corporation Product Name: VGN-TX5MN_W Version: J002E1W1 Serial Number: 28201552-5001397 UUID: D3E82F60-5B3C-11D9-839E-0013A9FA863C Wake-up Type: Power Switch SKU Number: N/A Family: N/A Handle 0x0002, DMI type 2, 10 bytes Base Board Information Manufacturer: Sony Corporation Product Name: VAIO Version: N/A Serial Number: N/A Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: Sony Corporation Type: Notebook Lock: Not Present Version: N/A Serial Number: J002E1W1 Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00FF Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: N/A Type: Central Processor Family: Other Manufacturer: GenuineIntel ID: EC 06 00 00 FF FB E9 AF Version: Intel(R) Core(TM) Solo CPU U1400 @ 1.20GHz Voltage: 1.1 V External Clock: 133 MHz Max Speed: 1200 MHz Current Speed: 1200 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: N/A Asset Tag: N/A Part Number: N/A Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 KB Maximum Size: 32 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: None System Type: Other Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 2048 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Burst Speed: Unknown Error Correction Type: None System Type: Data Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L3 Cache Configuration: Disabled, Not Socketed, Level 3 Operational Mode: Unknown Location: Unknown Installed Size: 0 KB Maximum Size: 0 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Burst Speed: Unknown Error Correction Type: None System Type: Data Associativity: 4-way Set-associative Handle 0x0008, DMI type 9, 13 bytes System Slot Information Designation: PCCARD1 Type: 32-bit PC Card (PCMCIA) Current Usage: Available Length: Other ID: Adapter 0, Socket 1 Characteristics: 5.0 V is provided 3.3 V is provided
Re: ACPI patches for Linux-2.6.25-rc2
On Thu 21. Feb - 04:37:45, Len Brown wrote: > sorry if this is a repeat. > backing down to git 1.5.4 to see if it can send > messages that vger.kernel.org likes... Any specific reason why the patch I sent one week ago should not not go into 2.6.25-rc2? ACPI: Do not pass NULL to acpi_get_handle() when looking for _EJD Thanks, Holger - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.25-rc2
On Thu, Feb 21, 2008 at 03:57:07AM -0500, Len Brown wrote: > Hi Linus, > > please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release > > Fixes a pair of a boot regressions, and some churn mostly related > to some of the new thermal and thinkpad code that went into -rc1. > > This will update the files shown below. Hi Len. Any specific reason the two section mismatch patches that I posted a few days ago are not included? If they are buggy or questionable please let me know. I can resend if you like. Sam - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/26] PM: Make suspend_device() static
From: Adrian Bunk <[EMAIL PROTECTED]>
suspend_device() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/base/power/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index bdc03f7..a96ca86 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -415,7 +415,7 @@ EXPORT_SYMBOL_GPL(device_power_down);
* @dev: Device.
* @state: Power state device is entering.
*/
-int suspend_device(struct device *dev, pm_message_t state)
+static int suspend_device(struct device *dev, pm_message_t state)
{
int error = 0;
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/26] Hibernation: Handle DEBUG_PAGEALLOC on x86
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make hibernation work with CONFIG_DEBUG_PAGEALLOC set on x86, by
checking if the pages to be copied are marked as present in the
kernel mapping and temporarily marking them as present if that's not
the case. No functional modifications are introduced if
CONFIG_DEBUG_PAGEALLOC is unset.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr.c | 19 ++-
include/linux/mm.h |6 ++
kernel/power/snapshot.c | 42 +-
3 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index e2a74ea..464d8fc 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -899,7 +899,24 @@ void kernel_map_pages(struct page *page, int numpages, int
enable)
*/
cpa_fill_pool();
}
-#endif
+
+#ifdef CONFIG_HIBERNATION
+
+bool kernel_page_present(struct page *page)
+{
+ unsigned int level;
+ pte_t *pte;
+
+ if (PageHighMem(page))
+ return false;
+
+ pte = lookup_address((unsigned long)page_address(page), &level);
+ return (pte_val(*pte) & _PAGE_PRESENT);
+}
+
+#endif /* CONFIG_HIBERNATION */
+
+#endif /* CONFIG_DEBUG_PAGEALLOC */
/*
* The testcases use internal knowledge of the implementation that shouldn't
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 26c7124..3b3e134 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1171,12 +1171,18 @@ static inline void enable_debug_pagealloc(void)
{
debug_pagealloc_enabled = 1;
}
+#ifdef CONFIG_HIBERNATION
+extern bool kernel_page_present(struct page *page);
+#endif /* CONFIG_HIBERNATION */
#else
static inline void
kernel_map_pages(struct page *page, int numpages, int enable) {}
static inline void enable_debug_pagealloc(void)
{
}
+#ifdef CONFIG_HIBERNATION
+static inline bool kernel_page_present(struct page *page) { return true; }
+#endif /* CONFIG_HIBERNATION */
#endif
extern struct vm_area_struct *get_gate_vma(struct task_struct *tsk);
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 95250d7..72a020c 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -875,8 +875,8 @@ static inline void *saveable_highmem_page(unsigned long
pfn) { return NULL; }
#endif /* CONFIG_HIGHMEM */
/**
- * saveable - Determine whether a non-highmem page should be included in
- * the suspend image.
+ * saveable_page - Determine whether a non-highmem page should be included
+ * in the suspend image.
*
* We should save the page if it isn't Nosave, and is not in the range
* of pages statically defined as 'unsaveable', and it isn't a part of
@@ -897,7 +897,8 @@ static struct page *saveable_page(unsigned long pfn)
if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page))
return NULL;
- if (PageReserved(page) && pfn_is_nosave(pfn))
+ if (PageReserved(page)
+ && (!kernel_page_present(page) || pfn_is_nosave(pfn)))
return NULL;
return page;
@@ -938,6 +939,25 @@ static inline void do_copy_page(long *dst, long *src)
*dst++ = *src++;
}
+
+/**
+ * safe_copy_page - check if the page we are going to copy is marked as
+ * present in the kernel page tables (this always is the case if
+ * CONFIG_DEBUG_PAGEALLOC is not set and in that case
+ * kernel_page_present() always returns 'true').
+ */
+static void safe_copy_page(void *dst, struct page *s_page)
+{
+ if (kernel_page_present(s_page)) {
+ do_copy_page(dst, page_address(s_page));
+ } else {
+ kernel_map_pages(s_page, 1, 1);
+ do_copy_page(dst, page_address(s_page));
+ kernel_map_pages(s_page, 1, 0);
+ }
+}
+
+
#ifdef CONFIG_HIGHMEM
static inline struct page *
page_is_saveable(struct zone *zone, unsigned long pfn)
@@ -946,8 +966,7 @@ page_is_saveable(struct zone *zone, unsigned long pfn)
saveable_highmem_page(pfn) : saveable_page(pfn);
}
-static inline void
-copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
+static void copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
{
struct page *s_page, *d_page;
void *src, *dst;
@@ -961,29 +980,26 @@ copy_data_page(unsigned long dst_pfn, unsigned long
src_pfn)
kunmap_atomic(src, KM_USER0);
kunmap_atomic(dst, KM_USER1);
} else {
- src = page_address(s_page);
if (PageHighMem(d_page)) {
/* Page pointed to by src may contain some kernel
* data modified by kmap_atomic()
*/
- do_copy_page(buffer, src);
+ safe_copy_page(buffer, s_page);
dst =
[PATCH 25/26] PCI ACPI: Fix comment describing acpi_pci_choose_state
From: Rafael J. Wysocki <[EMAIL PROTECTED]> The last line of the comment preceding the definition of acpi_pci_choose_state() is incorrect. Remove it. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/pci/pci-acpi.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index e569645..e818e52 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -241,8 +241,6 @@ EXPORT_SYMBOL(pci_osc_control_set); * choose from highest power _SxD to lowest power _SxW * else // no _PRW at S-state x * choose highest power _SxD or any lower power - * - * currently we simply return _SxD, if present. */ static pci_power_t acpi_pci_choose_state(struct pci_dev *pdev, -- 1.5.4 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/26] ACPI: thinkpad-acpi: minor hotkey_radio_sw fixes
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Fixes some minor points in the radio switch code and docs.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
Documentation/laptops/thinkpad-acpi.txt |2 +-
drivers/misc/thinkpad_acpi.c|8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 91f688c..606af16 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -306,7 +306,7 @@ sysfs notes:
The recommended polling frequency is 10Hz.
hotkey_radio_sw:
- if the ThinkPad has a hardware radio switch, this
+ If the ThinkPad has a hardware radio switch, this
attribute will read 0 if the switch is in the "radios
disabled" position, and 1 if the switch is in the
"radios enabled" position.
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 3548350..c119cf2 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1161,15 +1161,15 @@ static void tpacpi_input_send_radiosw(void)
{
int wlsw;
- mutex_lock(&tpacpi_inputdev_send_mutex);
-
if (tp_features.hotkey_wlsw && !hotkey_get_wlsw(&wlsw)) {
+ mutex_lock(&tpacpi_inputdev_send_mutex);
+
input_report_switch(tpacpi_inputdev,
SW_RADIO, !!wlsw);
input_sync(tpacpi_inputdev);
- }
- mutex_unlock(&tpacpi_inputdev_send_mutex);
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+ }
}
static void tpacpi_input_send_tabletsw(unsigned int state)
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/26] ACPI: sparse fix, replace macro with static function
From: Harvey Harrison <[EMAIL PROTECTED]>
replace acpi_util_eval_error macro with static function.
Avoid these sparse warnings due to using buffer within the macro.
drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/utils.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 34f1575..eba55b7 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -36,16 +36,20 @@ ACPI_MODULE_NAME("utils");
/* --
Object Evaluation Helpers
--
*/
+static void
+acpi_util_eval_error(acpi_handle h, acpi_string p, acpi_status s)
+{
#ifdef ACPI_DEBUG_OUTPUT
-#define acpi_util_eval_error(h,p,s) {\
- char prefix[80] = {'\0'};\
- struct acpi_buffer buffer = {sizeof(prefix), prefix};\
- acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);\
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",\
- (char *) prefix, p, acpi_format_exception(s))); }
+ char prefix[80] = {'\0'};
+ struct acpi_buffer buffer = {sizeof(prefix), prefix};
+ acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",
+ (char *) prefix, p, acpi_format_exception(s)));
#else
-#define acpi_util_eval_error(h,p,s)
+ return;
#endif
+}
+
acpi_status
acpi_extract_package(union acpi_object *package,
struct acpi_buffer *format, struct acpi_buffer *buffer)
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/26] ACPI: fix build warning
From: Ming Lin <[EMAIL PROTECTED]>
CC drivers/acpi/executer/exregion.o
drivers/acpi/executer/exregion.c: In function
âacpi_ex_pci_config_space_handlerâ:
drivers/acpi/executer/exregion.c:369: attention : passing argument 3 of
âacpi_os_read_pci_configurationâ from incompatible pointer type
exposed by 10270d4838bdc493781f5a1cf2e90e9c34c9142f
http://bugzilla.kernel.org/show_bug.cgi?id=9989
Signed-off-by: Ming Lin <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/executer/exregion.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/executer/exregion.c b/drivers/acpi/executer/exregion.c
index 2e9ce94..3f51b7e 100644
--- a/drivers/acpi/executer/exregion.c
+++ b/drivers/acpi/executer/exregion.c
@@ -338,6 +338,7 @@ acpi_ex_pci_config_space_handler(u32 function,
acpi_status status = AE_OK;
struct acpi_pci_id *pci_id;
u16 pci_register;
+ u32 value32;
ACPI_FUNCTION_TRACE(ex_pci_config_space_handler);
@@ -364,9 +365,9 @@ acpi_ex_pci_config_space_handler(u32 function,
switch (function) {
case ACPI_READ:
- *value = 0;
status = acpi_os_read_pci_configuration(pci_id, pci_register,
- value, bit_width);
+ &value32, bit_width);
+ *value = value32;
break;
case ACPI_WRITE:
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/26] ACPI: TSC breaks atkbd suspend
From: Pavel Machek <[EMAIL PROTECTED]>
TSC is used even on machines when CONFIG_X86_TSC is not set (X86_TSC
means _require_ TSC), but it is not properly disabled when it is
unusable, because ACPI code understood the config switch as "may use
TSC".
This actually fixes suspend problems on my x60.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_idle.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 980e1c3..6f3b217 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -364,7 +364,7 @@ int acpi_processor_resume(struct acpi_device * device)
return 0;
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
static int tsc_halts_in_c(int state)
{
switch (boot_cpu_data.x86_vendor) {
@@ -544,7 +544,7 @@ static void acpi_processor_idle(void)
/* Get end time (ticks) */
t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC halts in C2, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C2))
mark_tsc_unstable("possible TSC halt in C2");
@@ -609,7 +609,7 @@ static void acpi_processor_idle(void)
acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0);
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC halts in C3, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C3))
mark_tsc_unstable("TSC halts in C3");
@@ -1500,7 +1500,7 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
acpi_idle_do_entry(cx);
t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC could halt in idle, so notify users */
if (tsc_halts_in_c(cx->type))
mark_tsc_unstable("TSC halts in idle");;
@@ -1614,7 +1614,7 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
spin_unlock(&c3_lock);
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC could halt in idle, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C3))
mark_tsc_unstable("TSC halts in idle");
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/26] ACPI: thinkpad-acpi: add tablet-mode reporting
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
A quick study of the 0x5009/0x500A HKEY event on the X61t DSDT revealed the
existence of the EC HTAB register (EC 0x0f, bit 7), and a compare with the
X41t DSDT shows that HKEY.MHKG can be used to verify if the ThinkPad is
tablet-capable (MHKG present), and in tablet mode (bit 3 of MHKG return is
set).
Add an attribute to report this information, "hotkey_tablet_mode". This
attribute has poll()/select() support, and can be used along with EV_SW
SW_TABLET_MODE to hook userspace to tablet events.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
Documentation/laptops/thinkpad-acpi.txt |7 +++
drivers/misc/thinkpad_acpi.c| 79 ++
2 files changed, 75 insertions(+), 11 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 606af16..76cb428 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -313,6 +313,13 @@ sysfs notes:
This attribute has poll()/select() support.
+ hotkey_tablet_mode:
+ If the ThinkPad has tablet capabilities, this attribute
+ will read 0 if the ThinkPad is in normal mode, and
+ 1 if the ThinkPad is in tablet mode.
+
+ This attribute has poll()/select() support.
+
hotkey_report_mode:
Returns the state of the procfs ACPI event report mode
filter for hot keys. If it is set to 1 (the default),
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index c119cf2..bb269d0 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -221,6 +221,7 @@ static struct {
u32 hotkey:1;
u32 hotkey_mask:1;
u32 hotkey_wlsw:1;
+ u32 hotkey_tablet:1;
u32 light:1;
u32 light_status:1;
u32 bright_16levels:1;
@@ -1060,6 +1061,9 @@ static struct attribute_set *hotkey_dev_attributes;
#define HOTKEY_CONFIG_CRITICAL_END
#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+/* HKEY.MHKG() return bits */
+#define TP_HOTKEY_TABLET_MASK (1 << 3)
+
static int hotkey_get_wlsw(int *status)
{
if (!acpi_evalf(hkey_handle, status, "WLSW", "d"))
@@ -1067,6 +1071,16 @@ static int hotkey_get_wlsw(int *status)
return 0;
}
+static int hotkey_get_tablet_mode(int *status)
+{
+ int s;
+
+ if (!acpi_evalf(hkey_handle, &s, "MHKG", "d"))
+ return -EIO;
+
+ return ((s & TP_HOTKEY_TABLET_MASK) != 0);
+}
+
/*
* Call with hotkey_mutex held
*/
@@ -1172,15 +1186,20 @@ static void tpacpi_input_send_radiosw(void)
}
}
-static void tpacpi_input_send_tabletsw(unsigned int state)
+static void tpacpi_input_send_tabletsw(void)
{
- mutex_lock(&tpacpi_inputdev_send_mutex);
+ int state;
- input_report_switch(tpacpi_inputdev,
- SW_TABLET_MODE, !!state);
- input_sync(tpacpi_inputdev);
+ if (tp_features.hotkey_tablet &&
+ !hotkey_get_tablet_mode(&state)) {
+ mutex_lock(&tpacpi_inputdev_send_mutex);
- mutex_unlock(&tpacpi_inputdev_send_mutex);
+ input_report_switch(tpacpi_inputdev,
+ SW_TABLET_MODE, !!state);
+ input_sync(tpacpi_inputdev);
+
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+ }
}
static void tpacpi_input_send_key(unsigned int scancode)
@@ -1691,6 +1710,29 @@ static void hotkey_radio_sw_notify_change(void)
"hotkey_radio_sw");
}
+/* sysfs hotkey tablet mode (pollable) - */
+static ssize_t hotkey_tablet_mode_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int res, s;
+ res = hotkey_get_tablet_mode(&s);
+ if (res < 0)
+ return res;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", !!s);
+}
+
+static struct device_attribute dev_attr_hotkey_tablet_mode =
+ __ATTR(hotkey_tablet_mode, S_IRUGO, hotkey_tablet_mode_show, NULL);
+
+static void hotkey_tablet_mode_notify_change(void)
+{
+ if (tp_features.hotkey_tablet)
+ sysfs_notify(&tpacpi_pdev->dev.kobj, NULL,
+"hotkey_tablet_mode");
+}
+
/* sysfs hotkey report_mode */
static ssize_t hotkey_report_mode_show(struct device *dev,
struct device_attribute *attr,
@@ -1903,7 +1945,7 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
str_supported(tp_features.hotkey));
if (tp_features.hotkey) {
- hotkey_dev_attributes = create_attr_set(12, NULL);
+ hotkey_dev_attributes = create_attr_set(13, NULL);
if (!hotkey_dev_attri
[PATCH 21/26] ACPI: remove is_processor_present prototype
From: Glauber Costa <[EMAIL PROTECTED]>
The function itself is defined just below, so this prototype is not really
useful.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 75ccf5d..923fddb 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -826,8 +826,6 @@ static int acpi_processor_remove(struct acpi_device
*device, int type)
* Acpi processor hotplug support *
/
-static int is_processor_present(acpi_handle handle);
-
static int is_processor_present(acpi_handle handle)
{
acpi_status status;
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/26] ACPI: thinkpad-acpi: improve thinkpad-acpi input device documentation
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Fix a few spelling errors, and also document the EV_SW events thinkpad-acpi can issue. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- Documentation/laptops/thinkpad-acpi.txt | 48 +- 1 files changed, 27 insertions(+), 21 deletions(-) diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 0ae5708..91f688c 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -160,7 +160,7 @@ Hot keys procfs: /proc/acpi/ibm/hotkey sysfs device attribute: hotkey_* -In a ThinkPad, the ACPI HKEY handler is responsible for comunicating +In a ThinkPad, the ACPI HKEY handler is responsible for communicating some important events and also keyboard hot key presses to the operating system. Enabling the hotkey functionality of thinkpad-acpi signals the firmware that such a driver is present, and modifies how the ThinkPad @@ -193,7 +193,7 @@ Not all bits in the mask can be modified. Not all bits that can be modified do anything. Not all hot keys can be individually controlled by the mask. Some models do not support the mask at all, and in those models, hot keys cannot be controlled individually. The behaviour of -the mask is, therefore, higly dependent on the ThinkPad model. +the mask is, therefore, highly dependent on the ThinkPad model. Note that unmasking some keys prevents their default behavior. For example, if Fn+F5 is unmasked, that key will no longer enable/disable @@ -288,7 +288,7 @@ sysfs notes: in ACPI event mode, volume up/down/mute are reported as separate events, but this behaviour may be corrected in future releases of this driver, in which case the - ThinkPad volume mixer user interface semanthics will be + ThinkPad volume mixer user interface semantics will be enforced. hotkey_poll_freq: @@ -308,7 +308,7 @@ sysfs notes: hotkey_radio_sw: if the ThinkPad has a hardware radio switch, this attribute will read 0 if the switch is in the "radios - disabled" postition, and 1 if the switch is in the + disabled" position, and 1 if the switch is in the "radios enabled" position. This attribute has poll()/select() support. @@ -339,7 +339,7 @@ sysfs notes: wakeup_hotunplug_complete: Set to 1 if the system was waken up because of an undock or bay ejection request, and that request - was sucessfully completed. At this point, it might + was successfully completed. At this point, it might be useful to send the system back to sleep, at the user's choice. Refer to HKEY events 0x4003 and 0x3003, below. @@ -392,7 +392,7 @@ event codeKey Notes Lenovo: battery 0x1004 0x03FN+F4 Sleep button (ACPI sleep button - semanthics, i.e. sleep-to-RAM). + semantics, i.e. sleep-to-RAM). It is always generate some kind of event, either the hot key event or a ACPI sleep button @@ -403,12 +403,12 @@ event codeKey Notes time passes. 0x1005 0x04FN+F5 Radio. Enables/disables - the internal BlueTooth hardware + the internal Bluetooth hardware and W-WAN card if left in control of the firmware. Does not affect the WLAN card. Should be used to turn on/off all - radios (bluetooth+W-WAN+WLAN), + radios (Bluetooth+W-WAN+WLAN), really. 0x1006 0x05FN+F6 - @@ -417,7 +417,7 @@ event codeKey Notes Do you feel lucky today? 0x1008 0x07FN+F8 IBM: toggle screen expand - Lenovo: configure ultranav + Lenovo: configure UltraNav 0x1009 0x08FN+F9 - .. .. .. @@ -447,7 +447,7 @@ event codeKey Notes 0x1011 0x10FN+END Brightness down. See brightness up for details. -0x1012 0x11FN+PGUP Thinklight toggle. This key is +0x1012 0x11FN+PGUP ThinkLight toggle. This key is always handled by the firmware,
[PATCH 20/26] acer-wmi: Add DMI match for mail LED on Acer TravelMate 4200 series
From: Carlos Corbacho <[EMAIL PROTECTED]>
The TM4200 series use the same method as the TM2490 series to control the
mail LED, so add a DMI based quirk for these laptops.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/acer-wmi.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/acer-wmi.c b/drivers/misc/acer-wmi.c
index d7aea93..74d12b4 100644
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@ -273,6 +273,15 @@ static struct dmi_system_id acer_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = "Acer TravelMate 4200",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4200"),
+ },
+ .driver_data = &quirk_acer_travelmate_2490,
+ },
+ {
+ .callback = dmi_matched,
.ident = "Medion MD 98300",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/26] ACPI: thinkpad-acpi: trivial fix to documentation
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Fix a stray ibm-acpi that should have been replaced with thinkpad-acpi. Thanks to Damjan <[EMAIL PROTECTED]> for noticing this one. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- Documentation/laptops/thinkpad-acpi.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 6c24777..33d6e5a 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1309,7 +1309,7 @@ Enabling debugging output The module takes a debug parameter which can be used to selectively enable various classes of debugging output, for example: -modprobe ibm_acpi debug=0x +modprobe thinkpad_acpi debug=0x will enable all debugging output classes. It takes a bitmask, so to enable more than one output class, just add their values. -- 1.5.4 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/26] ACPI: thinkpad-acpi: issue input events for tablet swivel events
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Issue EV_SW SW_TABLET_MODE events for HKEY events 0x5009 and 0x500A on the
X41t/X60t/X61t. As usual, we suppress the HKEY events on the netlink
interface to avoid sending duplicate events to userspace.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
Documentation/laptops/thinkpad-acpi.txt |4 ++--
drivers/misc/thinkpad_acpi.c| 22 --
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 33d6e5a..0ae5708 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -491,6 +491,8 @@ generate input device EV_KEY events.
Non hot-key ACPI HKEY event map:
0x5001 Lid closed
0x5002 Lid opened
+0x5009 Tablet swivel: switched to tablet mode
+0x500A Tablet swivel: switched to normal mode
0x7000 Radio Switch may have changed state
The above events are not propagated by the driver, except for legacy
@@ -505,8 +507,6 @@ The above events are never propagated by the driver.
0x3003 Bay ejection (see 0x2x05) complete, can sleep again
0x4003 Undocked (see 0x2x04), can sleep again
-0x5009 Tablet swivel: switched to tablet mode
-0x500A Tablet swivel: switched to normal mode
0x500B Tablet pen insterted into its storage bay
0x500C Tablet pen removed from its storage bay
0x5010 Brightness level changed (newer Lenovo BIOSes)
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 4ea3866..3548350 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1172,6 +1172,17 @@ static void tpacpi_input_send_radiosw(void)
mutex_unlock(&tpacpi_inputdev_send_mutex);
}
+static void tpacpi_input_send_tabletsw(unsigned int state)
+{
+ mutex_lock(&tpacpi_inputdev_send_mutex);
+
+ input_report_switch(tpacpi_inputdev,
+ SW_TABLET_MODE, !!state);
+ input_sync(tpacpi_inputdev);
+
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+}
+
static void tpacpi_input_send_key(unsigned int scancode)
{
unsigned int keycode;
@@ -2020,6 +2031,10 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
set_bit(EV_SW, tpacpi_inputdev->evbit);
set_bit(SW_RADIO, tpacpi_inputdev->swbit);
}
+ if (thinkpad_id.vendor == PCI_VENDOR_ID_LENOVO) {
+ set_bit(EV_SW, tpacpi_inputdev->evbit);
+ set_bit(SW_TABLET_MODE, tpacpi_inputdev->swbit);
+ }
dbg_printk(TPACPI_DBG_INIT,
"enabling hot key handling\n");
@@ -2169,11 +2184,14 @@ static void hotkey_notify(struct ibm_struct *ibm, u32
event)
/* 0x5000-0x5FFF: human interface helpers */
switch (hkey) {
case 0x5010: /* Lenovo new BIOS: brightness changed */
- case 0x5009: /* X61t: swivel up (tablet mode) */
- case 0x500a: /* X61t: swivel down (normal mode) */
case 0x500b: /* X61t: tablet pen inserted into bay */
case 0x500c: /* X61t: tablet pen removed from bay */
break;
+ case 0x5009: /* X61t: swivel up (tablet mode) */
+ case 0x500a: /* X61t: swivel down (normal mode) */
+ tpacpi_input_send_tabletsw((hkey == 0x5009));
+ send_acpi_ev = 0;
+ break;
case 0x5001:
case 0x5002:
/* LID switch events. Do not propagate */
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/26] ACPI: thinkpad-acpi: always track input device open/close
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
The open() and close() hooks for the input device are useful even when
hotkey NVRAM polling support is not in use, so it is better to always have
them around.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 723d37b..6da3f40 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1417,6 +1417,14 @@ static void hotkey_poll_setup_safe(int may_warn)
mutex_unlock(&hotkey_mutex);
}
+#else /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+
+static void hotkey_poll_setup_safe(int __unused)
+{
+}
+
+#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+
static int hotkey_inputdev_open(struct input_dev *dev)
{
switch (tpacpi_lifecycle) {
@@ -1444,7 +1452,6 @@ static void hotkey_inputdev_close(struct input_dev *dev)
if (tpacpi_lifecycle == TPACPI_LIFE_RUNNING)
hotkey_poll_setup_safe(0);
}
-#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
/* sysfs hotkey enable - */
static ssize_t hotkey_enable_show(struct device *dev,
@@ -2023,12 +2030,10 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
(hotkey_report_mode < 2) ?
"enabled" : "disabled");
-#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
tpacpi_inputdev->open = &hotkey_inputdev_open;
tpacpi_inputdev->close = &hotkey_inputdev_close;
hotkey_poll_setup_safe(1);
-#endif
}
return (tp_features.hotkey)? 0 : 1;
@@ -2221,9 +2226,7 @@ static void hotkey_resume(void)
hotkey_radio_sw_notify_change();
hotkey_wakeup_reason_notify_change();
hotkey_wakeup_hotunplug_complete_notify_change();
-#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
hotkey_poll_setup_safe(0);
-#endif
}
/* procfs -- */
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/26] ACPI: thinkpad-acpi: trivial fix to module_desc typo
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Thanks to Damjan <[EMAIL PROTECTED]> for noticing this one. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/misc/thinkpad_acpi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index e2c7edd..723d37b 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -5918,7 +5918,7 @@ MODULE_PARM_DESC(hotkey_report_mode, #define TPACPI_PARAM(feature) \ module_param_call(feature, set_ibm_param, NULL, NULL, 0); \ - MODULE_PARM_DESC(feature, "Simulates thinkpad-aci procfs command " \ + MODULE_PARM_DESC(feature, "Simulates thinkpad-acpi procfs command " \ "at module load, see documentation") TPACPI_PARAM(hotkey); -- 1.5.4 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/26] ACPI: thinkpad-acpi: synchronize input device switches
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Issue EV_SW events at module init time to synchronize the input device with the current state of the switch, otherwise we might lose the first event. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/misc/thinkpad_acpi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index 6da3f40..02f9465 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -2034,6 +2034,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) tpacpi_inputdev->close = &hotkey_inputdev_close; hotkey_poll_setup_safe(1); + tpacpi_input_send_radiosw(); } return (tp_features.hotkey)? 0 : 1; -- 1.5.4 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/26] ACPI: thinkpad-acpi: make the video output feature optional
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
The video output port control feature is not very useful on many ThinkPads
(especially when a X server is running), and lately userspace is getting
better and better at it, so it makes sense to allow users to stripe out the
thinkpad-acpi video feature from their kernels and save at least 2KB.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig | 17 +
drivers/misc/thinkpad_acpi.c | 20 +---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1abc95c..982e27b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -258,6 +258,23 @@ config THINKPAD_ACPI_BAY
If you are not sure, say Y here.
+config THINKPAD_ACPI_VIDEO
+ bool "Video output control support"
+ depends on THINKPAD_ACPI
+ default y
+ ---help---
+ Allows the thinkpad_acpi driver to provide an interface to control
+ the various video output ports.
+
+ This feature often won't work well, depending on ThinkPad model,
+ display state, video output devices in use, whether there is a X
+ server running, phase of the moon, and the current mood of
+ Schroedinger's cat. If you can use X.org's RandR to control
+ your ThinkPad's video output ports instead of this feature,
+ don't think twice: do it and say N here to save some memory.
+
+ If you are not sure, say Y here.
+
config THINKPAD_ACPI_HOTKEY_POLL
bool "Suport NVRAM polling for hot keys"
depends on THINKPAD_ACPI
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 02f9465..4ea3866 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -301,6 +301,13 @@ TPACPI_HANDLE(hkey, ec, "\\_SB.HKEY", /* 600e/x,
770e, 770x */
"HKEY", /* all others */
); /* 570 */
+TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */
+ "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */
+ "\\_SB.PCI0.VID0", /* 770e */
+ "\\_SB.PCI0.VID",/* A21e, G4x, R50e, X30, X40 */
+ "\\_SB.PCI0.AGP.VID",/* all others */
+ ); /* R30, R31 */
+
/*
* ACPI helpers
@@ -2680,6 +2687,8 @@ static struct ibm_struct wan_driver_data = {
* Video subdriver
*/
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
+
enum video_access_mode {
TPACPI_VIDEO_NONE = 0,
TPACPI_VIDEO_570, /* 570 */
@@ -2707,13 +2716,6 @@ static int video_orig_autosw;
static int video_autosw_get(void);
static int video_autosw_set(int enable);
-TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */
- "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */
- "\\_SB.PCI0.VID0", /* 770e */
- "\\_SB.PCI0.VID",/* A21e, G4x, R50e, X30, X40 */
- "\\_SB.PCI0.AGP.VID",/* all others */
- ); /* R30, R31 */
-
TPACPI_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID"); /* G41 */
static int __init video_init(struct ibm_init_struct *iibm)
@@ -3023,6 +3025,8 @@ static struct ibm_struct video_driver_data = {
.exit = video_exit,
};
+#endif /* CONFIG_THINKPAD_ACPI_VIDEO */
+
/*
* Light (thinklight) subdriver
*/
@@ -5807,10 +5811,12 @@ static struct ibm_init_struct ibms_init[] __initdata = {
.init = wan_init,
.data = &wan_driver_data,
},
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
{
.init = video_init,
.data = &video_driver_data,
},
+#endif
{
.init = light_init,
.data = &light_driver_data,
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/26] intel_menlo: extract return values using PTR_ERR
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/intel_menlow.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/intel_menlow.c b/drivers/misc/intel_menlow.c
index f70984a..de16e88 100644
--- a/drivers/misc/intel_menlow.c
+++ b/drivers/misc/intel_menlow.c
@@ -170,10 +170,13 @@ static int intel_menlow_memory_add(struct acpi_device
*device)
cdev = thermal_cooling_device_register("Memory controller", device,
&memory_cooling_ops);
- acpi_driver_data(device) = cdev;
- if (!cdev)
- result = -ENODEV;
- else {
+ if (IS_ERR(cdev)) {
+ result = PTR_ERR(cdev);
+ goto end;
+ }
+
+ if (cdev) {
+ acpi_driver_data(device) = cdev;
result = sysfs_create_link(&device->dev.kobj,
&cdev->device.kobj, "thermal_cooling");
if (result)
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/26] ACPI thermal: extract return values using PTR_ERR
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c | 37 ++---
1 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 75ccf5d..b020069 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -670,21 +670,26 @@ static int __cpuinit acpi_processor_start(struct
acpi_device *device)
pr->cdev = thermal_cooling_device_register("Processor", device,
&processor_cooling_ops);
- if (pr->cdev)
+ if (IS_ERR(pr->cdev)) {
+ result = PTR_ERR(pr->cdev);
+ goto end;
+ }
+ if (pr->cdev) {
printk(KERN_INFO PREFIX
"%s is registered as cooling_device%d\n",
device->dev.bus_id, pr->cdev->id);
- else
- goto end;
- result = sysfs_create_link(&device->dev.kobj, &pr->cdev->device.kobj,
- "thermal_cooling");
- if (result)
- return result;
- result = sysfs_create_link(&pr->cdev->device.kobj, &device->dev.kobj,
- "device");
- if (result)
- return result;
+ result = sysfs_create_link(&device->dev.kobj,
+ &pr->cdev->device.kobj,
+ "thermal_cooling");
+ if (result)
+ return result;
+ result = sysfs_create_link(&pr->cdev->device.kobj,
+ &device->dev.kobj,
+ "device");
+ if (result)
+ return result;
+ }
if (pr->flags.throttling) {
printk(KERN_INFO PREFIX "%s [%s] (supports",
@@ -809,10 +814,12 @@ static int acpi_processor_remove(struct acpi_device
*device, int type)
acpi_processor_remove_fs(device);
- sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
- sysfs_remove_link(&pr->cdev->device.kobj, "device");
- thermal_cooling_device_unregister(pr->cdev);
- pr->cdev = NULL;
+ if (pr->cdev) {
+ sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+ sysfs_remove_link(&pr->cdev->device.kobj, "device");
+ thermal_cooling_device_unregister(pr->cdev);
+ pr->cdev = NULL;
+ }
processors[pr->id] = NULL;
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/26] ACPI: EC: Use proper handle for boot EC
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
Fall back to ACPI_ROOT_HANDLE only in case of error.
ACPI: EC: EC description table is found, configuring boot EC
ACPI Error (evregion-0316): No handler for Region [ECOR] (81007a651620)
[EmbeddedControl] [20070126]
ACPI Error (exfldio-0289): Region EmbeddedControl(3) has no handler [20070126]
http://bugzilla.kernel.org/show_bug.cgi?id=9916
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7222a18..caf873c 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -943,7 +943,11 @@ int __init acpi_ec_ecdt_probe(void)
boot_ec->command_addr = ecdt_ptr->control.address;
boot_ec->data_addr = ecdt_ptr->data.address;
boot_ec->gpe = ecdt_ptr->gpe;
- boot_ec->handle = ACPI_ROOT_OBJECT;
+ if (ACPI_FAILURE(acpi_get_handle(NULL, ecdt_ptr->id,
+ &boot_ec->handle))) {
+ pr_info("Failed to locate handle for boot EC\n");
+ boot_ec->handle = ACPI_ROOT_OBJECT;
+ }
} else {
/* This workaround is needed only on some broken machines,
* which require early EC, but fail to provide ECDT */
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/26] ACPI fan: extract return values using PTR_ERR
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly. thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/fan.c | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 48cb705..c8e3cba 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -256,22 +256,28 @@ static int acpi_fan_add(struct acpi_device *device)
cdev = thermal_cooling_device_register("Fan", device,
&fan_cooling_ops);
- if (cdev)
+ if (IS_ERR(cdev)) {
+ result = PTR_ERR(cdev);
+ goto end;
+ }
+ if (cdev) {
printk(KERN_INFO PREFIX
"%s is registered as cooling_device%d\n",
device->dev.bus_id, cdev->id);
- else
- goto end;
- acpi_driver_data(device) = cdev;
- result = sysfs_create_link(&device->dev.kobj, &cdev->device.kobj,
- "thermal_cooling");
- if (result)
- return result;
- result = sysfs_create_link(&cdev->device.kobj, &device->dev.kobj,
- "device");
-if (result)
-return result;
+ acpi_driver_data(device) = cdev;
+ result = sysfs_create_link(&device->dev.kobj,
+ &cdev->device.kobj,
+ "thermal_cooling");
+ if (result)
+ return result;
+
+ result = sysfs_create_link(&cdev->device.kobj,
+ &device->dev.kobj,
+ "device");
+ if (result)
+ return result;
+ }
result = acpi_fan_add_fs(device);
if (result)
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/26] ACPI video: check for error from thermal_cooling_device_register
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to check whether thermal_cooling_device_register
returned ERROR or not.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/video.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 7f714fa..12cce69 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -731,6 +731,9 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
device->cdev = thermal_cooling_device_register("LCD",
device->dev, &video_cooling_ops);
+ if (IS_ERR(device->cdev))
+ return;
+
if (device->cdev) {
printk(KERN_INFO PREFIX
"%s is registered as cooling_device%d\n",
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/26] thermal: use ERR_PTR for returning error
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to return using ERR_PTR instead of NULL
in case of errors.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/thermal/thermal.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c
index 5f1d318..8b86e53 100644
--- a/drivers/thermal/thermal.c
+++ b/drivers/thermal/thermal.c
@@ -448,20 +448,20 @@ struct thermal_cooling_device
*thermal_cooling_device_register(char *type,
int result;
if (strlen(type) >= THERMAL_NAME_LENGTH)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (!ops || !ops->get_max_state || !ops->get_cur_state ||
!ops->set_cur_state)
- return NULL;
+ return ERR_PTR(-EINVAL);
cdev = kzalloc(sizeof(struct thermal_cooling_device), GFP_KERNEL);
if (!cdev)
- return NULL;
+ return ERR_PTR(-ENOMEM);
result = get_idr(&thermal_cdev_idr, &thermal_idr_lock, &cdev->id);
if (result) {
kfree(cdev);
- return NULL;
+ return ERR_PTR(result);
}
strcpy(cdev->type, type);
@@ -473,7 +473,7 @@ struct thermal_cooling_device
*thermal_cooling_device_register(char *type,
if (result) {
release_idr(&thermal_cdev_idr, &thermal_idr_lock, cdev->id);
kfree(cdev);
- return NULL;
+ return ERR_PTR(result);
}
/* sys I/F */
@@ -509,7 +509,7 @@ struct thermal_cooling_device
*thermal_cooling_device_register(char *type,
unregister:
release_idr(&thermal_cdev_idr, &thermal_idr_lock, cdev->id);
device_unregister(&cdev->device);
- return NULL;
+ return ERR_PTR(result);
}
EXPORT_SYMBOL(thermal_cooling_device_register);
@@ -581,17 +581,17 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
int count;
if (strlen(type) >= THERMAL_NAME_LENGTH)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (trips > THERMAL_MAX_TRIPS || trips < 0)
- return NULL;
+ return ERR_PTR(-EINVAL);
if (!ops || !ops->get_temp)
- return NULL;
+ return ERR_PTR(-EINVAL);
tz = kzalloc(sizeof(struct thermal_zone_device), GFP_KERNEL);
if (!tz)
- return NULL;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&tz->cooling_devices);
idr_init(&tz->idr);
@@ -599,7 +599,7 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
result = get_idr(&thermal_tz_idr, &thermal_idr_lock, &tz->id);
if (result) {
kfree(tz);
- return NULL;
+ return ERR_PTR(result);
}
strcpy(tz->type, type);
@@ -612,7 +612,7 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
if (result) {
release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);
kfree(tz);
- return NULL;
+ return ERR_PTR(result);
}
/* sys I/F */
@@ -654,7 +654,7 @@ struct thermal_zone_device
*thermal_zone_device_register(char *type,
unregister:
release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);
device_unregister(&tz->device);
- return NULL;
+ return ERR_PTR(result);
}
EXPORT_SYMBOL(thermal_zone_device_register);
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/26] thermal: validate input parameters
From: Thomas Sujith <[EMAIL PROTECTED]>
Added sanity check to make sure that thermal zone
and cooling device exists.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/thermal/thermal.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c
index e782b3e..5f1d318 100644
--- a/drivers/thermal/thermal.c
+++ b/drivers/thermal/thermal.c
@@ -306,12 +306,23 @@ int thermal_zone_bind_cooling_device(struct
thermal_zone_device *tz,
{
struct thermal_cooling_device_instance *dev;
struct thermal_cooling_device_instance *pos;
+ struct thermal_zone_device *pos1;
+ struct thermal_cooling_device *pos2;
int result;
if (trip >= tz->trips || (trip < 0 && trip != THERMAL_TRIPS_NONE))
return -EINVAL;
- if (!tz || !cdev)
+ list_for_each_entry(pos1, &thermal_tz_list, node) {
+ if (pos1 == tz)
+ break;
+ }
+ list_for_each_entry(pos2, &thermal_cdev_list, node) {
+ if (pos2 == cdev)
+ break;
+ }
+
+ if (tz != pos1 || cdev != pos2)
return -EINVAL;
dev =
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/26] kernel-doc: fix pci-acpi warning
From: Randy Dunlap <[EMAIL PROTECTED]> Fix PCI kernel-doc warning: Warning(linux-2.6.24-git12//drivers/pci/pci-acpi.c:166): No description found for parameter 'hid' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/pci/pci-acpi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index e569645..2f2d308 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -158,6 +158,7 @@ run_osc_out: /** * __pci_osc_support_set - register OS support to Firmware * @flags: OS support bits + * @hid: hardware ID * * Update OS support fields and doing a _OSC Query to obtain an update * from Firmware on supported control bits. -- 1.5.4 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/26] ACPI: thermal: Check whether cooling device exists before unregistering
From: Zhao Yakui <[EMAIL PROTECTED]>
OS should check whether the cooling device exists before it is unregistered.
If it doesn't exists, it is unnecessary to remove the sysfs link
and call the function of thermal_cooling_device_unregister.
http://bugzilla.kernel.org/show_bug.cgi?id=9982
Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
Tested-by: Dhaval Giani <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 75ccf5d..697335c 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -809,10 +809,12 @@ static int acpi_processor_remove(struct acpi_device
*device, int type)
acpi_processor_remove_fs(device);
- sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
- sysfs_remove_link(&pr->cdev->device.kobj, "device");
- thermal_cooling_device_unregister(pr->cdev);
- pr->cdev = NULL;
+ if (pr->cdev) {
+ sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+ sysfs_remove_link(&pr->cdev->device.kobj, "device");
+ thermal_cooling_device_unregister(pr->cdev);
+ pr->cdev = NULL;
+ }
processors[pr->id] = NULL;
--
1.5.4
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ACPI patches for Linux-2.6.25-rc2
sorry if this is a repeat. backing down to git 1.5.4 to see if it can send messages that vger.kernel.org likes... thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/26] PCI ACPI: Fix comment describing acpi_pci_choose_state
From: Rafael J. Wysocki <[EMAIL PROTECTED]> The last line of the comment preceding the definition of acpi_pci_choose_state() is incorrect. Remove it. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/pci/pci-acpi.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index e569645..e818e52 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -241,8 +241,6 @@ EXPORT_SYMBOL(pci_osc_control_set); * choose from highest power _SxD to lowest power _SxW * else // no _PRW at S-state x * choose highest power _SxD or any lower power - * - * currently we simply return _SxD, if present. */ static pci_power_t acpi_pci_choose_state(struct pci_dev *pdev, -- 1.5.4.2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/26] PM: Make suspend_device() static
From: Adrian Bunk <[EMAIL PROTECTED]>
suspend_device() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/base/power/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index bdc03f7..a96ca86 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -415,7 +415,7 @@ EXPORT_SYMBOL_GPL(device_power_down);
* @dev: Device.
* @state: Power state device is entering.
*/
-int suspend_device(struct device *dev, pm_message_t state)
+static int suspend_device(struct device *dev, pm_message_t state)
{
int error = 0;
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/26] Hibernation: Handle DEBUG_PAGEALLOC on x86
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make hibernation work with CONFIG_DEBUG_PAGEALLOC set on x86, by
checking if the pages to be copied are marked as present in the
kernel mapping and temporarily marking them as present if that's not
the case. No functional modifications are introduced if
CONFIG_DEBUG_PAGEALLOC is unset.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr.c | 19 ++-
include/linux/mm.h |6 ++
kernel/power/snapshot.c | 42 +-
3 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index e2a74ea..464d8fc 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -899,7 +899,24 @@ void kernel_map_pages(struct page *page, int numpages, int
enable)
*/
cpa_fill_pool();
}
-#endif
+
+#ifdef CONFIG_HIBERNATION
+
+bool kernel_page_present(struct page *page)
+{
+ unsigned int level;
+ pte_t *pte;
+
+ if (PageHighMem(page))
+ return false;
+
+ pte = lookup_address((unsigned long)page_address(page), &level);
+ return (pte_val(*pte) & _PAGE_PRESENT);
+}
+
+#endif /* CONFIG_HIBERNATION */
+
+#endif /* CONFIG_DEBUG_PAGEALLOC */
/*
* The testcases use internal knowledge of the implementation that shouldn't
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 26c7124..3b3e134 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1171,12 +1171,18 @@ static inline void enable_debug_pagealloc(void)
{
debug_pagealloc_enabled = 1;
}
+#ifdef CONFIG_HIBERNATION
+extern bool kernel_page_present(struct page *page);
+#endif /* CONFIG_HIBERNATION */
#else
static inline void
kernel_map_pages(struct page *page, int numpages, int enable) {}
static inline void enable_debug_pagealloc(void)
{
}
+#ifdef CONFIG_HIBERNATION
+static inline bool kernel_page_present(struct page *page) { return true; }
+#endif /* CONFIG_HIBERNATION */
#endif
extern struct vm_area_struct *get_gate_vma(struct task_struct *tsk);
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 95250d7..72a020c 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -875,8 +875,8 @@ static inline void *saveable_highmem_page(unsigned long
pfn) { return NULL; }
#endif /* CONFIG_HIGHMEM */
/**
- * saveable - Determine whether a non-highmem page should be included in
- * the suspend image.
+ * saveable_page - Determine whether a non-highmem page should be included
+ * in the suspend image.
*
* We should save the page if it isn't Nosave, and is not in the range
* of pages statically defined as 'unsaveable', and it isn't a part of
@@ -897,7 +897,8 @@ static struct page *saveable_page(unsigned long pfn)
if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page))
return NULL;
- if (PageReserved(page) && pfn_is_nosave(pfn))
+ if (PageReserved(page)
+ && (!kernel_page_present(page) || pfn_is_nosave(pfn)))
return NULL;
return page;
@@ -938,6 +939,25 @@ static inline void do_copy_page(long *dst, long *src)
*dst++ = *src++;
}
+
+/**
+ * safe_copy_page - check if the page we are going to copy is marked as
+ * present in the kernel page tables (this always is the case if
+ * CONFIG_DEBUG_PAGEALLOC is not set and in that case
+ * kernel_page_present() always returns 'true').
+ */
+static void safe_copy_page(void *dst, struct page *s_page)
+{
+ if (kernel_page_present(s_page)) {
+ do_copy_page(dst, page_address(s_page));
+ } else {
+ kernel_map_pages(s_page, 1, 1);
+ do_copy_page(dst, page_address(s_page));
+ kernel_map_pages(s_page, 1, 0);
+ }
+}
+
+
#ifdef CONFIG_HIGHMEM
static inline struct page *
page_is_saveable(struct zone *zone, unsigned long pfn)
@@ -946,8 +966,7 @@ page_is_saveable(struct zone *zone, unsigned long pfn)
saveable_highmem_page(pfn) : saveable_page(pfn);
}
-static inline void
-copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
+static void copy_data_page(unsigned long dst_pfn, unsigned long src_pfn)
{
struct page *s_page, *d_page;
void *src, *dst;
@@ -961,29 +980,26 @@ copy_data_page(unsigned long dst_pfn, unsigned long
src_pfn)
kunmap_atomic(src, KM_USER0);
kunmap_atomic(dst, KM_USER1);
} else {
- src = page_address(s_page);
if (PageHighMem(d_page)) {
/* Page pointed to by src may contain some kernel
* data modified by kmap_atomic()
*/
- do_copy_page(buffer, src);
+ safe_copy_page(buffer, s_page);
dst =
[PATCH 21/26] ACPI: remove is_processor_present prototype
From: Glauber Costa <[EMAIL PROTECTED]>
The function itself is defined just below, so this prototype is not really
useful.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 75ccf5d..923fddb 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -826,8 +826,6 @@ static int acpi_processor_remove(struct acpi_device
*device, int type)
* Acpi processor hotplug support *
/
-static int is_processor_present(acpi_handle handle);
-
static int is_processor_present(acpi_handle handle)
{
acpi_status status;
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/26] ACPI: TSC breaks atkbd suspend
From: Pavel Machek <[EMAIL PROTECTED]>
TSC is used even on machines when CONFIG_X86_TSC is not set (X86_TSC
means _require_ TSC), but it is not properly disabled when it is
unusable, because ACPI code understood the config switch as "may use
TSC".
This actually fixes suspend problems on my x60.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/processor_idle.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 980e1c3..6f3b217 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -364,7 +364,7 @@ int acpi_processor_resume(struct acpi_device * device)
return 0;
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
static int tsc_halts_in_c(int state)
{
switch (boot_cpu_data.x86_vendor) {
@@ -544,7 +544,7 @@ static void acpi_processor_idle(void)
/* Get end time (ticks) */
t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC halts in C2, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C2))
mark_tsc_unstable("possible TSC halt in C2");
@@ -609,7 +609,7 @@ static void acpi_processor_idle(void)
acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0);
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC halts in C3, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C3))
mark_tsc_unstable("TSC halts in C3");
@@ -1500,7 +1500,7 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
acpi_idle_do_entry(cx);
t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC could halt in idle, so notify users */
if (tsc_halts_in_c(cx->type))
mark_tsc_unstable("TSC halts in idle");;
@@ -1614,7 +1614,7 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
spin_unlock(&c3_lock);
}
-#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86_TSC)
+#if defined (CONFIG_GENERIC_TIME) && defined (CONFIG_X86)
/* TSC could halt in idle, so notify users */
if (tsc_halts_in_c(ACPI_STATE_C3))
mark_tsc_unstable("TSC halts in idle");
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/26] ACPI: sparse fix, replace macro with static function
From: Harvey Harrison <[EMAIL PROTECTED]>
replace acpi_util_eval_error macro with static function.
Avoid these sparse warnings due to using buffer within the macro.
drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:259:21: originally declared here
drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one
drivers/acpi/utils.c:348:21: originally declared here
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/utils.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 34f1575..eba55b7 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -36,16 +36,20 @@ ACPI_MODULE_NAME("utils");
/* --
Object Evaluation Helpers
--
*/
+static void
+acpi_util_eval_error(acpi_handle h, acpi_string p, acpi_status s)
+{
#ifdef ACPI_DEBUG_OUTPUT
-#define acpi_util_eval_error(h,p,s) {\
- char prefix[80] = {'\0'};\
- struct acpi_buffer buffer = {sizeof(prefix), prefix};\
- acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);\
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",\
- (char *) prefix, p, acpi_format_exception(s))); }
+ char prefix[80] = {'\0'};
+ struct acpi_buffer buffer = {sizeof(prefix), prefix};
+ acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluate [%s.%s]: %s\n",
+ (char *) prefix, p, acpi_format_exception(s)));
#else
-#define acpi_util_eval_error(h,p,s)
+ return;
#endif
+}
+
acpi_status
acpi_extract_package(union acpi_object *package,
struct acpi_buffer *format, struct acpi_buffer *buffer)
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/26] acer-wmi: Add DMI match for mail LED on Acer TravelMate 4200 series
From: Carlos Corbacho <[EMAIL PROTECTED]>
The TM4200 series use the same method as the TM2490 series to control the
mail LED, so add a DMI based quirk for these laptops.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/acer-wmi.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/acer-wmi.c b/drivers/misc/acer-wmi.c
index d7aea93..74d12b4 100644
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@ -273,6 +273,15 @@ static struct dmi_system_id acer_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = "Acer TravelMate 4200",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4200"),
+ },
+ .driver_data = &quirk_acer_travelmate_2490,
+ },
+ {
+ .callback = dmi_matched,
.ident = "Medion MD 98300",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/26] ACPI: thinkpad-acpi: make the video output feature optional
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
The video output port control feature is not very useful on many ThinkPads
(especially when a X server is running), and lately userspace is getting
better and better at it, so it makes sense to allow users to stripe out the
thinkpad-acpi video feature from their kernels and save at least 2KB.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig | 17 +
drivers/misc/thinkpad_acpi.c | 20 +---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1abc95c..982e27b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -258,6 +258,23 @@ config THINKPAD_ACPI_BAY
If you are not sure, say Y here.
+config THINKPAD_ACPI_VIDEO
+ bool "Video output control support"
+ depends on THINKPAD_ACPI
+ default y
+ ---help---
+ Allows the thinkpad_acpi driver to provide an interface to control
+ the various video output ports.
+
+ This feature often won't work well, depending on ThinkPad model,
+ display state, video output devices in use, whether there is a X
+ server running, phase of the moon, and the current mood of
+ Schroedinger's cat. If you can use X.org's RandR to control
+ your ThinkPad's video output ports instead of this feature,
+ don't think twice: do it and say N here to save some memory.
+
+ If you are not sure, say Y here.
+
config THINKPAD_ACPI_HOTKEY_POLL
bool "Suport NVRAM polling for hot keys"
depends on THINKPAD_ACPI
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 02f9465..4ea3866 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -301,6 +301,13 @@ TPACPI_HANDLE(hkey, ec, "\\_SB.HKEY", /* 600e/x,
770e, 770x */
"HKEY", /* all others */
); /* 570 */
+TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */
+ "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */
+ "\\_SB.PCI0.VID0", /* 770e */
+ "\\_SB.PCI0.VID",/* A21e, G4x, R50e, X30, X40 */
+ "\\_SB.PCI0.AGP.VID",/* all others */
+ ); /* R30, R31 */
+
/*
* ACPI helpers
@@ -2680,6 +2687,8 @@ static struct ibm_struct wan_driver_data = {
* Video subdriver
*/
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
+
enum video_access_mode {
TPACPI_VIDEO_NONE = 0,
TPACPI_VIDEO_570, /* 570 */
@@ -2707,13 +2716,6 @@ static int video_orig_autosw;
static int video_autosw_get(void);
static int video_autosw_set(int enable);
-TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA", /* 570 */
- "\\_SB.PCI0.AGP0.VID0", /* 600e/x, 770x */
- "\\_SB.PCI0.VID0", /* 770e */
- "\\_SB.PCI0.VID",/* A21e, G4x, R50e, X30, X40 */
- "\\_SB.PCI0.AGP.VID",/* all others */
- ); /* R30, R31 */
-
TPACPI_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID"); /* G41 */
static int __init video_init(struct ibm_init_struct *iibm)
@@ -3023,6 +3025,8 @@ static struct ibm_struct video_driver_data = {
.exit = video_exit,
};
+#endif /* CONFIG_THINKPAD_ACPI_VIDEO */
+
/*
* Light (thinklight) subdriver
*/
@@ -5807,10 +5811,12 @@ static struct ibm_init_struct ibms_init[] __initdata = {
.init = wan_init,
.data = &wan_driver_data,
},
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
{
.init = video_init,
.data = &video_driver_data,
},
+#endif
{
.init = light_init,
.data = &light_driver_data,
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/26] ACPI: thinkpad-acpi: add tablet-mode reporting
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
A quick study of the 0x5009/0x500A HKEY event on the X61t DSDT revealed the
existence of the EC HTAB register (EC 0x0f, bit 7), and a compare with the
X41t DSDT shows that HKEY.MHKG can be used to verify if the ThinkPad is
tablet-capable (MHKG present), and in tablet mode (bit 3 of MHKG return is
set).
Add an attribute to report this information, "hotkey_tablet_mode". This
attribute has poll()/select() support, and can be used along with EV_SW
SW_TABLET_MODE to hook userspace to tablet events.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
Documentation/laptops/thinkpad-acpi.txt |7 +++
drivers/misc/thinkpad_acpi.c| 79 ++
2 files changed, 75 insertions(+), 11 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b/Documentation/laptops/thinkpad-acpi.txt
index 606af16..76cb428 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -313,6 +313,13 @@ sysfs notes:
This attribute has poll()/select() support.
+ hotkey_tablet_mode:
+ If the ThinkPad has tablet capabilities, this attribute
+ will read 0 if the ThinkPad is in normal mode, and
+ 1 if the ThinkPad is in tablet mode.
+
+ This attribute has poll()/select() support.
+
hotkey_report_mode:
Returns the state of the procfs ACPI event report mode
filter for hot keys. If it is set to 1 (the default),
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index c119cf2..bb269d0 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -221,6 +221,7 @@ static struct {
u32 hotkey:1;
u32 hotkey_mask:1;
u32 hotkey_wlsw:1;
+ u32 hotkey_tablet:1;
u32 light:1;
u32 light_status:1;
u32 bright_16levels:1;
@@ -1060,6 +1061,9 @@ static struct attribute_set *hotkey_dev_attributes;
#define HOTKEY_CONFIG_CRITICAL_END
#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+/* HKEY.MHKG() return bits */
+#define TP_HOTKEY_TABLET_MASK (1 << 3)
+
static int hotkey_get_wlsw(int *status)
{
if (!acpi_evalf(hkey_handle, status, "WLSW", "d"))
@@ -1067,6 +1071,16 @@ static int hotkey_get_wlsw(int *status)
return 0;
}
+static int hotkey_get_tablet_mode(int *status)
+{
+ int s;
+
+ if (!acpi_evalf(hkey_handle, &s, "MHKG", "d"))
+ return -EIO;
+
+ return ((s & TP_HOTKEY_TABLET_MASK) != 0);
+}
+
/*
* Call with hotkey_mutex held
*/
@@ -1172,15 +1186,20 @@ static void tpacpi_input_send_radiosw(void)
}
}
-static void tpacpi_input_send_tabletsw(unsigned int state)
+static void tpacpi_input_send_tabletsw(void)
{
- mutex_lock(&tpacpi_inputdev_send_mutex);
+ int state;
- input_report_switch(tpacpi_inputdev,
- SW_TABLET_MODE, !!state);
- input_sync(tpacpi_inputdev);
+ if (tp_features.hotkey_tablet &&
+ !hotkey_get_tablet_mode(&state)) {
+ mutex_lock(&tpacpi_inputdev_send_mutex);
- mutex_unlock(&tpacpi_inputdev_send_mutex);
+ input_report_switch(tpacpi_inputdev,
+ SW_TABLET_MODE, !!state);
+ input_sync(tpacpi_inputdev);
+
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+ }
}
static void tpacpi_input_send_key(unsigned int scancode)
@@ -1691,6 +1710,29 @@ static void hotkey_radio_sw_notify_change(void)
"hotkey_radio_sw");
}
+/* sysfs hotkey tablet mode (pollable) - */
+static ssize_t hotkey_tablet_mode_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int res, s;
+ res = hotkey_get_tablet_mode(&s);
+ if (res < 0)
+ return res;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", !!s);
+}
+
+static struct device_attribute dev_attr_hotkey_tablet_mode =
+ __ATTR(hotkey_tablet_mode, S_IRUGO, hotkey_tablet_mode_show, NULL);
+
+static void hotkey_tablet_mode_notify_change(void)
+{
+ if (tp_features.hotkey_tablet)
+ sysfs_notify(&tpacpi_pdev->dev.kobj, NULL,
+"hotkey_tablet_mode");
+}
+
/* sysfs hotkey report_mode */
static ssize_t hotkey_report_mode_show(struct device *dev,
struct device_attribute *attr,
@@ -1903,7 +1945,7 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
str_supported(tp_features.hotkey));
if (tp_features.hotkey) {
- hotkey_dev_attributes = create_attr_set(12, NULL);
+ hotkey_dev_attributes = create_attr_set(13, NULL);
if (!hotkey_dev_attri
[PATCH 12/26] ACPI: thinkpad-acpi: always track input device open/close
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
The open() and close() hooks for the input device are useful even when
hotkey NVRAM polling support is not in use, so it is better to always have
them around.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 723d37b..6da3f40 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1417,6 +1417,14 @@ static void hotkey_poll_setup_safe(int may_warn)
mutex_unlock(&hotkey_mutex);
}
+#else /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+
+static void hotkey_poll_setup_safe(int __unused)
+{
+}
+
+#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
+
static int hotkey_inputdev_open(struct input_dev *dev)
{
switch (tpacpi_lifecycle) {
@@ -1444,7 +1452,6 @@ static void hotkey_inputdev_close(struct input_dev *dev)
if (tpacpi_lifecycle == TPACPI_LIFE_RUNNING)
hotkey_poll_setup_safe(0);
}
-#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
/* sysfs hotkey enable - */
static ssize_t hotkey_enable_show(struct device *dev,
@@ -2023,12 +2030,10 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
(hotkey_report_mode < 2) ?
"enabled" : "disabled");
-#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
tpacpi_inputdev->open = &hotkey_inputdev_open;
tpacpi_inputdev->close = &hotkey_inputdev_close;
hotkey_poll_setup_safe(1);
-#endif
}
return (tp_features.hotkey)? 0 : 1;
@@ -2221,9 +2226,7 @@ static void hotkey_resume(void)
hotkey_radio_sw_notify_change();
hotkey_wakeup_reason_notify_change();
hotkey_wakeup_hotunplug_complete_notify_change();
-#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
hotkey_poll_setup_safe(0);
-#endif
}
/* procfs -- */
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/26] ACPI: thinkpad-acpi: synchronize input device switches
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Issue EV_SW events at module init time to synchronize the input device with the current state of the switch, otherwise we might lose the first event. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/misc/thinkpad_acpi.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index 6da3f40..02f9465 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -2034,6 +2034,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) tpacpi_inputdev->close = &hotkey_inputdev_close; hotkey_poll_setup_safe(1); + tpacpi_input_send_radiosw(); } return (tp_features.hotkey)? 0 : 1; -- 1.5.4.2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/26] ACPI: thinkpad-acpi: trivial fix to module_desc typo
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Thanks to Damjan <[EMAIL PROTECTED]> for noticing this one. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- drivers/misc/thinkpad_acpi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index e2c7edd..723d37b 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -5918,7 +5918,7 @@ MODULE_PARM_DESC(hotkey_report_mode, #define TPACPI_PARAM(feature) \ module_param_call(feature, set_ibm_param, NULL, NULL, 0); \ - MODULE_PARM_DESC(feature, "Simulates thinkpad-aci procfs command " \ + MODULE_PARM_DESC(feature, "Simulates thinkpad-acpi procfs command " \ "at module load, see documentation") TPACPI_PARAM(hotkey); -- 1.5.4.2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/26] ACPI: thinkpad-acpi: trivial fix to documentation
From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Fix a stray ibm-acpi that should have been replaced with thinkpad-acpi. Thanks to Damjan <[EMAIL PROTECTED]> for noticing this one. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- Documentation/laptops/thinkpad-acpi.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 6c24777..33d6e5a 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1309,7 +1309,7 @@ Enabling debugging output The module takes a debug parameter which can be used to selectively enable various classes of debugging output, for example: -modprobe ibm_acpi debug=0x +modprobe thinkpad_acpi debug=0x will enable all debugging output classes. It takes a bitmask, so to enable more than one output class, just add their values. -- 1.5.4.2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/26] ACPI: fix build warning
From: Ming Lin <[EMAIL PROTECTED]>
CC drivers/acpi/executer/exregion.o
drivers/acpi/executer/exregion.c: In function
âacpi_ex_pci_config_space_handlerâ:
drivers/acpi/executer/exregion.c:369: attention : passing argument 3 of
âacpi_os_read_pci_configurationâ from incompatible pointer type
exposed by 10270d4838bdc493781f5a1cf2e90e9c34c9142f
http://bugzilla.kernel.org/show_bug.cgi?id=9989
Signed-off-by: Ming Lin <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/executer/exregion.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/executer/exregion.c b/drivers/acpi/executer/exregion.c
index 2e9ce94..3f51b7e 100644
--- a/drivers/acpi/executer/exregion.c
+++ b/drivers/acpi/executer/exregion.c
@@ -338,6 +338,7 @@ acpi_ex_pci_config_space_handler(u32 function,
acpi_status status = AE_OK;
struct acpi_pci_id *pci_id;
u16 pci_register;
+ u32 value32;
ACPI_FUNCTION_TRACE(ex_pci_config_space_handler);
@@ -364,9 +365,9 @@ acpi_ex_pci_config_space_handler(u32 function,
switch (function) {
case ACPI_READ:
- *value = 0;
status = acpi_os_read_pci_configuration(pci_id, pci_register,
- value, bit_width);
+ &value32, bit_width);
+ *value = value32;
break;
case ACPI_WRITE:
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/26] intel_menlo: extract return values using PTR_ERR
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/intel_menlow.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/intel_menlow.c b/drivers/misc/intel_menlow.c
index f70984a..de16e88 100644
--- a/drivers/misc/intel_menlow.c
+++ b/drivers/misc/intel_menlow.c
@@ -170,10 +170,13 @@ static int intel_menlow_memory_add(struct acpi_device
*device)
cdev = thermal_cooling_device_register("Memory controller", device,
&memory_cooling_ops);
- acpi_driver_data(device) = cdev;
- if (!cdev)
- result = -ENODEV;
- else {
+ if (IS_ERR(cdev)) {
+ result = PTR_ERR(cdev);
+ goto end;
+ }
+
+ if (cdev) {
+ acpi_driver_data(device) = cdev;
result = sysfs_create_link(&device->dev.kobj,
&cdev->device.kobj, "thermal_cooling");
if (result)
--
1.5.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
