* [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y
@ 2006-10-26 6:43 Vitaly Wool
2006-10-26 13:57 ` Kumar Gala
0 siblings, 1 reply; 5+ messages in thread
From: Vitaly Wool @ 2006-10-26 6:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: oprofile-list, linuxppc-embedded
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 <vwool@ru.mvista.com>
Index: linux-2.6.18/arch/powerpc/oprofile/Makefile
===================================================================
--- linux-2.6.18.orig/arch/powerpc/oprofile/Makefile
+++ linux-2.6.18/arch/powerpc/oprofile/Makefile
@@ -13,4 +13,4 @@ DRIVER_OBJS := $(addprefix ../../../driv
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_PPC64) += op_model_rs64.o op_model_power4.o
oprofile-$(CONFIG_FSL_BOOKE) += op_model_fsl_booke.o
-oprofile-$(CONFIG_PPC32) += op_model_7450.o
+oprofile-$(CONFIG_6XX) += op_model_7450.o
Index: linux-2.6.18/arch/powerpc/oprofile/common.c
===================================================================
--- linux-2.6.18.orig/arch/powerpc/oprofile/common.c
+++ linux-2.6.18/arch/powerpc/oprofile/common.c
@@ -135,19 +135,18 @@ int __init oprofile_arch_init(struct opr
return -ENODEV;
switch (cur_cpu_spec->oprofile_type) {
-#ifdef CONFIG_PPC64
+#if defined(CONFIG_PPC64)
case PPC_OPROFILE_RS64:
model = &op_model_rs64;
break;
case PPC_OPROFILE_POWER4:
model = &op_model_power4;
break;
-#else
+#elif defined (CONFIG_6XX)
case PPC_OPROFILE_G4:
model = &op_model_7450;
break;
-#endif
-#ifdef CONFIG_FSL_BOOKE
+#elif defined (CONFIG_FSL_BOOKE)
case PPC_OPROFILE_BOOKE:
model = &op_model_fsl_booke;
break;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y
2006-10-26 6:43 [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y Vitaly Wool
@ 2006-10-26 13:57 ` Kumar Gala
2006-10-26 20:26 ` Vitaly Wool
0 siblings, 1 reply; 5+ messages in thread
From: Kumar Gala @ 2006-10-26 13:57 UTC (permalink / raw)
To: Vitaly Wool
Cc: linuxppc-dev list, oprofile-list,
linuxppc-embedded ((((E-Mail))))
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 <vwool@ru.mvista.com>
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
>
> Index: linux-2.6.18/arch/powerpc/oprofile/Makefile
> ===================================================================
> --- linux-2.6.18.orig/arch/powerpc/oprofile/Makefile
> +++ linux-2.6.18/arch/powerpc/oprofile/Makefile
> @@ -13,4 +13,4 @@ DRIVER_OBJS := $(addprefix ../../../driv
> oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
> oprofile-$(CONFIG_PPC64) += op_model_rs64.o op_model_power4.o
> oprofile-$(CONFIG_FSL_BOOKE) += op_model_fsl_booke.o
> -oprofile-$(CONFIG_PPC32) += op_model_7450.o
> +oprofile-$(CONFIG_6XX) += op_model_7450.o
> Index: linux-2.6.18/arch/powerpc/oprofile/common.c
> ===================================================================
> --- linux-2.6.18.orig/arch/powerpc/oprofile/common.c
> +++ linux-2.6.18/arch/powerpc/oprofile/common.c
> @@ -135,19 +135,18 @@ int __init oprofile_arch_init(struct opr
> return -ENODEV;
>
> switch (cur_cpu_spec->oprofile_type) {
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64)
> case PPC_OPROFILE_RS64:
> model = &op_model_rs64;
> break;
> case PPC_OPROFILE_POWER4:
> model = &op_model_power4;
> break;
> -#else
> +#elif defined (CONFIG_6XX)
> case PPC_OPROFILE_G4:
> model = &op_model_7450;
> break;
> -#endif
> -#ifdef CONFIG_FSL_BOOKE
> +#elif defined (CONFIG_FSL_BOOKE)
> case PPC_OPROFILE_BOOKE:
> model = &op_model_fsl_booke;
> break;
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y
2006-10-26 13:57 ` Kumar Gala
@ 2006-10-26 20:26 ` Vitaly Wool
2006-10-26 20:32 ` Sergei Shtylyov
0 siblings, 1 reply; 5+ messages in thread
From: Vitaly Wool @ 2006-10-26 20:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, oprofile-list
Hello Kumar,
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y
2006-10-26 20:26 ` Vitaly Wool
@ 2006-10-26 20:32 ` Sergei Shtylyov
2006-10-27 20:03 ` Andy Fleming
0 siblings, 1 reply; 5+ messages in thread
From: Sergei Shtylyov @ 2006-10-26 20:32 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linuxppc-dev list, oprofile-list
Hello.
Vitaly Wool wrote:
> Hello Kumar,
>>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 :)
The most funny/stupd thing is that the patch existed since May but it never
went in:
http://patchwork.ozlabs.org/linuxppc/patch?id=5531
> Thanks,
> Vitaly
WBR, Sergei
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y
2006-10-26 20:32 ` Sergei Shtylyov
@ 2006-10-27 20:03 ` Andy Fleming
0 siblings, 0 replies; 5+ messages in thread
From: Andy Fleming @ 2006-10-27 20:03 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev list, Vitaly Wool, oprofile-list
On Oct 26, 2006, at 15:32, Sergei Shtylyov wrote:
> Hello.
>
> Vitaly Wool wrote:
>> Hello Kumar,
>
>>> 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 :)
>
> The most funny/stupd thing is that the patch existed since May
> but it never
> went in:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=5531
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.
>
>> Thanks,
>> Vitaly
>
> WBR, Sergei
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-27 20:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-26 6:43 [1/2] build failure for E500 CPUs w/ CONFIG_OPROFLE=y Vitaly Wool
2006-10-26 13:57 ` Kumar Gala
2006-10-26 20:26 ` Vitaly Wool
2006-10-26 20:32 ` Sergei Shtylyov
2006-10-27 20:03 ` Andy Fleming
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).