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

[Santosh Shilimkar]

> -----Original Message-----
> From: ccross@xxxxxxxxxx [mailto:ccross@xxxxxxxxxx] On Behalf Of
> Colin Cross
> Sent: Saturday, February 05, 2011 10:06 PM
> To: Santosh Shilimkar
> Cc: Russell King - ARM Linux; Will Deacon; Catalin Marinas; Linus
> Walleij; konkers@xxxxxxxxxxx; Tony Lindgren; linux-
> kernel@xxxxxxxxxxxxxxx; linux-tegra@xxxxxxxxxxxxxxx; olof@xxxxxxxxx;
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support
> forre-enabling l2x0
>
> On Sat, Feb 5, 2011 at 4:41 AM, Santosh Shilimkar
> <santosh.shilimkar@xxxxxx> wrote:
[....]

> >> On Sat, Feb 05, 2011 at 01:21:24PM +0530, Santosh Shilimkar
> wrote:
> >> > 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.
> >>
> >> What this means is that we're going to end up littering things
> like
> >> GIC
> >> and other stuff with lots of individual SoC specific code to save
> >> state
> >> into individual SoC specific structures.  This is not sane, and
> >> we're
> >> not going to corrupt generic code with SoC specific code.
> >
> > Fully agree and hence flagged it early.
> >
[....]

>
> Would putting dummy values in the areas the boot ROM uses and then
> letting the common GIC code restore over them cause any problems?

Ya there are few issue. GIC and GIC OMAP extension are managed
together by BOOT ROM code. It's far optimal save and restore. Only
needed registers from OMAP point of view are saved/restored.
And for such reasons I would not like to use dummy stuff.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/