summaryrefslogtreecommitdiff
path: root/arch/arm/kernel/pmu.c
AgeCommit message (Collapse)Author
2012-08-23ARM: pmu: remove unused reservation mechanismWill Deacon
The PMU reservation mechanism was originally intended to allow OProfile and perf-events to co-ordinate over access to the CPU PMU. Since then, OProfile for ARM has moved to using perf as its backend, so the reservation code is no longer used. This patch removes the reservation code for the CPU PMU on ARM. Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-11-16ARM: PMU: re-export release_pmu symbol to modulesWill Deacon
Commit b0e89590 ("ARM: PMU: move CPU PMU platform device handling and init into perf") inadvertently removed the EXPORT_SYMBOL_GPL on release_pmu, so out-of-tree modules can no longer play nice with perf, even if they tried in the first place. This patch re-exports the symbol. Reported-by: Jon Medhurst (Tixy) <jon.medhurst@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-08-31ARM: PMU: move CPU PMU platform device handling and init into perfWill Deacon
Once upon a time, OProfile and Perf fought hard over who could play with the PMU. To stop all hell from breaking loose, pmu.c offered an internal reserve/release API and took care of parsing PMU platform data passed in from board support code. Now that Perf has ingested OProfile, let's move the platform device handling into the Perf driver and out of the PMU locking code. Unfortunately, the lock has to remain to prevent Perf being bitten by out-of-tree modules such as LTTng, which still claim a right to the PMU when Perf isn't looking. Acked-by: Jamie Iles <jamie@jamieiles.com> Reviewed-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-08-12ARM: perf: make name of arm_pmu_type consistentMark Rutland
Commit f12482c9 ("ARM: 6974/1: pmu: refactor reservation") changed {release,reserve}_pmu to take an enum arm_pmu_type as a parameter, but inconsistently named the parameter `type' or `device'. It would be nice if these were consistent. This patch makes use of enum arm_pmu_type consistent, always using `type'. Related printks are updated, explicitly mentioning `type' also. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-06-29ARM: 6977/1: pmu: add platform_device_id table supportMark Rutland
This patch adds support for platform_device_id tables, allowing new PMU types to be registered with the correct type, without requiring new platform_driver shims to provide the type. An single entry for existing devices is provided. Macros matching functionality of the of_device_id table macros are provided for convenience. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-06-29ARM: 6976/1: pmu: add OF probing supportMark Rutland
This is based on an earlier patch from Rob Herring <rob.herring@calxeda.com> > Add OF match table to enable OF style driver binding. The dts entry is like > this: > > pmu { > compatible = "arm,cortex-a9-pmu"; > interrupts = <100 101>; > }; > > The use of pdev->id as an index breaks with OF device binding, so set the type > based on the OF compatible string. This modification sets the PMU hardware type based on data embedded in the binding, allowing easy addition of new PMU types in future. Support for new PMU types not provided by devicetree can be added later using platform_device_id tables in a similar fashion. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Rob Herring <rob.herring@calxeda.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-06-29ARM: 6975/1: pmu: reject duplicate PMU registrationsMark Rutland
Currently, the PMU reservation framework allows for multiple PMUs of the same type to register themselves. This can lead to a bug with the sequence: register_pmu(pmu1); reserve_pmu(pmu_type); register_pmu(pmu2); release_pmu(pmu1); Here, pmu1 cannot be released, and pmu2 cannot be reserved. This patch modifies register_pmu to reject registrations where a PMU is already present, preventing this problem. PMUs which can have multiple instances should not use the PMU reservation framework. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-06-29ARM: 6974/1: pmu: refactor reservationMark Rutland
Currently, PMU platform_device reservation relies on some minor abuse of the platform_device::id field for determining the type of PMU. This is problematic for device tree based probing, where the ID cannot be controlled. This patch removes reliance on the id field, and depends on each PMU's platform driver to figure out which type it is. As all PMUs handled by the current platform_driver name "arm-pmu" are CPU PMUs, this convention is hardcoded. New PMU types can be supported through the use of {of,platform}_device_id tables Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Will Deacon <will.deacon@arm.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-02-19ARM: 6742/1: pmu: avoid setting IRQ affinity on UP systemsWill Deacon
Now that we can execute a CONFIG_SMP kernel on a uniprocessor system, extra care has to be taken in the PMU IRQ affinity setting code to ensure that we don't always fail to initialise. This patch changes the CPU PMU initialisation code so that when we only have a single IRQ, whose affinity can not be changed at the controller, we report success (0) rather than -EINVAL. Reported-by: Avik Sil <avik.sil@linaro.org> Acked-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-05-17ARM: 6064/1: pmu: register IRQs at runtimeWill Deacon
The current PMU infrastructure for ARM requires that the IRQs for the PMU device are fixed at compile time and are selected based on the ARCH_ or MACH_ flags. This has the disadvantage of tying the Kernel down to a particular board as far as profiling is concerned. This patch replaces the compile-time IRQ registration with a runtime mechanism which allows the IRQs to be registered with the framework as a platform_device. A further advantage of this change is that there is scope for registering different types of performance counters in the future by changing the id of the platform_device and attaching different resources to it. Acked-by: Jamie Iles <jamie.iles@picochip.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-02-12ARM: 5899/2: arm: provide a mechanism to reserve performance countersJamie Iles
To add support for perf events and to allow the hardware counters to be shared with oprofile, we need a way to reserve access to the pmu (performance monitor unit). Platforms with PMU interrupts should register the interrupts in arch/arm/kernel/pmu.c Signed-off-by: Jamie Iles <jamie.iles@picochip.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>