Re: [Zaurus-devel] [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
On Wed, Apr 27, 2011 at 6:46 PM, Stanislav Brabec wrote: > MyungJoo Ham wrote: > >> As long as sysdevs are resumed and some devices/subsystems (I2C-PMIC, >> ADC, and RTC in my cases) can be selectively resumed and suspended, it >> is fine. >> Thus, your "alternative" suggestion is perfect with me. Actually, this >> is almost going back to the original hack. =) >> >> I'll submit next revision with platform_suspend_ops later. > > Does kernel have something like "sleepy task" interface, e. g. special > mode that is triggered by some sort of interrupt and instead of going to > perform full resume, it just lets a hook to wake up "manually" needed > devices, perform the "sleepy task" and then tell the system whether full > resume is requested? Not that I know of. I don't see anything that stops the resuming flow (full resume will be performed at any wakeup event before this patch) The patch that is going to be revised as mentioned will allow you to perform 1) "manually" wake up some devices 2) perform "sleepy tasks" 3) "manually" suspend devices waked up at 1) 4) tell the system whether full resume is requested. at the suspend_again callback of struct platform_suspend_ops suspend_ops. However, you may need some "helpers" to do 1 and 3 easily. Anyway, for the "helpers" for 1) and 3), I expect that allowing the one who provide suspend_ops to provide a list of struct dev pointers that required wakeup would be enough. I'd look at this issue as well because I have the same issue, but I'd do it separately with the "suspend_again". > > It can fit for Zaurus battery charging monitoring - timer interrupt > needs to wake just the SPI bus. > > But I can imagine a GPS logger using such interface to save energy - > serial interrupt semi-wakes the system each second, but will not go to > do full resume. It just processes NMEA sentence and buffers the result. > Only if buffer becomes full, it issues full resume and writes data > somewhere. Sure, as long as the platform file (or machine/board file) has the suspend_again callback implemented correctly, it will work as you expected. > > -- > Best Regards / S pozdravem, > > Stanislav Brabec > software developer > - > SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz > Lihovarská 1060/12 tel: +49 911 7405384547 > 190 00 Praha 9 fax: +420 284 028 951 > Czech Republic http://www.suse.cz/ > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > Cheers! - MyungJoo -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
MyungJoo Ham wrote: > As long as sysdevs are resumed and some devices/subsystems (I2C-PMIC, > ADC, and RTC in my cases) can be selectively resumed and suspended, it > is fine. > Thus, your "alternative" suggestion is perfect with me. Actually, this > is almost going back to the original hack. =) > > I'll submit next revision with platform_suspend_ops later. Does kernel have something like "sleepy task" interface, e. g. special mode that is triggered by some sort of interrupt and instead of going to perform full resume, it just lets a hook to wake up "manually" needed devices, perform the "sleepy task" and then tell the system whether full resume is requested? It can fit for Zaurus battery charging monitoring - timer interrupt needs to wake just the SPI bus. But I can imagine a GPS logger using such interface to save energy - serial interrupt semi-wakes the system each second, but will not go to do full resume. It just processes NMEA sentence and buffers the result. Only if buffer becomes full, it issues full resume and writes data somewhere. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
On Wed, Apr 27, 2011 at 7:32 AM, Rafael J. Wysocki wrote: > On Tuesday, April 26, 2011, Rafael J. Wysocki wrote: >> On Tuesday, April 26, 2011, Pavel Machek wrote: > ... >> > Ok, see the spitz_should_wakeup() function in arch/arm/mach-pxa/* and >> > should_wakeup() usage. >> >> OK, I will. > > Well, as far as I can tell, on Zaurus this is all done within the platform > ->enter() callback, so it doesn't carry out the device resume, while the > proposed $subject patch does. For this reason, I'm not even sure if the > proposed approach is really suitable for Zaurus (the resuming and suspending > of all devices every once a while will cost quite some enery I guess). In fact, the kernel "hacks" of mine have been looping at sysdev-suspend/resume implemented with platform_suspend_ops; thus it does not carry device resume either. I've moved the looping point to general device-suspend/resume because I thought that other systems may require active devices. However, if others can be satisfied without resumed devices, it is perfect with me to move that inside device resume as well. > > Still, in the unlikely case it is suitable, here's my opinion. > > I don't think syscore_ops is the right place to put the new "suspend > again" callback for reasons stated previously. > > I also don't think dev_pm_ops is the right place to put such a callback, > because it will only be necessary on very few platforms and there's no > reason why every driver, subsystem or power domain in the kernel should care. > > Moreover, the usage cases appear to be suspend-specific. > > For the above reasons, the only place the "suspend again" callback may be > put into is struct platform_suspend_ops. Then, suspend_devices_and_enter() > may be modified so that it loops between dpm_suspend_start() and > dpm_suspend_end() until that callback returns "false" and there are no > wakeup events (as indicated by pm_wakeup_pending(); but please note that > this would require suspend_enter() to indicate that pm_wakeup_pending() > returned "true" and events_check_enabled should not be reset until > we're sure that we _really_ want to resume). > > Alternatively, if that's sufficient, suspend_enter() may be called in a > loop until the "suspend again" callback returns "false" and there are no > wakeup events (in the above sense). > > The callback can be called "repeat" and return bool as far as I'm concerned, > but I'm not insisting on that. > > MyungJoo, would that be suitable to you? As long as sysdevs are resumed and some devices/subsystems (I2C-PMIC, ADC, and RTC in my cases) can be selectively resumed and suspended, it is fine. Thus, your "alternative" suggestion is perfect with me. Actually, this is almost going back to the original hack. =) I'll submit next revision with platform_suspend_ops later. Thank you! > > Rafael > Cheers! - MyungJoo -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
