Skip to content

L
linux
Switch branch/tag
  1. 18 Oct, 2011 8 commits
    • Greg Ungerer's avatar
      m68k: move hardware vector setting from traps.c to its own file · bc4f4ac2
      Greg Ungerer authored 
      Most of the trap.c code is general to all m68k arch members. But the code
it currently contains to set the hardware vector table is quite specific to
the 680x0 family. They can have the vector table at any address unlike
other family members (which either support only a single fixed address,
or a limited range of addresses). So lets move that code out to a new file,
vectors.c. This will make sharing the rest of the trap.c code easier and
cleaner.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      bc4f4ac2
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu include/asm/entry.h files · 61619b12
      Greg Ungerer authored 
      The changes in the mmu version of entry.h (entry_mm.h) and the non-mmu
version (entry_no.h) are not about the presence or use of an MMU at all.
The main changes are to support the ColdFire processors. The code for
trap entry and exit for all types of 68k processor outside coldfire is
the same.

So merge the files back to a single entry.h and share the common 68k
entry/exit code. Some changes are required for the non-mmu entry
handlers to adopt the differing macros for system call and interrupt
entry, but this is quite strait forward. The changes for the ColdFire
remove a couple of instructions for the separate a7 register case, and
are no worse for the older single a7 register case.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      61619b12
    • Greg Ungerer's avatar
      m68k: merge the mmu and non-mmu kernel/Makefiles · 0a01b310
      Greg Ungerer authored 
      The few differences between the mmu and non-mmu kernel/Makefiles can
easily be handled inside of a single Makefile. Merge the 2 back into
a single Makefile.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      0a01b310
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu arch Makefiles · 281eff53
      Greg Ungerer authored 
      Most of the build logic is the same for the mmu and non-mmu m68k targets.
Merge the top level architecture Makefiles back into a single Makefile.

For the most part this is just adding the non-mmu processor types and
their specific cflags and other options into the mmu Makefile.

Note that all the BOARD setting logic that was in the non-mmu Makefile
is completely removed. It was no longer being used at all.

This has been build and run tested on ColdFire targets and ARAnyM.
It has been build tested on all the m68k defconfig targets using a
gcc-4.5.1 based toolchain.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      281eff53
    • Greg Ungerer's avatar
      m68k: reorganize Kconfig options to improve mmu/non-mmu selections · 0e152d80
      Greg Ungerer authored 
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      0e152d80
    • Peter Turczak's avatar
      m68knommu: fix problems with SPI/GPIO on ColdFire 520x · 89127ed3
      Peter Turczak authored 
      The problem has its root in the calculation of the set-port offsets (macro
MCFGPIO_SETR() in arch/m68k/include/asm/gpio.h), this assumes that all ports
have the same offset from the base port address (MCFGPIO_SETR) which is
defined in mcf520xsim.h as an alias of MCFGIO_PSETR_BUSCTL. Because the BUSCTL
and BE port do not have a set-register (see MCF5208 Reference Manual Page
13-10, Table 13-3) the offset calculations went wrong.

Because the BE and BUSCTL port do not seem useful in these parts, as they
lack a set register, I removed them and adapted the gpio chip bases which
are also used for the offset-calculations. Now both setting and resetting
the chip selects works as expected from userland and from the kernelspace.
Signed-off-by: default avatarPeter Turczak <peter@turczak.de>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      89127ed3
    • Greg Ungerer's avatar
      m68k: fix memcpy to unmatched/unaligned source and dest on 68000 · f230e80b
      Greg Ungerer authored 
      The original 68000 processors cannot copy 16bit or larger quantities from
odd addresses. All newer members of the 68k family (including ColdFire)
can do this.

In the current memcpy implementation after trying to align the destination
address to a 16bit boundary if we end up with an odd source address we go
off and try to copy multi-byte quantities from it. This will trap on the
68000.

The only solution if we end with an odd source address is to byte wise
copy the whole memcpy region. We only need to do this if we are supporting
original 68000 processors.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      f230e80b
    • Linus Torvalds's avatar
      Linux 3.1-rc10 · 899e3ee4
      Linus Torvalds authored
      899e3ee4
  3. 17 Oct, 2011 1 commit
    • Linus Torvalds's avatar
      Avoid using variable-length arrays in kernel/sys.c · a84a79e4
      Linus Torvalds authored 
      The size is always valid, but variable-length arrays generate worse code
for no good reason (unless the function happens to be inlined and the
compiler sees the length for the simple constant it is).

Also, there seems to be some code generation problem on POWER, where
Henrik Bakken reports that register r28 can get corrupted under some
subtle circumstances (interrupt happening at the wrong time?).  That all
indicates some seriously broken compiler issues, but since variable
length arrays are bad regardless, there's little point in trying to
chase it down.

"Just don't do that, then".
Reported-by: default avatarHenrik Grindal Bakken <henribak@cisco.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a84a79e4
  5. 16 Oct, 2011 1 commit
  7. 15 Oct, 2011 3 commits
  9. 14 Oct, 2011 6 commits
  11. 13 Oct, 2011 7 commits
  13. 11 Oct, 2011 5 commits
  15. 10 Oct, 2011 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7