Paul, > -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Monday, December 13, 2010 4:13 PM > To: Vishwanath Sripathy > Cc: Kevin Hilman; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [PATCH/RFC 2/2] OMAP: PM: implement context loss count > APIs > > Hello Vishwa, > > On Fri, 10 Dec 2010, Vishwanath Sripathy wrote: > > > > + count = omap_device_get_context_loss_count(pdev); > > > + pr_debug("OMAP PM: context loss count for dev %s = %d\n", > > > + dev_name(dev), count); > > Shouldn't this implementation be part of omap-pm.c where all the > OMAP PM > > functions are to be implemented? I thought omap-pm-noop.c should > have > > dummy implementation. > > In general, yes. But we also want the code in omap-pm-noop.c not to > cause > additional breakage. Unlike most of the other functions in this file, if > the context loss count function doesn't do something minimally useful, > then > the system is going to break badly. You've probably seen this thread: > > http://www.mail-archive.com/linux- > omap@xxxxxxxxxxxxxxx/msg40079.html > > (By the way, the reason why I think we shouldn't use the approach > described in > > http://www.mail-archive.com/linux- > omap@xxxxxxxxxxxxxxx/msg40101.html > > is because I suspect it is going to seriously damage retention idle > performance. For example, the HSMMC driver resets its entire IP block in > its context restore function...) > > But to confirm your general point, yes, in general, further functional > development of the OMAP PM code should take place outside the no-op > file. > Hopefully, at some point, we'll be able to drop the no-op file. Once > there is a useful replacement, we should be able to switch to it as a > default. I have no issues with the implementation and I agree. All I am saying is that why can't this implementation be added in omap-pm.c and compile this file instead of omap-pm-noop.c when OMAP_PM is enabled. I believe this function is useful when off mode is enabled which means OMAP_PM is enabled. Vishwa > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
