+ linux-omap on this thread.
> -----Original Message----- > From: Santosh Shilimkar [mailto:[email protected]] > Sent: Saturday, February 12, 2011 8:40 PM > To: Russell King - ARM Linux > Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm- > [email protected] > Subject: RE: [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume > support > > > -----Original Message----- > > From: Russell King - ARM Linux [mailto:[email protected]] > > Sent: Saturday, February 12, 2011 8:20 PM > > To: Santosh Shilimkar > > Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm- > > [email protected] > > Subject: Re: [PATCH v3 2/5] ARM: pm: add generic CPU > suspend/resume > > support > > > > On Fri, Feb 11, 2011 at 05:37:04PM +0530, Santosh Shilimkar wrote: > > > There is a Monitor secure API, needs to be called from non- > secure > > > software to set this diagnostic registers in resume path. > > > > It would be an idea to get the OMAP sleep code up to date so that > I > > can > > look at OMAPs requirements for this to be useful. > > > > As the current code stands, I don't see any reason why the > sleep34xx > > code > > can't use this infrastructure, but I'm loathed to start modifying > > that if there's outstanding code changes in that area. > > Yep. There are few issues out there with sleep34xx code. > - Secure APIs > - Current code needs to be cleaned up to remove > unwanted registers save restore > - Some part of the code on OMAP3 must be run from > SRAM. It can't run from DDR > - AUXCTLR, Diagnostic registers aren't accessible > in secure mode. > - L2 cache needs to be handled with secure APIs. > - Code sequence needs to handle errata's handling > which accesses OMAP PM registers. > > Few of the above are getting addressed for this merge window. > > So my plan was to take a look at generic suspend after the > merge window. By that time your generic stuff and omap > cleanup would have got merged hopefully. > > Regards, > Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
