Hi Kevin,
On Tue, Mar 31, 2015 at 07:58:21PM +0100, Kevin Hilman wrote:
Will Deacon will.dea...@arm.com writes:
On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
On 26 March 2015 at 06:36, Will Deacon will.dea
On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote:
On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
On Tue, Mar 24, 2015 at 11:13:58AM
On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
I think we now have a new error: (seen with omap2plus_defconfig)
on next-20150324 :
./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
On Sun, Jan 25, 2015 at 03:56:52PM +, Russell King - ARM Linux wrote:
On Sat, Jan 24, 2015 at 04:23:42PM -0600, Felipe Balbi wrote:
yeah, I'll try a few older kernels, also see if I can reproduce on other
boards.
Perf works for me with CONFIG_FRAME_POINTER=y, but that's only for kernel
On Mon, Jan 26, 2015 at 12:12:43PM +, Arnaldo Carvalho de Melo wrote:
Em Mon, Jan 26, 2015 at 10:27:11AM +, Will Deacon escreveu:
On Sun, Jan 25, 2015 at 03:56:52PM +, Russell King - ARM Linux wrote:
On Sat, Jan 24, 2015 at 04:23:42PM -0600, Felipe Balbi wrote:
yeah, I'll try
out there that
don't predict mov pc, lr at all (let alone do anything with the return
stack).
discussing this with Will Deacon over the last couple of days, who has
also been talking to the hardware people in ARM, and Will is happy with
this patch as in its current form.) This is why I've
On Thu, May 29, 2014 at 06:52:14PM +0100, Rob Herring wrote:
On Thu, May 29, 2014 at 1:38 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
DRA7 SOCs.
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring robh...@kernel.org
Hi Santosh,
On Tue, Aug 13, 2013 at 02:31:04PM +0100, Santosh Shilimkar wrote:
On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
I think this an A9-specific
On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote:
Hi!
I get:
CC arch/arm/kernel/machine_kexec.o
/tmp/ccCFXeXG.s: Assembler messages:
/tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
nshst'
/tmp/ccCFXeXG.s:225: Error: garbage following instruction --
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
I think this an A9-specific register, which reads as 0 on UP A9 and reads as
some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE
is zero
.
The issue was spotted on TI's Aegis device and this patch
makes now the device work with omap2plus_defconfig which
enables SMP by default. The change is kept limited to only
Cortex-A9 MPCore detection code.
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Acked
On Fri, Aug 02, 2013 at 04:45:46PM +0100, Sudeep KarkadaNagesha wrote:
On 02/08/13 16:22, Santosh Shilimkar wrote:
+ @ Core indicates it is SMP. Check for Aegis SOC where a single
+ @ Cortex-A9 CPU is present but SMP operations fault.
+ mov r4, #0x4100
+ orr r4, r4,
as it's obsolete, per Nico's post:
http://www.spinics.net/lists/arm-kernel/msg261208.html
This patch is a collaboration with Will Deacon and Russell King.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc
Hi Paul,
On Sun, Jul 28, 2013 at 09:16:29PM +0100, Paul Walmsley wrote:
Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc (ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting) breaks
the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an
undefined instruction
On Sat, Jul 27, 2013 at 05:10:56AM +0100, Paul Walmsley wrote:
Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux
colleagues perhaps, and started testing, and eventually wound up with this
one:
commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
Author: Will Deacon
On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
Hi Rajendra,
On Tue, 23 Jul 2013, Rajendra Nayak wrote:
On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
On Thu, Apr 11, 2013 at 05:19:21PM +0100, Stephen Warren wrote:
On 04/10/2013 10:46 PM, Li Haifeng wrote:
2013/4/10 Stephen Warren swar...@wwwdotorg.org:
On 04/10/2013 03:35 AM, Li Haifeng wrote:
Hi, everyone.
Recently, I try to run kdump on pandaboard ES with omap4460. After
load
On Mon, Mar 25, 2013 at 09:11:00AM +, Santosh Shilimkar wrote:
Will,
Hi Santosh,
Are you going to send the patch for 3.9-rcx ? As I said before without the
patch OMAP4 CPUILDE is unusable because of that debug noise and hence it
will be good to get that patch in
It's in Russell's tree,
On Tue, Mar 19, 2013 at 06:39:38AM +, Santosh Shilimkar wrote:
On Monday 18 March 2013 10:36 PM, Will Deacon wrote:
Any chance you could follow up with your firmware/hardware guys about this
please? I'd really like to understand how we end up in this state in case we
can do something
Hi Santosh,
On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
Furthermore, I was under the impression that hw_breakpoint did actually
work on panda, which implies that a cold boot *does* manage to reset the
registers
On Mon, Mar 18, 2013 at 03:46:28PM +, Santosh Shilimkar wrote:
On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
That really sucks :( Does this affect all OMAP-based boards?
All OMAP4 based boards..
Brilliant. Is there any way that the secure code can be fixed in future
products
On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote:
On Wed, 12 Dec 2012, Will Deacon wrote:
Back to the case in hand Lorenzo just pointed out to me that the
finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so
the louis stuff should be irrelevant
On Thu, Dec 13, 2012 at 02:32:46PM +, Guennadi Liakhovetski wrote:
On Thu, 13 Dec 2012, Will Deacon wrote:
On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote:
On Wed, 12 Dec 2012, Will Deacon wrote:
Back to the case in hand Lorenzo just pointed out to me
Hi Jon,
On Wed, Dec 12, 2012 at 09:43:04PM +, Jon Hunter wrote:
The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having
On Wed, Dec 12, 2012 at 09:43:06PM +, Jon Hunter wrote:
Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
AMBA bus driver so that we can use device-tree to look-up the hardware
specific information such as base address and interrupt number during
the device probe. This also
On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote:
Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
The ARM Cross Trigger Interface provides a way to route events between
processor modules. For example, on OMAP4430 we use the CTI module to
route PMU events to the
On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote:
On 12/11/12 08:38, Will Deacon wrote:
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index cd95664..f58248f 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -44,7 +44,8 @@ ENDPROC
On Wed, Dec 12, 2012 at 10:33:38AM +, Lorenzo Pieralisi wrote:
On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote:
On 12/11/12 08:38, Will Deacon wrote:
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index cd95664..f58248f 100644
--- a/arch/arm/mm/cache-v7.S
On Tue, Dec 11, 2012 at 04:07:56PM +, Guennadi Liakhovetski wrote:
Hi all
On Thu, 20 Sep 2012, Dave Martin wrote:
On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote:
On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote:
On Tue, Sep 18, 2012 at 05:35:33PM
On Tue, Dec 11, 2012 at 04:33:13PM +, Will Deacon wrote:
On Tue, Dec 11, 2012 at 04:07:56PM +, Guennadi Liakhovetski wrote:
Git bisect identified this patch, in the mainline as
commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560
Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com
On Tue, Dec 11, 2012 at 05:07:35PM +, Guennadi Liakhovetski wrote:
Hi Will
On Tue, 11 Dec 2012, Will Deacon wrote:
On Tue, Dec 11, 2012 at 04:33:13PM +, Will Deacon wrote:
On Tue, Dec 11, 2012 at 04:07:56PM +, Guennadi Liakhovetski wrote:
Git bisect identified this patch
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
Signed-off-by: Rob Clark r...@ti.com
---
On Mon, Nov 12, 2012 at 01:46:57PM +, Rob Clark wrote:
On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
@@ -122,22 +124,35 @@ extern int __get_user_4(void
On Thu, Oct 25, 2012 at 09:23:18PM +0100, Jon Hunter wrote:
Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
use runtime PM which was prototyped and validated on the OMAP devices. In this
commit, there is no call pm_runtime_enable() and for OMAP devices
On Thu, Oct 25, 2012 at 05:42:21PM +0100, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
On 10/24/2012 12:23 PM, Will Deacon wrote:
What do other drivers do? Grepping around, I see calls to pm_runtime_enable
made in various drivers and, given that you pass the device
On Wed, Oct 24, 2012 at 03:16:43PM +0100, Jon Hunter wrote:
Hi Will,
On 10/24/2012 04:31 AM, Will Deacon wrote:
Can we not just use the presence of the resume/suspend function pointers to
indicate whether we should enable runtime pm or not? i.e. if they're not
NULL, then enable the thing
On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote:
On 10/24/2012 09:32 AM, Will Deacon wrote:
Hmmm, now I start to wonder whether your original idea of having separate
callbacks for enable/disable irq and resume/suspend doesn't make more sense.
Then the CTI magic can go in the irq
On Tue, Oct 16, 2012 at 06:09:00PM +0100, Aaro Koskinen wrote:
On Tue, Oct 16, 2012 at 05:32:26PM +0100, Will Deacon wrote:
Interesting, it sounds like kexec thinks that you don't have contiguous
memory from 0x80008000 to 0x803ad000. Can you provide some more information
about your physical
Hi Mark,
On Wed, Oct 03, 2012 at 01:52:18AM +0100, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Commit 923df96b9f31b7d08d8438ff9677326d9537accf
(ARM: 7451/1: arch timer: implement read_current_timer and get_cycles)
modifies get_cycles() such that it calls
On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote:
On 09/20/2012 04:09 PM, Will Deacon wrote:
On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material
On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
Hi Jon, Will, Ming, et al.,
Hi Paul,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch (which looks to me
On Wed, Aug 01, 2012 at 12:07:16AM +0100, Jon Hunter wrote:
I have just updated my pmu branch for omap3/4. You can pull my latest
patches from [1].
Great, thanks for that. I've pushed out to perf/omap4 and I've also
included your runtime PM hooks in my perf/updates branch. I have a fair
amount
On Thu, Jul 26, 2012 at 04:16:15PM +0100, Jon Hunter wrote:
On 07/26/2012 10:05 AM, Will Deacon wrote:
Ok, thanks for updating me. I've pushed the patches out onto my
perf/omap4-dev branch as that seems to be a good place to collate the
current state of things. I've not tried doing anything
On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
We support booting a kernel on systems with or without SMP support, even
On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
Hi Javier,
On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
It seems
Hi Russell,
On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
I did comment on this one:
http://thread.gmane.org/gmane.linux.kernel/1303115
and I really think we should fix the cause of the problem
On Thu, Jul 26, 2012 at 01:41:23AM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
On 07/05/2012 07:40 PM, Jon Hunter wrote:
I just wanted to let you know that I have been updating the PMU patches
for OMAP. Latest can be found here [1]. I have not included Paul's patch
[2] in this series at the
Jon,
[cutting out realms of context!]
On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
Another proposal I also thought of is re-working the flags to describe
the HW mode to be used when turning on the CLKDM, when the CLKDM is
active and when the CLKDM is shut down. So instead of
On Mon, Jul 02, 2012 at 05:50:38PM +0100, Jon Hunter wrote:
On 07/02/2012 04:55 AM, Will Deacon wrote:
Did you have any luck getting to the bottom of this?
I am still waiting for feedback from design. They were trying to confirm
my observations. Unfortunately, it is taking some time. I
Hi Jon,
Did you have any luck getting to the bottom of this?
It would be good to take your PMU suspend/resume patches once we know that
they will get used.
On Tue, Jun 12, 2012 at 11:41:27PM +0100, Jon Hunter wrote:
On 06/12/2012 04:31 PM, Will Deacon wrote:
That's understandable -- one
On Mon, Jun 11, 2012 at 08:01:23PM +0100, Jon Hunter wrote:
Hi Will,
Hello,
On 06/11/2012 12:39 PM, Will Deacon wrote:
This looks better to me, so I took it for a spin on my 4460 (thanks
Nicolas!)
and noticed that only the cycle counter seems to tick -- the event counters
always
On Tue, Jun 12, 2012 at 10:17:16PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
On 06/12/2012 04:28 AM, Will Deacon wrote:
Well, I tried that and the results are pretty whacky: the event counters do
indeed tick but interrupts only fire if I pin the perf task to CPU1! What's
more
On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
Here is an updated version. I was going to send out a V3, but I wanted
to wait to see if others had more comments first.
This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!)
and noticed that
Hi Jon,
On Thu, Jun 07, 2012 at 10:22:03PM +0100, Jon Hunter wrote:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..00adb98 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include
On Tue, Jun 05, 2012 at 02:19:02PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
On 06/04/2012 04:44 PM, Jon Hunter wrote:
Anyway, let me know what you think of this approach. An alternative is
to put the calls pm_runtime_get/put outside of the reserve/release_pmu,
which would be a simpler
Hi Jon, Kevin,
I've been between timezones, so sorry for the slow response.
On Fri, Jun 01, 2012 at 03:42:56PM +0100, Jon Hunter wrote:
On 05/31/2012 07:27 PM, Kevin Hilman wrote:
Hmmm ... however, now looking at the history behind the plat-irq_*
hooks, I see that Ming specifically added
Hi Kevin,
On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote:
Basically, I don't like the result when we have to hack around missing
runtime PM support for a driver, so IMO, the driver should be updated.
IOW, it looks to me like the armpmu driver should grow runtime PM
support.
On Sat, May 12, 2012 at 12:51:00AM +0100, Jon Hunter wrote:
On 05/11/2012 11:38 AM, Will Deacon wrote:
Excellent, that works for me. Once we've worked out the problem with my
.config you can have my tested-by.
Great! I have been looking at your .config, but I have not been able to
figure
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote:
Hi Will,
Hi Jon,
For my testing I have just been reading the PM_EMU_PWRSTST register which
shows the power state of the EMU power domain. It should read 3 when the
power domain is ON and 0 when it is off. I did something like the
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote:
On 05/11/2012 07:25 AM, Will Deacon wrote:
I figured I may as well take perf for a spin and see how I got on. The good
news is that the hwmod bits all seem to work as before and the correct IRQs
are requested:
root@florentine
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote:
Hi Will,
Hello,
On 05/11/2012 08:49 AM, Will Deacon wrote:
I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way.
I tried the same (make omap2plus_defconfig and enabled the above
option), and I do see
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote:
Can you send me your .config?
Sent off-list.
At the same time, maybe just try make omap2plus_defconfig and enable
the OMAP3 debug devices config. That's all I am doing.
Excellent, that works for me. Once we've worked out the problem
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get
Hi Paul,
On Wed, Apr 04, 2012 at 01:00:53AM +0100, Paul Walmsley wrote:
On Tue, 3 Apr 2012, Will Deacon wrote:
I'll take JTAG for a whirl to see where we are. If anything looks wrong in
my dmesg, please shout (there are plenty of things in there that look like
they've gone awry
On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
Hmm, doesn't seem to work but I do see the following in
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
---
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote:
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote:
It seems that they're both needed to get reliable PMU operation. Without the
CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote:
Hi Will,
Hi Kevin,
Will Deacon will.dea...@arm.com writes:
The problem is, trying to boot this on my pandaboard results in a hang (see
dmesg below). Even worse, the problem isn't easily bisectable since
rebuilding
a working
On Wed, Mar 07, 2012 at 02:49:46AM +, Ming Lei wrote:
Hi Will,
Hello,
On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote:
Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections
On Mon, Jan 30, 2012 at 05:15:53PM +, stephane eranian wrote:
Still need to investigate why the frequency mode does
not yield the correct number of samples even with low frequency.
$ taskset -c 1 perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
Aggregated stats:
On Mon, Jan 30, 2012 at 05:45:19PM +, stephane eranian wrote:
There you go, no attachment, not sure the omap list
supports this.
Cheers Stephane.
There is something quite interesting to observe.
While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number
Hi guys,
On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote:
On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote:
On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
eran...@googlemail.com wrote:
Started afresh from:
90a4c0f uml: fix compile for x86-64
Mans,
On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote:
Will Deacon will.dea...@arm.com writes:
Did this lead anywhere in the end? It seems as though Ming Lei has a working
setup but Stephane is unable to replicate it, despite applying the necessary
patches and trying
On Fri, Jan 27, 2012 at 01:47:01PM +, Måns Rullgård wrote:
Will Deacon will.dea...@arm.com writes:
Mans,
On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote:
Will Deacon will.dea...@arm.com writes:
Did this lead anywhere in the end? It seems as though Ming Lei has
On Fri, Jan 27, 2012 at 03:45:53PM +, stephane eranian wrote:
Hi,
Hi Stephane,
Ok, with the one-line patch [1], this works much better now.
No more wrap around a 4 billion cycles.
Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I
remember Santosh had objections to
On Fri, Jan 27, 2012 at 03:57:25PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon will.dea...@arm.com wrote:
Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections
On Fri, Jan 27, 2012 at 05:03:28PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon will.dea...@arm.com wrote:
That said, if you see any bugs in the code please do shout!
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts
PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ { IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ{ IRQ_PB1176_SCI }
This looks fine to me. It matches what I posted originally, which was the
intention.
Acked-by: Will Deacon will.dea...@arm.com
On Tue, Jan 24, 2012 at 09:45:31PM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 05:26:00PM +, Will Deacon wrote:
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
On Wed, Jan 25, 2012 at 10:22:02AM +, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 09:58:00AM +, Will Deacon wrote:
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
Hi Russell,
On Tue, Jan 24, 2012 at 09:50:09AM +, Russell King - ARM Linux wrote:
Right, although it's out there - but I'd like to get the AMBA changes
into it which are already conflicting the Samsung development. So I'm
going to hold off officially asking for people to include the
On Tue, Jan 24, 2012 at 11:27:45AM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 10:56:45AM +, Will Deacon wrote:
I took a look at your amba branch, but all I can see in there is:
6cfa627 ARM: 7079/1: spi: Fix builderror in spi-pl022.c
1c3be36 PM: add runtime PM
++--
3 files changed, 14 insertions(+), 31 deletions(-)
Looks good to me, and I've boot-tested it on my board as well.
Acked-by: Will Deacon will.dea...@arm.com
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
though; I suspect it's
related to the recent VIC changes and removal of MULTI_IRQ_HANDLER
(especially since the ethernet interrupts lives on the secondary
controller).
So for this patch:
Tested-by: Will Deacon will.dea...@arm.com
I'll investigate the other problem separately.
Will
--
To unsubscribe
Hi Russell,
On Fri, Jan 20, 2012 at 09:29:30AM +, Russell King - ARM Linux wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-realview/core.h| 20 ---
arch/arm/mach-realview/realview_eb.c | 38
+++---
files changed, 22 insertions(+), 97 deletions(-)
Seems happy enough on my Integrator-CP w/ 1136 core tile.
Tested-by: Will Deacon will.dea...@arm.com
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Tue, Jan 24, 2012 at 04:23:28PM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 04:00:44PM +, Will Deacon wrote:
but then I see a warning during boot:
[1.669654] [ cut here ]
[1.684021] WARNING: at drivers/amba/bus.c:514
above look sane).
OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June
2010. This support is available in OProfile 0.9.7. According to Will's
posting, the kernel support was due to be added to Ubuntu Maverick, so I
would
expect your version should support CA9 out
On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
Hi Will,
Hi Peter [adding linux-arm-kernel],
Thanks for the fixes to kexec for ARM that went into mainline this
week. Mostly things work now.
Great, that's good to hear!
One issue: the USB EHCI port on the (rev C2)
On Mon, Jan 09, 2012 at 10:54:03PM +, Will Deacon wrote:
On Mon, Jan 09, 2012 at 10:09:54PM +, Peter Chubb wrote:
Hi Will,
Hi Peter [adding linux-arm-kernel],
*Actually* adding linux-arm-kernel this time...
Thanks for the fixes to kexec for ARM that went into mainline
Hi Stephen,
I maintain the ARM perf backend and would be very grateful if you could
please include this branch in linux-next:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
This request has arisen specifically from some work with the OMAP guys
where it would be
On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote:
The OMAP-specific parts should be queued up in my/Benoît's/Tony's trees,
rather than placed directly into -next. Otherwise they are likely to
generate merge conflicts with other OMAP changes that we may generate.
So I'd
On Mon, Nov 21, 2011 at 02:53:54PM +, Ming Lei wrote:
On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote:
On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote:
The OMAP-specific parts should be queued up in my/Benoît's/Tony's trees,
rather than placed
Hi Benoit,
On Fri, Nov 18, 2011 at 12:58:20PM +, Cousson, Benoit wrote:
Hi Ming Lei,
Sorry, for the delay, it took me some time to gather the exhaustive data for
that block.
Thanks for looking at this! I don't think we'd have managed to get all of
the magic numbers in the right place
[Adding Benoit to CC].
On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote:
On Wed, 9 Nov 2011, Ming Lei wrote:
Also, current arm perf code don't handle three IRQs(one pl310 irq and
two CTI irq) inside one device correctly.
To fix this, that ARM perf code should either be using
On Fri, Nov 11, 2011 at 11:47:35AM +, Jamie Iles wrote:
On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote:
The issue stems from the fact that we have to route the PMU interrupts to
the correct CPU manually (I think only MSM routes them as PPIs, which is
clearly the correct
Hi Benoit,
On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote:
It will come soon... along with the updated patch for reg-names support.
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
Will
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Nov 11, 2011 at 03:12:49PM +, Cousson, Benoit wrote:
Hi Will,
Hello,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
And I'll do :-)
Cheers!
We already started looking at that with Paul a couple of days ago
1 - 100 of 112 matches
Mail list logo
