On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: > > It's true that under some exceptional circumstances the system would > > never remove a wakeup source from the "active" list and then would > > never go idle. But exactly the same problem exists with wakelocks, if > > the kernel activates a wakelock and there's no user process reading the > > corresponding event queue. > > > > No, you have a different problem. If you open an input device and > issue the ioctl to enable the suspend blocker that blocks while the Um, the suspend blocker that is active while the queue is nonempty is an in-kernel suspend blocker, right? Not a userspace suspend blocker. Hence it doesn't have to be enabled by an ioctl. Or is this some part of the whole wakelock design that hasn't yet been posted? As far as I know, you intended the in-kernel suspend blocker to be enabled whenever the input device file is open. > queue is not empty then don't read the event, that is a bug that is > easy to fix. I assume you mean "you open an input device but then fail to read from it". When that happens the device's driver will activate its in-kernel suspend blocker, and since the input queue will never become empty, the suspend blocker will never be deactivated. Yes, that's a bug. > What you have is a race condition. If you read an event > that occurred after you blocked the task freezing tasks will never get > frozen again (until more events occur). Sorry, I can't parse that sentence. Could you rephrase it more grammatically? It seems to say: "If you read an event that occurred after [something], then tasks won't get frozen again until more events occur". Which doesn't make sense, firstly because in my scheme reading events has no direct connection with freezing or unfreezing tasks, and secondly because the occurrence of events doesn't cause tasks to be frozen -- just the opposite: occurrence of events _prevents_ tasks from being frozen. > We have multiple input devices and one thread reading from them. Do > all input devices that can generate wakeup events share a wakeup > source? Basically, a wakeup source is a file descriptor that in your scheme, some user process would read from in order to clear an in-kernel wakelock. Thus, if each of your input devices activates an in-kernel wakelock that is cleared when a user process reads the device, then the file descriptors for these input devices would each be considered a wakeup source. > It seems you would need a way to pass the wakeup source id to use from > user space to the driver and for this to work No, nothing needs to be passed from userspace to the kernel. However the source ID (or a set of source IDs) does need to be passed to the power manager process, probably when the suspend blocker is created. [On rereading this, I realized it might not have been clear that in my scheme, suspend blockers have no in-kernel component. They are implemented entirely by IPC between the process owning the suspend blocker and the power manager process. Would it be less confusing if I called them something else?] > (ignoring the race if > you allow multiple alarms per file) which seems like more work than > using a suspend blocker. It's not very much more: just one additional argument to the routine that creates a suspend blocker. I get the impression that you don't fully understand how my scheme is meant to work. Would some additional explanation or examples help? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
