On Wednesday, November 20, 2013 11:04:28 AM Viresh Kumar wrote: > On 18 November 2013 11:09, viresh kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 18 November 2013 03:07, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > >> On Sunday, November 17, 2013 10:27:43 PM Viresh Kumar wrote: > > > >>> Okay.. Even these notifiers would be fine for me. To make things more clear > >>> before I start implementing them: > >>> - What about implementing syscore's suspend_prepare and post_suspend? > >> > >> I'm not sure how useful that would be. When would you like to execute those > >> things? > > > > Maybe after freezing userspace. So I was actually looking to move the existing > > code I wrote in PM notifiers to those.. > > > > Because in our usecase, we just want to know when suspend has started or > > resume has finished. And so we really don't need a per cpu callback. > > > > And so I felt probably it would be better to implement those instead of > > cpu_subsys callbacks. > > > >>> - Or you want to extend only CPU subsystems notifiers? What notifiers exactly? > >>> And at which places we want to issue them from? > >> > >> Why do we need to use notifiers? What about PM callbacks? > > > > Yeah, we don't need notifiers but callbacks. > > > >>> Okay, so you were asking about extending following list: CPU_ONLINE, > >>> CPU_UP_PREPARE, CPU_UP_CANCELED, CPU_DOWN_PREPARE, etc.. to > >>> include suspend/resume ones as well? > >> > >> No. Bus types (among other things) may provide suspend/resume callbacks for > >> handling devices. We have a bus type for CPUs, which is called cpu_subsys > >> and currently doesn't define any PM callbacks, although it could do that in > >> principle. Have you investigated that possibility? > > > > I did it now and got really confused. :) > > > > This is what my understanding is: > > - bus can register PM hooks, like suspend/resume/prepare, etc.. > > - devices under that bus would register themselves to that bus and eventually > > can get their _driver's_ callbacks called via bus hooks.. For example and I2C > > controller driver's callbacks will get called via i2c core bus.. > > > > - In case of cpu subsystem, even if cpu_subsys adds those hooks in > > drivers/base/cpu.c, then those hooks will get called for each cpu. CPU's don't > > have a driver and so the only callbacks called are the ones of cpu_subsys. > > - How will we bind/use them with cpufreq? > > > > Our sole requirement here is to get notify cpufreq core that system > > suspend/resume/hibernation/restore has started/finished. How will that get > > fulfilled with cpu_subsys callbacks? > > > >>> Logically speaking, all existing ones does look correct as they are more or > >>> less cpu related. But suspend/resume doesn't look any similar, Atleast to me. > >>> > >>> Suspend/resume are system's state rather than CPU's.. We aren't suspending > >>> or resuming CPUs, we are shutting them off.. So I thought maybe syscore ops > >>> is a better place (which is already used by cpufreq).. > >> > >> cpufreq uses syscore_ops for the boot CPU only and that admittedly is a hack. > > > > Why do you call it a hack? > > > >> syscore_ops is specifically for things that have to be suspended with only one > >> CPU online and with interrupts off. I'm not sure how that applies to cpufreq. > > > > Currently syscore_ops only implements suspend/resume/shutdown callbacks and > > those precisely happen the way you mentioned. i.e. after removing all non-boot > > CPUs and disabling interrupts (And before bringing back all CPUs and enabling > > interrupts on resume side).. So, yes we have limitation currently.. > > > > Honestly speaking I have looked at syscore ops for the first time now, when we > > got to this problem.. I couldn't find much information about it anywhere, > > leaving the commit itself: 40dc16 > > > > And by that, this is the definition of this framework: "PM / Core: Introduce > > struct syscore_ops for core subsystems PM" > > > > I can see that you mentioned the limitations like single cpu and disabled > > interrupts even in the log, but I think we can enhance this framework a little bit. > > > > Also I can see that there are many users of this framework which aren't core > > frameworks but simply drivers. I don't think that was the intention behind this > > framework, but that's how others went to use it. > > > > So, this framework exists to service core frameworks for their requirements > > about PM stages. Currently that is only limited to late suspend and early resume > > but I feel there is space for more.. > > > > For example, our current problem.. A core framework wants to prepare before > > suspend starts and after everything has resumed. Obviously that would violate > > one of the basic rules with which this was designed, but still this feature lies > > in scope of syscore. And so we can keep the limitations as is for > > suspend/resume/shutdown but not for prepare and resume_late. > > > > And I really feel even if we would be able to use cpu callbacks for > > suspend/resume, that would be a real *Hack*, because our framework doesn't want > > to get a callback for each of its devices (i.e. cpu) but a single callback at > > certain instances.. And syscore suits very well to this scenario.. > > Hi Rafael, > > I need few more suggestions from you on this :) And I need some more time to think about that. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
