suspend/resume PM criterion for application

Tue Sep 16 23:16:52 EDT 2014

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?

> >
> > Now, As I understand thus far, I have the following options (
> > requirement 3 above I will ignore, don't know how to handle it yet,
> > and assume for meanwhile that I have sysfs) :
> > 1. use suspend scheme (no runtime PM)
> >     1.a. create some kernel thread who check cpu load and will decide
> > to disable system only if its below some minimum threshold (which
> > should indicate no activity)
> >     1.b. initialize all HW interrupts (gpio, uart, etc) as wakeup sources
> >     with this scheme only this thread is responsible for the suspend,
> > and there is no use of the runtime PM, right ?
> >
> > 2. use runtime PM scheme :
> >     With this scheme I don't understand how some device will wake the
> > system , or doesn't it need to  ? If a driver wakes up maybe it need
> > to deliver some info to system    ?
> >
> > I think option 1 is also easier to support, what do you think about both
> ?
> >
> > Thanks!!
> > Ran
>
> Does Anyone have any suggestions and feedback on the above requirements ?
>
> Thank you,
> Ran
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140916/1afe9848/attachment-0001.html 