Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
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...@arm.com wrote: 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' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. I've also tested on the default ARM toolchains available with ubuntu[1] Are there any updates on this issue? It's been fixed since the end of last week! (see ARM: kvm: round HYP section to page size instead of log2 upper bound) This was confirmed by both my testing and also Simon Horman, who reported the initial breakage. It ha broken most of the ARM defconfigs in linux-next[2], and since it's been broken for a week now, it is masking other types of issues that we can normally find via automated boot testing. If you're referring to failures such as: http://storage.kernelci.org/next/next-20150331/arm-axm55xx_defconfig/build.log Then that's not coming from the arm64 tree, and is a completely separate issue from the one originally reported in this thread. 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 at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
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 -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' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) Thanks for testing this and sorry for the continued breakage. Which toolchain did you say you were using? Ard has some more patches trying to fix this, but none of our toolchains seem to tickle the issue. 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 at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
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' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. 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 at http://vger.kernel.org/majordomo-info.html
Re: perf not capturing stack traces
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 space, and for userspace where the programs have been built for ARM mode with frame pointers. The kernel may work without CONFIG_FRAME_POINTER set, but I've never tested that, and I'd suggest that (given my experience looking at oops dumps) it's not all that reliable. Lastly, userspace without frame pointers is pretty much hopeless. FWIW, perf can now use libunwind for unwinding the userspace side of things, so it's not quite as bad as it used to be. For the kernel side, if the unwinder isn't working properly it would be nice to know *why*, but I agree that it tends to be far flakier than the frame-pointer method. 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 at http://vger.kernel.org/majordomo-info.html
Re: perf not capturing stack traces
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 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 space, and for userspace where the programs have been built for ARM mode with frame pointers. The kernel may work without CONFIG_FRAME_POINTER set, but I've never tested that, and I'd suggest that (given my experience looking at oops dumps) it's not all that reliable. Lastly, userspace without frame pointers is pretty much hopeless. FWIW, perf can now use libunwind for unwinding the userspace side of things, so it's not quite as bad as it used to be. For the kernel side, if the unwinder isn't working properly it would be nice to know *why*, but I agree that it tends to be far flakier than the frame-pointer method. Any idea why, with userspace using frame pointers, perf doesn't go all the way from kernel to userspace main() (or whatever is the endpoint), as Russel stated? Did he state that? I thought he was just saying that he couldn't unwind userspace when *not* using frame pointers, which requires you to link a recent perf with a bleeding-edge libunwind. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores 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 changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/18] ARM: OMAP: Enable PCI for DRA7
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 Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index cb31d43..b179e80 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -75,6 +75,8 @@ config SOC_DRA7XX select ARM_GIC select HAVE_ARM_ARCH_TIMER select IRQ_CROSSBAR + select MIGHT_HAVE_PCI I believe we moved or intend to move this under MULTI_PLATFORM, so you don't need this. Will D. had a patch, but I don't think I saw a final version to merge. I posted it earlier this week for somebody in arm-soc to pick up (although I don't think they have done yet): http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/260238.html 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
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 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. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. Yep which surely we don't want considering after so much effort we have it working first place. How about going ahead with assumption that PERIPH_BASE = 0 case doesn't work. It's been over a month and I can't think of anything better than this without jeopardising the single zImage effort. However, it also doesn't seem fair if we rule out the possibility of single zImage for future SoCs which use 0x0 as their PERIPH_BASE (I don't know of any at the moment). So how about we go ahead with this, but add a big fat comment to the code in head.S saying that, if a future SoC *does* use 0x0 as the PERIPH_BASE, then the check will need to be #ifdef'd or equivalent for the Aegis platform? 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 at http://vger.kernel.org/majordomo-info.html
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based)
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 -- `dsb nsh' make[1]: *** [arch/arm/kernel/suspend.o] Error 1 make[1]: *** Waiting for unfinished jobs pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5 Minimum required gcc is 3.2, so I'm safe. Please check your binutils. = 2.22 has been reported to work. Will1 -- 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
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. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
On Thu, Aug 01, 2013 at 07:17:13PM +0100, Santosh Shilimkar wrote: From: Vaibhav Bedia vaibhav.be...@ti.com The generic code is well equipped to differentiate between SMP and UP configurations.However, there are some devices which use Cortex-A9 MP core IP with 1 CPU as configuration. To let these SOCs to co-exist in a CONFIG_SMP=y build by leveraging the SMP_ON_UP support, we need to additionally check the number the cores in Cortex-A9 MPCore configuration. Without such a check in place, the startup code tries to execute ALT_SMP() set of instructions which lead to CPU faults. 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-by: Sricharan R r.sricha...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/head.S | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 9cf6063..4924b11 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -486,7 +486,23 @@ __fixup_smp: mrc p15, 0, r0, c0, c0, 5 @ read MPIDR and r0, r0, #0xc000 @ multiprocessing extensions and teq r0, #0x8000 @ not part of a uniprocessor system? - moveq pc, lr @ yes, assume SMP + bne__fixup_smp_on_up@ no, assume UP + + @ 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, #0xc000 + orr r4, r4, #0x0090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + mrc p15, 4, r0, c15, c0 @ get SCU base address + teq r0, #0x0@ '0' on actual UP A9 hardware + beq __fixup_smp_on_up @ So its an A9 UP What if somebody builds an MP A9 with the private peripheral base address at 0x0? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
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, #0xc000 + orr r4, r4, #0x0090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + mrc p15, 4, r0, c15, c0 @ get SCU base address Correct me if I am interpreting this wrong, but CRn=15 here which is IMPLEMENTATION DEFINED registers. If not, then I wonder why few platform have to read SCU base from DT or some header, why not this way ? I don't know if there is Cortex-A9 based SOC which don't implement SCU CP15 base address register, so can't comment really why not always use CP15 based method. I am not even sure if there are other reasons behind DT usage. I may be wrong, but it's just my understanding as I see that ARM ARM clearly states CRn=15 space is IMPLEMENTATION DEFINED registers and we can't expect it to work on all IMPLEMENTATIONS. I just had a glance at all the usage of CR15 space of CP15 register, its either platform specific or under specific errata/condition. Will/Dave/Russell can confirm if it's safe to access these registers on any implementation or you may need to make it conditional. 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. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15 reads above is_smp() test
On Tue, Jul 30, 2013 at 12:32:06PM +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 abort from the CP15 read in cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the extended CP15 read above the is_smp() test. This breaks ARM1136 r0 cores, since they don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the details. So mark the extended CP15 read as clobbering memory, which prevents the compiler from reordering it before the is_smp() test. Russell states that the code generated from this approach is preferable to marking the inline asm as volatile. Remove the existing condition code clobber 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: Nicolas Pitre nicolas.pi...@linaro.org Cc: Tony Lindgren t...@atomide.com --- 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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test
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 abort from the CP15 read in
cache_ops_need_broadcast(). It turns out that gcc reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the
details.
Cheers for tracking this down. Interestingly, I can't reproduce this with
anything other than GCC 4.5.* tools -- 4.6+ do what we want. Still, it looks
like a valid (if not misguided) thing to do.
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..f428eb0 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,25 @@ extern unsigned int processor_id;
__val; \
})
+
+# if defined(CONFIG_CPU_V6)
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before an is_smp() test, causing
+ * undefined instruction aborts on ARM1136 r0.
+ */
+# define CPUID_EXT_REORDER cc, memory
+# else
+# define CPUID_EXT_REORDER cc
+# endif
+
#define read_cpuid_ext(ext_reg)
\
({ \
unsigned int __val; \
asm(mrcp15, 0, %0, c0, ext_reg \
: =r (__val) \
: \
- : cc);\
+ : CPUID_EXT_REORDER); \
__val; \
})
I wouldn't worry about checking for CPU_V6. Besides, we probably need this
to be re-evaluated across barrier() when we get CPU migration on a
big-little platform anyway (we should probably also drop the
__attribute_const__ for that).
So you can just replace the cc (now that Nico kindly explained why those
aren't needed the other day) with memory.
An alternative is to add barrier() between is_smp() and the read_cpuid_ext()
in all callers, adding a fake read from the stack to the latter (like I did
for the per-cpu accessor). However, this relies on fixing all callers for
very little gain, so I don't think it's worth the hassle.
I can cook a patch if you're tied up with other things -- just let me know.
Cheers,
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 at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
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 will.dea...@arm.com Oh, great... Date: Wed Jun 12 12:25:56 2013 +0100 ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting When scheduling an mm on a CPU where it hasn't previously been used, we flush the icache on that CPU so that any code loaded previously on a different core can be safely executed. For cores with hardware broadcasting of cache maintenance operations, this is clearly unnecessary, since the inner-shareable invalidation in __sync_icache_dcache will affect all CPUs. This patch conditionalises the icache flush in switch_mm based on cache_ops_need_broadcast(). Acked-by: Catalin Marinas catalin.mari...@arm.com Reported-by: Albin Tonnerre albin.tonne...@arm.com Signed-off-by: Will Deacon will.dea...@arm.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk ... v3.11-rc2 boots with it reverted. What also works is v3.11-rc2 with the below patch applied. That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've had issues with the bootloader on this machine in the past, since it enters the kernel in ABT mode or something). Would be pleased to boot-test anything you'd care to send my way, as long as you can tolerate response latency jitter. Can you try this quick hack please? It clobbers the I-cache as soon as we enter the kernel, so it should tell us whether my theory is correct. Cheers, Will ---8 diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 9cf6063..d74c64c 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,6 +83,9 @@ ENTRY(stext) THUMB(.thumb ) @ switch to Thumb now. THUMB(1: ) + mov r9, #0 + mcr p15, 0, r9, c7, c5, 0 + #ifdef CONFIG_ARM_VIRT_EXT bl __hyp_stub_install #endif -- 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 at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
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: Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. I understand completely... Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed. I don't have a 4430SDP, so you might consider touching base with rmk for that one. So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB) Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board. 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 at http://vger.kernel.org/majordomo-info.html
Re: Kexec couldn't reboot capture kernel on pandaboard ES with OMAP4460
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 capture kernel by kexec -l and execute kexec -e, the serial port output Starting new kernel and Bye, then the system hangs up. I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this issue. This is a shot in the dark. I assume you have SMP enabled. Can you use hotplug to remove all CPUs other than CPU0, so that the kexec happens on the boot CPU? That is certainly necessary for kexec to work correctly on Tegra. Thanks for your attention. I do disable SMP feature. And the .config file for v3.8 could be found here: http://pastehtml.com/view/cylyrfejt.txt ... The output: [ 57.373687] Starting new kernel [ 57.377044] Bye! Then system hangs. Oh well, you've exhausted my knowledge I'm afraid! I can only suggesting trying to enable earlyprintk and/or uncompressor debug in the kernel you're kexec'ing and see if that yields any clue. Either that, or JTAG! Also worth using the bleeding edge kexec-tools (i.e. build from source), especially if you want to anything device-tree related. Back to the SMP point: Stephen, did you ever get anywhere with that disable_nonboot_cpus thread from a few months back? I'm still keen to get that working, and I *thought* we had a potential solution... 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
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, so should be queued for mainline fairly soon. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
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 in the architecture to stop it from happening in future. I will check on this part and update you when I hear from them. Ok, thanks. Dietmar -- I seem to remember that you thought GDB did actually work with hardware breakpoints on Pandaboard across low-power states. Can you confirm/deny this please? Well, we could just add the warn_once prints but that doesn't stop debug from breaking after the first pm/suspend/hotplug operation. Probably we should drop the $subject patch approach and use warn_once at least for current rc. Ofcourse it doesn't help to get working hw_breakpoint support. Patch end of the email with warn_once. Yeah, I'll merge that, but it's a real shame that this breaks hardware debug on one of the few platforms where it was reported to work. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
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 (can you please confirm this by looking in your dmesg during
boot?). In that case, it seems as though a PM cycle is powering down a
bunch of debug logic that was powered up during boot, and then we trip over
because we can't access the register bank.
Actually it seems to be without PM. Thanks to analysis from Lokesh, the issue
can be seen even with just suspend or cpu hotplug. So cold boot as such is
fine.
Right, so what you're saying is that monitor-mode hardware debug only works
until the first pm/suspend/hotplug operation, then it's dead in the water?
The proper solution to this problem requires us to establish exactly what is
turning off the debug registers, and then having an OMAP PM notifier to
enable it again. Assuming this has always been the case, I expect hardware
debug across PM fails silently with older kernels.
This has been always the case it seems with CPU power cycle.
After the CPU is power cycled, 'DBGAUTHSTATUS' reads '0xaa' rather
than '0xaf' which means 'DBGEN = 0' and hence code fails to enable
monitor mode. This happens on both secure and GP devices and it can not
be patched since the secure code is ROM'ed. We didn't notice so far
because hw_breakpoint support was not default enabled on OMAP till the
multi-platform build.
That really sucks :( Does this affect all OMAP-based boards?
I was also wondering whether we should just warn once rather
than continuous warnings in the notifier. Patch is end of the
email.
Could do, but I'd like to see a fix for the real issue before we simply hide
the warnings :)
Agree here too. As evident above, the feature won't work on OMAP4
devices with PM and hence some solution is needed.
What you think of below ?
Comments inline...
From d74b4264f6a5967b0f7ada96aad77ab0ac30dbed Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 18 Mar 2013 11:59:04 +0530
Subject: [PATCH] ARM: hw_breakpoints: Check for CPU debug availability before
enabling it
CPU debug features like hardware break, watchpoints can be used only when
the debug mode is enabled and available for non-secure mode.
Hence check 'DBGAUTHSTATUS.DBGEN' before proceeding to enable the
features.
Thanks to Will for pointers and Lokesh for the analysis of the issue on
OMAP4 where after a CPU power cycle, debug mode gets disabled.
Cc: Will Deacon will.dea...@arm.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/hw_breakpoint.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..683a7cf 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -930,6 +930,14 @@ static void reset_ctrl_regs(void *unused)
int i, raw_num_brps, err = 0, cpu = smp_processor_id();
u32 val;
+ /* Check if we have access to CPU debug features */
+ ARM_DBG_READ(c7, c14, 6, val);
+ if ((val 0x1) == 0) {
+ pr_warn_once(CPU %d debug is unavailable\n, cpu);
+ cpumask_or(debug_err_mask, debug_err_mask, cpumask_of(cpu));
+ return;
+ }
There are a few of problems here:
1. That is only checking for non-secure access, which precludes
running Linux in secure mode.
2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
set for v7.1 processors.
3. DBGAUTHSTATUS doesn't exist in ARMv6.
4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
Assuming that your pr_warn_once is emitted, this implies that
DBGEN is driven high from cold boot, yet the NSE bit is low,
implying that DBGEN is also low. That's contradictory, so I have
no idea what's going on...
Apart from that, it's fine!
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
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?
+ /* Check if we have access to CPU debug features */
+ ARM_DBG_READ(c7, c14, 6, val);
+ if ((val 0x1) == 0) {
+ pr_warn_once(CPU %d debug is unavailable\n, cpu);
+ cpumask_or(debug_err_mask, debug_err_mask, cpumask_of(cpu));
+ return;
+ }
There are a few of problems here:
1. That is only checking for non-secure access, which precludes
running Linux in secure mode.
We can check bit 4 as well to take care linux running in secure mode.
It still doesn't help unless we know whether Linux is running secure or
non-secure.
2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
set for v7.1 processors.
3. DBGAUTHSTATUS doesn't exist in ARMv6.
We cans skip the code for these versions like...
if (!ARM_DEBUG_ARCH_V7_ECP14 == get_debug_arch())
goto skip_dbgsts_read;
Sure, I was just pointing out that the code needs fixing for this.
4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
Which bit is that ? I don't find this bit in Cortex-A9 docs. With all
these checks, may be a separate function like 'is_debug_available()'
would be better.
NSE is bit 0 (the one you're checking).
5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
Assuming that your pr_warn_once is emitted, this implies that
DBGEN is driven high from cold boot, yet the NSE bit is low,
implying that DBGEN is also low. That's contradictory, so I have
no idea what's going on...
Me neither. The warning is emitted at least.
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 in the architecture to stop it from happening in future.
Apart from that, it's fine!
If you agree, I can update patch accordingly.
BTW, do you have any better trick to take care of
above scenraio ?
Well, we could just add the warn_once prints but that doesn't stop debug
from breaking after the first pm/suspend/hotplug operation.
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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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 that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Well, the fix is yours, so, it should be From: you. I can certainly send it just copying your description above, but I'd also need your Sob. Something like the below (feel free to improve the subject line and the description): No, I didn't send any code for this so you should be the author. I can review/possibly ack it if you like (please send a v2 addressing Santosh's comments). 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/5] ARM: CORESIGHT: Add generic lock/unlock helpers
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 multiple definitions, just use the definitions from
coresight.h.
Add the following coresight macros ...
- coresight_unlock() -- Unlocks coresight module
- coresight_lock() -- Locks coresight module
Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h| 16 +++-
arch/arm/include/asm/hardware/coresight.h | 16
2 files changed, 11 insertions(+), 21 deletions(-)
[...]
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
#define ETBFF_TRIGEVTBIT(9)
#define ETBFF_TRIGFL BIT(10)
-#define etb_writel(t, v, x) \
- (__raw_writel((v), (t)-etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)-etb_regs + (x)))
#define etb_readl(t, x) (__raw_readl((t)-etb_regs + (x)))
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
- do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)-etb_regs)
+#define etb_unlock(t) coresight_unlock((t)-etb_regs)
+#define etm_lock(t) coresight_lock((t)-etm_regs)
+#define etm_unlock(t) coresight_unlock((t)-etm_regs)
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
- do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+ (__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
#endif /* __ASM_HARDWARE_CORESIGHT_H */
How about we take this opportunity to divorce the more general coresight
bits from the etb specific parts, like you've done for the cti. We could
move the ETB stuff out into asm/etb.h (although it might be nice to keep all
the coresight device headers in one place... answers on a postcard) and just
have the architected coresight functionality in this header.
Will
--
1.7.10.4
--
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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
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 add APIs to request, cti_get() and release,
cti_put(), a CTI module so that drivers can allocate a module at
runtime.
Currently, the driver only supports looking-up the CTI hardware
information via device-tree, however, the driver could be extended to
support non-device-tree configurations if needed for a particular
architecture.
The CTI driver only currently supports CTI modules that have a single
CPU interrupt, however, could be extended in the future to support more
interrupts if a device requires this.
Aha, so elaborating on my earlier comments, we basically want to do the same
thing for ETB I reckon. This does raise the question about namespaces
though...
+/**
+ * struct cti - Cross Trigger Interface (CTI) struct
+ *
+ * @node: Connects CTI instance to list of CTI instances
+ * @dev: Pointer to device structure
+ * @base: Mapped virtual address of the CTI module
+ * @name: Name associated with CTI instance
+ * @irq: Interrupt associated with CTI instance
+ * @trig_out: Trigger output associated with interrupt (@irq)
+ * @reserved: Used to indicate if CTI instance has been allocated
+ * @enabled: Used to indicate if CTI instance has been enabled
+ */
+struct cti {
+ struct list_head node;
+ struct device *dev;
+ void __iomem *base;
+ const char *name;
+ int irq;
+ int trig_out;
+ bool reserved;
+ bool enabled;
+};
+
+#ifdef CONFIG_ARM_AMBA_CTI
+
+int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
+int cti_enable(struct cti *cti);
+int cti_disable(struct cti *cti);
+int cti_irq_ack(struct cti *cti);
+struct cti *cti_get(const char *name);
+void cti_put(struct cti *cti);
I wonder whether we should stick these all into a struct and have a general
way to see which coresight devices we have and then retrieve their ops
structures (so things like perf can walk a virtual coresight bus containing
initialised devices). It might also help if we decide to describe the
plumbing in the device tree, like Rob suggested.
What do you reckon?
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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding
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 GIC interrupt module. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Documentation/devicetree/bindings/arm/cti.txt | 32 + 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cti.txt diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt new file mode 100644 index 000..4a0e2d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cti.txt @@ -0,0 +1,32 @@ +* ARM Cross Trigger Interface (CTI) + +The ARM Cross Trigger Interface provides a way to route events between +processor modules. For example, debug events from one processor can be +broadcasted to other processors. The events that can be routed between +processors are specific to the device. + +Required properties: + +- compatible:Should be arm,primecell. +- interrupts:Interrupt associated with CTI module. +- reg: Contains timer register address range (base + address and length). +- arm,cti-name: A unique name for the CTI module, that will be + used when requesting the CTI module instance. + + +Optional properties: + +- arm-primecell-periphid:Primecell peripheral ID associated with CTI + module. For multi-cluster systems, I wouldn't be surprised to see multiple CTI instances, each with different CPU affinities. Can we include an affinity property following Mark's proposed binding? http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? Ha, nice catch. So the original patch ended up with a ridiculously high level number and would've flushed L2, hence we will need to retest with the fix below... Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..7539ec2 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,10 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr + ALT_SMP(mov r3, r3, lsr #20)@ r3 = LoUIS * 2 + ALT_UP(mov r3, r3, lsr #26)@ r3 = LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels -- 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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 +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. At some point we probably want to describe the level of flushing required in the device tree as a property of the CPU node (or something similar). That would allow us to have *one* function for flushing, e.g. cpu_suspend_flush_cache which flushes to the appropriate level. Then we could remove the louis flush from the CPU suspend code and instead make it the finisher's responsibility to call our flushing function when it's done, which helps to avoid over/under-flushing the cache. In the meantime, fixing louis as we've suggested should work. 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. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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 +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. Git bisect identified this patch, in the mainline as commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560 Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. My guess is that because Cortex-A8 does not implement the MP extensions, the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at all (I can see an early exit in v7_flush_dcache_louis). Lorenzo -- how is this supposed to work for uniprocessor CPUs? 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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 Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. My guess is that because Cortex-A8 does not implement the MP extensions, the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at all (I can see an early exit in v7_flush_dcache_louis). Lorenzo -- how is this supposed to work for uniprocessor CPUs? Bah, forgot to ask you if the following patch helps... Will ---8 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(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 -- 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 at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
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, in the mainline as commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560 Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. My guess is that because Cortex-A8 does not implement the MP extensions, the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at all (I can see an early exit in v7_flush_dcache_louis). Lorenzo -- how is this supposed to work for uniprocessor CPUs? Bah, forgot to ask you if the following patch helps... Yes, it does. Cracking, can I add you tested-by please? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: add get_user() support for 8 byte types
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
---
arch/arm/include/asm/uaccess.h | 25 -
arch/arm/lib/getuser.S | 17 -
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7e1f760..2e3fdb2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
extern int __get_user_1(void *);
extern int __get_user_2(void *);
extern int __get_user_4(void *);
+extern int __get_user_8(void *);
#define __GUP_CLOBBER_1 lr, cc
#ifdef CONFIG_CPU_USE_DOMAINS
@@ -108,6 +109,7 @@ extern int __get_user_4(void *);
#define __GUP_CLOBBER_2 lr, cc
#endif
#define __GUP_CLOBBER_4 lr, cc
+#define __GUP_CLOBBER_8 lr, cc
#define __get_user_x(__r2,__p,__e,__l,__s) \
__asm__ __volatile__ ( \
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({ \
unsigned long __limit = current_thread_info()-addr_limit - 1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
+ __get_user_x(__r2, __p, __e, __l, 8); \
+ x = (typeof(*(p))) __r2;\
break; \
+ } \
default: __e = __get_user_bad(); break; \
} \
- x = (typeof(*(p))) __r2;\
__e;\
})
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 4, r1, r2, __get_user_bad
Shouldn't you be passing 8 here, so that
Re: [PATCH] ARM: add get_user() support for 8 byte types
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 *);
({ \
unsigned long __limit = current_thread_info()-addr_limit -
1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
Is the question whether the compiler is guaranteed to allocate r2 and
r3 in all cases? I'm not quite sure, I confess to usually trying to
avoid inline asm. But from looking at the disassembly (for little
endian EABI build) it seemed to do the right thing.
I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...
The only other idea I had was to explicitly declare two 'unsigned
long's and then shift them into a 64bit x, although I'm open to
suggestions if there is a better way.
Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 4, r1, r2, __get_user_bad
Shouldn't you be passing 8 here, so that we validate the correct range?
yes, sorry, I'll fix that
+#ifdef CONFIG_THUMB2_KERNEL
+5: TUSER(ldr)r2, [r0]
+6: TUSER(ldr)r3, [r0, #4]
+#else
+5: TUSER(ldr)r2, [r0], #4
+6: TUSER(ldr)r3, [r0]
+#endif
This doesn't work for EABI big-endian systems.
Hmm, is that true? Wouldn't put_user() then have the same problem?
I dug up the PCS and it seems that we arrange the two halves of the
doubleword to match the ldm/stm memory representation for EABI, so sorry
for the confusion.
I guess __ARMEB__ is the flag for big
Re: [PATCH V2] ARM: PMU: fix runtime PM enable
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 pm_runtime_enable() is currently being called from the OMAP PMU code when the PMU device is created. However, there are two problems with this: 1. For any other ARM device wishing to use runtime PM for PMU they will need to call pm_runtime_enable() for runtime PM to work. 2. When booting with device-tree and using device-tree to create the PMU device, pm_runtime_enable() needs to be called from within the ARM PERF driver as we are no longer calling any device specific code to create the device. Hence, PMU does not work on OMAP devices that use the runtime PM callbacks when using device-tree to create the PMU device. Therefore, call pm_runtime_enable() directly from the ARM PMU driver when registering the device. For platforms that do not use runtime PM, pm_runtime_enable() does nothing and for platforms that do use runtime PM but may not require it specifically for PMU, this will just add a little overhead when initialising and uninitialising the PMU device. Tested with PERF on OMAP2420, OMAP3430 and OMAP4460. V2 changes: - Call pm_runtime_enable() unconditionally on registering the PMU device. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Cheers Jon! Looks a bit weird without the matching pm_runtime_disable, but we don't really have anywhere to put that since the PMU is not deregistered. Can we split this patch into two (even smaller!) patches so that I can take the perf part and the omap bit can go to Tony? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
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 in there, what's the problem with us just calling that unconditionally from perf? I know you said that will work for OMAP, but I'm trying to understand the effect that has on PM-aware platforms that don't require this for the PMU (since this seems to be per-device). I had done this initially when testing on OMAP platforms that do and don't require runtime PM for PMU. I don't see any side affect of this, however, may be Kevin could comment on if that is ok. It would be the best approach. Unconditonally enabling runtime PM should be fine. It may add a slight bit of overhead calling runtime PM functions that ultimately do nothing (because there are no callbacks), but it will be harmless. Personally, I think that would be cleaner. The less pdata we need, the better, IMO. Thanks Kevin, I'm fine with that. Jon: want me to write a patch or do you have something I can take into the ARM perf tree (if the latter, please base against perf/updates)? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
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? I wondered if you would ask that :-) Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU to work. However, neither of these devices are using the suspend/resume callbacks because the HWMOD framework is doing this for us behind the scenes. So then you ask, why do we need the resume/suspend callbacks, well we will need them for OMAP4430 where in addition to turning on the debug sub-system we need to configure the CTI module. Therefore, I had to add another plat data variable. 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 management code and be totally separate to the PM stuff. What do you reckon? By the way, I did add a comment in the above changelog about this. See the last paragraph, not sure if this is 100% clear. Sorry, I missed that this morning. One alternative I had thought about was always calling pm_runtime_enable() on registering the PMU device and avoid having a use_runtime_pm variable. For ARM platforms that don't use runtime PM the pm_runtime_enable() function does nothing. However, I was more concerned about adding unnecessary overhead for ARM platforms that are using runtime PM but don't need runtime PM for PMU. I don't see any side affects on our OMAP2 platform that does not need runtime PM for PMU. However, was not sure what is best here. Nah, we should be able to fix this in the platdata, I'd just rather have function pointers instead of state variables in there. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
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 management code and be totally separate to the PM stuff. What do you reckon? The resume/suspend calls really replaced the enable/disable irq callbacks. That still seems like a good approach given that we need runtime PM for OMAP and PMU. Ok, perhaps splitting it up isn't worth it then. I'm still not convinced either way. Nah, we should be able to fix this in the platdata, I'd just rather have function pointers instead of state variables in there. Well, we could pass a pointer to pm_runtime_enable() function in the platdata. 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 in there, what's the problem with us just calling that unconditionally from perf? I know you said that will work for OMAP, but I'm trying to understand the effect that has on PM-aware platforms that don't require this for the PMU (since this seems to be per-device). 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 at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
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 memory map please? Well, I think it's because the patch is wrong. Shouldn't it be: diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c index e29c333..a80192e 100644 --- a/arch/arm/kernel/machine_kexec.c +++ b/arch/arm/kernel/machine_kexec.c @@ -47,7 +47,7 @@ int machine_kexec_prepare(struct kimage *image) err = memblock_is_region_memory(current_segment-mem, current_segment-memsz); - if (err) + if (!err) return - EINVAL; err = get_user(header, (__be32*)current_segment-buf); Oops, that's a howler! Thanks for spotting it. We should probably reflow the code a bit because !err sounds like everything should be ok. Fancy reworking the patch or do you want me to take care of this? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: arch timer: Export 'read_current_timer' symbol
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 read_current_timer(). Unfortunately, the 'read_current_timer' symbol is not exported so when a driver that calls get_cycles() is built as a module, an undefined reference error occurs. A good example is the crypto/tcrypt.c (CONFIG_CRYPTO_TEST) driver because it calls get_cycles() and can only be built as a module. Fix this error by exporting the 'read_current_timer' symbol. This was already reported over on the kernel-janitors list, I assumed they'd CC'd LAK, but it looks like it didn't happen. http://marc.info/?l=kernel-janitorsm=134910841909057w=2 Anyway, I've got a fix in the works (I don't think you need the ifdef). 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
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) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Ok, thanks for queueing what you did. Jon -- could you pick the pieces up from what's left please and shout if you need anything from me? Yes will do. Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now that we have 3.6, I can try rebasing it but I don't know if it's worth the effort if some of the patches are being reworked. Of course, I'm happy to pick newer versions if they're available. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
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 like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Ok, thanks for queueing what you did. Jon -- could you pick the pieces up from what's left please and shout if you need anything from me? Apologies in advance if I broke something else in the process. There's not really anything to break yet :) Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 of cleanup sitting in there as well, so I'll post that to the list at -rc1 as a candidate for -next. I'll obviously leave the omap-specific bits for others to handle, although I'll continue maintaining my branch until that's hit mainline. In the latest series I have: 1. Pulled in an omap3 clock domain fix from Paul [2] 2. Rebased Paul's patch [3] on top of [2]. I have also made a couple updates to this patch and I need to get Paul's feedback. 3. I have removed the OMAP3 PMU dependency on ETM from the Kconfig. Fantastic! I actually already removed the OMAP3 Kconfig dependency in my perf/updates branch as part of removing CPU_HAS_PMU entirely, so you probably don't need to pursue that patch. I will probably send out the series once I align with Paul on the above changes and the HWMOD stuff I have added for OMAP3 with Benoit. Okey doke. If you need me to update my copy of your runtime PM patch, please shout (that seems to be a done deal afaict). 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 with it yet though. Ok, great. Let me know if you have any problems. I have ran some initial testing on omap3430, omap4430 and omap4460 and it seems ok (AFAICT). Just an FYI that I gave up maintaining the old perf/omap4 branch and instead moved everything from perf/omap4-dev onto that as the rebase was getting painful. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
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 with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer. So let's define it to point at a dummy function which explodes with a BUG if the cpumask passed in isn't empty. That allows SMP kernels to do things like `cross call to all other cores' without having to worry about whether there are any other cores or not. We should not be even attempting to do any cross calls when there aren't any other CPUs in the system - that's rather the point of leaving it as a NULL pointer so it does explode on such systems. . the scheduler won't call smp_send_reschedule() when there are no other CPUs in the system. . timer ticks won't be broadcast to other CPUs if there are no other CPUs in the system. . function calls will not be issued to other CPUs if there are no other CPUs in the system. There is only one case where this doesn't happen, and that's the shutdown path. Ok, that's a pretty compelling argument you've got there :) For instance, smp_call_function*() all check that the target CPUs are marked online before the arch code is requested to issue an IPI to the target CPU. Yes, thanks for making the case for the original patch. Consistency is the most important thing with these APIs, so I'll go full circle and offer my ack for the original patch: Acked-by: Will Deacon will.dea...@arm.com The next question is: who's putting this into the patch system? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
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 the same patch has been there for a while. http://thread.gmane.org/gmane.linux.kernel/1303115 Bah, why doesn't stuff like this get resent if nothing has happened for a while? Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-) I checked with Russell but this one is not in his patch tracking system [1] and so still not queued. Can you submit this? Would be great to get this one in. 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, rather than point patching this instance of it. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
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, rather than
point patching this instance of it.
What do you think needs fixing there?
Well, we certainly need to fix the NULL dereference and the original patch
does do that. I just think it might be nicer to remove the possibility of a
NULL dereference instead.
We support booting a kernel on systems with or without SMP support, even
with a SMP kernel. When the kernel is booted on such a system, it is
undefined whether smp_cross_call() is a valid function pointer.
So let's define it to point at a dummy function which explodes with a BUG if
the cpumask passed in isn't empty. That allows SMP kernels to do things like
`cross call to all other cores' without having to worry about whether there
are any other cores or not.
In any case, when we have only one CPU online in the system, it is
pointless even calling smp_cross_call().
Pointless, but also error-prone and requiring explicit cpumask checks at
each call-site.
That is why I explicitly suggested this solution. This is the solution
_I_ want, because it is the most sane solution all round.
Adding a dummy implementation is straightforward [ok, this is untested]:
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ffa411f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -329,7 +329,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void dummy_smp_cross_call(const struct cpumask *mask, unsigned int irq)
+{
+ BUG_ON(!cpumask_empty(mask));
+}
+
+static void (*smp_cross_call)(const struct cpumask *, unsigned int) =
+ dummy_smp_cross_call;
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned
int))
{
If you still prefer checking at the call-site then the original patch will
certainly work. Otherwise, I'm happy to submit the above after some testing.
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 moment, because although it works well for OMAP4, I need to create the HWMOD structures for OMAP3. Without these structures it breaks OMAP3 PMU support. Once this is done we should be able to get rid for the OMAP3 dependency on ETM. Unfortunately, Benoit (Mr HWMOD) is out on his holidays but should be back next week and then maybe he can give me some guidance on this HWMOD stuff. 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 with it yet though. Do you know when Benoit will be back online? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
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 saying what modes the CLKDM supports, specify what modes should be used for pre-ON (i.e. turn ON), ON and OFF. Right now software is trying to decide for us by what is available (which is ideal) but makes working around such nuances a little more painful. By the way, I did do some testing on OMAP3, but I don't recall now whether I was having such problems with OMAP3. I need to go back and test perf again on OMAP3 to see if such a flag is needed. If you do test on OMAP3, please kill the OMAP3_EMU option as I think this has the effect of keeping the EMU power domain up via the etm code (look at etb_probe). Will ---8--- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a91009c..d02054c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1139,8 +1139,7 @@ config XSCALE_PMU default y config CPU_HAS_PMU - depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU) \ - (!ARCH_OMAP3 || OMAP3_EMU) + depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU) default y bool -- 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 will ping them again. Ok, thanks. If pinging doesn't work, bribery can be quite effective with hardware guys :) It would be good to take your PMU suspend/resume patches once we know that they will get used. Yes that would be good. I could drop the 4460 specific changes for now and make 4460 work in the same way as 4430 (using CTI) for the time being and see if we can get these in. However, I recall that was not working for you, but it was working fine for me. Indeed, that hack didn't help me and I'd rather not commit it if it only partially fixes the problem. A better bet might just be to go with your original approach and see how many bug reports we receive. That might also help us narrow down the problem, but it's your call. In the meantime, I pushed what I think is the latest drop of your series to a new branch on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4-dev 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 of the CPUs is likely more loaded than the other. However, I'd like to confirm whether or not you see what I see. With the 4430_init hack on a 4460, if I run: # taskset 0x2 perf top then I get no samples. If I do: # taskset 0x1 perf top then I *do* get samples and from *both* CPUs. So it smells more like an issue poking some configuration registers from CPU1 rather than the IRQ path being broken. As I said before, if I don't do the extra init hack then I don't get this problem (but event counters don't tick). In both cases, I see interrupts on both CPUs. However, typically more on the CPU that perf is running on (which is probably to be expected). And I confirm that the only change I made was ... [...] When you boot the kernel what 4460 rev does it show (very early in the kernel boot log)? Mine shows ... [0.00] OMAP4460 ES1.1 Snap: [0.00] OMAP4460 ES1.1 However, the A9 version has not changed between ES1.0 and ES1.1. Both should be r2p10. Yup, that's what /proc/cpuinfo says. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 return 0 deltas (that is, they don't increment). Booting the same SD card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the event counters function correctly there. Thanks for the feedback. Being somewhat new to PMU, I was mainly using PERF to test and verify that with perf top I was seeing interrupts. How do I check what the event counters are returning? Any perf tests I could use? You can continue to use perf top, just specify an event other than cycles: # perf top -e instructions for example. You can also use perf stat, but that probably won't be triggering irqs. By the way, as a quick test you could modify the code in omap_init_pmu() to call omap4430_init_pmu() for all omap4 devices as follows ... if (cpu_is_omap44xx()) return omap4430_init_pmu(); I was hoping for 4460/70 we would not need to keep the debugss and other domains on and hence, I called the above function omap4430_init_pmu(). However this function works for all omap4 devices, it just turns on more power domains. 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, the interrupts do fire on both cores when they're working... Without the above change, I can generate cycle counter interrupts regardless of which CPU I run execute perf. It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these patches but I don't have any OMAP3 hardware to check if we get any regressions on older platforms. Do your patches only deal with OMAP4? It *should* work for all omap2+. So far I have tested an omap3 beagle but I have not tested an omap2 device. Again the extent of my testing was to run perf top and verify interrupts we being generated. I realise that this may not be sufficient and so if you have a more exhaustive test you recommend let me know. Well, try the above as well as what you're currently doing and that should test the basics. If that works, I'll happily drop the Kconfig dependency on OMAP3_EMU (which has been a regular source of confusion). Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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, the interrupts do fire on both cores when they're working... I tried this, and I see that interrupts occur on both, however, it seems that the majority occur on one CPU and only a few on the other. So it does appear that one CPU is getting a lot more interrupts. That's understandable -- one of the CPUs is likely more loaded than the other. However, I'd like to confirm whether or not you see what I see. With the 4430_init hack on a 4460, if I run: # taskset 0x2 perf top then I get no samples. If I do: # taskset 0x1 perf top then I *do* get samples and from *both* CPUs. So it smells more like an issue poking some configuration registers from CPU1 rather than the IRQ path being broken. As I said before, if I don't do the extra init hack then I don't get this problem (but event counters don't tick). From a PMU programming standpoint, if we just use perf top are the event counters not used/programmed? Just using perf top should use the cycle counter as the event source. And when we use perf top -e instructions is it the software increment event that the event counter(s) are monitoring? I am just trying to understand how the counters are being programmed and then I can ask the design folks an intelligent question :-) It depends on the CPU. For Cortex-A9, `instructions' maps to event 0x68, which isn't a perfect match. If you want to specify a hex value for the event code, you can do: # perf top -e rNN where NN is the hex event number. On A9, r11 would give you cycles via an event counter. By the way, I don't suppose there is any debugfs entry to dump the PMU registers? 'fraid not, but there is some debug code in perf_event_v7.c that you could call if you wanted to (just #define DEBUG at the top of the file). 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 only the cycle counter seems to tick -- the event counters always return 0 deltas (that is, they don't increment). Booting the same SD card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the event counters function correctly there. It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these patches but I don't have any OMAP3 hardware to check if we get any regressions on older platforms. Do your patches only deal with OMAP4? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
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 linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -367,8 +368,6 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
- struct arm_pmu_platdata *plat =
- dev_get_platdata(pmu_device-dev);
irqs = min(pmu_device-num_resources, num_possible_cpus());
@@ -376,14 +375,12 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
- if (irq = 0) {
- if (plat plat-disable_irq)
- plat-disable_irq(irq);
+ if (irq = 0)
free_irq(irq, armpmu);
- }
}
release_pmu(armpmu-type);
+ pm_runtime_put_sync(armpmu-plat_device-dev);
We probably want to suspend the device before releasing it, otherwise we
could race against somebody else trying to initialise the PMU again.
static int
@@ -403,6 +400,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return err;
}
+ pm_runtime_get_sync(armpmu-plat_device-dev);
Better pass pmu_device-dev instead (similarly in release).
+
plat = dev_get_platdata(pmu_device-dev);
if (plat plat-handle_irq)
handle_irq = armpmu_platform_irq;
@@ -440,8 +439,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
- } else if (plat plat-enable_irq)
- plat-enable_irq(irq);
+ }
cpumask_set_cpu(i, armpmu-active_irqs);
}
@@ -584,6 +582,28 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
There are potential failure paths in the reservation code here where we
don't `put' the PMU back. Can you move the pm_runtime_get_sync call later in
the function, or does it have to called before we enable the IRQ line?
+#ifdef CONFIG_PM_RUNTIME
+static int armpmu_runtime_resume(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_resume)
I think you need to check plat too since it may be NULL on other platforms.
+ return plat-runtime_resume(dev);
+
+ return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_suspend)
Same here.
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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 change, but I was thinking that the above maybe
more aligned with your thinking.
Ok, thanks for this. Whilst your code is definitely more like I'm
envisaging, you're right about the churn and until I've sorted out the
reservation code so that it's a callback via the PMU structure, it is
overly messy.
So for the time being let's do what you suggested and put the suspend/resume
calls into armpmu_{reserve,release}_hardware. We can still kill the irq
enable/disable calls and I can rework this slightly when I change the
reservation code.
Cheers,
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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 these for omap4 [1]. I was under the impression other architectures may be using this. I guess not. So if it is preferred we could do-away with the plat-irq_* and replace with the plat-runtime_*. Yes, that would certainly be my preference from a runtime PM readability PoV. I guess it's Will's call since it's his code. Ok great. Will, let me know your thoughts. I have a V2 series ready to post, I just need to know your thoughts on handling this runtime PM business. Or if you would just like me to send it out for review anyway, I can do that too. From my perspective, we have up to three pairs of functions on the PMU: 1. enable/disable irq 2. reserve/release pmu 3. suspend/resume pmu As you pointed out, (1) was added purely for OMAP so I'd definitely like to remove that if we can. What I wonder is whether (2) and (3) can also be combined into a single pair of functions. The default behaviour could be the simple bit lock that we have in pmu.c. If a platform wants to do more, then it can supply its own functions for these and do PM there as well as the mutual exclusion (which we may well get for free). This also fits with my previous plans for making reserve/release PMU-specific and killing the arm_pmu_type enumeration. So, if we can condense this all down into one pair of functions that also work correctly for the non-PM case (including mutual exclusion) then I'd love to see that merged. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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. The current armpmu_release|reserve should probably be replaced with runtime PM get/put, and the functionality in those functions would be the runtime PM callbacks instead. Will, any objections to armpmu growing runtime PM support? My plan for the armpmu reservation is to kill the global reservation scheme that we currently have and push those function pointers into the arm_pmu, so that fits with what you'd like. The only concern I have is that we need the mutual exclusion even when we don't have support for runtime PM. If we can solve that then I'm fine with the approach. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. Hmm, I'm honestly not sure -- it was just lying around in my home directory. Given that I know very little about OMAP, I would suspect that it's either based on the defconfig or I inherited a working kernel image from somebody else and used /proc/config.gz to build my own. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 following (dumping all EMU clock and power domain registers). 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-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu Well, at least it's working for somebody! What is your kernel commit ID that you applied the patches on top of? 7cf543bc (Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test). Is there something else I need too? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Ye olde Panda 4430. It does work with my perf/omap4 branch though using the same .config (I can mail it to you separately if you want). Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 with my .config you can have my tested-by. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 test. I know that Ming is out this week but said he can test next week. Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this. If I can get my hands on a Panda, I'll see if I can test something this week. Any particular tests you want me to run to exercise the interaction with PM? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] ARM: OMAP5: Add SMP support.
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
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/omap-headsmp.S | 21 ++
arch/arm/mach-omap2/omap-smp.c | 41 +--
3 files changed, 51 insertions(+), 12 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 151fd5b..9424bb6 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,10 @@
#include common.h
#include clockdomain.h
+#define CPU_MASK 0xff00
+#define CPU_CORTEX_A90x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
/* SCU base address */
static void __iomem *scu_base;
@@ -43,6 +47,14 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+static inline unsigned int get_a15_core_count(void)
+{
+ unsigned int ncores;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r (ncores));
+ return ((ncores 24) 3) + 1;
+}
This register (L2 control) only tells you how many cores you have hanging
off the L2 cache, which isn't really viable for future multi-cluster
configurations. You're probably better off either reading the number of CPU
nodes out of the DT (ppc, vexpress) or returning a constant for now
(exynos5).
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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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). Might be worth booting with initcall_debug on the kernel command line. That will probably be easier than dealing with JTAG. JTAG is unusable anyway because it requires a new MLO, which makes the problem disappear. Using initcall_debug I tracked the hang down to cti_unlock: val = __raw_readl(base + LOCKSTATUS); causes the board to die, presumably because CoreSight isn't in a fit state to be poked. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.
Any suggestions?
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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. 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 image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. 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). Will Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.3.0-5-gcd122ab (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 511MB = 511MB total [0.00] Memory: 506272k/506272k available, 18016k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05ebf68 (6032 kB) [0.00] .init : 0xc05ec000 - 0xc0639b40 ( 311 kB) [0.00] .data : 0xc063a000 - 0xc06c6d50 ( 564 kB) [0.00].bss : 0xc06c6d74 - 0xc0c1cb5c (5464 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [0.129791] pid_max: default: 32768 minimum: 301 [0.135192] Security Framework initialized [0.139678] Mount-cache hash table entries: 512 [0.147979] CPU: Testing write buffer coherency: ok [0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available [0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0 [0.175689] L310 cache controller enabled [0.179931] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47, Cache size: 1048576 B [0.190856] CPU1: Booted secondary processor [0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.254058] CPU1: Unknown IPI message
Re: oprofile and ARM A9 hardware counter
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 image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. 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). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Thanks for testing that. It turns out that updating my x-loader (it was pretty ancient) fixed the boot hang, though I'm not sure I want to know why! # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock#0.009 CPUs utilized 1 context-switches #0.104 K/sec 0 CPU-migrations#0.000 K/sec 147 page-faults #0.015 M/sec 5096283 cycles#0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend# 64.46% backend cycles idle 2722485 instructions #0.53 insns per cycle #1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches Right. Can you confirm whether the PMU/CTI interrupts fire for you please? Just run perf top and look at /proc/interrupts while it's running. You should see a couple of arm-pmu entries in there and hopefully numbers 0. For me, my earlier mis-diagnosis has turned out to be true and I can only see PMU interrupts if I apply the SWSUSP patch, which Santosh says will break pm. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 (and if you look at a profile, spin_unlock_irqrestore will be quite high). Also looks no any irq handler functions can be observed at a profile even though they may be run at a very high frequency. So could we configure ARM PMU interrupt as FIQ to address the above issues? I thought about that in the past but the problem is finding hardware which allows this. It probably means that you need a second GIC which can route interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed for secure interrupts, there could also still be latency issues here. A better (read: highly invasive) way to fix this is using interrupt priorities at the distributor. You then have to hack the interrupt disabling code so that it disables interrupts below a certain priority if they occur during an IRQ-off section. The re-enabling code would then have to undo those decisions and allow the interrupts to be serviced. Pretty nasty stuff. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 cycles stats: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 460 samples is way too low. Should be 100x10 = 1000 samples or close to it. Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my A9 boards? Thanks, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 of interrupts is way lower than expected. Therefore the number of samples is way too low: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events:535 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:520 The delta in /proc/interrupts on CPU1 is 520 interrupts. Yes, that is about half of what you'd expect. Running on my A9 platform (vexpress) I get: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1007 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:985 So looks like the frequency adjustment which is hooked off of the timer tick is either not called at each timer tick, the timer ticks are not at regular interval, or the math is wrong. My hunch is that that the interval is probably varying, but I don't know much about OMAP4 and its clocks. If I go with the fixed period mode: $ perf stat -e cycles noploop 10 noploop for 10 seconds Performance counter stats for 'noploop 10': 10079156960 cycles#0.000 GHz 10.004547117 seconds time elapsed That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157 $ perf record -e cycles -c 10079157 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1003 MMAP events: 11 COMM events: 2 EXIT events: 2 THROTTLE events: 1 UNTHROTTLE events: 1 SAMPLE events:986 Now, we're getting the right answer! Just to confirm, for me: $ perf stat -e cycles ./noploop 10 noploop for 10 seconds Performance counter stats for './noploop 10': 4001163930 cycles#0.000 GHz 10.006534024 seconds time elapsed $ perf record -e cycles -c 4001163 ./noploop 10 $ perf report -D | tail -20 Aggregated stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:998 cycles stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:998 which is close enough :) We need to elucidate what's going on in perf_event_task_tick(). I have tried with my throttling fix and it did not help. We are not subject to throttling with such a low rate. Ok. I would start by looking at the clock ticks if I were you, since this seems to be alright on my board. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. 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 an updated bootloader. Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei? If that works then you're probably just missing a patch. If it doesn't, then there must be something different between your boards. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. Perhaps, or (more likely) the interrupt affinity for the CTI isn't working properly and the interrupt is always delivered to CPU0. I'll keep this in mind in case we get any more reports like this. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 this patch so that needs to be resolved. Sampling is okay, though I noticed it tends to not get the correct number of samples for a controlled run: $ perf record -e cycles -c 1009213 noploop 10 noploop for 10 seconds $ perf report -D | tail -20 cycles stats: TOTAL events: 9938 MMAP events: 13 COMM events: 2 EXIT events: 2 THROTTLE events: 12 UNTHROTTLE events: 12 SAMPLE events: 9897 Should not get throttled samples. Should get abour 10k samples but only seeing 9897. The max_rate limit is way higher than what I set the period (1000 samples/sec). But then, is 3.2.0 throttling is broken. I posted a patch to fix that yesterday. I will try with my patch applied as well. 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 (and if you look at a profile, spin_unlock_irqrestore will be quite high). A7 and A15 have the ability to filter counters based on privilege level, so you can get more accurate userspace counts there. 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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 (and if
you look at a profile, spin_unlock_irqrestore will be quite high).
But I am only running a user space noploop. So it spends 99% in user space, no
critical section.
and your result is almost 99% of the way there :)
There are also potential overheads from the PMU interrupts themselves, since
there is a latency between overflow and taking the interrupt and then
between there are actually reading the counter (they continue to count after
overflow).
That said, if you see any bugs in the code please do shout!
A7 and A15 have the ability to filter counters based on privilege level, so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the same,
you just need to set some extra bits to determine which levels are included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
event description).
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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
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 of interrupts (samples). I'll check on that this week-end.
Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.
A7 and A15 have the ability to filter counters based on privilege level,
so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the
same,
you just need to set some extra bits to determine which levels are included
or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix
on an
event description).
It depends what you call the encoding? If the priv level can be encoded in the
attr-config field, then that's easy. If it needs to be set somewhere else,
then
we need to figure out how you encode it in the attr struct. Either in some
other
bits in attr-config or use attr-config1, for instance. You tell me.
The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Thu, Jan 26, 2012 at 05:25:27PM +, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 11:06:47AM +, Russell King - ARM Linux wrote:
Right, so with the stack of amba patches on top, it looks like this,
which to me looks sane. I haven't build-tested it though.
Will,
Hi Russell,
Did you see this? Any comment?
Sorry, this somehow got buried in other mail.
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
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /* CLCD
controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP
port */
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0 on
development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1 on
development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /* DMA
controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real
Time Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define 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
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
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
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /*
CLCD controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP port
*/
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0
on development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1
on development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /*
DMA controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real
Time Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define 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 }
I guess we should believe the TRM on this - can you put this in the patch
system please?
Sure. Which branch shall I take it against (before or after your amba
changes)?
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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
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 this -rc independently of the rest of the changes. If it's after, then it'll probably add a conflict. So, it'll be much easier to have it before, and I'll update what's necessary in the amba branch. Okey doke, I've submitted it as 7300/1 against 3.3-rc1. 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 at http://vger.kernel.org/majordomo-info.html
Re: ARM/ARM-SoC plans for v3.4 merge window
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 baseline until this evening. At that point, I will shut down my 'amba' branch and transfer that over; that means I won't be accepting any further acks etc for that work. If you haven't acked changes in the amba branch (eg, to Versatile, Realview etc) then it'll soon be too late... 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 support to MMCI 92b97f0 PM: add runtime PM support to core Primecell driver which don't seem to touch Versatile or Realview. Am I looking in the wrong place? Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: ARM/ARM-SoC plans for v3.4 merge window
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 support to MMCI 92b97f0 PM: add runtime PM support to core Primecell driver which don't seem to touch Versatile or Realview. Am I looking in the wrong place? Erm, I don't think you're looking at the right branch - especially as all the commits start ARM: amba:. They were sent out to the mailing list on 20th Jan as a set of 31 patches (latest first): [...] Indeed, the amba branch I was looking at no longer exists on your server and a git prune removed it. I'll take a look at the guys in devel-3.3 instead. Thanks, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/31] ARM: amba: vexpress: get rid of private platform amba_device initializer
On Fri, Jan 20, 2012 at 09:28:50AM +, Russell King - ARM Linux wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-vexpress/core.h | 17 - arch/arm/mach-vexpress/ct-ca9x4.c |8 arch/arm/mach-vexpress/v2m.c | 20 ++-- 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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/31] ARM: amba: versatile: get rid of private platform amba_device initializer
On Fri, Jan 20, 2012 at 09:29:10AM +, Russell King - ARM Linux wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-versatile/core.c | 36 arch/arm/mach-versatile/core.h | 20 - arch/arm/mach-versatile/versatile_pb.c | 10 3 files changed, 28 insertions(+), 38 deletions(-) This seems happy enough on a Versatile AB926, although I do get spurious IRQs from the ethernet chip: eth0: spurious interrupt (mask = 0xb3) This doesn't seem to be the fault of this patch 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 from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
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
+++---
arch/arm/mach-realview/realview_pb1176.c | 38
+++---
arch/arm/mach-realview/realview_pb11mp.c | 38
+++---
arch/arm/mach-realview/realview_pba8.c | 38
+++---
arch/arm/mach-realview/realview_pbx.c| 38
+++---
6 files changed, 100 insertions(+), 110 deletions(-)
After applying this patch, I get compile-time errors in realview_*.c.
E.g.:
arch/arm/mach-realview/realview_pb1176.c:158:1: error: ‘AACI’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:159:1: error: ‘MMCI0’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:160:1: error: ‘KMI0’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:161:1: error: ‘KMI1’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:162:1: error: ‘PB1176_UART4’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:165:1: error: ‘PB1176_SMC’ undeclared
here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:166:1: error: ‘SCTL’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:167:1: error: ‘PB1176_WATCHDOG’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:168:1: error: ‘PB1176_GPIO0’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:169:1: error: ‘GPIO1’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:170:1: error: ‘GPIO2’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:171:1: error: ‘PB1176_RTC’ undeclared
here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:172:1: error: ‘SCI’ undeclared here
(not in a function)
arch/arm/mach-realview/realview_pb1176.c:173:1: error: ‘PB1176_UART0’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:174:1: error: ‘PB1176_UART1’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:175:1: error: ‘PB1176_UART2’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:176:1: error: ‘PB1176_UART3’
undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:177:1: error: ‘PB1176_SSP’ undeclared
here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:178:1: error: ‘PB1176_CLCD’ undeclared
here (not in a function)
diff --git a/arch/arm/mach-realview/core.h b/arch/arm/mach-realview/core.h
index 735b57a..b1c6097 100644
--- a/arch/arm/mach-realview/core.h
+++ b/arch/arm/mach-realview/core.h
@@ -28,21 +28,11 @@
#include asm/setup.h
#include asm/leds.h
-#define AMBA_DEVICE(name,busid,base,plat) \
-static struct amba_device name##_device = {\
- .dev= { \
- .coherent_dma_mask = ~0,\
- .init_name = busid, \
- .platform_data = plat, \
- }, \
- .res= { \
- .start = REALVIEW_##base##_BASE, \
- .end= (REALVIEW_##base##_BASE) + SZ_4K - 1, \
- .flags = IORESOURCE_MEM, \
- },
Which is because the old AMBA_DEVICE macro munges REALVIEW_ and _BASE
around the peripheral identifier...
+#define APB_DEVICE(name, busid, base, plat)\
+static AMBA_APB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
+
+#define AHB_DEVICE(name, busid, base, plat)\
+static AMBA_AHB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
...whereas the new macros just use base directly.
Fixing the macro solves the build problem:
diff --git a/arch/arm/mach-realview/core.h b/arch/arm/mach-realview/core.h
index b1c6097..f8f2c0a 100644
--- a/arch/arm/mach-realview/core.h
+++ b/arch/arm/mach-realview/core.h
@@ -29,10 +29,10 @@
#include asm/leds.h
#define APB_DEVICE(name, busid, base, plat)\
-static AMBA_APB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
+static AMBA_APB_DEVICE(name, busid, 0, REALVIEW_##base##_BASE, base##_IRQ,
plat)
#define AHB_DEVICE(name, busid, base, plat)\
-static AMBA_AHB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
+static AMBA_AHB_DEVICE(name, busid, 0, REALVIEW_##base##_BASE, base##_IRQ,
plat)
struct machine_desc;
but then I see a warning during boot:
[1.669654] [
Re: [PATCH 22/31] ARM: amba: integrator: use common amba device initializers
On Fri, Jan 20, 2012 at 09:29:50AM +, Russell King - ARM Linux wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-integrator/core.c | 70 ++ arch/arm/mach-integrator/integrator_cp.c | 49 - 2 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
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
amba_device_add+0x1b4/0x1d0()
[1.705585] Modules linked in:
[1.715195] [c0013a00] (unwind_backtrace+0x0/0xfc) from [c03d1350]
(dump_stack+0x20/0x24)
[1.741288] [c03d1350] (dump_stack+0x20/0x24) from [c001f9b8]
(warn_slowpath_common+0x5c/0x74)
[1.768689] [c001f9b8] (warn_slowpath_common+0x5c/0x74) from
[c001f9fc] (warn_slowpath_null+0x2c/0x34)
[1.798165] [c001f9fc] (warn_slowpath_null+0x2c/0x34) from
[c023dcd4] (amba_device_add+0x1b4/0x1d0)
[1.826857] [c023dcd4] (amba_device_add+0x1b4/0x1d0) from [c023dd84]
(amba_device_register+0x94/0xc4)
[1.856106] [c023dd84] (amba_device_register+0x94/0xc4) from
[c0551934] (realview_pb1176_init+0x74/0xac)
[1.886120] [c0551934] (realview_pb1176_init+0x74/0xac) from
[c054d60c] (customize_machine+0x24/0x30)
[1.915340] [c054d60c] (customize_machine+0x24/0x30) from [c000879c]
(do_one_initcall+0x48/0x1a0)
[1.943505] [c000879c] (do_one_initcall+0x48/0x1a0) from [c054b870]
(kernel_init+0x80/0x128)
[1.970378] [c054b870] (kernel_init+0x80/0x128) from [c000ea78]
(kernel_thread_exit+0x0/0x8)
[1.997192] ---[ end trace 1b75b31a2719ed1e ]---
I suspect that comes from PB1176_GPIO0_IRQ being -1.
It seems you've also tested the code which detects -1 IRQs too, which
is good. PB1176 needs that GPIO0_IRQ fixing, but I suspect passing
zero may not be entirely a good thing for it as request_irq(0,...)
probably succeeds there. I think that needs fixing before this warning
can go away.
Yup, I actually tested this simply by checking out your devel-3.3 branch, so
the whole series has been tested on the boards that I've mentioned.
In the mean time, it's just a warning, and its saying there's something
wrong there which needs fixing but without anything currently broken.
So it's working as designed.
Right. I took a quick look at the TRM for the PB1176, and I think we do have
an interrupt for GPIO0, it's just on the other GIC. This patch should do the
trick, but I'm not sure what I can do to tickle the GPIO stuff anyway:
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
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /* CLCD
controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP port */
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0 on
development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1 on
development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /* DMA
controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real Time
Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define 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 }
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 at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 09, 2012 at 04:39:09PM +, Maynard Johnson wrote: On 01/08/2012 8:58 PM, Lik Lik wrote: Hi all, Hi guys [adding a bunch of people to CC because this issue is really annoying me now], I am an oprofile user and I need to profile one of my applications on a TI OMAP4 platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem is that oprofile always use the timer interrupt mode but doesn't recognize the hardware counters, which I am sure my platform has. First and foremost, we can't currently generate PMU interrupts on OMAP4 in mainline. There are some additional patches required for these to work: http://marc.info/?l=linux-arm-kernelm=131946761428296w=2 However, as Stephane has pointed out here: http://marc.info/?l=linux-omapm=132585784125352w=2 the interrupts still don't seem to work, even with the patches above applied. Ming Lei doesn't seem to be replying to email anymore, so maybe somebody else on linux-omap could please help us? I'm hoping that we're just missing some patches from somewhere, but it would be great if somebody could verify this (and indeed, verify that the interrupts we're registering in the thread 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 of the box. If not already using oprofile 0.9.7, please upgrade to that version and retry. If it still doesn't work, please re-post with complete information (kernel version, oprofile command output, and contents of /dev/oprofile/cpu_type). If with the latest OProfile, `timer mode' is still reported then you should check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still won't work though, because of the problems I mentioned above. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: USB Host port inoperative after kexec on Beagleboard
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) beagleboard doesn't
work after a kexec. During boot after kexec, the host device is
detected and initialised, but nothing plugged in works, even when
everything was working corectly before the kexec. Das U-boot
must set up something that is then undone during the kexec reboot.
Ouch. Have you had a chance to look at the u-boot sources to see what it
does?
I've traced all calls to clk_enable() and clk_disable(), and
everything looks all right --- in particular I can't see
anything explicitly disabled during kexec that isn't reenabled
during boot of the subsequent kernel.
Voltages that I can measure look correct on the port.
Do you have any suggestions as to what else could be wrong?
I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
Have you tried re-initialising the host controller in the new kernel
manually (perhaps my building the driver as a module and {un}loading it a
few times?). It could be that some hardware state persists across the kexec
and it just needs resetting.
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 at http://vger.kernel.org/majordomo-info.html
Re: USB Host port inoperative after kexec on Beagleboard
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 this
week. Mostly things work now.
Great, that's good to hear!
One issue: the USB EHCI port on the (rev C2) beagleboard doesn't
work after a kexec. During boot after kexec, the host device is
detected and initialised, but nothing plugged in works, even when
everything was working corectly before the kexec. Das U-boot
must set up something that is then undone during the kexec reboot.
Ouch. Have you had a chance to look at the u-boot sources to see what it
does?
I've traced all calls to clk_enable() and clk_disable(), and
everything looks all right --- in particular I can't see
anything explicitly disabled during kexec that isn't reenabled
during boot of the subsequent kernel.
Voltages that I can measure look correct on the port.
Do you have any suggestions as to what else could be wrong?
I'm afraid I'm not familiar with the Beagleboard, so I can't begin to guess.
Have you tried re-initialising the host controller in the new kernel
manually (perhaps my building the driver as a module and {un}loading it a
few times?). It could be that some hardware state persists across the kexec
and it just needs resetting.
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 at http://vger.kernel.org/majordomo-info.html
Inclusion of ARM perf tree in linux-next
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 useful to spot any conflicts for 3.3, however I think it's generally a good idea for me to give some of the perf changes an airing before they get merged anyway. The merge path for these patches into mainline is usually via Russell, but platform updates may go via arm-soc (Arnd). Thanks, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 suggest splitting patches 1-3 off into a separate series that Will can pass on to -next if he wishes. Fine by me. If Ming Lei posts a new series so that everything is in one thread then I can pick out the bits I want. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 directly into -next. Otherwise they are likely to generate merge conflicts with other OMAP changes that we may generate. So I'd suggest splitting patches 1-3 off into a separate series that Will can pass on to -next if he wishes. Fine by me. If Ming Lei posts a new series so that everything is in one thread then I can pick out the bits I want. You mean the 3rd patch is the debugss patch posted by Benoit? The original 3rd patch is not needed any more once the debugss patch is taken. Ah sorry, I lost track a bit. In that case, I'll just keep hold of the two patches I have and deal with them appropriately. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 ourselves :) Ming Lei - can you take this into your patch series please? Then we'll have: - The two perf patches in my tree - The hwmod fix in Tony's tree (pending pull) - Your patches plus this one for hooking everything together The sooner we can push these into -next, the better. Cheers, 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
[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 platform_get_irq_byname(), or the hwmod hardware data will need to be rearranged to meet the arbitrary ordering requirement. I'd suggest pinging Will on this issue to see what he wants to do. 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 thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. So although the ordering requirements are a bit of a pain, I do think it's reasonable for perf to expect that it's not being handed some random other interrupts along with those for the PMU. So the clockdomain is already defined in mach-omap2/clockdomains44xx_data.c and there's code to control it - see for example clkdm_enable_idle(). But this code should not be called directly by any device driver code or driver integration code. The thing to do here is to ask Benoît to release the hwmod data for the DEBUGSS hwmod, then someone will need to write an MFD driver for that which exposes the PMU address space to the PMU platform driver. Benoit? Please can you chime in here? 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 thing to do). To do this, we expect the IRQ resources to be laid out in CPU order. In hindsight, maybe naming the resources might have been a good idea, but them we'd still have to generate the names using CPU numbers when iterating through the platform device. There isn't yet a way to do naming of resources with DT, and although I think there was a proposal for doing named register resources I don't think this has been accepted and there wasn't anything for IRQ resources... That's good news - means I have an excuse other than laziness for not implementing this for perf :) 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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 linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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, but
the organization of the debugss IPs inside MPUSS is a little bit messy
in OMAP :-)
Ok, I'm not familiar with it so that's why I've been pestering.
For the moment the cti IRQs are attached to the MPU subsystem which make
sense for the HW partitioning point of view.
Unfortunately, these debug IPs are accessed through an external L3_EMU
configuration bus and not using some internal bus inside the MPUSS.
In the memory maps they are thus all located inside the
0x5400-0x54164FFF.
So for the driver point of view, it might be better to assign these IRQs
to the debugss IP instead of the MPUSS IP.
The MPU will then only have the PL310 IRQ.
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
At some point I'd like to add support for the PL310 PMU, which will want to
use that IRQ. That would need to be passed to the PL310 driver though, which
will then register it's own PMU device with perf.
The debugss one will have the cti ones, that will start at 0 and thus
will make them even accessible using the index.
static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
{ .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
{ .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
I need to fix this IRQ mapping and then I'll be able to send a hwmod
version of this debugss virtual IP that should help Ming.
That looks cracking and should work out of the box.
Thanks,
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 at http://vger.kernel.org/majordomo-info.html
