This patch restores the blackfin Hardware Performance Monitor Profiling
support that was killed by
commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
Since there seems to be no good reason to behave differently from other
architectures, it now automatically selects the hardware performance counters
whenever the profiling is activated.
mach-common/irqpanic.c: pm_overflow
calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt that
setting HARDWARE_PM as "m" will work at all, since the pm_overflow_handler
should be in the core kernel image because it is called by irqpanic.c.
Therefore, I change HARDWARE_PM from a tristate to a bool.
The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since
part of the HARDWARE_PM support files sits in this directory, it makes sense to
also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on
PROFILING, it is correct to only depend on OPROFILE only.
Thanks to Adrian Bunk for finding this bug and providing an initial
patch.
Signed-off-by: Mathieu Desnoyers <[email protected]>
CC: Linus Torvalds <[email protected]>
CC: Adrian Bunk <[email protected]>
CC: Randy Dunlap <[email protected]>
CC: [email protected]
CC: Robin Getz <[email protected]>
---
arch/blackfin/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6-lttng/arch/blackfin/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-12-29 11:00:05.000000000 -0500
+++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-12-29 11:25:39.000000000 -0500
@@ -65,6 +65,10 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
+config HARDWARE_PM
+ def_bool y
+ depends on OPROFILE
+
source "init/Kconfig"
source "kernel/Kconfig.preempt"
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
On Tue 15 Jan 2008 12:42, Mathieu Desnoyers pondered:
> This patch restores the blackfin Hardware Performance Monitor Profiling
> support that was killed by
> commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
>
> Since there seems to be no good reason to behave differently from other
> architectures, it now automatically selects the hardware performance
> counters whenever the profiling is activated.
>
> mach-common/irqpanic.c: pm_overflow
> calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt
> that setting HARDWARE_PM as "m" will work at all, since the
> pm_overflow_handler should be in the core kernel image because it is
> called by irqpanic.c.
>
> Therefore, I change HARDWARE_PM from a tristate to a bool.
>
> The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE.
> Since part of the HARDWARE_PM support files sits in this directory, it makes
> sense to also depend on OPROFILE, not only PROFILING. Since OPROFILE already
> depends on PROFILING, it is correct to only depend on OPROFILE only.
>
> Thanks to Adrian Bunk for finding this bug and providing an initial
> patch.
>
> Signed-off-by: Mathieu Desnoyers <[email protected]>
> CC: Linus Torvalds <[email protected]>
> CC: Adrian Bunk <[email protected]>
> CC: Randy Dunlap <[email protected]>
> CC: [email protected]
> CC: Robin Getz <[email protected]>
Acked-by: Robin Getz <[email protected]>
> ---
> arch/blackfin/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> Index: linux-2.6-lttng/arch/blackfin/Kconfig
> ===================================================================
> --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-12-29
> 11:00:05.000000000 -0500
> +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-12-29
> 11:25:39.000000000 -0500
> @@ -65,6 +65,10 @@ config GENERIC_CALIBRATE_DELAY
> bool
> default y
>
> +config HARDWARE_PM
> + def_bool y
> + depends on OPROFILE
> +
> source "init/Kconfig"
> source "kernel/Kconfig.preempt"
>
>
>
On Jan 16, 2008 1:42 AM, Mathieu Desnoyers <[email protected]> wrote:
> This patch restores the blackfin Hardware Performance Monitor Profiling
> support that was killed by
> commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
>
> Since there seems to be no good reason to behave differently from other
> architectures, it now automatically selects the hardware performance counters
> whenever the profiling is activated.
>
> mach-common/irqpanic.c: pm_overflow
> calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt that
> setting HARDWARE_PM as "m" will work at all, since the pm_overflow_handler
> should be in the core kernel image because it is called by irqpanic.c.
>
> Therefore, I change HARDWARE_PM from a tristate to a bool.
>
> The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since
> part of the HARDWARE_PM support files sits in this directory, it makes sense to
> also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on
> PROFILING, it is correct to only depend on OPROFILE only.
>
> Thanks to Adrian Bunk for finding this bug and providing an initial
> patch.
>
> Signed-off-by: Mathieu Desnoyers <[email protected]>
> CC: Linus Torvalds <[email protected]>
> CC: Adrian Bunk <[email protected]>
> CC: Randy Dunlap <[email protected]>
> CC: [email protected]
> CC: Robin Getz <[email protected]>
> ---
Thanks, finally we got this.
Acked-by: Bryan Wu <[email protected]>
> arch/blackfin/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> Index: linux-2.6-lttng/arch/blackfin/Kconfig
> ===================================================================
> --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-12-29 11:00:05.000000000 -0500
> +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-12-29 11:25:39.000000000 -0500
> @@ -65,6 +65,10 @@ config GENERIC_CALIBRATE_DELAY
> bool
> default y
>
> +config HARDWARE_PM
> + def_bool y
> + depends on OPROFILE
> +
> source "init/Kconfig"
> source "kernel/Kconfig.preempt"
>
>
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>