- 29 5月, 2016 1 次提交
-
-
由 George Spelvin 提交于
This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at http://spiral.ece.cmu.edu/mcm/gen.htmlSigned-off-by: NGeorge Spelvin <linux@sciencehorizons.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Philippe De Muyter <phdm@macq.eu> Cc: linux-m68k@lists.linux-m68k.org
-
- 07 3月, 2016 1 次提交
-
-
由 Greg Ungerer 提交于
Remove the obsolete Motorola/Freescale 68360 SoC support. It has been bit rotting for many years with little active use in mainlne. There has been no serial driver support for many years, so it is largely not useful in its current state. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 13 7月, 2015 3 次提交
-
-
由 Greg Ungerer 提交于
It would be nice if we could support multiple ColdFire SoC types in a single binary - but currently the code simply does not support it. Change the SoC selection config options to be a choice instead of individual selectable entries. This fixes problems with building allnoconfig, and means that a sane linux kernel is generated for a single ColdFire SoC type. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
由 Greg Ungerer 提交于
Create some intelligent default settings for each ColdFire SoC type in the configuration entry for CONFIG_CLOCK_FREQ. The ColdFire clock frequency is configurable at build time. There is a lot of variation in the frequency of operation on specific ColdFire based boards. But we can choose a default that matches the maximum frequency of clock operation for a particular ColdFire part. That is typically the most common clock setting. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
由 Greg Ungerer 提交于
It is possible to disable the clock selection at configuration time, but for ColdFire targets we always expect a clock frequency to be selected. This results in the following compile time error: CC arch/m68k/kernel/asm-offsets.s In file included from ./arch/m68k/include/asm/timex.h:14:0, from include/linux/timex.h:65, from include/linux/sched.h:19, from arch/m68k/kernel/asm-offsets.c:14: ./arch/m68k/include/asm/coldfire.h:25:2: error: #error "Don't know what your ColdFire CPU clock frequency is??" Remove CONFIG_CLOCK_SELECT completely and always enable CONFIG_CLOCK_FREQ for ColdFire. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
- 29 4月, 2013 2 次提交
-
-
由 Greg Ungerer 提交于
The ColdFire 537x family is very similar internally to the ColdFire 532x family. So with just a little extra configuration we can configure and target them as well. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Greg Ungerer 提交于
The current CONFIG_M532x support definitions are actually common to a larger set of version 3 ColdFire CPU types. In the future we want to add support for the 537x family. It is very similar to the 532x internally, and will be able to use most of the same definitions. Create a CONFIG_M53xx option that is enabled to support any of the common 532x and 537x CPU types. Convert the current users of CONFIG_M532x to use CONFIG_M53xx instead. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 21 3月, 2013 1 次提交
-
-
由 Alexandre Courbot 提交于
Force use of gpiolib for Coldfire, as a step towards the deprecation of GENERIC_GPIO. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NGreg Ungerer <gerg@uclinux.org>
-
- 05 12月, 2012 2 次提交
-
-
由 Luis Alves 提交于
As pointed out by Geert, MC68000 target needs to be disabled when MMU support is enabled. From Geert: This needs a "depends on !MMU". Else allmodconfig will select it, causing -m68000 to be passed to the assembler, which may break the build depending on your version of binutils, a.o. arch/m68k/kernel/entry.S:186: Error: invalid instruction for this architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `bfextu %sp@(50){#0,#4},%d0' ignored arch/m68k/kernel/entry.S:211: Error: invalid operand mode for this architecture; needs 68020 or higher -- statement `jbsr @(sys_call_table,%d0:l:4)@(0)' ignored Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/7416877/Signed-off-by: NLuis Alves <ljalvs@gmail.com> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Luis Alves 提交于
Allow the M68000 option to be user configurable, for systems based on the original stand alone 68000 CPU. Signed-off-by: NLuis Alves <ljalvs@gmail.com> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 14 11月, 2012 1 次提交
-
-
由 Kees Cook 提交于
This config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it. CC: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
- 17 8月, 2012 2 次提交
-
-
由 Greg Ungerer 提交于
There is no specific atomic64 support code for any m68k CPUs, so we should select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection of this and select it for all m68k. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NFengguang Wu <fengguang.wu@intel.com> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
由 Greg Ungerer 提交于
The ColdFire CPU sub-arch has kernel clk code support, so select CONFIG_HAVE_CLK. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 16 7月, 2012 3 次提交
-
-
由 Steven King 提交于
Add support for the Coldfire 5441x (54410/54415/54416/54417/54418). Currently we only support noMMU mode. It requires the PIT patch posted previously as it uses the PIT instead of the dma timer as a clock source so we can get all that GENERIC_CLOCKEVENTS goodness. It also adds some simple clk definitions and very simple minded power management. The gpio code is tweeked and some additional devices are added to devices.c. The Makefile uses -mv4e as apparently, the only difference a v4m (m5441x) and a v4e is the later has a FPU, which I don't think should matter to us in the kernel. Signed-off-by: NSteven King <sfking@fdwdc.com> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Steven King 提交于
Basic support for the Coldfire 5251/5253. Signed-off-by: NSteven king <sfking@fdwdc.com> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Steven King 提交于
If we're not connecting external GPIO extenders via i2c or spi or whatever, we probably don't need GPIOLIB. If we provide an alternate implementation of the GPIOLIB functions to use when only on-chip GPIO is needed, we can change ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes optional. The downside is that in the GPIOLIB=n case, we lose all error checking done by gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the only checking that can be done is if we reference a gpio on an external part. Targets that need the extra error checking can still select GPIOLIB=y. For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a single chip, eliminating the tables of chips in the 5xxx.c files. The original motivation for the definition of multiple chips was to match the way many of the Coldfire variants defined their gpio as a spare array in memory. However, all this really gains us is some error checking when we request a gpio, gpiolib can check that it doesn't fall in one of the holes. If thats important, I think we can still come up with a better way of accomplishing that. Also in this patch is some general cleanup and reorganizing of the gpio header files (I'm sure I must have had a reason why I sometimes used a prefix of mcf_gpio and other times mcfgpio but for the life of me I can't think of it now). Signed-off-by: NSteven King <sfking@fdwdc.com> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 27 6月, 2012 1 次提交
-
-
由 Greg Ungerer 提交于
All of the current Linux supported ColdFire CPUs handle unaligned memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. If we ever support a specific ColdFire CPU that does not support unaligned accesses then we can insert the CONFIG_CPU_HAS_NO_UNALIGNED for that specific CPU type. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
- 10 6月, 2012 3 次提交
-
-
由 Geert Uytterhoeven 提交于
Hence select CPU_HAS_NO_UNALIGNED Reported-by: NPhilippe De Muyter <phdm@macqel.be> Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer<gerg@uclinux.org>
-
由 Geert Uytterhoeven 提交于
Use CONFIG_CPU_HAS_NO_UNALIGNED instead of open coding CONFIG_M68000 || CONFIG_COLDFIRE Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer<gerg@uclinux.org>
-
由 Geert Uytterhoeven 提交于
They belong together with the CPU selection Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer<gerg@uclinux.org>
-
- 12 5月, 2012 1 次提交
-
-
由 Mark Brown 提交于
Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NJonas Bonn <jonas@southpole.se> Acked-by: NTony Luck <tony.luck@intel.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 16 4月, 2012 1 次提交
-
-
由 Masanari Iida 提交于
Correct spelling typo in various Kconfig file. Signed-off-by: NMasanari Iida <standby24x7@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 30 12月, 2011 3 次提交
-
-
由 Greg Ungerer 提交于
The ColdFire 547x and 548x CPUs have internal MMU hardware. All code to support this is now in, so we can build kernels with it enabled. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NMatt Waddel <mwaddel@yahoo.com> Acked-by: NKurt Mahan <kmahan@xmission.com>
-
由 Geert Uytterhoeven 提交于
While you can build multiplatform kernels for machines with classic m68k processors, you cannot mix support for classic m68k and coldfire processors. To avoid such hybrid kernels, introduce CONFIG_M68KCLASSIC as an antipole for CONFIG_COLDFIRE, and make all specific processor support depend on one of them. All classic m68k machine support also needs to depend on this. The defaults (CONFIG_M68KCLASSIC if MMU, CONFIG_COLDFIRE if !MMU) are chosen such to make most of the existing configs build and work. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Greg Ungerer 提交于
Modify the user space access functions to support the ColdFire V4e cores running with MMU enabled. The ColdFire processors do not support the "moves" instruction used by the traditional 680x0 processors for moving data into and out of another address space. They only support the notion of a single address space, and you use the usual "move" instruction to access that. Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the CPU types that support separate address spaces, and thus also support the sfc/dfc registers and the "moves" instruction that go along with that. The code is almost identical for user space access, so lets just use a define to choose either the "move" or "moves" in the assembler code. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NMatt Waddel <mwaddel@yahoo.com> Acked-by: NKurt Mahan <kmahan@xmission.com> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
- 24 12月, 2011 3 次提交
-
-
由 Greg Ungerer 提交于
The traditional 68000 processors and the newer reduced instruction set ColdFire processors do not support the 32*32->64 multiply or the 64/32->32 divide instructions. This is not a difference based on the presence of a hardware MMU or not. Create a new config symbol to mark that a CPU type doesn't support the longer multiply/divide instructions. Use this then as a basis for using the fast 64bit based divide (in div64.h) and for linking in the extra libgcc functions that may be required (mulsi3, divsi3, etc). Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
由 Greg Ungerer 提交于
We have two implementations of the IP checksuming code for the m68k arch. One uses the more advanced instructions available in 68020 and above processors, the other uses the simpler instructions available on the original 68000 processors and the modern ColdFire processors. This simpler code is pretty much the same as the generic lib implementation of the IP csum functions. So lets just switch over to using that. That means we can completely remove the checksum_no.c file, and only have the local fast code used for the more complex 68k CPU family members. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Greg Ungerer 提交于
The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the MMU being present and enabled. It is a property of certain CPU families. So select it based on those CPU types being selected. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 18 10月, 2011 1 次提交
-
-
由 Greg Ungerer 提交于
The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-