Skip to content

L
linux
Switch branch/tag
  1. 25 Jul, 2011 13 commits
    • Geert Uytterhoeven's avatar
      m68k: Revive reporting of spurious interrupts · 8c9f08f9
      Geert Uytterhoeven authored 
      commit 2502b667 ("Change the m68knommu irq
handling to use the generic irq framework.") removed the reporting of spurious
interrupts on nommu (68328 and 68360).

Bring it back in a generic way, using "atomic_t irq_err_count", as that's what
most of the other architectures are using.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      8c9f08f9
    • Geert Uytterhoeven's avatar
      m68knommu: Move forward declaration of do_IRQ() from machdep.h to irq.h · 739735d5
      Geert Uytterhoeven authored 
      It is not machine-specific, but common irq infrastructure.
Also add the missing asmlinkage, to match its definition.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      739735d5
    • Greg Ungerer's avatar
      m68k: fix some atomic operation asm address modes for ColdFire · 35de6749
      Greg Ungerer authored 
      The ColdFire processors have a much more limited set of addressing modes
that can be used for most instructions. A number of the atomic operations
have already been fixed to limit the addressing modes used with add and
sub instructions when building for ColdFire. But we missed a few.
Fix the remaining atomic operations to be clean for ColdFire processors.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      35de6749
    • Greg Ungerer's avatar
      m68k: use CPU_HAS_NO_BITFIELDS for signal functions · f3c23a28
      Greg Ungerer authored 
      When reworking bitops.h to be clean for all processor types we introduced
a CONFIG_CPU_HAS_NO_BITFIELDS define to signal whether this processor type
supported the bit field instructions. The ARCH_SIG_BITOPS functions for
m68k use these instruction types. We should base the use of these functions
(or the generic versions) on the CONFIG_CPU_HAS_NO_BITFIELDS define.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      f3c23a28
    • Greg Ungerer's avatar
      m68k: merge and clean up delay.h files · 7c946199
      Greg Ungerer authored 
      The real difference between the mmu and non-mmu varients of the delay.h
files has nothing to do with having an mmu or not. It is processor family
differences that means slightly different code. Merge the delay_mm.h and
delay_no.h files back into a single file.

The primarly difference we need to deal with is whether the processor
supports a 32bit * 32bit -> 64bit multiply. Without it we need to do some
shift scaling as well as use a 32bit * 32bit -> 32bit multiply. If building
for a multi-CPU type kernel then we must use the simpler mult/shift scaling.

This version of delay code allows the CPU32 family to use a 64bit mul,
since it supports this instruction, the old code did not.

The changes use macros where appropriate to try and optimize constant sized
udelay times. And it removes the use of a fixed lib function for the non-mmu
case. Code size on typical kernel configurations is similar, or only larger
by a few tens of bytes.

Also removed the unused muldiv() code from delay_mm.h.

Build and run tested on ColdFire and ARAnyM. Build tested only on 68328
and 68360 (CPU32).
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      7c946199
    • Greg Ungerer's avatar
      m68knommu: correctly use trap_init · 622e9472
      Greg Ungerer authored 
      Currently trap_init() is an empty function for m68knommu. Instead
the vectors are being setup as part of the IRQ initialization.
This is inconsistent with m68k and other architectures.

Change the local init_vectors() to be trap_init(), and init the
vectors at the correct time during startup. This will help merge of
m68k and m68knommu trap code in the furture.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      622e9472
    • Greg Ungerer's avatar
      m68knommu: merge ColdFire 5206 and 5206e platform code · f4a54373
      Greg Ungerer authored 
      The ColdFire 5206 and 5206e CPU families are almost identical, we can
easily merge the platform support code for them. All the differences
are dealt with in the current include/asm/5206sim.h.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      f4a54373
    • 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
    • Greg Ungerer's avatar
      m68k: merge MMU and non MMU versions of system.h · f941f5ca
      Greg Ungerer authored 
      The non-MMU m68k targets can use the same asm/system.h as the MMU
targets. So switch the current system_mm.h to be system.h and remove
system_no.h.

The assembly support code for the non-MMU resume functions needs to
be modified to match the now common switch_to() macro. Specifically
this means correctly saving and restoring the status flags in the case
of the ColdFire resume, and some reordering of the code to not use
registers before they are saved or after they are restored.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      f941f5ca
    • Greg Ungerer's avatar
      m68k: merge MMU and non-MMU versions of asm/hardirq.h · 10f939ff
      Greg Ungerer authored 
      The contents of asm/hardirq.h are pretty strait forward for both the
MMU (hardirq_mm.h) and non-MMU (hardirq_no.h) include files. Merge the
two back into a single file.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      10f939ff
    • Greg Ungerer's avatar
      m68k: merge the non-mmu and mmu versions of module.c · a66af298
      Greg Ungerer authored 
      The non-mmu and mmu versions of the module loader module.c are
nearly identical. Merge them back to a single module.c. There is
a little bit of re-ordering of the struct and enum definitions in
module.h to keep the ifdefery to a minimum.
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      a66af298
    • Geert Uytterhoeven's avatar
      m68knommu: Fix printk() format in free_initrd_mem() · 6617eaf3
      Geert Uytterhoeven authored 
      arch/m68k/mm/init_no.c:123: warning: format "%d" expects type "int", but argument 2 has type "long unsigned int"

And use pr_notice() while we're at it.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      6617eaf3
    • Geert Uytterhoeven's avatar
      m68knommu: Make empty_zero_page "void *", like on m68k · 45d1564c
      Geert Uytterhoeven authored 
      This allows to get rid of the casts.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      45d1564c
  3. 24 Jul, 2011 27 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7