t; - execution resume in resume function pointer
> - drivers restore their own modules as needed.
>
> So, there is no real black magic here :)
>
:)
Also if you are interested in how the SRAM copy stuff work, look
at OMAP3 entry into OFF state and memory self refresh is triggered
from code running from SRAM. On the wakeup though, we directly jump
to DDR address.
regards,
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thursday 21 February 2013 02:31 PM, Daniel Lezcano wrote:
On 02/21/2013 07:19 AM, Santosh Shilimkar wrote:
On Tuesday 19 February 2013 11:51 PM, Daniel Lezcano wrote:
On 02/19/2013 07:10 PM, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, Daniel Lezcano wrote:
I am working on identifying the
ctiveness of such optimization solely depends
on how well the affinity (in low powers) supported by your IRQ chip.
Hope this is helpful for you.
Regards,
Santosh
From d70f2d48ec08a3f1d73187c49b16e4e60f81a50c Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Wed, 25 Jul 2012 03:42:33 +0530
S
Its bit early but will try to reach ARM office by 10.30.
Regards,
Santosh
Cell: +919845640191
From: Viresh Kumar [viresh.ku...@linaro.org]
Sent: Sunday, February 17, 2013 12:27 PM
To: Aneesh Kumar K.V; Shilimkar, Santosh; Vineet Gupta; Srivatsa S. Bhat
Viresh,
On Friday 01 February 2013 02:22 PM, Santosh Shilimkar wrote:
On Friday 01 February 2013 01:32 PM, Viresh Kumar wrote:
On 1 February 2013 13:03, Santosh Shilimkar
wrote:
I am not talking about just notifiers. This is for external users who
has subscribed for notifiers. The point is
On Friday 01 February 2013 01:32 PM, Viresh Kumar wrote:
On 1 February 2013 13:03, Santosh Shilimkar wrote:
I am not talking about just notifiers. This is for external users who
has subscribed for notifiers. The point is whether the core CPUFReq
gets updated without that flag for all affected
On Friday 01 February 2013 12:43 PM, Viresh Kumar wrote:
On 1 February 2013 12:17, Santosh Shilimkar wrote:
I haven't looked at the cpufreq code recently but remember
that it was needed to ensure that all the CPU which
share clock/voltage gets updated (affected cpus) on
freq change. The
ore
http://bugzilla.kernel.org/show_bug.cgi?id=5737
Many non-ACPI systems are filling this field by mistake, which makes its usage
confusing. Lets clean it.
Signed-off-by: Viresh Kumar
Cc: Linus Walleij
Cc: Stephen Warren
Cc: Shawn Guo
Cc: Santosh Shilimkar
---
I haven't looked at the
I miss something ?
There might be an issue with status updating. Just look for gptimer1
interrupts. if they are incrementing then, broadcast is being used
but just the status update isn't happening some how.
regards
santosh
___
linaro
On Monday 29 October 2012 06:58 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can&#
On Monday 29 October 2012 06:57 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
yes
The goal is to prevent the
On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
On 24 October 2012 17:20, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
During sched_domain creation, we define a pack buddy CPU if available.
On a system
On Monday 29 October 2012 03:20 PM, Vincent Guittot wrote:
It looks like i need to describe more what
On 29 October 2012 10:40, Vincent Guittot wrote:
On 24 October 2012 17:17, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot
very convenient.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
main_span(sd),
+ nohz.idle_cpus_mask);
+
+ if (ilb < nr_cpu_ids)
+ break;
+ }
if (ilb < nr_cpu_ids && idle_cpu(ilb))
return ilb;
Can you please expand "idle CPU _close_ the pac
ct pair getting read
for rq runnable_avg_sum and runnable_avg_period. Seems
like the fix is to update them together under some lock
to avoid such issues.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
the task is a small one and the buddy is not overloaded,
+ * we use buddy cpu
+*/
+if (!is_light_task(p) || is_buddy_busy(buddy))
+ return false;
This is right but both the evaluation needs update to be effective.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
stand the clear
meaning of this new flag. Have you not considered SD_SHARE_CPUPOWER
because it is being used for cpu_power and needs at least minimum two
domains ? SD_PACKING would have been probably more appropriate based
on the way it is being used in further series.
Regards
Sa
log. Would be give a reference
about the commit which removed the feature(was present before), and
also some examples like say big.LITTLE, Tegra arch which needs the
per CPU latency tables.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@l
-off-by: Daniel Lezcano
> ---
Would be good to also mention the intention behind this change
in the change-log. The next patch make it clear but for this change
too, it should be added.
Feel free to add my ack if you need one.
Acked-by: Santosh Shilimkar
_
On Mon, Jul 9, 2012 at 8:40 PM, Vincent Guittot
wrote:
> On 9 July 2012 16:37, Shilimkar, Santosh wrote:
>> On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot
>> wrote:
>>> On 9 July 2012 15:00, Shilimkar, Santosh wrote:
>>>> On Mon, Jul 9, 2012 at 6:02 PM, Vin
On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot
wrote:
> On 9 July 2012 15:00, Shilimkar, Santosh wrote:
>> On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
>> wrote:
>>> On 9 July 2012 12:55, Shilimkar, Santosh wrote:
>>>> Vincent,
>>>>
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot
wrote:
> On 9 July 2012 12:55, Shilimkar, Santosh wrote:
>> Vincent,
>> On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot
>> wrote:
>>> Use cpu compatibility field and clock-frequency field of DT to
>>> es
On Mon, Jul 9, 2012 at 4:30 PM, Peter Zijlstra wrote:
> On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
>> Having that support would greatly help for the SOC's which have not
>> yet
>> reached to stage where entire SOC is DT compliant and want to use
&g
o stage where entire SOC is DT compliant and want to use
big.LITTLE infrastructure.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Jun 25, 2012 at 6:40 PM, Daniel Lezcano
wrote:
> On 06/25/2012 02:58 PM, Shilimkar, Santosh wrote:
>> On Mon, Jun 18, 2012 at 7:00 PM, a0393909 wrote:
>>> Daniel,
>>>
>>>
>>> On 06/18/2012 02:10 PM, Daniel Lezcano wrote:
>>>>
ssed is bringing the CPU cluster/package
> notion in the core idle code. Couple idle did bring that idea to some
> extent but in can be further extended and abstracted. Atm, most of
> the work is done in back-end cpuidle drivers which can be easily
> abstracted if the "clus
On Tue, May 1, 2012 at 3:50 PM, Daniel Lezcano
wrote:
> On 05/01/2012 11:55 AM, Shilimkar, Santosh wrote:
>>
>> On May 1, 2012 1:46 PM, "Daniel Lezcano"
>> wrote:
>>>
>>> On 05/01/2012 12:58 AM, Kevin Hilman wrote:
>>>>
>>&g
>
> Rob ? Do you mind the test the series again, the problem you were facing
when unplugging the cpu1 may have been fixed.
>
Have already tested this series on omap4 with cpu offline as well as with
couple idle series on top of it.
I haven't finished omap3 testing and hen
On Wed, Mar 21, 2012 at 6:49 PM, Jean Pihet wrote:
> Hi Santosh, Daniel,
>
> On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
> wrote:
>> Daniel,
>>
>> On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
>>> This patchset is a proposition to impr
On Wed, Mar 21, 2012 at 4:13 PM, Daniel Lezcano
wrote:
> On 03/21/2012 10:56 AM, Santosh Shilimkar wrote:
>>
>> On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
>>>
>>> On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
>>>>
>>
e series looks fine to me in general. This clean-up is applicable
for OMAP3 cpuidle code as well.
I want Jean to look at this series because some of his earlier
clean up has introduced those custom functions which
are getting removed in this series.
Regards
santosh
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote:
> On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
>> On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
>> wrote:
>>> The 'valid' field is never used in the code, let's remove it.
>>>
&g
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
> On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
>> On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
>> wrote:
>>> This patchset is a proposition to improve a bit the code.
>>> The changes are cod
TATES];
> +static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
OK
Regards
santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ions at boot time.
>
> Signed-off-by: Daniel Lezcano
> ---
Jean added the fill_cstate() kind of helpers o.w in the old
cpuidle code9OMAP30, static tables were used. Ofcourse those
tables were not uinsg the cpuidle driver structure.
Regards
santosh
_
te etc.
So unless and until there is a strong reason, i would like to retain it.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
neric WFI?
If yes, then, it's mainly because OMAP need additional
custom barriers.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Feb 29, 2012 at 12:48 PM, Richard Zhao wrote:
> arm registered cpufreq transition notifier to recalculate it.
>
> Signed-off-by: Richard Zhao
> ---
Thanks for the OMAP updates
Acked-by: Santosh Shilimkar
___
linaro-dev mailing lis
On Wed, Feb 29, 2012 at 12:48 PM, Richard Zhao wrote:
> If CONFIG_SMP, cpufreq skips loops_per_jiffy update, because different
> arch has different per-cpu loops_per_jiffy definition.
>
> Signed-off-by: Richard Zhao
> Acked-by: Russell King
> ---
Acked-by:
On Thu, Dec 22, 2011 at 3:54 PM, Russell King - ARM Linux
wrote:
> On Thu, Dec 22, 2011 at 02:19:23PM +0530, Shilimkar, Santosh wrote:
>> + Peter Z
>>
>> On Wed, Dec 21, 2011 at 3:37 PM, Russell King - ARM Linux
>> wrote:
>> > On Wed, Dec 21, 2011 a
There's nothing ARM specific about it.
There are few patches floating around for this issue. I posted one version
long back [1] and then there was one more form Thomas G.
The most recent is from one is from Peter Z [2] which is moving the
fix
ny_ identifier for it?
>>
>> ARM expanded errata 752271 to cover DLF not working till r3p2 in errata
>> version 13.1 (21 Nov 11), 4460 is r3p1-50rel0 and is impacted.
>
> Found the updated text, most annoying. It really does help performance.
>
You already see the updat
On Wed, Nov 23, 2011 at 6:55 AM, Andy Green wrote:
> On 11/22/2011 08:57 PM, Somebody in the thread at some point said:
>>
>> On Tue, Nov 22, 2011 at 6:02 PM, Mans Rullgard
>> wrote:
>>>
>>> On 22 November 2011 05:14, Shilimkar, Santosh
>>> wrote
On Tue, Nov 22, 2011 at 6:02 PM, Mans Rullgard wrote:
> On 22 November 2011 05:14, Shilimkar, Santosh
> wrote:
>> Mans,
>>
>> On Tue, Nov 22, 2011 at 8:15 AM, Mans Rullgard
>> wrote:
>>> These patches fix and tweak various cache settings for the
Mans,
On Tue, Nov 22, 2011 at 8:15 AM, Mans Rullgard wrote:
> These patches fix and tweak various cache settings for the 4460
> resulting in a speed increase exceeding 10% in some tests.
>
> Mans Rullgard (5):
> OMAP4: apply L2 cache lockdown workaround only on 4460 ES1.0
This one is OK though t
SoC., e.g., OMAP4, STE and so on.
BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
and should be zero (SBZ).
That's because not all PL310 versions double line fill.
Regards
santosh
___
linaro-dev mailing list
linaro-dev@l
sume code and learn
about something I've no current clue about.
Please continue your help on generic suspend.
Can someone please investigate and fix whatever is broken.
Will find somebody to look at this issue.
Regards
Santosh
___
lina
at using the policy->cpus field.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Colin,
On Friday 22 July 2011 10:51 AM, Colin Cross wrote:
On Thu, Jul 21, 2011 at 10:10 PM, Santosh Shilimkar
[]
For my OMAP4 PM rebasing, for time-being I will go with exported
GIC functions so that I don't have too many redundancies with GIC
save/restore code.
I think you s
On 7/22/2011 6:15 PM, Woodruff, Richard wrote:
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
With fixed IRQ migration and forcing CPU0 into an infinite WFI loop,
I can offline CPU0 and still have a
On 7/22/2011 12:36 AM, Colin Cross wrote:
On Thu, Jul 21, 2011 at 3:46 AM, Santosh Shilimkar
wrote:
On 7/21/2011 3:57 PM, Lorenzo Pieralisi wrote:
On Thu, Jul 21, 2011 at 09:32:12AM +0100, Santosh Shilimkar wrote:
Lorenzo, Colin,
On 7/7/2011 9:20 PM, Lorenzo Pieralisi wrote:
From
On 7/21/2011 7:00 PM, Russell King - ARM Linux wrote:
On Thu, Jul 21, 2011 at 11:03:04AM +0530, Santosh Shilimkar wrote:
Just talking on behalf of OMAP, we can't offline CPU0 and limitation
would remain in future OMAPs too.
Apart from the broken IRQ migration, and the way CPU0 immedi
On 7/21/2011 3:57 PM, Lorenzo Pieralisi wrote:
On Thu, Jul 21, 2011 at 09:32:12AM +0100, Santosh Shilimkar wrote:
Lorenzo, Colin,
On 7/7/2011 9:20 PM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the
ode based on power sequence need
might be better.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
er case of
everybody just copying other platforms' code, not a platform limitation.
Just talking on behalf of OMAP, we can't offline CPU0 and limitation
would remain in future OMAPs too.
Regards
Santosh
___
linaro-dev mailing li
On 7/11/2011 1:14 PM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 01:05:20PM -0700, Santosh Shilimkar wrote:
(Just to add few more points on top of what Colin already commented)
On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100
s
it's state to SAR ram, which is mapped uncached, which avoids L2
problems.
I'm afraid your information is out of date. See:
I think the confusion is OMAP3 and OMAP4. Colin was talking about OMAP4
which isn't merged in mainline yet where as you were referring OMAP3
clean-ups happe
e but not the ABI registers.
2. Mandate that L2 configuration is to be restored by platforms in their
pre-cpu_resume code so L2 is available when the C bit is set.
This seems a workable approach to me.
Thanks Russell for describing this clearly.
Regards
Santosh
_
rq
to reconfigure it, but that will be very inefficient - it will convert
each register write in the restore functions to a read-modify-write
per interrupt in that register. Santosh is already complaining that
this commong GIC restore code will be slower than the automatic DMA to
restore th
PU_V7&& CPU_PM
^
space needed.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
right ?
I noticed this in your other patches too.
Regards
santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ssible from non-secure SW. They need a secure API to set them.
This one too like GIC looks not useful in it's current form. :(
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
When a CLUSTER is powered down the SCU must be reinitialized on
warm-boot.
This patch adds a hook to reset the SCU, which implies invalidating
TAG RAMs and renabling it.
The scu virtual address is saved in a static variable when the SCU
is first enab
On 7/7/2011 6:41 PM, Colin Cross wrote:
On Thu, Jul 7, 2011 at 6:35 PM, Santosh Shilimkar
wrote:
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the cpu complex is powered
down
: "Ir" (0x40)
+: );
+}
To avoid aborts on platform which doesn't provide
access to SMP bit, NSACR bit 18 should be read.
Something like
mrc p15, 0, r0, c1, c1, 2
tst r0, #(1 << 18)
mrcne p15, 0, r0, c1, c0, 1
bicne r0, r0, #(1 <&l
reason CPU didn't hit targeted
state in IDLE. Does CPU keep looping here forever.
On OMAP4, we need to issue additional interconnect
barrier before WFI. How can we make provision for the same
Regards
Santosh
___
linaro-dev mailing list
linar
dle this? We would like to
use common ARM code as much as possible.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
b);
+int cpu_pm_unregister_notifier(struct notifier_block *nb);
+
+int cpu_pm_enter(void);
+int cpu_pm_exit(void);
+
+int cpu_complex_pm_enter(void);
+int cpu_complex_pm_exit(void);
+
Can "cpu_complex_pm*" renamed to "cpu_cluster_pm*" as discussed
earlier o
must be executed using a flat identity mapping with
+ * caches disabled.
Align the text body.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On 5/6/2011 7:57 PM, Santosh Shilimkar wrote:
On 5/6/2011 7:03 PM, Paolo Pisati wrote:
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
[...]
wrong id on the datasheet?
Not sure. Will confirm with TI hardware team but am quite certain about
the PL310 version used on OMAP4430.
Got
On 5/6/2011 7:03 PM, Paolo Pisati wrote:
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
Something wrong in ID decoding. The actual PL310 version used
on OMAP4430 ES2.x is r2p0 and hence errata 753970 is NA for
OMAP4430 PANDA/BLAZE/SDP.
weird since it's just a pci read:
arm/mm/cache
], that means Panda has a r3p0 L310 L2 controller.
Something wrong in ID decoding. The actual PL310 version used
on OMAP4430 ES2.x is r2p0 and hence errata 753970 is NA for
OMAP4430 PANDA/BLAZE/SDP.
Regards
Santosh
___
linaro-dev mailing list
linaro-dev
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Tuesday, March 08, 2011 3:05 AM
> To: Santosh Shilimkar
> Cc: Dave Martin; linux-arm-ker...@lists.infradead.org;
> patc...@linaro.org; Tony Lindgren; Jean Pihet-XID; linux-
> o...@vger.kern
Dave,
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Friday, March 04, 2011 11:05 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: patc...@linaro.org; Tony Lindgren; Santosh Shilimkar; Jean
> Pihet; Kevin Hilman; linux-o...@vger.k
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Turgis, Frederic
> Sent: Monday, February 21, 2011 11:20 PM
> To: linaro-dev@lists.linaro.org
> Subject: linaro-omap kernel 1003.6 boot failure
>
> Hi, (writing from
next do_dbs_timer is called and the point
> > raised by you is perfectly valid. Why don't you post this query to
> > cpu_freq mailing list?
> >
>
> ok, i'm going to send it
>
May be just send the patch to fix it.
Regards,
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Wednesday, December 08, 2010 4:35 PM
> To: Santosh Shilimkar
> Cc: Tony Lindgren; linux-o...@vger.kernel.org; linaro-
> d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org
> Subje
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Wednesday, December 08, 2010 4:11 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subje
Dave,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Wednesday, December 08, 2010 11:27 AM
> To: Dave Martin
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Tuesday, December 07, 2010 10:21 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subje
Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org;
bol, which will
> ensure that link-time fixups don't accidentally switch to the
> wrong instruction set.
>
> omap_secondary_startup might still need to be changed to ARM,
> depending on the compatibility status of bootloaders.
>
> Signed-off-by: Dave Martin
> ---
>
Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org;
> -Original Message-
> From: Bobby Batacharia [mailto:bobby.batacha...@arm.com]
> Sent: Monday, October 18, 2010 12:33 PM
> To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org
> Subject: RE: Common ARM context save/restore code
>
> Hi,
>
> Thanks f
Bobby,
> -Original Message-
> From: Bobby Batacharia [mailto:bobby.batacha...@arm.com]
> Sent: Sunday, October 17, 2010 4:08 AM
> To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org
> Subject: RE: Common ARM context save/restore code
>
> Santosh,
>
>
need to save/restore only 14 CP15 registers
(only needed ones) to get things working. Rest all is handles
as mentioned using secure code.
Having said that, would be good to see your patches.
Regards,
Santosh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Amit Kucheria
> Sent: Monday, October 04, 2010 2:27 PM
> To: Sripathy, Vishwanath
> Cc: Kevin Hilman; linux-o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subject: Re
m DDR and need not be from
cache. The only real implementation on OMAP3 is around DVFS code,
where you need to put DDR to self refresh and execute some
piece of code. That still needs to be executed from some other
memory like (SRAM).
Regards,
Santosh
_
7;t
> see too much variance in the latency to execute this bit of code. Vishwa
> is
> going to confirm that now. If that hypothesis is true, we can indeed move
> to
> using tracepoints in the idle path and use external tools to track l
ll not scale easily on OMAP4.
>
Just discussed how to scale this for all OMAPs. Firstly we need to
get this code to common place instead of tying it to OMAP3/OMAP4
specific low level code. Since on OMAP3, we can push C-functions
on SRAM and for OMAP4 we don't have any limitation, all this
91 matches
Mail list logo
