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? > > > > 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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Peter Teoh
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
