On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote:
> On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote:
> > I think it makes sense if this 'upstream' doesn't include board files
> > though, they should come from LT trees.
> >
> As for the board specific fragments, I feel it would be better if
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/ar
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/arch
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index cdf1b8f..332b636 100644
--- a/arch/arm/mach-omap
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 +++--
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cdd7932..fb0f76e 1006
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index fb0
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimka
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 86 +---
1 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 35a1471..f54e6ae 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm
We are storing the 'omap3_idle_data' in the private data field
if the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
As the table is initialized static
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
Daniel Lezcano (17):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle -
We are storing the 'omap4_idle_data' in the private data field
if the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
Also, that simplfies the code.
Si
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
4 files changed, 22 insertions(+), 22 deletions
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 882d349..413aac4 100644
--
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle4
As suggested, this table is an optimized version for rx51 and we
remove it in order to consolidate the cpuidle code between omap3
and omap4, we remove this specific data definition which is used
to override the default omap3 latencies but at the cost of extra
code and complexity.
In order to not l
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach
Simplify the indentation by removing the useless 'else' statement.
Remove the first loop for the 'idx' search as we have it already
with the 'index' passed as parameter.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 53 +---
1 files chang
On 04/02/2012 02:15 PM, Pantelis Antoniou wrote:
Example session:
# perf sched record
< run process, etc.>
^C<- perf ends producing a perf.data file.
# perf sched spr-replay -l
# perf sched spr-replay -s -s -d -n -g
# perf sched spr-replay -s -g>test.spr
# perf sched spr-replay -f
On 04/02/2012 02:18 PM, Pantelis Antoniou wrote:
Ah, about the load it's because perf sched record adds too many events to the
recording (and configuring small buffers for perf). Using a smaller set
of events works much better.
I tried with a different subsets of 'sched:*' events, but it didn'
On 04/04/2012 01:02 PM, Jon Medhurst (Tixy) wrote:
> On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote:
>> On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote:
>>> I think it makes sense if this 'upstream' doesn't include board files
>>> though, they should come from LT trees.
>>>
>> As for the
Hi Dmitry,
There is big difference between threads and processes as far as the kernel
is concerned; both are performed by just a clone syscall, and share or
not address space/fd's etc.
If you want to replay per-process workloads, you can just
record only the activity of the pids of the threads o
Hello,
I am working on behalf of an SoC vendor and I am trying to work out
which (if any) of the many git trees at http://git.linaro.org/gitweb we
should base our work on. I would like to use the Linaro code base
because the arch/arm support is ahead of mainline. But I also need a
degree of s
On Apr 4, 2012, at 1:13 PM, Dmitry Antipov wrote:
> On 04/02/2012 02:18 PM, Pantelis Antoniou wrote:
>
>> Ah, about the load it's because perf sched record adds too many events to the
>> recording (and configuring small buffers for perf). Using a smaller set
>> of events works much better.
>
>
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds
wrote:
> Hello,
>
> I am working on behalf of an SoC vendor and I am trying to work out which
> (if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or an existing SoC?
> base our work on.
On 04/02/2012 02:11 PM, Daniel Vetter wrote:
On Mon, Apr 02, 2012 at 12:40:39PM +0900, Kyungmin Park wrote:
On Mon, Apr 2, 2012 at 12:34 AM, Rob Clark wrote:
On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
wrote:
- drm dma-buf prime support. Dave Airlie sent me the pull request but
didn
On 04/04/2012 06:20 PM, Somebody in the thread at some point said:
> On 04/04/2012 01:02 PM, Jon Medhurst (Tixy) wrote:
>> On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote:
>>> On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote:
I think it makes sense if this 'upstream' doesn't include bo
@Subash Patel, prime is already included.
Why the CMA is at 24 version and still not included ?
Linus, please include
CMA,git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git
3.4-rc1-cma-v24
___
linaro-dev mailing list
linaro-dev@lists.linaro.o
Hey Jo/Hector,
Did anything ever result from this?
Peter
On Thu, Feb 2, 2012 at 11:11 PM, Hector Oron wrote:
> Hello Jo,
>
> I am forwarding the message to a couple mailing lists which might have
> people interested on the Mono porting for ARM hard-float ABI.
>
> 2012/2/2 Jo Shields :
>> Right
Dmitry,
The reason for the slowdown is that perf sched record default settings is
tuned for x86 pretty much, and there's a huge amount of data being generated.
perf sched record is just a wrapper for perf record so try using this script
for recording:
> #!/bin/sh
> perf record \
> -a \
>
Hi,
On 2012-04-02, at 5:45 AM, Andy Green wrote:
> On 04/02/2012 05:31 PM, Somebody in the thread at some point said:
>> On Sun, 2012-04-01 at 20:59 +0400, Andrey Konovalov wrote:
>>> On 03/31/2012 01:17 PM, Jon Medhurst (Tixy) wrote:
On Fri, 2012-03-30 at 10:15 -0700, John Stultz wrote:
>>>
On 2012-04-04, at 10:07 AM, Kevyn-Alexandre Paré wrote:
> Hi,
>
> On 2012-04-02, at 5:45 AM, Andy Green wrote:
>
>> On 04/02/2012 05:31 PM, Somebody in the thread at some point said:
>>> On Sun, 2012-04-01 at 20:59 +0400, Andrey Konovalov wrote:
On 03/31/2012 01:17 PM, Jon Medhurst (Tixy)
Daniel,
On Wed, Apr 4, 2012 at 11:42 AM, Daniel Lezcano
wrote:
> We are storing the 'omap3_idle_data' in the private data field
> if the cpuidle device. As we are using this variable only in this file,
Typo: _of_ the cpuidle device.
> that does not really make sense. Let's use the global variabl
Daniel,
On Wed, Apr 4, 2012 at 11:42 AM, Daniel Lezcano
wrote:
> This patchset makes some cleanup on these cpuidle drivers
> and consolidate the code across both architecture.
>
> Tested on OMAP3 (igepV2).
> Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
Ok with this patch s
Hi Daniel,
On Wed, Apr 4, 2012 at 11:42 AM, Daniel Lezcano
wrote:
> We are storing the 'omap4_idle_data' in the private data field
> if the cpuidle device. As we are using this variable only in this file,
Typo: _of_ the cpuidle device.
> that does not really make sense. Let's use the global vari
On 04/04/12 11:53, Amit Kucheria wrote:
On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds
wrote:
Hello,
I am working on behalf of an SoC vendor and I am trying to work out which
(if any) of the many git trees at http://git.linaro.org/gitweb we should
Is this a new SoC (no mainline support) or
Hi,
Today we migrated the www.linaro.org website to a new server at our
provider. The website was down for less than a minute (pingdom didn't
even fire an alert). We've tested it and it appears to be in perfect
order. Should you find any issues, please give me a shout.
Thanks,
Joey
--
Joey S
On 4 April 2012 09:54, Chris Simmonds wrote:
> On 04/04/12 11:53, Amit Kucheria wrote:
>>
>> On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds
>> wrote:
>>>
>>> Hello,
>>>
>>> I am working on behalf of an SoC vendor and I am trying to work out which
>>> (if any) of the many git trees at http://git.
Hi Daniel,
Daniel Lezcano writes:
> This patchset makes some cleanup on these cpuidle drivers
> and consolidate the code across both architecture.
>
> Tested on OMAP3 (igepV2).
> Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
Any reason this wasn't posted to linux-omap?
Wa
On 04/04/2012 08:40 PM, Kevin Hilman wrote:
Hi Daniel,
Daniel Lezcano writes:
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
Any reaso
On 04/04/2012 06:05 PM, Jean Pihet wrote:
Daniel,
On Wed, Apr 4, 2012 at 11:42 AM, Daniel Lezcano
wrote:
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offl
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 35a1471..f54e6ae 100644
--- a/arch/arm/mach-omap2/cpu
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index fb0
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/ar
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle4
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 8
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
V2 : Fixed a couple of typos in the patch description
V1 : Initial Post
Daniel Lezcano (17):
We are storing the 'omap4_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
Also, that simplfies the code.
Si
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
4 files changed, 22 in
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
d
Simplify the indentation by removing the useless 'else' statement.
Remove the first loop for the 'idx' search as we have it already
with the 'index' passed as parameter.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 53 +-
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimka
We are storing the 'omap3_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly
instead dereferencing pointers in an idle critical loop.
As the table is initialized static
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index cdf1b8f..332b636 100644
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 28
As suggested, this table is an optimized version for rx51 and we
remove it in order to consolidate the cpuidle code between omap3
and omap4, we remove this specific data definition which is used
to override the default omap3 latencies but at the cost of extra
code and complexity.
In order to not l
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cdd7932..fb0f76e 1006
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 86 +---
1 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/arch
On Wed, Apr 04, 2012 at 05:54:13PM +0100, Chris Simmonds wrote:
> >Is this a new SoC (no mainline support) or an existing SoC?
>
> It's a new SoC which will have its own arch/arm/mach-xxx directory
You haven't stated clearly your intention -- is it your first priority
to have support for this pla
Hi Durgadoss,
Instead of making all the trip-points of a thermal zone writeable we should
only allow non-critical trip points to be writeable.
Thanks,
Amit Daniel
> -Original Message-
> From: Durgadoss R
> Sent: Friday, January 27, 2012 9:58 PM
> To: linux-a...@vger.kernel.org
> Cc: l..
62 matches
Mail list logo
