1. 30 Jul, 2012 1 commit
  2. 06 Jun, 2012 1 commit
  3. 21 May, 2012 2 commits
  4. 05 May, 2012 2 commits
  5. 04 Mar, 2012 2 commits
    • Greg Ungerer's avatar
      m68k: make support for FPU hardware configurable · 9657a872
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      9657a872
    • Greg Ungerer's avatar
      m68knommu: remove unused CONFIG_GENERIC_CMOS_UPDATE option · b6c58e8a
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      b6c58e8a
  6. 11 Jan, 2012 1 commit
  7. 29 Dec, 2011 3 commits
  8. 24 Dec, 2011 3 commits
    • Greg Ungerer's avatar
      m68k: handle presence of 64bit mul/div instructions cleanly · 84f3fb7a
      Greg Ungerer authored
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      84f3fb7a
    • Greg Ungerer's avatar
      m68k: simpler m68k and ColdFire CPU's can use generic csum code · 7f73bafc
      Greg Ungerer authored
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      7f73bafc
    • Greg Ungerer's avatar
      m68k: selection of GENERIC_ATOMIC64 is not MMU specific · 5717a02b
      Greg Ungerer authored
      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: default avatarGreg Ungerer <gerg@uclinux.org>
      5717a02b
  9. 24 Nov, 2011 1 commit
  10. 08 Nov, 2011 10 commits
  11. 17 Oct, 2011 1 commit
    • 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
  12. 03 Aug, 2011 1 commit
  13. 24 Jul, 2011 1 commit
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu bitops.h · 171d809d
      Greg Ungerer authored
      The following patch merges the mmu and non-mmu versions of the m68k
      bitops.h files. Now there is a good deal of difference between the two
      files, but none of it is actually an mmu specific difference. It is
      all about the specific m68k/coldfire varient we are targeting. So it
      makes an awful lot of sense to merge these into a single bitops.h.
      
      There is a number of ways I can see to factor this code. The approach
      I have taken here is to keep the various versions of each macro/function
      type together. This means that there is some ifdefery with each to handle
      each CPU type.
      
      I have added some comments in a couple of appropriate places to try
      and make it clear what the differences we are dealing with are.
      Specifically the instruction and addressing mode differences we have
      to deal with.
      
      The merged form keeps the same underlying optimizations for each CPU
      type for all the general bit clear/set/change and find bit operations.
      It does switch to using the generic le operations though, instead of
      any local varients.
      
      Build tested on ColdFire, 68328, 68360 (which is cpu32) and 68020+.
      Run tested on ColdFire and ARAnyM.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      171d809d
  14. 23 May, 2011 1 commit
  15. 30 Mar, 2011 1 commit
  16. 24 Mar, 2011 1 commit
    • Greg Ungerer's avatar
      m68k: merge m68k and m68knommu arch directories · 66d857b0
      Greg Ungerer authored
      There is a lot of common code that could be shared between the m68k
      and m68knommu arch branches. It makes sense to merge the two branches
      into a single directory structure so that we can more easily share
      that common code.
      
      This is a brute force merge, based on a script from Stephen King
      <sfking@fdwdc.com>, which was originally written by Arnd Bergmann
      <arnd@arndb.de>.
      
      > The script was inspired by the script Sam Ravnborg used to merge the
      > includes from m68knommu. For those files common to both arches but
      > differing in content, the m68k version of the file is renamed to
      > <file>_mm.<ext> and the m68knommu version of the file is moved into the
      > corresponding m68k directory and renamed <file>_no.<ext> and a small
      > wrapper file <file>.<ext> is used to select between the two version. Files
      > that are common to both but don't differ are removed from the m68knommu
      > tree and files and directories that are unique to the m68knommu tree are
      > moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
      >
      > To select between the the versions of the files, the wrapper uses
      >
      > #ifdef CONFIG_MMU
      > #include <file>_mm.<ext>
      > #else
      > #include <file>_no.<ext>
      > #endif
      
      On top of this file merge I have done a simplistic merge of m68k and
      m68knommu Kconfig, which primarily attempts to keep existing options and
      menus in place. Other than a handful of options being moved it produces
      identical .config outputs on m68k and m68knommu targets I tested it on.
      
      With this in place there is now quite a bit of scope for merge cleanups
      in future patches.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      66d857b0
  17. 16 Mar, 2011 5 commits
  18. 22 Feb, 2011 1 commit
  19. 22 Oct, 2010 1 commit
  20. 19 Sep, 2010 1 commit