Below is the patch for the problem described in "[0/2] build failure for 8540 w/ CONFIG_OPROFLE=y" letter representing the first approach. This approach is based on (pretty reasonable) assumption that op_model_7450.c is applicable only to 6XX, so let's compile it only when CONFIG_6XX==y. This results in more #ifdef's in arch/powerpc/oprofile/common.c, which doesn't look good to me. I'd rather "switch (cur_cpu_spec->oprofile_type) ..." to SoC-dependent header files arranging that one as static inline func...
Anyway, here's the patch.
arch/powerpc/oprofile/Makefile | 2 +-
arch/powerpc/oprofile/common.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
Signed-off-by: Vitaly Wool <redacted>
Index: linux-2.6.18/arch/powerpc/oprofile/Makefile
===================================================================
@@ -135,19 +135,18 @@ int __init oprofile_arch_init(struct oprreturn-ENODEV;switch(cur_cpu_spec->oprofile_type){-#ifdef CONFIG_PPC64+#if defined(CONFIG_PPC64)casePPC_OPROFILE_RS64:model=&op_model_rs64;break;casePPC_OPROFILE_POWER4:model=&op_model_power4;break;-#else+#elif defined (CONFIG_6XX)casePPC_OPROFILE_G4:model=&op_model_7450;break;-#endif-#ifdef CONFIG_FSL_BOOKE+#elif defined (CONFIG_FSL_BOOKE)casePPC_OPROFILE_BOOKE:model=&op_model_fsl_booke;break;
From: Kumar Gala <hidden> Date: 2006-10-26 13:57:59
On Oct 26, 2006, at 1:43 AM, Vitaly Wool wrote:
Below is the patch for the problem described in "[0/2] build
failure for 8540 w/ CONFIG_OPROFLE=y" letter representing the first
approach. This approach is based on (pretty reasonable) assumption
that op_model_7450.c is applicable only to 6XX, so let's compile it
only when CONFIG_6XX==y. This results in more #ifdef's in arch/
powerpc/oprofile/common.c, which doesn't look good to me. I'd
rather "switch (cur_cpu_spec->oprofile_type) ..." to SoC-dependent
header files arranging that one as static inline func...
Anyway, here's the patch.
arch/powerpc/oprofile/Makefile | 2 +-
arch/powerpc/oprofile/common.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
Signed-off-by: Vitaly Wool <redacted>
This makes sense to me since we are just increasing kernel code size
for code we would never use for an FSL_BOOKE part if we do it the
other way. I dont think its that much more messy with the ifdef's.
If you want to do the other cleanup as well I've got no issue with
that, but we really should NOT build in support for 7450 into a
FSL_BOOKE kernel when reasonably avoidable.
- kumar
@@ -135,19 +135,18 @@ int __init oprofile_arch_init(struct oprreturn-ENODEV;switch(cur_cpu_spec->oprofile_type){-#ifdef CONFIG_PPC64+#if defined(CONFIG_PPC64)casePPC_OPROFILE_RS64:model=&op_model_rs64;break;casePPC_OPROFILE_POWER4:model=&op_model_power4;break;-#else+#elif defined (CONFIG_6XX)casePPC_OPROFILE_G4:model=&op_model_7450;break;-#endif-#ifdef CONFIG_FSL_BOOKE+#elif defined (CONFIG_FSL_BOOKE)casePPC_OPROFILE_BOOKE:model=&op_model_fsl_booke;break;
This makes sense to me since we are just increasing kernel code size
for code we would never use for an FSL_BOOKE part if we do it the
other way. I dont think its that much more messy with the ifdef's.
Okay, if you're fine with this patch, is it possible that you include it
into your tree?
If you want to do the other cleanup as well I've got no issue with
that, but we really should NOT build in support for 7450 into a
FSL_BOOKE kernel when reasonably avoidable.
That's fine with me.
As of the cleanups, well... looks to me some more patches will follow
soon, kinda bugfixing ones rather than cleanups first :)
Thanks,
Vitaly
From: Sergei Shtylyov <hidden> Date: 2006-10-26 20:32:25
Hello.
Vitaly Wool wrote:
Hello Kumar,
quoted
This makes sense to me since we are just increasing kernel code size
for code we would never use for an FSL_BOOKE part if we do it the
other way. I dont think its that much more messy with the ifdef's.
Okay, if you're fine with this patch, is it possible that you include it
into your tree?
quoted
If you want to do the other cleanup as well I've got no issue with
that, but we really should NOT build in support for 7450 into a
FSL_BOOKE kernel when reasonably avoidable.
That's fine with me.
As of the cleanups, well... looks to me some more patches will follow
soon, kinda bugfixing ones rather than cleanups first :)
From: Andy Fleming <hidden> Date: 2006-10-27 20:03:59
On Oct 26, 2006, at 15:32, Sergei Shtylyov wrote:
Hello.
Vitaly Wool wrote:
quoted
Hello Kumar,
quoted
quoted
This makes sense to me since we are just increasing kernel code size
for code we would never use for an FSL_BOOKE part if we do it the
other way. I dont think its that much more messy with the ifdef's.
quoted
Okay, if you're fine with this patch, is it possible that you
include it
into your tree?
quoted
quoted
If you want to do the other cleanup as well I've got no issue with
that, but we really should NOT build in support for 7450 into a
FSL_BOOKE kernel when reasonably avoidable.
quoted
That's fine with me.
As of the cleanups, well... looks to me some more patches will follow
soon, kinda bugfixing ones rather than cleanups first :)
Yeah, I guess it got lost. After looking at both patches, I see the
different approaches. I think I'd vote for the older patch, since it
also solves some SMP issues that will crop up when the dual-core 8572
comes out. In fact, it's similar to this patch: http://
patchwork.ozlabs.org/linuxppc/patch?id=4012
Oi. Ok, I'm going to update and resend that patch in just a second
(Ok, this took longer than I thought, due to the lwsync patch I sent
out being required). I like Vitaly's patch, but the one I sent
cleans up some early design mistakes I made in the original ppc32
oprofile code.