On Thu, 2012-05-17 at 09:37 -0700, Kevin Hilman wrote: > "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> writes: > > > On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh > > <santosh.shilimkar@xxxxxx> wrote: > >> On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman <khilman@xxxxxx> wrote: > >>> Tero Kristo <t-kristo@xxxxxx> writes: > >>> > >>>> From: Rajendra Nayak <rnayak@xxxxxx> > >>>> > >>>> SAR/ROM code restores only CORE DPLL to its original state > >>>> post wakeup from OFF mode. > >>>> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER) > >>>> are saved and restored here during an OFF transition. > >>>> > >>>> [nm@xxxxxx: minor cleanups] > >>>> Signed-off-by: Nishanth Menon <nm@xxxxxx> > >>>> Signed-off-by: Rajendra Nayak <rnayak@xxxxxx> > >>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx> > >>>> Signed-off-by: Tero Kristo <t-kristo@xxxxxx> > >>> > >>> Some general comments: > >>> > >>> - the register dump/print doesn't belong here. If needed, should be a > >>> debug feature if needed. > >>> > >>> - Rather than hooking into omap4_enter_lowpower(), should use > >>> the cluster PM enter/exit notifier chain. > >>> > >> This is again specific to device OFF only and not related to CPU > >> cluster state as such. So I don't think notifiers should be used here. > >> > >> O.w even when we attempt just MPU OSWR C-state, all these functions will > >> get called in notifier chain. > >> > > Just a thought, we can have a separate notifier chain for device OFF. It can > > allow use to get rid of 'enable_off_mode" kind of flags and can be > > used by many drivers too. > > Yes, I like this idea. > > It allows a much cleaner collection of all the activities needed for > device off. I can just read the device next state off in the notifier func. -Tero -- 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
