- 04 Mar, 2012 40 commits
-
-
Greg Ungerer authored
The ColdFire FEC is common to quite a few ColdFire CPUs. No need to duplicate its platform setup code for every CPU family member that has it. Merge all the setup code into a single shared file. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 532x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 528x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 527x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5272 FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 523x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 520x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Some ColdFire CPU UART hardware modules can configure the IRQ they use. Currently the same setup code is duplicated in the init code for each of these ColdFire CPUs. Merge all this code to a single instance. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The ColdFire UART is common to all ColdFire CPU's. No need to duplicate its platform setup code for every CPU family member. Merge all the setup code into a single shared file. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 54xx UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5407 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 532x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 528x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5307 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 527x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5272 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5249 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 523x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 520x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5206 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The MMU and non-MMU varients of the m68k arch process.c code are pretty much the same. Only a few minor details differ between the two. The majority of the difference is to deal with having or wanting hardware FPU support. So merge them back into a single process.c file. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
The classic m68k code has always supported an FPU (although it may have been a software emulated one). The non-MMU m68k code has never supported FPU hardware. To help in merging common code create a configation setting that signifies if we are builing in FPU support or not. This switch, CONFIG_FPU, is set as per the current use cases. So it is always enabled if CONFIG_MMU is set, and disabled otherwise. With a little extra code it will be possible to disable it on the classic m68k platforms as well, and to enable it on non-MMU platforms that do have hardware FPU. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
Most of the code in the non-mmu ptrace_no.c file is the same as the mmu version ptrace_mm.c. So merge them back into a single file. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
The set_rtc_mmss() function is defined "static inline" but is never used in this file. Remove it. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
There is only trivial differences between the mmu time_mm.c and non-mmu time_no.c files. Merge them back into a single time.c. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
-
Greg Ungerer authored
The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU m68k case. But the underlying code to support it, update_persistent_clock(), doesn't end up doing anything on the currently supported non-MMU platforms. No platforms supply the necessary function support for writing back the RTC. So lets remove this option and support code. This also brings m68knommu in line with the m68k, which doesn't enabled this switch either. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
With a few small changes we can make the m68knommu timer init code the same as the m68k code. By using the mach_sched_init function pointer and reworking the current timer initializers to keep track of the common m68k timer_interrupt() handler we end up with almost identical code for m68knommu. This will allow us to more easily merge the mmu and non-mmu m68k time.c in future patches. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The read_persistent_clock() code is different on m68knommu, for really no reason. With a few changes to support function names and some code re-organization the code can be made the same. This will make it easier to merge the arch/m68k/kernel/time.c for m68k and m68knommu in a future patch. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
The base of the real RAM resident hardware vectors, _ramvec, is declared in our asm/traps.h. No need to have local declarations spread around in other files that use this. So remove them. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-
Greg Ungerer authored
There is a lot of years of collected cruft in the m68knommu linker script. Clean it all up and use the well defined linker script support macros. Support is maintained for building both ROM/FLASH based and RAM based setups. No major changes to section layouts, though the rodata section is now lumped in with the read/write data section. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
-