[PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0

[Santosh Shilimkar]

> -----Original Message-----
> From: ccross at google.com [mailto:ccross at google.com] On Behalf Of
> Colin Cross
> Sent: Saturday, February 05, 2011 7:15 AM
> To: Russell King - ARM Linux
> Cc: Will Deacon; Santosh Shilimkar; Catalin Marinas; Linus Walleij;
> konkers at android.com; Tony Lindgren; linux-kernel at vger.kernel.org;
> linux-tegra at vger.kernel.org; olof at lixom.net; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for
> re-enabling l2x0
>
> On Fri, Feb 4, 2011 at 5:43 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Fri, Feb 04, 2011 at 05:32:26PM -0600, Colin Cross wrote:
> >> On Tue, Jan 25, 2011 at 12:39 PM, Will Deacon
> <will.deacon at arm.com> wrote:
> >> > Well if you set the priority fields in the notifier blocks
> correctly
> >> > then you can just return NOTIFY_STOP when you've saved/restored
> as much
> >> > as you want. This assumes of course that you can identify which
> power
> >> > mode you're entering/leaving and that each one is `deeper' than
> the previous.
> >>
> >> I doubt its possible to create an order that will work for all
> >> architectures, and returning NOTIFY_STOP would require the
> decision on
> >> when to finish to be made by the notifier block instead of the
> >> platform code.
> >>
> >> Tegra has three possible idle modes:
> >>
> >> 1.  WFI - nothing reset
> >> 2.  CPU, TWD, L1, GIC lost, L2 needs to be disabled but not reset
> >> 3.  CPU, TWD, L1, GIC, and L2 lost
> >
> > (2) and (3) don't sound like per-cpu modes but system modes.  If
> you're
> > having to disable L2, then your other CPU can't be active.
>
> Yes, 2 and 3 require both CPUs to be idle.  Unfortunately, on Tegra,
> it is important to use at least 2 as much as possible, because the
> two
> CPUs are not individually power gated.
>
> >> CPU and L1 are already handled by the platform-specific suspend
> code.
> >> TWD is handled by the clockevents broadcast notifiers.  That
> leaves L2
> >> and GIC.
> >
> > GIC can be handled in just the same way - upon a CPU idling and it
> > being decided that the CPU should enter low power mode, the idle
> states
> > are entered which does what's required with TWD, L1, VFP, Neon,
> etc.
> > We just need the GIC CPU interface included in there.
> >
> > When both CPUs are idled, then the L2 comes into play, and then
> modes
> > (2) and (3) become possible and this is where you start doing the
> extra
> > stuff.
>
> Are you suggesting that the idle notifiers only handle TWD, L1, VFP,
> Neon, and GIC?  That would simplify things, as there are probably no
> ordering requirements, and they should be the same for any platform
> that uses them.
>
> > Note that you have to do it that way anyway, because you can't
> save
> > the state of the other CPU's GIC without doing an IPI call, which
> > could kick it out of its idle mode.
>
> There is currently no state that needs to be saved in the GIC CPU
> registers, they can all be reinitialized.
GIC save/restore on OMAP follows different strategy. There is a
Predefined layout to save content and restore is done atomically
by boot ROM code.
L2 cache also same case. Only AUXCTRL needs to be programmed on
wakeup from low power mode and that too with secure call. Rest
of the registers are managed by boot ROM code.

TWD is already managed through framework. Othe CPU low power
sequence is very small and OMAP has restrictions on the last
core to go down and first to wakeup.

So at least I don't see any use of common notifiers for GIC
and L2 will help OMAP lower power code.

Regards,
Santosh