summaryrefslogtreecommitdiff
path: root/arch/powerpc/kernel/perf_event_fsl_emb.c
AgeCommit message (Collapse)Author
2010-08-03perf, powerpc: fsl_emb: Restore setting perf_sample_data.periodScott Wood
Commit 6b95ed345b9faa4ab3598a82991968f2e9f851bb changed from a struct initializer to perf_sample_data_init(), but the setting of the .period member was left out. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: stable@kernel.org Signed-off-by: Paul Mackerras <paulus@samba.org>
2010-08-03perf, powerpc: Convert the FSL driver to use local64_tPeter Zijlstra
For some reason the FSL driver got left out when we converted perf to use local64_t instead of atomic64_t. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2010-07-27perf, powerpc: Use perf_sample_data_init() for the FSL codePeter Zijlstra
We should use perf_sample_data_init() to initialize struct perf_sample_data. As explained in the description of commit dc1d628a ("perf: Provide generic perf_sample_data initialization"), it is possible for userspace to get the kernel to dereference data.raw, so if it is not initialized, that means that unprivileged userspace can possibly oops the kernel. Using perf_sample_data_init makes sure it gets initialized to NULL. This conversion should have been included in commit dc1d628a, but it got missed. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2010-03-05powerpc/perf: e500 supportScott Wood
This implements perf_event support for the Freescale embedded performance monitor, based on the existing perf_event.c that supports server/classic chips. Some limitations: - Performance monitor interrupts are regular EE interrupts, and thus you can't profile places with interrupts disabled. We may want to implement soft IRQ-disabling, with perfmon interrupts exempted and treated as NMIs. - When trying to schedule multiple event groups at once, and using restricted events, situations could arise where scheduling fails even though it would be possible. Consider three groups, each with two events. One group has restricted events, the others don't. The two non-restricted groups are scheduled, then one is removed, which happens to occupy the two counters that can't do restricted events. The remaining non-restricted group will not be moved to the non-restricted-capable counters to make room if the restricted group tries to be scheduled. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>