linux-toradex.git/arch/m68k/lib, branch v3.2.20

m68k: fix memcpy to unmatched/unaligned source and dest on 68000

2011-10-18T04:22:24+00:00

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: Greg Ungerer

m68k: merge and clean up delay.h files

2011-07-25T01:20:41+00:00

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: Greg Ungerer

m68k: use kernel processor defines for conditional optimizations

2011-06-14T01:42:29+00:00

Older m68k-linux compilers will include pre-defined symbols that
confuse what processor it is being targeted for. For example gcc-4.1.2
will pre-define __mc68020__ even if you specify the target processor
as -m68000 on the gcc command line. Newer versions of gcc have this
corrected.

In a few places the m68k code uses defined(__mc68020__) for optimizations
that include instructions that are specific to the CPU 68020 and above.
When compiling with older compilers this will be true even when we have
selected to compile for the older 68000 processors.

Switch to using the kernel processor defines, CONFIG_M68020 and friends.

Signed-off-by: Greg Ungerer

m68knommu: move EXPORT of local checksumming functions to definitions

2011-05-24T00:03:51+00:00

The EXPORT_SYMBOL() of the local lib checksum functions belongs with
the definitions, not in some other random code file. So move then there.

Signed-off-by: Greg Ungerer

m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.c

2011-05-24T00:03:50+00:00

We don't need an arch/m68k/lib/checksum.c wrapper to include the correct
mmu or non-mmu version of the checksum code. Let the Makefile just build
the appropriate one.

Signed-off-by: Greg Ungerer

m68k: remove duplicate memcpy() implementation

2011-05-24T00:03:49+00:00

Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memcpy(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memcpy(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven

m68k: remove duplicate memset() implementation

2011-05-24T00:03:49+00:00

Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memset(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memset(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven

m68k: remove duplicate memmove() implementation

2011-05-24T00:03:49+00:00

Merging the mmu and non-mmu directories we ended up with duplicate
(and identical) implementations of memmove(). Remove one of them.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven

m68k: merge mmu and non-mmu versions of lib/Makefile

2011-05-24T00:03:49+00:00

We can easily support the slight differences in libs needed by the
mmu and non-mmu builds in a single Makefile, so merge them back into
a single file again.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven

m68k: merge mmu and non-mmu versions of muldi3

2011-05-24T00:03:49+00:00

The implementation of gcc's muldi3 support function differs only in
the use of the machine's 64 bit sized mul or not. (It isn't based
on using an MMU or not). Merge the current mmu and non-mmu versions
of arc/m68k/lib/muldi3 and use the appropriate pre-processor
conditionals to get the right version for all m68k processor types.

Signed-off-by: Greg Ungerer 
Acked-by: Geert Uytterhoeven