Hi Amit,
Apologies for the delayed response.
> Yes, the earlier the better to starting incorporating the
> changes in Linux.
Agreed - this is a priority for ARM. (We're at least a little behind the curve
on putting the arch and CPU-centric stuff in shared arch code, given the
device-specific c
Santosh,
Again - apologies for the tardy responses to this thread.
> This is something very different from SOC point of view.
> Example OMAP4, the restore for GIC, SCU, L2 is handled by ROM
> code and it expect it to save in a particular pattern and
> pre-defined memory location. Generic code won
g that.It's doable but it will end up with some SOC specific execeptions.
Understood.
-Bobby
> -Original Message-
> From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com]
> Sent: 18 October 2010 06:19
> To: Bobby Batacharia; Jon Callan; linaro-dev@lists.linaro.o
s fixed secure code.)
-Bobby
> -Original Message-
> From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com]
> Sent: 18 October 2010 08:09
> To: Bobby Batacharia; Jon Callan; linaro-dev@lists.linaro.org
> Subject: RE: Common ARM context save/restore code
>
> > ---
Hi Catalin,
> > Our plan is definitely to get this into the Linaro kernel for the
> > 11.05 release. My preferred approach is to get it into Catalin's
> > public tree by early Q1, so that we stand a chance of merging it into
> > the Linaro consolidated kernel.
>
> Another step before this would be
> > > * ACTION: ARM to discuss giving out internal Eclipse based tool
> > > (similar to powertop) (no ETA as of now)
The tool is an Eclipse-based generic event viewer. Internally, we're displaying
'power events,' such as those that Srinivas' recent ftrace patches around
cpufreq/cpuidle. Ther
