gmane.linux.power-management.general

Re: [Suspend-devel] TAP (and TUN?) devices not workingafter resume

James Le Cuirot — 2008-11-29T10:18:49

On Thu, 24 Jul 2008 20:50:32 -0700 Max Krasnyansky qualcomm.com> wrote: Sorry about the crazy delay here, I didn't need to use QEMU for ages and I don't like firing up Windows unless I have too. :D I'm not sure about 2.6.26 but this appears to be fixed in 2.6.27. Thanks, James

Re: [ath5k-devel] Bugs on aspire one A150

Maxim Levitsky — 2008-12-01T15:33:15

Hi, Any update on that? Best regards, Maxim Levitsky

Re: [PATCH 1/1] Hibernate: Take overlapping zones intoaccount (rev. 2)

Rafael J. Wysocki — 2008-11-26T23:11:47

Thanks a lot Len! Rafael

Re: [PATCH 1/1] Hibernate: Take overlapping zones intoaccount (rev. 2)

Len Brown — 2008-11-26T23:04:26

done. previous version has been replaced with this version. also, suspend branch is now rebased to latest linus top of tree. thanks, -Len

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T21:07:47

On a standard laptop the WLAN interface would be a PCI device, so it could use the standard PCI wakeup method (PME#). Or the motherboard manufacturer could use vendor-specific signalling. But you're not likely to find an onboard WLAN interface communicating with the CPU via USB. In this particular case, can't you set it up so that the EC always pays attention to the WLAN's GPIO line, but the WLAN interface enables the GPIO for wakeup signalling only if power/wakeup is set? It sounds like the same sort of problem: a device on a different bus that has to talk to the platform's EC. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T20:38:37

On Nov 25 2008, at 15:18, Alan Stern was caught saying: I'm going to throw a patch togethre and post it here and on lkml for vetting and we can go from there. I think in that case we couldn't really do WOL. I imagine this is the case on a standard laptop too. On future XO versions, we may move to an SDIO based card and we will have to deal with the same situation where the SDIO stack has a concept of wake up on card insert/remove but we will need to route the WOL signal from the card to the EC. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T20:18:29

It's a difficult problem. You've essentially got a platform device on the USB bus. I'm not sure... This sort of thing isn't something I've had to deal with before. Suppose the same sort of WLAN interface was packaged as an independent, external USB device and one of them was plugged into an OLPC. Then how would you know which device was the one attached to the embedded controller and which was external? That's understandable. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T19:19:29

On Nov 25 2008, at 13:57, Alan Stern was caught saying: The sideband signal is a gpio. The driver knows that the GPIO exists, but it does not know that it anything about it is routed on the board IMHO it should not. Agreed, and there are several ways to do this: One is to do wrap code around #ifdef and if(machine_is_olpc()) to make a call to an OLPC-specific call. The other is to add a generic platform wakeup hook mechanism such as either my original proposal or adding a set_wakeup() to struct device itself. Another option is to have a single platform_set_wakeup() pointer similar to the platform_notify() and platform_notify_remove(). Note that in the OLPC tree we have some #ifdef OLPC in the wifi driver but those are not upstream and I'm going to work on removing them. I would prefer not to add anymore. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T18:57:17

It depends on the hardware and the driver. Is this a specialized sort of USB WLAN device with features specific to the XO? How is the sideband wakeup signal implemented? Does the driver know that it is running on an XO? Does the driver know that this sideband signal exists? The easiest answer is for the driver to call directly into the platform code. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T18:07:44

On Nov 25 2008, at 10:09, Alan Stern was caught saying: What is the method to connect between the driver's WOL code and the platform code in this situation? tnx, ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T15:09:14

No, don't do that. If the device has a sideband wakeup signal then the device's driver should be aware of that signal. So the driver should be modified, not the device core. The driver can ask the platform code to do whatever is necessary. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T04:23:11

On Nov 24 2008, at 18:08, Alan Stern was caught saying: Just thought of something. Not all the devices we can wakeup on are platform devices. The WLAN specifically is an on-board USB device with a sideband wakeup signal connected to the EC. So instead I'll make the set_wakeup() ptr a member of struct device and call it in device_suspend(). ~Deepak

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T03:26:06

On Nov 24 2008, at 18:08, Alan Stern was caught saying: Correct. Most embedded platforms are fairly static and don't need the complexity of ACPI. This sounds good. I think I can get away with doing this w/o having to touch shared drivers such as i8042. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-24T23:08:39

ACPI may not be such a good model after all. It's very table-driven, with its own little interpreter (or not so little!), whereas most platforms have a pretty good idea beforehand of what devices can exist, and they are described as static data. Right? So the platform code could initialize the "can_wakeup" setting when it first detects and registers the device. And you could add a "set_wakeup" function pointer to struct platform_device, which the bus-level suspend and resume routines would invoke to enable or disable remote wakeup, as appropriate. In the static structures these function pointers would point to routines that set or clear the appropriate bits in your Embedded Controller. I think this is the right way to go... Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-24T22:32:58

On Nov 24 2008, at 23:19, Rafael J. Wysocki was caught saying: Yep. i8042, lid, power button, battery state change, WOL. I think I can do something similar to what ACPI is doing by trapping the device registration. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-levelhandler

Deepak Saxena — 2008-11-24T22:29:00

On Nov 24 2008, at 17:14, Alan Stern was caught saying: ACPI hides a lot of the EC magic from us, but it looks like it uses the platform_notify() and platform_remove_notify() handlers to track what devices are added to the system. I think I can make use of the same to set dev->wakeup_capable for the devices I care about, store the pointers to those devices, and then configure the EC bits as needed when we suspend by looking at the result of device_may_wakeup(). I might not need a callback afterall. Thanks, ~Deepak

Re: [RFC] Tying sysfs "wakeup" file to platform-levelhandler

Rafael J. Wysocki — 2008-11-24T22:19:14

For PCI we set the can_wakeup flag during the initialization of devices. For some other devices, ACPI BIOS contains information telling us whether they are capable of waking the system up and the ACPI code sets that flag for them on this basis. Does your platform know which devices can wake up? Rafael

Re: [RFC] Tying sysfs "wakeup" file to platform-level handler

Alan Stern — 2008-11-24T22:14:24

I see. IMO, in your example there's no way around modifying the i8042 driver. That is, changes should be made at the driver level instead of to the generic PM core. However exactly what form these changes should take isn't clear. Perhaps something like your platform_wakeup_ops should become part of the platform bus structure, directly accessible by any platform device driver. You'd only need to implement an enable_wakeup and a disable_wakeup routine. How does ACPI go about doing the equivalent thing? Maybe you can copy that approach. Alan Stern

Re: [RFC] Tying sysfs "wakeup" file toplatform-levelhandler

Deepak Saxena — 2008-11-24T22:02:34

On Nov 24 2008, at 16:34, Alan Stern was caught saying: ACK. Because some of the drivers we are using are generic and I do not want to put a bunch of platform-specific code in there. Let's look at the PS2 driver for example. We use the generic i8042 driver and I would like to be able to use /sys/bus/platform/devices/i8042/power/wakeup to set wakeup enable on mouse or keyboard input so I need a way to trigger an EC mask update on a write to that file. Maybe there is some other way to do this that I don't quite grok? Right now, the i8042 device does not have the can_wakeup flag set so writing either "enabled" or "disabled" leads to -EINVAL. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file to platform-level handler

Alan Stern — 2008-11-24T21:34:01

Then I must have misunderstood the point of your earlier message. Are you saying that the real problem is to tie the existing /sys/devices/.../power/wakeup flags into your platform handler? The sources you listed (ac_power, battery_state, and so on) are all pretty much platform-level entities to begin with. Their drivers must already contain or communicate with a fair amount of platform-level code. So why should there be any trouble about adding a new communication channel for wakeup settings? Alan Stern

Re: [RFC] Tying sysfs "wakeup" file toplatform-levelhandler

Deepak Saxena — 2008-11-24T21:09:49

On Nov 24 2008, at 15:57, Alan Stern was caught saying: Ack. This is what we are already doing. The decision on whether or not a device should wake us up from suspend is handle via OHM on the XO and we set the OLPC-specific flags in /sys/power/wakeup_events as there is no standard way to specify wakeup events from userland. My proposal uses the existing sysfs interface to connect into a platform level handler that can set the appropriate low-level HW bits. The decision of whether or not to enable the device's wakeup capability would still be left to user space. ~Deepak