suspend/resume PM criterion for application

[Peter Teoh]

On Wed, Sep 17, 2014 at 11:16 AM, Peter Teoh <htmldeveloper at gmail.com>
wrote:

>
>
> On Sun, Sep 14, 2014 at 2:11 AM, Ran Shalit <ranshalit at gmail.com> wrote:
>
>> On Thu, Sep 11, 2014 at 12:24 PM, Ran Shalit <ranshalit at gmail.com> wrote:
>> > On Thu, Sep 11, 2014 at 8:32 AM, AYAN KUMAR HALDER <
>> ayankumarh at gmail.com> wrote:
>> >> On Thu, Sep 11, 2014 at 12:55 AM,  <Valdis.Kletnieks at vt.edu> wrote:
>> >>> On Wed, 10 Sep 2014 21:58:48 +0300, Ran Shalit said:
>> >>>
>> >>>> 1. How can I make a process to notice this inactivity ? Do you think
>> >>>> it can be implemented by some periodic process who check if there is
>> >>>> activity ? It returns to the original question I raised, that I will
>> >>>> use some periodic process who checks maybe cpu load or something like
>> >>>> that. What do you think ?
>> >>>
>> >>> That's going to depend on your system and what processes are running.
>> >>>
>> >>> You may have an MP3 player going that doesn't take much CPU at all -
>> but
>> >>> shutting down because the user hasn't hit a button in 47 minutes will
>> probably
>> >>> irritate the user no end.  Or there may be a screensaver running that
>> takes
>> >>> twice as much CPU as the MP3 player, but is totally OK on the system
>> >>> suspending whenever the rest of the system wants it.
>> >>>
>> >>> You're going to have to look at your system design, and decide for
>> yourself
>> >>> what the criteria are.
>> >>
>> >> Please correct me if my understanding is wrong:-
>> >>
>> >> I believe that autosuspend feature (for system suspend) is not present
>> >> in kernel. I believe that there is no feature in kernel which checks
>> >> for system ( cpu, devices) inactivity and suspends the entire system.
>> >> System suspend is caused when :-
>> >> 1. the user issues a command
>> >> 2. The system receives some interrupt or event (lid closing event)
>> >> 3. There is an external process which monitors system inactivity and
>> >> suspends the system.
>> >>
>> >> For runtime suspend of a device, I believe it is the driver who has
>> >> the complete responsibility to decide when to suspend the device or
>> >> resume it.  The driver can take this decision on user intervention (eg
>> >> when user writes to   /sys/devices/<my-device>/power/* ) or when the
>> >> driver has completed servicing an interrupt and feels it has nothing
>> >> more to do, etc
>> >
>> > Thanks Vlaid, Ayan,
>> >
>> > I am a bit yet struggling for couple of days on this PM issue, and I
>> > would appreciate your continous advise.
>> > The system requirement I have is as following:
>> > 1. make everything as automatic as possible , so that there won't be
>> > any need to add any userspace application for the matter.
>> > 2. wakeup from all relevant wakeup sources
>> > 3. should not use sysfs (it should be disabled from kernel)
>> > 4. platform is OMAP3530.
>>
>
> a.   look into /arch/arm/mach-omap2 of kernel source and grep for "sleep"
> and "wakeup" functionality:   power management is just managing with the
> different frequencies of the the CPU.   as far as I can tell, once sleep,
> only uart pin can be used for waking up....not sure.
>
> b.   read this:
>
>
> http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/30005.aspx
>
> http://www.ti.com/lit/an/slva310b/slva310b.pdf   (read page 2, which
> describe the different powerup-sequence of the CPU, "Powering-Up Sequence".
>
>
> c.   the technology brand name for omap3530 is "DVFS"....search for this
> inside the arch/arm kernel source.....you can find lots of sample codes
> there.
>
> (don't confuse with another omap CPU brand name "DeepSleep" but is PM for
> another type of omap cpu.)
>
> d.   http://www.ti.com/product/omap3530 --> on the right is a DVSDK +
> Android source code for 3530....grep the codes for the above keywords...
>
> hopefully it helps?
>
>
at the risk of missing out other files:

how about this two files:

inside arch/arm/mach-omap2:

omap-pm.h
omap-pm-noop.c

which I think provide a lot of hint for you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140917/9170d2f8/attachment.html