suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: David Brownell on 11 Jun 2010 00:30 This is a bit off the topic of Android flamage, but I thought it would be worth highlighting an example where the current frameworks may still have a deficiency... one that likewise relates to needing to block entry ot a system suspend state, but in this case user-space isn't very involved (just drivers coping with hardware). The example I wanted to re-post (I've done so in the past) is one where drivers ouldn't really do the right thing, since driver.suspend() wasn't quite powerful enough as a programming interface. The example works with USB on many ARM SoCs, and similar non-USB examples aren't rare. - Want to enter a system suspend state, with some USB wakeup sources. USB peripheral waken up by the host, or vice versa. NOTE ASSUMPTION: there are multiple suspend states supported by the hardware, significantly different in hardware configuration Linux should be able to use more than one such state... (if only because their power savings differ.) This can mean driver-specific knowledge about those various states. - The wakeup requires a particular clock to be active, so the USB controller can detect that the wakeup should trigger, then issue the right signals triggering the non-USB parts of the system. Problem: how does the device driver suspend() method block entry to a suspend state when it can't ensure that clock is going to be active. Magic return code? There are other issues here too. (Is the target system suspend state one of the ones which doesn't allow that clock to be active? SoC-specific calls might suffice for this issue. A number of years ago, this problem was insoluble with the then-current Linux PM and clock frameworks. I've been away from this issue for quite a while now, but don't recall seeing its sub-problems get solved ... If they're now solved, I'll be glad. (I know Kevin's recent OMAP stuff addresses similar issues, but It's OMAP-specific...) After all these thousands and thousands of emails... I'm not sure how much forward motion has happened. Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as "removed by driver.resume(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 11 Jun 2010 10:30 On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: > Do we at least have a clean way that a driver can > reject a system suspend? I've lost track of many > issues, but maybe this could be phrased as a QOS > constraint: the current config of driver X needs > clock Y active to enter the target system suspend > state, driver's suspend() method reports as much. Then the entry to > that system state gets blocked > if the clock isn't enabled. So in QoS modifications to android patches, the answer is "yes" ... except that the current android patch set didn't actually have this type of wakelock in it. Android wants an idleness suspend block (or pm qos constraint) that a driver can set to prevent the system idleness power govenor from dropping into a power state too low for the driver, so in USB terms this would prevent the states that shut down the clock. For android, it prevented shutdown of an internal i2c bus. The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. > (That QOS constraint should be removed when that > driver no longer needs to issue wakeups; that's > not quite the same as "removed by driver.resume(). The USB one needs user input, doesn't it, since user hot plug might (or might not) be one of the wakeup sources. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 Jun 2010 10:40 On Thu, 10 Jun 2010, Arve Hj�nnev�g wrote: > > You've lost me. �If the power manager is sitting inside a select/poll, > > how can it miss the event (given that the event will make data > > available to be read on one of the descriptors being polled)? > > > > It cannot sit inside of select/poll all the time. > > > Or put it another way: With wakelocks, if the app doesn't use a suspend > > blocker then once it reads the event data and the timed wakelock is > > deactivated, there is nothing to prevent the system from immediately > > going into opportunistic suspend. �My scheme can fail in the same way. > > Is that what you meant? > > > > No, if an app reads from a file descriptor and block suspend when the > read call returns, then suspend is blocked while processing the data. > If the driver uses a wakelock with a timeout this will fail if the > thread does not get to the suspend block call before the timeout > expires, but unrelated events that don't prevent the app from running > will not cause any problems. Wait a second. Maybe I have misunderstood how timeouts are supposed to work with wakelocks. I thought the idea was that the wakelock would be released when the timeout expires or the event queue is emptied, whichever comes first. Now it sounds like you're saying that the wakelock doesn't get released until the timeout expires, even if userspace finishes processing all pending events before then. > In your scheme the user-space power > manager may miss events on this file descriptor since select/poll will > not see an event if the app read that event right before the power > manager called select/poll. If the wakelock is supposed to remain active until the timeout expires then you are right. On the other hand, this seems like a rather strange and suspicious way of handling wakelocks. Why would you want to do it that way? > > There's one question that I don't remember ever seeing answered. �To > > which kernel drivers do you intend to add suspend blockers? > > > > All drivers that generate wakeup events need to either use suspend > blockers directly or call into something else that does. For instance, > with the patch to block suspend while input events are queued to > user-space, an input driver that fully handles its events in its > interrupt handler does not need any additional suspend blockers, but > if the driver needs a work function or a timer to run before it > reports the event it needs to block suspend until it has reported the > event. Sure. But specifically, which drivers on Android generate wakeup events? And which of them don't fully handle their events in their interrupt handlers? Maybe another way to put this is: Where in the kernel do you intend to add suspend blockers? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 Jun 2010 10:50 On Fri, 11 Jun 2010, James Bottomley wrote: > On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: > > Do we at least have a clean way that a driver can > > reject a system suspend? I've lost track of many > > issues, but maybe this could be phrased as a QOS > > constraint: the current config of driver X needs > > clock Y active to enter the target system suspend > > state, driver's suspend() method reports as much. Then the entry to > > that system state gets blocked > > if the clock isn't enabled. > > So in QoS modifications to android patches, the answer is "yes" ... > except that the current android patch set didn't actually have this type > of wakelock in it. > > Android wants an idleness suspend block (or pm qos constraint) that a > driver can set to prevent the system idleness power govenor from > dropping into a power state too low for the driver, so in USB terms this > would prevent the states that shut down the clock. For android, it > prevented shutdown of an internal i2c bus. > > The one thing that does look difficult is that these power constraints > are device (and sometimes SoC) specific. Expressing them in a generic > way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 11 Jun 2010 10:50
On Thu, 10 Jun 2010, David Brownell wrote: > This is a bit off the topic of Android > flamage, but I thought it would be worth > highlighting an example where the current > frameworks may still have a deficiency... > one that likewise relates to needing to > block entry ot a system suspend state, but > in this case user-space isn't very involved > (just drivers coping with hardware). > > The example I wanted to re-post (I've done so > in the past) is one where drivers ouldn't really > do the right thing, since driver.suspend() wasn't > quite powerful enough as a programming interface. > > The example works with USB on many ARM SoCs, > and similar non-USB examples aren't rare. > > - Want to enter a system suspend state, with > some USB wakeup sources. USB peripheral > waken up by the host, or vice versa. > > NOTE ASSUMPTION: there are multiple suspend > states supported by the hardware, significantly > different in hardware configuration Linux should > be able to use more than one such state... (if > only because their power savings differ.) This > can mean driver-specific knowledge about those > various states. > > - The wakeup requires a particular clock to be active, so the USB controller can detect that the > wakeup should trigger, then issue the right signals > triggering the non-USB parts of the system. > > Problem: how does the device driver suspend() > method block entry to a suspend state > when it can't ensure that clock is > going to be active. Magic return code? At the moment, drivers aren't told what suspend state the system is going into. They know the difference between suspend and hibernate, but the PM core doesn't tell drivers whether it's going into standby vs. suspend. (Strictly speaking, those terms apply mostly to ACPI systems and not so much elsewhere. What I'm talking about is the /sys/power/state interface, where the user can write either "standby" or "mem". Drivers aren't told which was written.) > There are other issues here too. (Is the target > system suspend state one of the ones which doesn't > allow that clock to be active? SoC-specific calls > might suffice for this issue. I imagine platforms have to answer all such questions when they decide exactly how they will implement "standby" and "mem". > A number of years ago, this problem was insoluble > with the then-current Linux PM and clock frameworks. > I've been away from this issue for quite a while > now, but don't recall seeing its sub-problems get > solved ... If they're now solved, I'll be glad. > (I know Kevin's recent OMAP stuff addresses similar > issues, but It's OMAP-specific...) > > After all these thousands and thousands of emails... > I'm not sure how much forward motion has happened. I'm not aware of any progress. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |