| Message ID | 1400232598.20342.16.camel@x220 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 16, 2014 at 11:29:58AM +0200, Paul Bolle wrote: > Support for ARM710 CPUs was removed in v3.5. But a few lines of ARM710 > specific assembler code were left in the tree. Remove these too. > > Signed-off-by: Paul Bolle <pebolle@tiscali.nl> > --- > This minor cleanup was suggested by Arnd. This patch is mostly > guesswork, as I already told Arnd, since I have never touched ARM > assembler before (as far as I can remember). Untested too! And this does > need testing. NAK. There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. These are two completely different CPUs, the former was removed along with the removal of ARMv3 support. The latter remains because we still support ARMv4. This is a nice instance of arm-soc people thinking that they are somehow authoritive for core ARM stuff...
On Fri, 2014-05-16 at 13:55 +0100, Russell King - ARM Linux wrote: > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. > > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. > > These are two completely different CPUs, the former was removed along with > the removal of ARMv3 support. The latter remains because we still support > ARMv4. Thanks for taking the time to explain this. Next time I hope to be more aware of the possibility of important differences between ARM CPUs that have rather similar names. Paul Bolle
On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. > > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. > > These are two completely different CPUs, the former was removed along with > the removal of ARMv3 support. The latter remains because we still support > ARMv4. BTW, while clearly this patch was removing code for the wrong reasons, I think we should set a longer term timeline for getting rid of some of old features. Let's say in 10 years time we remove everything ARMv4, another 10 years ARMv5 and so on. We could make these milestones shorter but it really depends on what people use, we should not force them out of the kernel if still in use. We can start with ARM core and SoC code that we suspect people haven't used in a while (or at least not with mainline). We should not remove them straight away but give some advanced warning. My proposal is to add a CONFIG_DEPRECATED option and update it with a 2 year cadence. Code that we want to remove will depend on DEPRECATED and explicitly not covered by defconfig. This way we can get interested parties sending patches to remove the DEPRECATED dependency. Something like this: config DEPRECATED bool "Enable deprecated kernel features" help Kernel features no longer in use are marked as DEPRECATED for two years and removed at the end of this period. This option should only be enabled explicitly and must not be included in defconfig files. If you think a DEPRECATED kernel feature is still needed, please contact the corresponding maintainers to remove the DEPRECATED dependency. The next scheduled DEPRECATED code removal is planned for 2016. It would be even better if we make such option across the whole kernel, especially since we have significant ARM SoC code into drivers. Otherwise calling it ARM_DEPRECATED would work as well.
On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote: > On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: > > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. > > > > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. > > > > These are two completely different CPUs, the former was removed along with > > the removal of ARMv3 support. The latter remains because we still support > > ARMv4. > > BTW, while clearly this patch was removing code for the wrong reasons, I > think we should set a longer term timeline for getting rid of some of > old features. Let's say in 10 years time we remove everything ARMv4, > another 10 years ARMv5 and so on. We could make these milestones shorter > but it really depends on what people use, we should not force them out > of the kernel if still in use. I still use StrongARM based machines here, and I don't see that changing unless some suitably designed ARM boards come my way which (a) offer the same features and (b) out perform it. The problem is that there's lots of ARM boards which satisfy (b) - the iMX6 stuff clearly does - but hardly anything which satisfies (a). There's also been some recent effort with SA1100 SoC code, so there's also other interest there still. So, ARMv4 is still very much in use with modern kernels. The difference between what you're proposing and what happened to ARMv3 is that ARMv3 was broken for quite some time (we read from some of the CP15 registers which are read-only in ARMv3) and no one ever raised a problem with that. So, after a sufficient period of time, it got removed - and no one batted an eyelid. That's the correct way to do it - allow code to age, and if no one notices it's been broken, then it can be removed. That process is slightly broken by the automated build testing we now have (provided people are looking at the results.)
On 17 May 2014, at 10:46, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote: >> On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: >>> There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. >>> >>> There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. >>> >>> These are two completely different CPUs, the former was removed along with >>> the removal of ARMv3 support. The latter remains because we still support >>> ARMv4. >> >> BTW, while clearly this patch was removing code for the wrong reasons, I >> think we should set a longer term timeline for getting rid of some of >> old features. Let's say in 10 years time we remove everything ARMv4, >> another 10 years ARMv5 and so on. We could make these milestones shorter >> but it really depends on what people use, we should not force them out >> of the kernel if still in use. > > I still use StrongARM based machines here, and I don't see that changing > unless some suitably designed ARM boards come my way which (a) offer the > same features and (b) out perform it. > > The problem is that there's lots of ARM boards which satisfy (b) - the > iMX6 stuff clearly does - but hardly anything which satisfies (a). > > There's also been some recent effort with SA1100 SoC code, so there's > also other interest there still. > > So, ARMv4 is still very much in use with modern kernels. That’s why I said maybe aim for removing it in 10 year. But if code is still in use by that time, we keep it. > The difference between what you're proposing and what happened to ARMv3 > is that ARMv3 was broken for quite some time (we read from some of the > CP15 registers which are read-only in ARMv3) and no one ever raised a > problem with that. So, after a sufficient period of time, it got removed > - and no one batted an eyelid. That's the correct way to do it - allow > code to age, and if no one notices it's been broken, then it can be > removed. I’m more for pro-actively “breaking” it with a DEPRECATED dependency. For example, if you suspect that some code like ARM710T is no longer in use, we mark it and see if anyone complains about this over a two years period. If not, it gets removed. Waiting for code to get broken is another way but it’s less predictable. Catalin
On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote: > > The difference between what you're proposing and what happened to ARMv3 > > is that ARMv3 was broken for quite some time (we read from some of the > > CP15 registers which are read-only in ARMv3) and no one ever raised a > > problem with that. So, after a sufficient period of time, it got removed > > - and no one batted an eyelid. That's the correct way to do it - allow > > code to age, and if no one notices it's been broken, then it can be > > removed. > > I’m more for pro-actively “breaking” it with a DEPRECATED > dependency. For example, if you suspect that some code like ARM710T is > no longer in use, we mark it and see if anyone complains about this over > a two years period. If not, it gets removed. > > Waiting for code to get broken is another way but it’s less > predictable. When code being used gets broken, it's nice to think that we'll get bug reports which will tell us if it's still being used. The problem with DEPRECATED is that it will get lost amongst all the thousands of other config options and won't be noticed. Just like EXPERIMENTAL or any of the other similar options we've had.
On Sat, May 17, 2014 at 11:26:38AM +0100, Russell King - ARM Linux wrote: > On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote: > > > The difference between what you're proposing and what happened to ARMv3 > > > is that ARMv3 was broken for quite some time (we read from some of the > > > CP15 registers which are read-only in ARMv3) and no one ever raised a > > > problem with that. So, after a sufficient period of time, it got removed > > > - and no one batted an eyelid. That's the correct way to do it - allow > > > code to age, and if no one notices it's been broken, then it can be > > > removed. > > > > I’m more for pro-actively “breaking” it with a DEPRECATED > > dependency. For example, if you suspect that some code like ARM710T is > > no longer in use, we mark it and see if anyone complains about this over > > a two years period. If not, it gets removed. > > > > Waiting for code to get broken is another way but it’s less > > predictable. > > When code being used gets broken, it's nice to think that we'll get > bug reports which will tell us if it's still being used. But if you don't get any reports, you can't really whether it's broken (just because it compiles doesn't mean it still works). So we end up with keeping code in the kernel for much longer than necessary. > The problem > with DEPRECATED is that it will get lost amongst all the thousands > of other config options and won't be noticed. Just like EXPERIMENTAL > or any of the other similar options we've had. DEPRECATED is meant for documenting the planned removal. If people complain afterwards, it's their problem for not reporting it earlier. But we can make it even clearer by adding "depends on n" for DEPRECATED or just making it not user selectable, so that people would need to actively change the Kconfig source. They can't complain they haven't noticed.
On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote: > > The difference between what you're proposing and what happened to ARMv3 > > is that ARMv3 was broken for quite some time (we read from some of the > > CP15 registers which are read-only in ARMv3) and no one ever raised a > > problem with that. So, after a sufficient period of time, it got removed > > - and no one batted an eyelid. That's the correct way to do it - allow > > code to age, and if no one notices it's been broken, then it can be > > removed. > > I’m more for pro-actively “breaking” it with a DEPRECATED > dependency. For example, if you suspect that some code like ARM710T is > no longer in use, we mark it and see if anyone complains about this over > a two years period. If not, it gets removed. > > Waiting for code to get broken is another way but it’s less > predictable. We used to have 'feature-removal-schedule.txt' file in the Documentation. It never worked, and I don't see a reason to introduce something like that again. Yes, this means we will keep going through things that may or may not be considered obsolete occasionally asking whether it's already dead. There are a number of platforms we removed in the past years (e.g. shark, h720x, bcmring, pnx4008, ixp2xxx, tcc8k and others before) and we haven't had to revert any of those back. The rule has always been that even if someone later comes and wants them back, we will revert the removal. Others have been given temporary (e.g. gemini) or permanent (e.g. ixp4xx) extensions, based on the feedback from the maintainers or remaining users. For the case of ARM710T, I think the last remaining user that can be configured is mach-integrator, but I don't know if anybody even has that CPU tile, or wants to keep using it. If Russell and Linus as the only people that have cared about Integrator in the past years want to cut down the number of supported CPUs, that would be a different matter: quite a number of CPUs are not supported in any other platform. Note that the integrator target in qemu does not support any ARM7, only StrongARM, ARM9 or later. I also double-checked about mach-clps711x, but I'm pretty sure those SoCs are all either ARM710a (no longer supported) or ARM720T (quite active). Arnd
> old features. Let's say in 10 years time we remove everything ARMv4, > another 10 years ARMv5 and so on. We could make these milestones shorter > but it really depends on what people use, we should not force them out > of the kernel if still in use. Why do you care ? Worry about it at the point nobody can remember needing the support, or when it creates some horrible situation that is painful to keep supporting and nobody seems to care. We've only recently dropped 80386 support, and we still support MC68000. Or just wait until 2038 approaches and the 32bit panic stations begins, then clean out 8) Alan
* Arnd Bergmann <arnd@arndb.de> [140519 04:27]: > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote: > > For the case of ARM710T, I think the last remaining user that can be > configured is mach-integrator, but I don't know if anybody even has that > CPU tile, or wants to keep using it. If Russell and Linus as the only > people that have cared about Integrator in the past years want to > cut down the number of supported CPUs, that would be a different matter: > quite a number of CPUs are not supported in any other platform. > Note that the integrator target in qemu does not support any ARM7, only > StrongARM, ARM9 or later. I also double-checked about mach-clps711x, > but I'm pretty sure those SoCs are all either ARM710a (no longer supported) > or ARM720T (quite active). Hmm I don't think mach-integrator is using ARM710T? The ARM710T was done by NEC and was used by the Psion MX hardware. It's very close to ARM720T as far as I remember so might as well keep the CPU support for it as that's just a few lines of code in the mainline kernel. I don't think we have any mach directories using ARM710T, but I would not be surprised if somebody comes along with device tree based booting patches for Psion MX at some point. Regards, Tony
On Tue, May 20, 2014 at 04:48:19PM +0100, One Thousand Gnomes wrote: > > old features. Let's say in 10 years time we remove everything ARMv4, > > another 10 years ARMv5 and so on. We could make these milestones shorter > > but it really depends on what people use, we should not force them out > > of the kernel if still in use. > > Why do you care ? For now, just some negative diffstats in the arm tree ;). Longer term, supporting only ARMv6+ could bring further core arm code clean-up but that's not planned for another ~20 years. > Worry about it at the point nobody can remember needing > the support, or when it creates some horrible situation that is painful > to keep supporting and nobody seems to care. We've only recently dropped > 80386 support, and we still support MC68000. It's not necessarily how far back we go but rather the wide variation in ARM processors implementation, especially for the older architecture versions, and not knowing whether the code still works since no-one seems to remember having such hardware. > Or just wait until 2038 approaches and the 32bit panic stations begins, > then clean out 8) This kind of matches my proposal to remove ARMv5 support in 20 years (though we still keep ARMv6 and ARMv7 with 32-bit). Anyway, the feedback seems to be that we keep them around until they can no longer be supported (which probably means compiled).
On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote: > * Arnd Bergmann <arnd@arndb.de> [140519 04:27]: > > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote: > > > > For the case of ARM710T, I think the last remaining user that can be > > configured is mach-integrator, but I don't know if anybody even has that > > CPU tile, or wants to keep using it. If Russell and Linus as the only > > people that have cared about Integrator in the past years want to > > cut down the number of supported CPUs, that would be a different matter: > > quite a number of CPUs are not supported in any other platform. > > Note that the integrator target in qemu does not support any ARM7, only > > StrongARM, ARM9 or later. I also double-checked about mach-clps711x, > > but I'm pretty sure those SoCs are all either ARM710a (no longer supported) > > or ARM720T (quite active). > > Hmm I don't think mach-integrator is using ARM710T? I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator. Without any further information, I assumed that both might potentially be used. > The ARM710T was done by NEC and was used by the Psion MX hardware. > It's very close to ARM720T as far as I remember so might as well keep > the CPU support for it as that's just a few lines of code in the > mainline kernel. > > I don't think we have any mach directories using ARM710T, but I > would not be surprised if somebody comes along with device tree > based booting patches for Psion MX at some point. Of course, if someone does this, the CPU support would be the least of their work ;-) Just out of curiosity: was that NEC 710T a SoC that replaced the CL/PS7110, or a standalone CPU that Psion combined with a custom ASIC? Arnd
* Arnd Bergmann <arnd@arndb.de> [140520 13:10]: > On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote: > > * Arnd Bergmann <arnd@arndb.de> [140519 04:27]: > > > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote: > > > > > > For the case of ARM710T, I think the last remaining user that can be > > > configured is mach-integrator, but I don't know if anybody even has that > > > CPU tile, or wants to keep using it. If Russell and Linus as the only > > > people that have cared about Integrator in the past years want to > > > cut down the number of supported CPUs, that would be a different matter: > > > quite a number of CPUs are not supported in any other platform. > > > Note that the integrator target in qemu does not support any ARM7, only > > > StrongARM, ARM9 or later. I also double-checked about mach-clps711x, > > > but I'm pretty sure those SoCs are all either ARM710a (no longer supported) > > > or ARM720T (quite active). > > > > Hmm I don't think mach-integrator is using ARM710T? > > I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T > use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator. > Without any further information, I assumed that both might potentially be used. > > > The ARM710T was done by NEC and was used by the Psion MX hardware. > > It's very close to ARM720T as far as I remember so might as well keep > > the CPU support for it as that's just a few lines of code in the > > mainline kernel. > > > > I don't think we have any mach directories using ARM710T, but I > > would not be surprised if somebody comes along with device tree > > based booting patches for Psion MX at some point. > > Of course, if someone does this, the CPU support would be the least > of their work ;-) Right :) > Just out of curiosity: was that NEC 710T a SoC that replaced the > CL/PS7110, or a standalone CPU that Psion combined with a custom > ASIC? I think 710T was a pin compatible clone of CL/PS7110 by NEC. The device registers were different both from CL/PS7110 and 720T for most part. Regards, Tony
* Tony Lindgren <tony@atomide.com> [140522 11:41]: > * Arnd Bergmann <arnd@arndb.de> [140520 13:10]: > > On Tuesday 20 May 2014 09:05:13 Tony Lindgren wrote: > > > * Arnd Bergmann <arnd@arndb.de> [140519 04:27]: > > > > On Saturday 17 May 2014 10:56:02 Catalin Marinas wrote: > > > > > > > > For the case of ARM710T, I think the last remaining user that can be > > > > configured is mach-integrator, but I don't know if anybody even has that > > > > CPU tile, or wants to keep using it. If Russell and Linus as the only > > > > people that have cared about Integrator in the past years want to > > > > cut down the number of supported CPUs, that would be a different matter: > > > > quite a number of CPUs are not supported in any other platform. > > > > Note that the integrator target in qemu does not support any ARM7, only > > > > StrongARM, ARM9 or later. I also double-checked about mach-clps711x, > > > > but I'm pretty sure those SoCs are all either ARM710a (no longer supported) > > > > or ARM720T (quite active). > > > > > > Hmm I don't think mach-integrator is using ARM710T? > > > > I don't know, we don't have a separate Kconfig option, so ARM710T and ARM720T > > use the same CONFIG_CPU_ARM720T symbol that can be enabled for integrator. > > Without any further information, I assumed that both might potentially be used. > > > > > The ARM710T was done by NEC and was used by the Psion MX hardware. > > > It's very close to ARM720T as far as I remember so might as well keep > > > the CPU support for it as that's just a few lines of code in the > > > mainline kernel. > > > > > > I don't think we have any mach directories using ARM710T, but I > > > would not be surprised if somebody comes along with device tree > > > based booting patches for Psion MX at some point. > > > > Of course, if someone does this, the CPU support would be the least > > of their work ;-) > > Right :) > > > Just out of curiosity: was that NEC 710T a SoC that replaced the > > CL/PS7110, or a standalone CPU that Psion combined with a custom > > ASIC? > > I think 710T was a pin compatible clone of CL/PS7110 by NEC. The > device registers were different both from CL/PS7110 and 720T for > most part. Oh and that also means that mach-integrator probably never used 710T as we only have the 720T SoC registers in the mainline. From CPU point of view 710T and 720T can be considered the same for most part like we do. Regards, Tony
diff --git a/arch/arm/mm/proc-arm720.S b/arch/arm/mm/proc-arm720.S index d42c37f9f5bc..6699f91a6a0f 100644 --- a/arch/arm/mm/proc-arm720.S +++ b/arch/arm/mm/proc-arm720.S @@ -116,34 +116,6 @@ ENTRY(cpu_arm720_reset) ENDPROC(cpu_arm720_reset) .popsection - .type __arm710_setup, #function -__arm710_setup: - mov r0, #0 - mcr p15, 0, r0, c7, c7, 0 @ invalidate caches -#ifdef CONFIG_MMU - mcr p15, 0, r0, c8, c7, 0 @ flush TLB (v4) -#endif - mrc p15, 0, r0, c1, c0 @ get control register - ldr r5, arm710_cr1_clear - bic r0, r0, r5 - ldr r5, arm710_cr1_set - orr r0, r0, r5 - mov pc, lr @ __ret (head.S) - .size __arm710_setup, . - __arm710_setup - - /* - * R - * .RVI ZFRS BLDP WCAM - * .... 0001 ..11 1101 - * - */ - .type arm710_cr1_clear, #object - .type arm710_cr1_set, #object -arm710_cr1_clear: - .word 0x0f3f -arm710_cr1_set: - .word 0x013d - .type __arm720_setup, #function __arm720_setup: mov r0, #0 @@ -177,7 +149,6 @@ arm720_crval: string cpu_arch_name, "armv4t" string cpu_elf_name, "v4" - string cpu_arm710_name, "ARM710T" string cpu_arm720_name, "ARM720T" .align @@ -215,5 +186,4 @@ __\name\()_proc_info: .size __\name\()_proc_info, . - __\name\()_proc_info .endm - arm720_proc_info arm710, 0x41807100, 0xffffff00, cpu_arm710_name, __arm710_setup arm720_proc_info arm720, 0x41807200, 0xffffff00, cpu_arm720_name, __arm720_setup
Support for ARM710 CPUs was removed in v3.5. But a few lines of ARM710 specific assembler code were left in the tree. Remove these too. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> --- This minor cleanup was suggested by Arnd. This patch is mostly guesswork, as I already told Arnd, since I have never touched ARM assembler before (as far as I can remember). Untested too! And this does need testing. arch/arm/mm/proc-arm720.S | 30 ------------------------------ 1 file changed, 30 deletions(-)