Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: david on 5 Aug 2010 20:20 On Thu, 5 Aug 2010, Brian Swetland wrote: > On Thu, Aug 5, 2010 at 4:03 PM, Paul E. McKenney > <paulmck(a)linux.vnet.ibm.com> wrote: >>>> so what would wake a phone up from suspend where the phone should go back to >>>> sleep in under a second? >>> >>> Here are some real-world examples from shipped android devices: >>> - battery gauging happens every 10 minutes, need to wake long enough >>> to chatter with the 1w interface and make sure the battery is not >>> exploding >>> - always on mail/im/calendar/etc sync often has network events that >>> happen every 5-10 minutes which cause devices to briefly wake up and >>> return to sleep >>> - gps tracker app might wake every couple minutes or every n gps >>> events to log location >>> - low power audio subsystems can wake you up every 1-4 seconds (pcm) >>> or 1-4 minutes (mp3) to fetch more data >> >> Interesting! >> >> So for an mp3 playback, does an Android suspend between data fetches? > > It can if the latency is long enough (which is why I point out low > power audio which is usually high latency). For low latency (system > sounds, etc) 10-25ms between buffers it's not practical to fully > suspend but we will go to the lowest power state in idle if possible. the playback is able to continue even with all the clocks stopped? that surprises me. I would hav expected it to be able to sleep while playing audio, but not do a full suspend. David Lang -- 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: Brian Swetland on 5 Aug 2010 20:30 On Thu, Aug 5, 2010 at 5:16 PM, <david(a)lang.hm> wrote: >>> >>> So for an mp3 playback, does an Android suspend between data fetches? >> >> It can if the latency is long enough (which is why I point out low >> power audio which is usually high latency). For low latency (system >> sounds, etc) 10-25ms between buffers it's not practical to fully >> suspend but we will go to the lowest power state in idle if possible. > > the playback is able to continue even with all the clocks stopped? that > surprises me. I would hav expected it to be able to sleep while playing > audio, but not do a full suspend. Obviously not all clocks are stopped (the DSP and codec are powered and clocked, for example), but yeah we can clock gate and power gate the cpu and most other peripherals while audio is playing on a number of ARM SoC designs available today (and the past few years). Brian -- 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: Rafael J. Wysocki on 5 Aug 2010 20:50 On Friday, August 06, 2010, Brian Swetland wrote: > 2010/8/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > >> > >> Our wakelock stats currently have > >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time > >> and last_change. Not all of these are equally important (total_time is > >> most important followed by active_since), but you only have count. > >> Also as discussed before, many wakelocks/suspendblockers are not > >> associated with a struct device. > > > > OK > > > > How much of that is used in practice and what for exactly? > > > > Do you _really_ have to debug the wakelocks in drivers that much? > > Debugging power related issues is pretty critical to building > competitive mobile devices. Well, I don't think anyone will disagree with that. > Throughout the several months of this discussion I have been > continually scratching my head at this "debugability considered > harmful" attitude that I see in reaction to our interest in having the > ability (gated behind a config option even -- really, that'd be fine, > not everyone need enable it) to gather useful stats and examine the > state of the system. The problem is what kind of stats would be actually sufficient and we haven't seriously discussed that. You said you'd need statistics and we took that for granted, but we didn't really go into details here. > At this point it sounds like there's no interest in the solution we > have, which works and has worked for a few years, and has been revised > 10+ times based on feedback here, and no interest in providing a > solution that accomplishes similar functionality, so perhaps it's time > for us to cut our losses and just go back to maintaining our patches > instead of having the same arguments over and over again. Please remember that I also have spent considerable amount of time trying to push your solution upstream and defending it. I might have spent that time on other things instead, so please don't tell me about "losses". If you want to stay in your ivory tower, that's perfectly fine by me, but I guess that won't really benefit anyone in the long run. Thanks, Rafael -- 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: david on 5 Aug 2010 21:10 On Thu, 5 Aug 2010, Brian Swetland wrote: > On Thu, Aug 5, 2010 at 5:16 PM, <david(a)lang.hm> wrote: >>>> >>>> So for an mp3 playback, does an Android suspend between data fetches? >>> >>> It can if the latency is long enough (which is why I point out low >>> power audio which is usually high latency). For low latency (system >>> sounds, etc) 10-25ms between buffers it's not practical to fully >>> suspend but we will go to the lowest power state in idle if possible. >> >> the playback is able to continue even with all the clocks stopped? that >> surprises me. I would hav expected it to be able to sleep while playing >> audio, but not do a full suspend. > > Obviously not all clocks are stopped (the DSP and codec are powered > and clocked, for example), but yeah we can clock gate and power gate > the cpu and most other peripherals while audio is playing on a number > of ARM SoC designs available today (and the past few years). does this then mean that you have multiple variations of suspend? for example, one where the audio stuff is left powered, and one where it isn't? David Lang
From: Brian Swetland on 5 Aug 2010 21:30
On Thu, Aug 5, 2010 at 6:01 PM, <david(a)lang.hm> wrote: > On Thu, 5 Aug 2010, Brian Swetland wrote: >> On Thu, Aug 5, 2010 at 5:16 PM, <david(a)lang.hm> wrote: >>>>> >>>>> So for an mp3 playback, does an Android suspend between data fetches? >>>> >>>> It can if the latency is long enough (which is why I point out low >>>> power audio which is usually high latency). For low latency (system >>>> sounds, etc) 10-25ms between buffers it's not practical to fully >>>> suspend but we will go to the lowest power state in idle if possible. >>> >>> the playback is able to continue even with all the clocks stopped? that >>> surprises me. I would hav expected it to be able to sleep while playing >>> audio, but not do a full suspend. >> >> Obviously not all clocks are stopped (the DSP and codec are powered >> and clocked, for example), but yeah we can clock gate and power gate >> the cpu and most other peripherals while audio is playing on a number >> of ARM SoC designs available today (and the past few years). > > does this then mean that you have multiple variations of suspend? > > for example, one where the audio stuff is left powered, and one where it > isn't? While the cpu (and the bulk of the system) is suspended, it's not uncommon for some peripherals to continue to operate -- for example a cellular radio, gps, low power audio playback, etc. Details will vary depending on the SoC and board design. It's not so much a different suspend mode (the system is still suspended), just a matter of whether a peripheral can operate independently (and if it is lower power for it to do so). Brian -- 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/ |