Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi <[EMAIL PROTECTED]> wrote: > I'm very annoyed and a bit surprised to hear they admitted such a big > change so easily. Why be annoyed? It's not actually a substantial change. > You and I know there are consumer devices already out running the am33 > port of the kernel. Yes, and have been for years, I suspect. > What triggered me to comment on your patch was that its directory and file > structure is very different from the ones there. There are no cpu-, proc- > and unit- directories and no names with mn103e10_* there. Things are allowed to change. > The kernels there seem to be already running on several processors, > some of which are with AM34 cores that you concern about, according to > the #ifdefs there. Yes. > > The problem is how much? I could just move all the cpu-am33v2/ files into > > the dir above, but what happens if an incompatible CPU core is introduced? > > How does your client say? MEI have agreed for me to do that. I can always undo it later if sufficiently incompatible CPU cores arise that warrant that level of segregation. David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi [EMAIL PROTECTED] wrote: I'm very annoyed and a bit surprised to hear they admitted such a big change so easily. Why be annoyed? It's not actually a substantial change. You and I know there are consumer devices already out running the am33 port of the kernel. Yes, and have been for years, I suspect. What triggered me to comment on your patch was that its directory and file structure is very different from the ones there. There are no cpu-, proc- and unit- directories and no names with mn103e10_* there. Things are allowed to change. The kernels there seem to be already running on several processors, some of which are with AM34 cores that you concern about, according to the #ifdefs there. Yes. The problem is how much? I could just move all the cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU core is introduced? How does your client say? MEI have agreed for me to do that. I can always undo it later if sufficiently incompatible CPU cores arise that warrant that level of segregation. David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Thank you for your replies. On 10/31/07, David Howells <[EMAIL PROTECTED]> wrote: > Anyway, I've discussed this with MEI, and they're willing for some flattening > to take place. I'm very annoyed and a bit surprised to hear they admitted such a big change so easily. You and I know there are consumer devices already out running the am33 port of the kernel. I guess they have some policy for the port, including the directory structure under arch/, if they have already shipped several versions of the kernel on their commercial products. If so, they would take objection to the change, partly or entirely, I think. I suspect that your port is not a version of the line of the proven, running kernels on the shipped products and that your client is not, or doesn't have contact with, the developers of the running kernels. I have taken a look at the kernels for am33 on www.am-linux.jp (*). What triggered me to comment on your patch was that its directory and file structure is very different from the ones there. There are no cpu-, proc- and unit- directories and no names with mn103e10_* there. The kernels there seem to be already running on several processors, some of which are with AM34 cores that you concern about, according to the #ifdefs there. I thought at first your port was the revised one after refactoring, but it has turned out not to be. You should let your client to discuss with all the developers concerned in the whole company. (*) Only a version of an old model is linked from the top page. Newer models appear to have their unique URIs, and there are v2.6 kernels there, too. > The problem is how much? I could just move all the > cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU > core is introduced? How does your client say? Ok, I agree it's the preparation for incompatible CPU cores. There might be no incompatible CPU core, currently, though. But I have become worried about the incompatibility with the running kernels that have no cpu/ directories. > It's an awkward situation, yes, but not one most people will be concerned > with. There needs to be some way to multiplex alternate register sets. The > main ways of doing that are: > > (1) #include hell > > (2) #ifdef hell > > (3) Both > > Which do you prefer? Do the company accept my personal preference? I prefer (2), as long as the difference is only an addition or the difference is small enough. > However, I'll concede that the various versions of AM33 processor should > perhaps be represented by the same CPU subdirectory (cpu-am33), using #ifdef > to add extra features. However, should, say, an AM34 be produced that's > effectively a variant of the AM33, then that scheme falls down too. As I said in the other thread, am33 is a reasonable name if the AM33 is the first one that is supported by the port and the AM34 and newer ones are compatible with that. > And if all asm/cpu-regs.h does is #include asm/cpu/cpu-regs.h, then what's the > point in having it? I meant if there is only an asm/cpu-regs.h and no cpu/ directory at first and later cpu-regs.h comes up in the cpu/ directories for cpu variants, you don't have to change the ``#include '' in the arch-dependent codes. cpu-regs.h may not be good for an example. Anyway, I have no doubt that your port is too immature to be merged into the upstream kernel. It doesn't mean there is any technical problem. I understand your position. -- Suzuki Takashi Japan - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Thank you for your replies. On 10/31/07, David Howells [EMAIL PROTECTED] wrote: Anyway, I've discussed this with MEI, and they're willing for some flattening to take place. I'm very annoyed and a bit surprised to hear they admitted such a big change so easily. You and I know there are consumer devices already out running the am33 port of the kernel. I guess they have some policy for the port, including the directory structure under arch/, if they have already shipped several versions of the kernel on their commercial products. If so, they would take objection to the change, partly or entirely, I think. I suspect that your port is not a version of the line of the proven, running kernels on the shipped products and that your client is not, or doesn't have contact with, the developers of the running kernels. I have taken a look at the kernels for am33 on www.am-linux.jp (*). What triggered me to comment on your patch was that its directory and file structure is very different from the ones there. There are no cpu-, proc- and unit- directories and no names with mn103e10_* there. The kernels there seem to be already running on several processors, some of which are with AM34 cores that you concern about, according to the #ifdefs there. I thought at first your port was the revised one after refactoring, but it has turned out not to be. You should let your client to discuss with all the developers concerned in the whole company. (*) Only a version of an old model is linked from the top page. Newer models appear to have their unique URIs, and there are v2.6 kernels there, too. The problem is how much? I could just move all the cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU core is introduced? How does your client say? Ok, I agree it's the preparation for incompatible CPU cores. There might be no incompatible CPU core, currently, though. But I have become worried about the incompatibility with the running kernels that have no cpu/ directories. It's an awkward situation, yes, but not one most people will be concerned with. There needs to be some way to multiplex alternate register sets. The main ways of doing that are: (1) #include hell (2) #ifdef hell (3) Both Which do you prefer? Do the company accept my personal preference? I prefer (2), as long as the difference is only an addition or the difference is small enough. However, I'll concede that the various versions of AM33 processor should perhaps be represented by the same CPU subdirectory (cpu-am33), using #ifdef to add extra features. However, should, say, an AM34 be produced that's effectively a variant of the AM33, then that scheme falls down too. As I said in the other thread, am33 is a reasonable name if the AM33 is the first one that is supported by the port and the AM34 and newer ones are compatible with that. And if all asm/cpu-regs.h does is #include asm/cpu/cpu-regs.h, then what's the point in having it? I meant if there is only an asm/cpu-regs.h and no cpu/ directory at first and later cpu-regs.h comes up in the cpu/ directories for cpu variants, you don't have to change the ``#include asm/cpu-regs.h'' in the arch-dependent codes. cpu-regs.h may not be good for an example. Anyway, I have no doubt that your port is too immature to be merged into the upstream kernel. It doesn't mean there is any technical problem. I understand your position. -- Suzuki Takashi Japan - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi <[EMAIL PROTECTED]> wrote: > But people aren't, are they? On the other hand, these particular header files are of interest to arch maintainers. If there are variances between CPUs that mandate different sets of registers or different usage protocols for equivalent modules, then you will end up with something you'll object to. Anyway, I've discussed this with MEI, and they're willing for some flattening to take place. The problem is how much? I could just move all the cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU core is introduced? > If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h, > people have to > 1) open cpu-am33v3/cpu-regs.h, > saying #include (and sigh). > 2) open cpu-am33v2/cpu-regs.h. It's an awkward situation, yes, but not one most people will be concerned with. There needs to be some way to multiplex alternate register sets. The main ways of doing that are: (1) #include hell (2) #ifdef hell (3) Both Which do you prefer? Besides, you should use emacs tags:-) However, I'll concede that the various versions of AM33 processor should perhaps be represented by the same CPU subdirectory (cpu-am33), using #ifdef to add extra features. However, should, say, an AM34 be produced that's effectively a variant of the AM33, then that scheme falls down too. > This decreases development efficiency. Like I said, it'll make very little difference to most people because few people go poking around in the arch code. > It is not too late to split into directories It is already split up into directories. > And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and > people would #include asm/cpu-regs.h for the general purpose so that > they aren't confused which is cpu-specific and which is proc-specific. I'm confused as to what you're talking about. asm/cpu-regs.h would not for general purpose at all. It would be an arch specific header file and should not be used by code outside of the arch. And if all asm/cpu-regs.h does is #include asm/cpu/cpu-regs.h, then what's the point in having it? > > > Stranger names here. > > > > How so? > > The file is under cpu/, but the names are mn103e010_* which is proc-specific. Good point. That bears moving then. David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi [EMAIL PROTECTED] wrote: But people aren't, are they? On the other hand, these particular header files are of interest to arch maintainers. If there are variances between CPUs that mandate different sets of registers or different usage protocols for equivalent modules, then you will end up with something you'll object to. Anyway, I've discussed this with MEI, and they're willing for some flattening to take place. The problem is how much? I could just move all the cpu-am33v2/ files into the dir above, but what happens if an incompatible CPU core is introduced? If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h, people have to 1) open cpu-am33v3/cpu-regs.h, saying #include asm/cpu-am33v2/cpu-regs.h (and sigh). 2) open cpu-am33v2/cpu-regs.h. It's an awkward situation, yes, but not one most people will be concerned with. There needs to be some way to multiplex alternate register sets. The main ways of doing that are: (1) #include hell (2) #ifdef hell (3) Both Which do you prefer? Besides, you should use emacs tags:-) However, I'll concede that the various versions of AM33 processor should perhaps be represented by the same CPU subdirectory (cpu-am33), using #ifdef to add extra features. However, should, say, an AM34 be produced that's effectively a variant of the AM33, then that scheme falls down too. This decreases development efficiency. Like I said, it'll make very little difference to most people because few people go poking around in the arch code. It is not too late to split into directories It is already split up into directories. And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and people would #include asm/cpu-regs.h for the general purpose so that they aren't confused which is cpu-specific and which is proc-specific. I'm confused as to what you're talking about. asm/cpu-regs.h would not for general purpose at all. It would be an arch specific header file and should not be used by code outside of the arch. And if all asm/cpu-regs.h does is #include asm/cpu/cpu-regs.h, then what's the point in having it? Stranger names here. How so? The file is under cpu/, but the names are mn103e010_* which is proc-specific. Good point. That bears moving then. David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
On 10/31/07, David Howells <[EMAIL PROTECTED]> wrote: > > Does this mean cpu-am33v3, cpu-am33v4, etc. will be created > > when a new core comes up? > > Yes. Note that the headers in a later one can 'inherit' from those of an > earlier one simply by #including that earlier one, much like archs do with > asm-generic headers. GCC is willing to include the earlier one. But people aren't, are they? If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h, people have to 1) open cpu-am33v3/cpu-regs.h, saying #include (and sigh). 2) open cpu-am33v2/cpu-regs.h. This decreases development efficiency. If there is no difference and they are all #including only headers, there is nothing but development efficiency decrease. It is not too late to split into directories only after some large difference to the earlier one comes on. And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and people would #include asm/cpu-regs.h for the general purpose so that they aren't confused which is cpu-specific and which is proc-specific. > > Isn't it possible to split codes by features, instead of target cores? > > Perhaps, but I personally am not in a position to judge what features are > common to what CPUs. I'll have to let someone from MEI answer that one. I'll > discuss it with them. Ok. I'll wait. > > Stranger names here. > > How so? The file is under cpu/, but the names are mn103e010_* which is proc-specific. -- Suzuki Takashi Japan - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi <[EMAIL PROTECTED]> wrote: > Does this mean cpu-am33v3, cpu-am33v4, etc. will be created > when a new core comes up? Yes. Note that the headers in a later one can 'inherit' from those of an earlier one simply by #including that earlier one, much like archs do with asm-generic headers. > Isn't it possible to split codes by features, instead of target cores? Perhaps, but I personally am not in a position to judge what features are common to what CPUs. I'll have to let someone from MEI answer that one. I'll discuss it with them. > If similar codes were in multiple files and directories, it would be > hard to maintain them. #include is a wonderful thing. > > +#ifdef CONFIG_MN10300_PROC_MN103E010 > > + nop > > + nop > > + nop > > +#endif > > This should be conditioned by a feature. > Isn't it a feature or a limitation that several non-FPU instructions are > necessary just after the EPSW_FE is set? Or it could just be a h/w bug in this particular processor. I can always patch it later to change the name. Whatever it is, I suspect it will always be controlled implicitly. > Are these specific to MN103E010, or applicable to some other LSIs? Yes. > If they are not specific to MN103E010, the file names aren't good. I realise that, but I haven't been able to get any better names for them. > Stranger names here. How so? David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
On 10/29/07, David Howells <[EMAIL PROTECTED]> wrote:
> diff --git a/Documentation/mn10300/compartmentalisation.txt
> b/Documentation/mn10300/compartmentalisation.txt
(snip)
> + (1) CPU level
> +
> + This involves support for a specific set of registers and instructions
> and
> + some very low-level peripherals.
> +
> + CPU-specific constants, definitions and sources are segregated by having
> + the header files divided into CPU specific directories under the asm
> + headers directory:
> +
> + (*) include/asm-mn10300/cpu-am33v2/
> +
> + Support for the AM33v2 CPU core.
> +
> + The appropriate CPU is selected by a CONFIG_MN10300_CPU_ option from
> + the "Processor core support" choice menu in the arch/mn10300/Kconfig
> file.
Does this mean cpu-am33v3, cpu-am33v4, etc. will be created
when a new core comes up?
Isn't it possible to split codes by features, instead of target cores?
If the AM33v2 is the base architecture and a new core feature comes up
on AM33v3,
that core feature should be enabled by a new CONFIG_* or a dynamic switch.
Generally, drastic changes won't come up
as long as the new CPU core is on the same architecture.
Whole directory separation would be inappropriate for the CPU cores on
the same arch.
If similar codes were in multiple files and directories, it would be
hard to maintain them.
> + (2) Processor level
> +
> + The "processor level" is a CPU core plus the other on-silicon
> + peripherals.
> +
> + Processor-specific header files are divided among directories in a
> similar
> + way to the CPU level:
> +
> + (*) include/asm-mn10300/proc-mn103e010/
> +
> + Support for the AM33v2 CPU core.
> +
> + The appropriate processor is selected by a CONFIG_MN10300_PROC_
> option
> + from the "Processor support" choice menu in the arch/mn10300/Kconfig
> file.
Ditto. Splitting by features would be better.
> diff --git a/arch/mn10300/kernel/fpu-low.S b/arch/mn10300/kernel/fpu-low.S
(snip)
> + .globl fpu_init_state
> + .type fpu_init_state,@function
> +fpu_init_state:
> + mov epsw,d0
> + or EPSW_FE,epsw
> +
> +#ifdef CONFIG_MN10300_PROC_MN103E010
> + nop
> + nop
> + nop
> +#endif
This should be conditioned by a feature.
Isn't it a feature or a limitation that several non-FPU instructions are
necessary just after the EPSW_FE is set?
> diff --git a/arch/mn10300/kernel/mn103e010-debug.c
> b/arch/mn10300/kernel/mn103e010-debug.c
(snip)
> diff --git a/arch/mn10300/kernel/mn103e010-serial-low.S
> b/arch/mn10300/kernel/mn103e010-serial-low.S
(snip)
> diff --git a/arch/mn10300/kernel/mn103e010-serial.c
> b/arch/mn10300/kernel/mn103e010-serial.c
(snip)
> diff --git a/arch/mn10300/kernel/mn103e010-serial.h
> b/arch/mn10300/kernel/mn103e010-serial.h
(snip)
> diff --git a/arch/mn10300/kernel/mn103e010-watchdog-low.S
> b/arch/mn10300/kernel/mn103e010-watchdog-low.S
(snip)
> diff --git a/arch/mn10300/kernel/mn103e010-watchdog.c
> b/arch/mn10300/kernel/mn103e010-watchdog.c
Are these specific to MN103E010, or applicable to some other LSIs?
If they are not specific to MN103E010, the file names aren't good.
> diff --git a/include/asm-mn10300/cpu-am33v2/dmactl-regs.h
> b/include/asm-mn10300/cpu-am33v2/dmactl-regs.h
(snip)
> +struct mn103e010_dmactl_regs {
> + u32 ctr;
> + const void *src;
> + void*dst;
> + u32 siz;
> + u32 cyc;
> +} __attribute__((aligned(0x100)));
> +
> +extern volatile struct mn103e010_dmactl_regs mn103e010_dmactl_regs[4];
Stranger names here.
--
Suzuki Takashi
Japan
-
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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
On 10/29/07, David Howells [EMAIL PROTECTED] wrote:
diff --git a/Documentation/mn10300/compartmentalisation.txt
b/Documentation/mn10300/compartmentalisation.txt
(snip)
+ (1) CPU level
+
+ This involves support for a specific set of registers and instructions
and
+ some very low-level peripherals.
+
+ CPU-specific constants, definitions and sources are segregated by having
+ the header files divided into CPU specific directories under the asm
+ headers directory:
+
+ (*) include/asm-mn10300/cpu-am33v2/
+
+ Support for the AM33v2 CPU core.
+
+ The appropriate CPU is selected by a CONFIG_MN10300_CPU_ option from
+ the Processor core support choice menu in the arch/mn10300/Kconfig
file.
Does this mean cpu-am33v3, cpu-am33v4, etc. will be created
when a new core comes up?
Isn't it possible to split codes by features, instead of target cores?
If the AM33v2 is the base architecture and a new core feature comes up
on AM33v3,
that core feature should be enabled by a new CONFIG_* or a dynamic switch.
Generally, drastic changes won't come up
as long as the new CPU core is on the same architecture.
Whole directory separation would be inappropriate for the CPU cores on
the same arch.
If similar codes were in multiple files and directories, it would be
hard to maintain them.
+ (2) Processor level
+
+ The processor level is a CPU core plus the other on-silicon
+ peripherals.
+
+ Processor-specific header files are divided among directories in a
similar
+ way to the CPU level:
+
+ (*) include/asm-mn10300/proc-mn103e010/
+
+ Support for the AM33v2 CPU core.
+
+ The appropriate processor is selected by a CONFIG_MN10300_PROC_
option
+ from the Processor support choice menu in the arch/mn10300/Kconfig
file.
Ditto. Splitting by features would be better.
diff --git a/arch/mn10300/kernel/fpu-low.S b/arch/mn10300/kernel/fpu-low.S
(snip)
+ .globl fpu_init_state
+ .type fpu_init_state,@function
+fpu_init_state:
+ mov epsw,d0
+ or EPSW_FE,epsw
+
+#ifdef CONFIG_MN10300_PROC_MN103E010
+ nop
+ nop
+ nop
+#endif
This should be conditioned by a feature.
Isn't it a feature or a limitation that several non-FPU instructions are
necessary just after the EPSW_FE is set?
diff --git a/arch/mn10300/kernel/mn103e010-debug.c
b/arch/mn10300/kernel/mn103e010-debug.c
(snip)
diff --git a/arch/mn10300/kernel/mn103e010-serial-low.S
b/arch/mn10300/kernel/mn103e010-serial-low.S
(snip)
diff --git a/arch/mn10300/kernel/mn103e010-serial.c
b/arch/mn10300/kernel/mn103e010-serial.c
(snip)
diff --git a/arch/mn10300/kernel/mn103e010-serial.h
b/arch/mn10300/kernel/mn103e010-serial.h
(snip)
diff --git a/arch/mn10300/kernel/mn103e010-watchdog-low.S
b/arch/mn10300/kernel/mn103e010-watchdog-low.S
(snip)
diff --git a/arch/mn10300/kernel/mn103e010-watchdog.c
b/arch/mn10300/kernel/mn103e010-watchdog.c
Are these specific to MN103E010, or applicable to some other LSIs?
If they are not specific to MN103E010, the file names aren't good.
diff --git a/include/asm-mn10300/cpu-am33v2/dmactl-regs.h
b/include/asm-mn10300/cpu-am33v2/dmactl-regs.h
(snip)
+struct mn103e010_dmactl_regs {
+ u32 ctr;
+ const void *src;
+ void*dst;
+ u32 siz;
+ u32 cyc;
+} __attribute__((aligned(0x100)));
+
+extern volatile struct mn103e010_dmactl_regs mn103e010_dmactl_regs[4];
Stranger names here.
--
Suzuki Takashi
Japan
-
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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
Suzuki Takashi [EMAIL PROTECTED] wrote: Does this mean cpu-am33v3, cpu-am33v4, etc. will be created when a new core comes up? Yes. Note that the headers in a later one can 'inherit' from those of an earlier one simply by #including that earlier one, much like archs do with asm-generic headers. Isn't it possible to split codes by features, instead of target cores? Perhaps, but I personally am not in a position to judge what features are common to what CPUs. I'll have to let someone from MEI answer that one. I'll discuss it with them. If similar codes were in multiple files and directories, it would be hard to maintain them. #include is a wonderful thing. +#ifdef CONFIG_MN10300_PROC_MN103E010 + nop + nop + nop +#endif This should be conditioned by a feature. Isn't it a feature or a limitation that several non-FPU instructions are necessary just after the EPSW_FE is set? Or it could just be a h/w bug in this particular processor. I can always patch it later to change the name. Whatever it is, I suspect it will always be controlled implicitly. Are these specific to MN103E010, or applicable to some other LSIs? Yes. If they are not specific to MN103E010, the file names aren't good. I realise that, but I haven't been able to get any better names for them. Stranger names here. How so? David - 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/
Re: [Linux-am33-list] [PATCH 2/2] MN10300: Add the MN10300/AM33 architecture to the kernel [try #2]
On 10/31/07, David Howells [EMAIL PROTECTED] wrote: Does this mean cpu-am33v3, cpu-am33v4, etc. will be created when a new core comes up? Yes. Note that the headers in a later one can 'inherit' from those of an earlier one simply by #including that earlier one, much like archs do with asm-generic headers. GCC is willing to include the earlier one. But people aren't, are they? If cpu-am33v3/cpu-regs.h #includes cpu-am33v2/cpu-regs.h, people have to 1) open cpu-am33v3/cpu-regs.h, saying #include asm/cpu-am33v2/cpu-regs.h (and sigh). 2) open cpu-am33v2/cpu-regs.h. This decreases development efficiency. If there is no difference and they are all #including only headers, there is nothing but development efficiency decrease. It is not too late to split into directories only after some large difference to the earlier one comes on. And at that time asm/cpu-regs.h should #include cpu/cpu-regs.h and people would #include asm/cpu-regs.h for the general purpose so that they aren't confused which is cpu-specific and which is proc-specific. Isn't it possible to split codes by features, instead of target cores? Perhaps, but I personally am not in a position to judge what features are common to what CPUs. I'll have to let someone from MEI answer that one. I'll discuss it with them. Ok. I'll wait. Stranger names here. How so? The file is under cpu/, but the names are mn103e010_* which is proc-specific. -- Suzuki Takashi Japan - 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/
