On Wed, Sep 17, 2014 at 11:16 AM, Peter Teoh <htmldevelo...@gmail.com> wrote:
> > > On Sun, Sep 14, 2014 at 2:11 AM, Ran Shalit <ransha...@gmail.com> wrote: > >> On Thu, Sep 11, 2014 at 12:24 PM, Ran Shalit <ransha...@gmail.com> wrote: >> > On Thu, Sep 11, 2014 at 8:32 AM, AYAN KUMAR HALDER < >> ayankum...@gmail.com> wrote: >> >> On Thu, Sep 11, 2014 at 12:55 AM, <valdis.kletni...@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.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
