On 07/11/2012 11:06 AM, Benjamin Herrenschmidt wrote:
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -207,6 +207,12 @@ static struct
the context in arch_uprobe_abort_xol() (Oleg)
---
Suzuki K. Poulose (4):
kprobes/powerpc: Do not disable External interrupts during single step
powerpc: Move the single step enable code to a generic path
uprobes/powerpc: Introduce routines for save/restore context
uprobes
From: Suzuki K. Poulose suz...@in.ibm.com
External/Decrement exceptions have lower priority than the Debug Exception.
So, we don't have to disable the External interrupts before a single step.
However, on BookE, Critical Input Exception(CE) has higher priority than a
Debug Exception. Hence we
From: Suzuki K. Poulose suz...@in.ibm.com
This patch moves the single step enable code used by kprobe to a generic
routine header so that, it can be re-used by other code, in this case,
uprobes. No functional changes.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: Ananth N
From: Suzuki K. Poulose suz...@in.ibm.com
Introduce routines for saving and restoring the context
befre/after the single step. No functional changes involved.
These will be extended later to save/restore more info about
the process once we replace the ptrace helpers.
Signed-off-by: Suzuki K
From: Suzuki K. Poulose suz...@in.ibm.com
Replace the ptrace helpers with the powerpc generic routines to
enable/disable single step. We save/restore the MSR (and DCBR for BookE)
across for the operation. We don't have to disable the single step,
as restoring the MSR/DBCR would restore
On 12/03/2012 08:45 PM, Ananth N Mavinakayanahalli wrote:
On Mon, Dec 03, 2012 at 08:39:35PM +0530, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
Introduce routines for saving and restoring the context
befre/after the single step. No functional changes involved
On 09/07/2012 07:05 AM, Benjamin Herrenschmidt wrote:
On Tue, 2012-08-21 at 17:12 +0530, Suzuki K. Poulose wrote:
There are some device-tree nodes, whose values are of type phys_addr_t.
The phys_addr_t is variable sized based on the CONFIG_PHSY_T_64BIT.
Change these to a fixed unsigned long
...@in.ibm.com
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Arnaldo Carvalho de Melo a...@infradead.org
---
tools/perf/util/strlist.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/strlist.c b/tools/perf/util
On 08/29/2012 11:59 AM, David Ahern wrote:
On 8/29/12 12:00 AM, Suzuki K. Poulose wrote:
The following commit:
authorDavid Ahern dsah...@gmail.com
Tue, 31 Jul 2012 04:31:33 + (22:31 -0600)
committerArnaldo Carvalho de Melo a...@redhat.com
Fri, 3 Aug 2012 13:39:51 + (10
-off-by: Suzuki K Poulose suz...@in.ibm.com
Cc: David Ahern dsah...@gmail.com
---
tools/perf/util/intlist.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/intlist.c b/tools/perf/util/intlist.c
index fd530dc..77c504f 100644
--- a/tools/perf/util
The nr_entries in rblist is never decremented when an element
is deleted. Also, use rblist__remove_node to delete a node in
rblist__delete(). This would keep the nr_entries sane.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: David S. Ahern dsah...@gmail.com
---
tools/perf/util/rblist.c
On 08/07/2012 09:42 PM, Sebastian Andrzej Siewior wrote:
by the time we get here (after we pass cleanup_ret) uprobe is always is
set. If it is NULL we leave very early in the code.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
kernel/events/uprobes.c | 16
On 08/08/2012 03:05 PM, Sebastian Andrzej Siewior wrote:
On 08/08/2012 11:10 AM, Suzuki K. Poulose wrote:
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1528,17 +1528,15 @@ cleanup_ret:
utask-active_uprobe = NULL;
utask-state = UTASK_RUNNING;
}
- if (uprobe) {
- if (!(uprobe
'phys_addr_t' (which
is 32bit on some ppc32 and 64 bit on ppc64 and some ppc32)
* Rebased the patch to use recently fixed prom_update_property()
which would add the property if it didn't exist.
---
Suzuki K. Poulose (2):
[powerpc] Change memory_limit from phys_addr_t to unsigned
the different sized values and then change
the above.
Suggested-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
---
arch/powerpc/include/asm/setup.h|2 +-
arch/powerpc/kernel/fadump.c|3 +--
arch/powerpc/kernel
this patch on ppc64 and ppc32(ppc440) with a kexec-tools
patch by Mahesh.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Tested-by: Mahesh J. Salgaonkar mah...@linux.vnet.ibm.com
---
arch/powerpc/kernel/machine_kexec.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff
On 12/03/2012 08:37 PM, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suz...@in.ibm.com
External/Decrement exceptions have lower priority than the Debug Exception.
So, we don't have to disable the External interrupts before a single step.
However, on BookE, Critical Input Exception(CE) has
the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Without this patch, I couldn't build perf on powerpc, with 3.7.0-rc2
Tested-by: Suzuki K. Poulose suz...@in.ibm.com
Thanks
Suzuki
---
tools/perf/perf.h |2 +-
1
applies on top of the patches posted by Oleg at :
https://lkml.org/lkml/2012/10/28/92
Patches have been verified on Power6 and PPC440 (BookE).
---
Suzuki K. Poulose (2):
powerpc: Move the single step enable code to a generic path
uprobes/powerpc: Make use of generic routines
From: Suzuki K. Poulose suz...@in.ibm.com
This patch moves the single step enable code used by kprobe to a generic
routine so that, it can be re-used by other code, in this case,
uprobes.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: linuxppc-...@ozlabs.org
---
arch/powerpc
From: Suzuki K. Poulose suz...@in.ibm.com
Replace the ptrace helpers with the powerpc generic routines to
enable/disable single step. We save/restore the MSR (and DCBR for BookE)
across for the operation.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
---
arch/powerpc/include/asm/uprobes.h
On 11/26/2012 10:31 PM, Oleg Nesterov wrote:
On 11/26, Suzuki K. Poulose wrote:
@@ -121,8 +125,11 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe,
struct pt_regs *regs)
* to be executed.
*/
regs-nip = utask-vaddr + MAX_UINSN_BYTES;
+ regs-msr = utask
On 11/26/2012 11:40 PM, Sebastian Andrzej Siewior wrote:
On 11/26/2012 12:05 PM, Suzuki K. Poulose wrote:
diff --git a/arch/powerpc/include/asm/probes.h
b/arch/powerpc/include/asm/probes.h
index 5f1e15b..836e9b9 100644
--- a/arch/powerpc/include/asm/probes.h
+++ b/arch/powerpc/include/asm
On 12/15/2012 01:32 AM, Oleg Nesterov wrote:
On 12/03, Suzuki K. Poulose wrote:
Replace the ptrace helpers with the powerpc generic routines to
enable/disable single step. We save/restore the MSR (and DCBR for BookE)
across for the operation. We don't have to disable the single step
From: Suzuki K. Poulose suz...@in.ibm.com
Uprobes uses emulate_step in sstep.c, but we haven't explicitly specified
the dependency. On pseries HAVE_HW_BREAKPOINT protects us, but 44x has no
such luxury.
Consolidate other users that depend on sstep and create a new config option.
Signed-off
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote:
(9/3/13 4:39 AM), Janani Venkataraman wrote:
Hello,
We are working on an infrastructure to create a system core file of a
specific
process at run-time, non-disruptively. It can also be extended to a
case where
a process is able to take a
On 10/04/2013 07:14 PM, Andi Kleen wrote:
On Fri, Oct 04, 2013 at 04:00:12PM +0530, Janani Venkataraman wrote:
Hi all,
The following series implements an infrastructure for capturing the core of
an
application without disrupting its process.
The problem is that gcore et.al. have to stop
initializing
blacklist.
Changes in V2:
- Use function_entry() macro when lookin up symbols instead
of storing it.
- Update for the latest -next.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Reported-by: Tony Luck tony.l...@gmail.com
Cc: Suzuki K. Poulose suz...@in.ibm.com
On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by
On 06/19/2014 10:22 AM, Masami Hiramatsu wrote:
(2014/06/19 10:30), Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
(2014/06/18 16:56), Michael Ellerman wrote:
On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
Ping?
I guess this should go to 3.16
On 06/19/2014 12:56 PM, Masami Hiramatsu wrote:
(2014/06/19 15:40), Suzuki K. Poulose wrote:
On 06/19/2014 10:22 AM, Masami Hiramatsu wrote:
(2014/06/19 10:30), Michael Ellerman wrote:
On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
(2014/06/18 16:56), Michael Ellerman wrote
On 03/24/2014 07:24 PM, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/24/2014 5:43 AM, Janani Venkataraman wrote:
Gcore attaches to the process using gdb and runs the gdb gcore
command and then detaches. In gcore the dump cannot be issued from
a signal handler
On 17/12/14 17:39, Will Deacon wrote:
On Wed, Dec 17, 2014 at 03:50:21PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
We initialise the SCTLR_EL1 value by read-modify-writeback
of the desired bits, leaving the other bits (including reserved
bits(RESx
From: Suzuki K. Poulose suzuki.poul...@arm.com
We initialise the SCTLR_EL1 value by read-modify-writeback
of the desired bits, leaving the other bits (including reserved
bits(RESx)) untouched. However, sometimes the boot monitor could
leave garbage values in the RESx bits which could have
On 04/12/14 19:44, Steven Stewart-Gallus wrote:
Hello,
Given an evil hacker trying to confuse process monitors that might use such
strange process names as 'pause) R 0 0 (foo' how can I correctly parse the
command name from /proc/pid/stat? Maybe I should just use /proc/pid/status?
Maybe there
On 10/01/15 08:55, Vladimir Davydov wrote:
On Fri, Jan 09, 2015 at 05:43:17PM +, Suzuki K. Poulose wrote:
Hi
We have hit a hang on ARM64 defconfig, while running LTP tests on
3.19-rc3. We are
in the process of a git bisect and will update the results as and
when we find the commit.
During
On 16/01/15 16:15, Suzuki K. Poulose wrote:
On 16/01/15 15:53, Will Deacon wrote:
On Thu, Jan 15, 2015 at 12:36:04PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch keeps track of the mixed endian EL0 support across
the system and provides helper
On 16/01/15 16:07, Will Deacon wrote:
On Thu, Jan 15, 2015 at 12:36:05PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
As of now each insn_emulation has a cpu hotplug notifier that
enables/disables the CPU feature bit for the functionality. This
patch re
On 16/01/15 15:53, Will Deacon wrote:
On Thu, Jan 15, 2015 at 12:36:04PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch keeps track of the mixed endian EL0 support across
the system and provides helper functions to export it. The status
is a boolean
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch keeps track of the mixed endian EL0 support across
the system and provides helper functions to export it. The status
is a boolean indicating whether all the CPUs on the system supports
mixed endian at EL0.
Signed-off-by: Suzuki K. Poulose
From: Suzuki K. Poulose suzuki.poul...@arm.com
As of now each insn_emulation has a cpu hotplug notifier that
enables/disables the CPU feature bit for the functionality. This
patch re-arranges the code, such that there is only one notifier
that runs through the list of registered emulation hooks
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series add support for controlling the 'setend' instruction,
which is deprecated in ARMv8, using the legacy instruction emulation
framework, introduced by Punit Agrawal.
Changes since V1:
- Added a patch to keep track of the mixed endian
From: Suzuki K. Poulose suzuki.poul...@arm.com
Emulate deprecated 'setend' instruction for AArch32 bit tasks.
setend [le/be] - Sets the endianness of EL0
On systems with CPUs which support mixed endian at EL0, the hardware
support for the instruction can be enabled by setting
From: Suzuki K. Poulose suzuki.poul...@arm.com
As of now each insn_emulation has a cpu hotplug notifier that
enables/disables the CPU feature bit for the functionality. This
patch re-arranges the code, such that there is only one notifier
that runs through the list of registered emulation hooks
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series add support for controlling the 'setend' instruction,
which is deprecated in ARMv8, using the legacy instruction emulation
framework, introduced by Punit Agrawal.
Changes since V2:
- Move ID_AA64MMFR0_EL1 bit definitions to asm
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch keeps track of the mixed endian EL0 support across
the system and provides helper functions to export it. The status
is a boolean indicating whether all the CPUs on the system supports
mixed endian at EL0.
Signed-off-by: Suzuki K. Poulose
From: Suzuki K. Poulose suzuki.poul...@arm.com
Emulate deprecated 'setend' instruction for AArch32 bit tasks.
setend [le/be] - Sets the endianness of EL0
On systems with CPUs which support mixed endian at EL0, the hardware
support for the instruction can be enabled by setting
On 13/02/15 20:50, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 13, 2015 at 12:39:24PM -0700, David Ahern escreveu:
On 02/13/2015 11:40 AM, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
Commit 1971f59 (perf stat: Use read_counter in read_counter_aggr )
broke
Hi
We have hit a hang on ARM64 defconfig, while running LTP tests on
3.19-rc3. We are
in the process of a git bisect and will update the results as and
when we find the commit.
During the ksm ltp run, the test hangs trying to mount memcg with the
following strace
output:
mount(memcg,
On 07/01/15 05:52, Leo Yan wrote:
Currently kernel has set the bit SCTLR_EL1.SED, so the SETEND
instruction will be treated as UNALLOCATED; this error can be
reproduced when ARMv8 cpu runs with EL1/aarch64 and EL0/aarch32
mode, finally kernel will trap the exception if the userspace
libs use
On 08/01/15 18:43, Mark Rutland wrote:
Hi Suzuki,
On Wed, Jan 07, 2015 at 04:16:45PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
Emulate deprecated 'setend' instruction for AArch32 bit tasks.
setend [le/be] - Sets the endianness of EL0
The hardware
On 11/01/15 20:55, Johannes Weiner wrote:
On Sat, Jan 10, 2015 at 04:43:16PM -0500, Tejun Heo wrote:
Currently, if a hierarchy doesn't have any live children when it's
unmounted, the hierarchy starts dying by killing its refcnt. The
expectation is that even if there are lingering dead children
On Fri, Jan 09, 2015 at 09:46:49PM +, Tejun Heo wrote:
On Fri, Jan 09, 2015 at 05:43:17PM +, Suzuki K. Poulose wrote:
We have hit a hang on ARM64 defconfig, while running LTP tests on 3.19-rc3.
We are
in the process of a git bisect and will update the results as and
when we find
From: Suzuki K. Poulose suzuki.poul...@arm.com
Commit 1971f59 (perf stat: Use read_counter in read_counter_aggr )
broke the perf stat output for unsupported counters.
$ perf stat -v -a -C 0 -e CCI_400/config=24/ sleep 1
Warning:
CCI_400/config=24/ event is not supported by the kernel
From: Suzuki K. Poulose suzuki.poul...@arm.com
Emulate deprecated 'setend' instruction for AArch32 bit tasks.
setend [le/be] - Sets the endianness of EL0
The hardware support for the instruction can be enabled by setting the
SCTLR_EL1.SED bit. Like the other emulated instructions
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series add support for controlling the 'setend' instruction,
which is deprecated in ARMv8, using the legacy instruction emulation
framework, introduced by Punit Agrawal.
Patch 1 re-organises the infrastructure a little bit to avoid multiple
CPU
From: Suzuki K. Poulose suzuki.poul...@arm.com
As of now each insn_emulation has a cpu hotplug notifier that
enables/disables the CPU feature bit for the functionality. This
patch re-arranges the code, such that there is only one notifier
that runs through the list of registered emulation hooks
On 17/03/15 18:54, Will Deacon wrote:
On Tue, Mar 10, 2015 at 03:18:50PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver
From: Suzuki K. Poulose suzuki.poul...@arm.com
CCI400 has different event specifications for PMU, for revsion
0 and revision 1. As of now, we check the revision every single
time before using the parameters for the PMU. This patch abstracts
the details of the pmu models in a struct (cci_pmu_model
From: Suzuki K. Poulose suzuki.poul...@arm.com
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().
Change since V2:
- Removed unnecessary goto. (Suggested-by: Sudeep Holla)
Signed-off
From: Suzuki K. Poulose suzuki.poul...@arm.com
We mask the event with the CCI_PMU_EVENT_MASK, before passing
the config to pmu_validate_hw_event(), which causes extra bits
to be ignored and qualifies an invalid event code as valid.
e.g,
$ perf stat -a -C 0 -e CCI_400/config=0x1ff,name=cycles
From: Suzuki K. Poulose suzuki.poul...@arm.com
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secure transaction. This puts a limitation on the usage of the
driver
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM driver is only used on ARM(32) and contains
arm32 assembly and hence can't be built on ARM64
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch separates the PMU driver code from the low level
CCI driver code and enables the PMU driver for ARM64.
Introduces config options for both.
ARM_CCI400_PORT_CTRL - controls the low level driver code for
CCI400
From: Suzuki K. Poulose suzuki.poul...@arm.com
A minor change, fixed missplled 'DEPRECATED' in the dev_warn().
Thanks
Suzuki
8
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400
On 19/03/15 17:38, Sudeep Holla wrote:
On 19/03/15 17:32, Mark Rutland wrote:
One more thing:
@@ -883,7 +894,11 @@ static inline const struct cci_pmu_model
*get_cci_model(struct platform_device *
pdev-dev.of_node);
if (!match)
From: Suzuki K. Poulose suzuki.poul...@arm.com
This is a collection of fixes which denies grouping hardware events
from different PMUs. They also fix crashes triggered by perf_fuzzer
on Linux-4.0-rc2.
Pawel,
Similar fix is required in ARM CCN PMU driver. I didn't find it
straight forward to fix
From: Suzuki K. Poulose suzuki.poul...@arm.com
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs
From: Suzuki K. Poulose suzuki.poul...@arm.com
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs
From: Suzuki K. Poulose suzuki.poul...@arm.com
Invalidate an event if the group has a hardware event from
a different PMU as we cannot schedule all of them in the same
context. The perf core code won't check the group consistency
until after pmu_event_init().
Signed-off-by: Suzuki K. Poulose
On 09/03/15 12:43, a wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This is a collection of fixes which denies grouping hardware events
from different PMUs. They also fix crashes triggered by perf_fuzzer
on Linux-4.0-rc2.
Pawel,
Similar fix is required in ARM CCN PMU driver. I didn't
On 10/03/15 11:27, Peter Zijlstra wrote:
On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Uhm, how does this work? If we have multiple hardware PMUs
On 10/03/15 13:00, Peter Zijlstra wrote:
On Tue, Mar 10, 2015 at 01:53:51PM +0100, Peter Zijlstra wrote:
It would be nicer if we could prevent this in the core so we're not
reliant on every PMU driver doing the same verification. My initial
thought was that seemed like unnecessary duplication
From: Suzuki K. Poulose suzuki.poul...@arm.com
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().
Change since V2:
- Removed unnecessary goto. (Suggested-by: Sudeep Holla)
Signed-off
From: Suzuki K. Poulose suzuki.poul...@arm.com
CCI400 has different event specifications for PMU, for revsion
0 and revision 1. As of now, we check the revision every single
time before using the parameters for the PMU. This patch abstracts
the details of the pmu models in a struct (cci_pmu_model
On 10/03/15 16:09, Nicolas Pitre wrote:
On Tue, 10 Mar 2015, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM
From: Suzuki K. Poulose suzuki.poul...@arm.com
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secure transaction. This puts a limitation on the usage of the
driver
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch separates the PMU driver code from the low level
CCI driver code and enables the PMU driver for ARM64.
Introduces config options for both.
ARM_CCI400_PORT_CTRL - controls the low level driver code for
CCI400
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM driver is only used on ARM(32) and contains
arm32 assembly and hence can't be built on ARM64
On 10/03/15 16:21, Sudeep Holla wrote:
On 10/03/15 15:18, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM
From: Suzuki K. Poulose suzuki.poul...@arm.com
We mask the event with the CCI_PMU_EVENT_MASK, before passing
the config to pmu_validate_hw_event(), which causes extra bits
to be ignored and qualifies an invalid event code as valid.
e.g,
$ perf stat -a -C 0 -e CCI_400/config=0x1ff,name=cycles
On 23/03/15 21:16, Stephen Rothwell wrote:
Hi all,
On Mon, 23 Mar 2015 15:13:51 + Suzuki K. Poulose suzuki.poul...@arm.com
wrote:
On 23/03/15 14:41, Abhilash Kesavan wrote:
On Mon, Mar 23, 2015 at 6:03 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Today's linux-next merge
On 23/03/15 14:41, Abhilash Kesavan wrote:
Hi Stephen,
On Mon, Mar 23, 2015 at 6:03 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/bus/Kconfig between commit c9966c98697a (arm-cci: Split the
code for PMU vs
On 23/03/15 15:10, Valentin Rothberg wrote:
Hi Suzuki,
your commit c9966c98697a (arm-cci: Split the code for PMU vs driver
support) renames the Kconfig option ARM_CCI to ARM_CCI400_PORT_CTRL.
However, the commit does not rename all references on ARM_CCI:
It renames, but still, leaves the
On 23/03/15 15:17, Suzuki K. Poulose wrote:
On 23/03/15 15:10, Valentin Rothberg wrote:
Hi Suzuki,
your commit c9966c98697a (arm-cci: Split the code for PMU vs driver
support) renames the Kconfig option ARM_CCI to ARM_CCI400_PORT_CTRL.
However, the commit does not rename all references
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM driver is only used on ARM(32) and contains
arm32 assembly and hence can't be built on ARM64
From: Suzuki K. Poulose suzuki.poul...@arm.com
We mask the event with the CCI_PMU_EVENT_MASK, before passing
the config to pmu_validate_hw_event(), which causes extra bits
to be ignored and qualifies an invalid event code as valid.
e.g,
$ perf stat -a -C 0 -e CCI_400/config=0x1ff,name=cycles
From: Suzuki K. Poulose suzuki.poul...@arm.com
CCI400 has different event specifications for PMU, for revsion0 and
revision 1. As of now, we check the revision twice, for using the
parameters for the PMU. This patch abstracts the details of the pmu
models in a struct (cci_pmu_model) and stores
From: Suzuki K. Poulose suzuki.poul...@arm.com
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secure transaction. This puts a limitation on the usage of the
driver
From: Suzuki K. Poulose suzuki.poul...@arm.com
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().
Signed-off-by: Suzuki K. Poulose suzuki.poul...@arm.com
---
drivers/bus/arm-cci.c
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch separates the PMU driver code from the low level
CCI driver code.
Introduces config options for both.
ARM_CCI400_PORT_CTRL - controls the low level driver code for
CCI400 ports.
ARM_CCI400_PMU
On 03/03/15 15:44, Sudeep Holla wrote:
On 02/03/15 11:29, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400
On 03/03/15 15:53, Sudeep Holla wrote:
On 02/03/15 11:29, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch separates the PMU driver code from the low level
CCI driver code.
Introduces config options for both.
ARM_CCI400_PORT_CTRL - controls the low
On 03/03/15 16:00, Sudeep Holla wrote:
On 02/03/15 11:29, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
This series enables the PMU monitoring support for CCI400 on ARM64.
The existing CCI400 driver code is a mix of PMU driver and the MCPM
driver code. The MCPM
On 03/03/15 15:35, Sudeep Holla wrote:
On 02/03/15 11:29, Suzuki K. Poulose wrote:
From: Suzuki K. Poulose suzuki.poul...@arm.com
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports
From: Suzuki K. Poulose suzuki.poul...@arm.com
With FAN_ONDIR set, the user can end up getting events, which
it hasn't marked. This was revealed with fanotify04 testcase
failure on Linux-4.0-rc1, and is a regression from 3.19, revealed
with commit (66ba93c0d7fe6: fanotify: don't set FAN_ONDIR
From: Suzuki K. Poulose suzuki.poul...@arm.com
No functional changes, only code re-arrangements for easier split of the
PMU code vs low level driver code. Extracts the port handling code
to cci_probe_ports().
Signed-off-by: Suzuki K. Poulose suzuki.poul...@arm.com
---
drivers/bus/arm-cci.c
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch separates the PMU driver code from the low level
CCI driver code, and enables the CCI400-PMU for ARM64.
Introduces config options for both.
- ARM_CCI400_MCPM - controls the low level MCPM driver code for CCI
- ARM_CCI400_PMU
From: Suzuki K. Poulose suzuki.poul...@arm.com
We mask the event with the CCI_PMU_EVENT_MASK, before passing
the config to pmu_validate_hw_event(), which causes extra bits
to be ignored and qualifies an invalid event code as valid.
e.g,
$ perf stat -a -C 0 -e CCI_400/config=0x1ff,name=cycles
1 - 100 of 5007 matches
Mail list logo
