From: Greg Ungerer g...@uclinux.org
The inclusion of multiple FEC ethernet platform devices is based around
the FEC address definitions in the platform headers. The ColdFire m527x
platform is defining 2 FEC modules, but the 5271 SoC only has a single
FEC hardware module. The attempt to probe and
From: Greg Ungerer g...@uclinux.org
The ColdFire DMA timer hardware module is a free running counter that is
derived from the master system clock. It is effectively a cycle counter,
so lets add it to the entropy pool.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
Acquire the SoC clock when using the PIT timer hardware module. It seems
to be powered up and enabled by default on most ColdFire SoC, but this
just makes sure that is true.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/pit.c |
From: Greg Ungerer g...@uclinux.org
We have separate architecture functions for freeing the initrd memory, and
for freeing the init sections. But they are essentially the same code, they
are doing exactly the same thing.
Create a common local arch free memory function and make the current users
From: Greg Ungerer g...@uclinux.org
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
From: Greg Ungerer g...@uclinux.org
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: Greg Ungerer g...@uclinux.org
---
arch/m68k/Kconfig.cpu |8
From: Greg Ungerer g...@uclinux.org
Add a configuration switch for supporting the Freescale M5373EVB board.
It is based on the newly added ColdFire 537x CPU support.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/Kconfig.machine |7 +++
1 files changed, 7 insertions(+), 0
The current Coldfire clock code only really supports those ColdFire CPU types
that have the more advanced enable/disable clock hardware support. If we
generalize our clock code we can support all types, even those with simpler
fixed clock trees.
This results in much cleaner and consistent clock
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 5249 ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m5249.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 525x ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m525x.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 528x ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m528x.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 527x ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m527x.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 5407 ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m5407.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 523x ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m523x.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 5206 ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m5206.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 5307 ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m5307.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
The clock support code for ColdFire CPUs currently supports those that
have the clock control register PPMCR. Expose the struct clk for all CPU
types and add a definition for all other ColdFire CPU types.
With this we will be able to define simple clock trees
From: Greg Ungerer g...@uclinux.org
Add a base set of clocks for the 54xx ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m54xx.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git
From: Greg Ungerer g...@uclinux.org
The existing clk.c code for ColdFire CPUs has one set of functions to
support those CPU types that have selectable clocks (those with a PPMCR
register), and a duplicate simpler set for those with static clocks.
Modify the clk.c code so there is just one set of
From: Greg Ungerer g...@uclinux.org
When compiling for original 68000 or ColdFire targets you will get the
following warning when compiling arch/m68k/lib/memcpy.c:
CC arch/m68k/lib/memcpy.o
arch/m68k/lib/memcpy.c: In function ‘__builtin_memcpy’:
arch/m68k/lib/memcpy.c:13:15: warning:
From: Greg Ungerer g...@uclinux.org
The contents of the m68k asm/dbg.h are never used, remove the file and
remove the one reference to it.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/dbg.h |6 --
drivers/tty/serial/68328serial.c |1 -
2 files changed,
From: Greg Ungerer g...@uclinux.org
The ColdFire 5249 and 525x family of SoCs are very similar. Most of the
internals are the same, and are mapped the same. We can use a single set of
peripheral definitions for all of them.
So merge the current m5249sim.h and m525xsim.h definitions into a single
From: Greg Ungerer g...@uclinux.org
To be consistent with the set of MMU definitions we should define KMAP_START
and KMAP_END. Future common m68k code will use their values.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/pgtable_no.h |2 ++
1 files changed, 2
From: Greg Ungerer g...@uclinux.org
The page_to_virt() macro for m68knommu is currently effectively returning
an int type. But the equivilent m68k macro returns a void * virtual address.
Modify the non-MMU macro to return a void * as well (using the __va macro).
This change will remove compiler
Reformat broken tab alignment on some defines. This makes the format
mostly consistent in these files.
---
arch/m68k/include/asm/m523xsim.h | 18 +-
arch/m68k/include/asm/m5272sim.h |7 ---
arch/m68k/include/asm/m527xsim.h | 34 +-
From: Greg Ungerer g...@uclinux.org
Fix tab broken address defines to be consistent with others in this file.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m527xsim.h | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff
From: Greg Ungerer g...@uclinux.org
Fix tab broken address defines to be consistent with others in this file.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m523xsim.h | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git
This patch series is a bunch of cleanups and fixes across the ColdFire
periperhal header files. Primarily they are:
. fix mixed up uses of relative and absolute address
. convert hard coded addresses into proper definitions
. use consistent names for definitions across different ColdFire types
.
From: Greg Ungerer g...@uclinux.org
There is a bunch of old unused and ugly register definitions in the ColdFire
5282 header. Remove them.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m528xsim.h | 51 +-
1 files changed, 1
From: Greg Ungerer g...@uclinux.org
Currently the setup code for the FEC multi-function pins on the ColdFire 528x
has the addresses hard coded in the code. Use the register defines that
already exist for this.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/coldfire/m528x.c
From: Greg Ungerer g...@uclinux.org
There are a lot of unused and uneccessary definitions in the header to
support the ColdFire 532x CPU family. Remove the junk.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m532xsim.h | 1033 +-
1
From: Greg Ungerer g...@uclinux.org
The ColdFire 532x CPU register definitions for the multi-function setup
pins are inconsistently defined compared with other ColdFire parts. Modify
the register defintions to be just the addresses, not pointers. This also
fixes the erroneous use in one case of
From: Greg Ungerer g...@uclinux.org
Remove the last address definitions relative to the IPSBAR peripheral region
for the ColdFire 527x family. This involved cleaning up some magic numbers
used in the code part, and making them proper register definitions in the 527x
specific header.
This is part
From: Greg Ungerer g...@uclinux.org
The registers used to configure and set the multifunction pins on the 5272
ColdFire are defined as absolute addresses. So the use of them does not need
to be offset relative to the peripheral region address.
Fix two cases of incorrect usage of these addresses.
From: Greg Ungerer g...@uclinux.org
Move the base address defines of the ColdFire 54xx CPU slice timers into the
54xx specific header (m54xxsim.h). They are CPU specific, and belong with the
CPU specific defines. Also make them relative to the MBAR peripheral region,
making the define the
From: Greg Ungerer g...@uclinux.org
Get rid of the use of local IO access macros and switch to using the standard
read*/write* family of access functions for the ColdFire m532x setup code.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m532xsim.h| 104
From: Greg Ungerer g...@uclinux.org
The Pin Assignment register definitions for the ColdFire 54xx CPU family are
inconsistently named and defined compared to the other ColdFire part
definitions. Rename them with the same prefix as used on other parts,
MCFGPIO_PAR_, and make their definitions
From: Greg Ungerer g...@uclinux.org
Convert the ColdFire 54xx CPU General Timer register address definitions to
include the MCF_MBAR peripheral region offset. This makes them consistent
with all other 54xx address register definitions (in m54xxsim.h).
The goal is to reduce different definitions
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Pin Assignment registers absolute
addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Interrupt Mask and Pending registers
absolute addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Chip Select registers absolute addresses.
Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are relative
From: Greg Ungerer g...@uclinux.org
Make the remaining definitions of the 5272 ColdFire registers absolute
addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Interrupt Source registers absolute
addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Reset and System registers absolute
addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are
From: Greg Ungerer g...@uclinux.org
Make all definitions of the ColdFire Software watchdog registers absolute
addresses. Currently some are relative to the MBAR peripheral region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are
From: Greg Ungerer g...@uclinux.org
Make the ColdFire 5249 MBAR peripheral register definitions absolute
addresses, instead of offsets into the region.
The various ColdFire parts use different methods to address the internal
registers, some are absolute, some are relative to peripheral regions
From: Greg Ungerer g...@uclinux.org
The stack frame format field needs to be explicitly set on thread creation
on ColdFire. For a normal long word aligned user stack pointer the frame
format is 0x4.
We were doing this for non-MMU ColdFire, but not for the case with MMU enabled.
So fix it so we
From: Greg Ungerer g...@uclinux.org
The ColdFire CPU sub-arch has kernel clk code support, so select
CONFIG_HAVE_CLK.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/Kconfig.cpu |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/Kconfig.cpu
From: Greg Ungerer g...@uclinux.org
The uclinux.c map driver has traditionally been used only on non-MMU based
systems. But there is no fundamental reason it can't be used on systems
running with virtual memory.
Some ColdFire CPU based systems now have full paged MMU hardware and can use
the
This is an updated patch set of the NS8390 eth support for some of the
older ColdFire boards.
I have broken out the mcfne.h - mcf8390.h file move to its own patch,
didn't want to make the actual driver patch any bigger or harder to follow.
I also improved the commit log messages a little. The
From: Greg Ungerer g...@uclinux.org
Quite a few of Freescale's older ColdFire development boards used an NS8390
based ethernet interface. Add a platform definition for the resources used
by these devices so we can use it on these boards.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
Define the usual memory access functions (readb/writeb/...) and I/O space
functions (inb/outb/...) for PCI bus support on ColdFire CPU based platforms.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/io_mm.h | 48
From: Greg Ungerer g...@uclinux.org
The ColdFire M54xx SoC family have a traditional PCI bus interface.
Add the core support code to access and use this bus on these parts.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/m54xxpci.h | 138 +++
From: Greg Ungerer g...@uclinux.org
All support code for the PCI bus hardware on the ColdFire 547x and 548x
CPUs is now in. Allow enabling of CONFIG_PCI for them.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/Kconfig.bus |7 +++
1 files changed, 7 insertions(+), 0
From: Greg Ungerer g...@uclinux.org
Basic set of definitions and support code required to turn on CONFIG_PCI
for the m68k architecture. Nothing specific to any PCI implementation in
any m68k class CPU harwdare yet.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/include/asm/dma.h |
From: Greg Ungerer g...@uclinux.org
Commit f4d40de39a23f0c39cca55ac63e1175c69c3d2f7 (net fec: do not depend
on grouped clocks) breaks compilation of the FEC driver for non iMX
platforms in linux-3.5-rc1. For example when compiling for ColdFire I get:
LD vmlinux
drivers/built-in.o:
I have broken up the NS8390 support for ColdFire boards into 2 patches.
The first is the net support side of it, and the other is the ColdFire
platform support.
If no-one has any comments then I'll send the first patch onto the net list
for review. I'll add the second platform patch to the
From: Greg Ungerer g...@uclinux.org
A number of older ColdFire based boards use NS8390 based network controllers.
Most use the Davicom 9008F or the UMC 9008F. This driver provides the support
code to get these devices working on these platforms.
The way these devices are wired up to the ColdFire
From: Greg Ungerer g...@uclinux.org
A number of older ColdFire based boards use NS8390 based network controllers.
Most use the Davicom 9008F or the UMC 9008F. This driver provides the support
code to get these devices working on these platforms.
The way these devices are wired up to the ColdFire
From: Greg Ungerer g...@uclinux.org
When building for non-MMU based classic 68k CPU types (like the 68328 for
example) you get a compilation error:
CC arch/m68k/kernel/time.o
arch/m68k/kernel/time.c:91:5: error: redefinition of ‘arch_gettimeoffset’
include/linux/time.h:145:19: note:
From: Greg Ungerer g...@uclinux.org
Compiling for 68328 based targets fails with:
arch/m68k/platform/68328/timers.c: In function ‘hw_tick’:
arch/m68k/platform/68328/timers.c:65:2: error: implicit declaration of
function ‘arch_timer_interrupt’
arch/m68k/platform/68328/timers.c: At
From: Greg Ungerer g...@uclinux.org
The assembler entry code calls directly to the syscall_trace_enter() and
syscall_trace_leave() functions. But currently they are conditionaly
compiled out for the non-MMU classic m68k CPU types (so 68328 for example),
resulting in a link error:
LD
From: Greg Ungerer g...@uclinux.org
Compiling for 68360 based targets fails with:
arch/m68k/platform/68360/config.c: In function ‘hw_tick’:
arch/m68k/platform/68360/config.c:55:2: error: implicit declaration of
function ‘arch_timer_interrupt’
arch/m68k/platform/68360/config.c: At
From: Greg Ungerer g...@uclinux.org
All current ColdFire CPUs are able to support unaligned memory accesses.
So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire.
It seems that the current restriction was inherrited from the early non-MMU
support for the basic 68000 proecssors
With a little cleanup we can use much of the entry.S code on both the
MMU and non-MMU m68k targets.
This is the second iteration of this patch set. I have limited the
changes converting to use the ret_from_exception function entry point
over the label. I have only changed those shared by both
From: Greg Ungerer g...@uclinux.org
The ret_from_excption code is referenced by its function name, or by a label
set at the start of its code. The non-MMU code can share some of this code
if we make direct calls to ret_from_exception instead of the associated label.
The effected function paths
From: Greg Ungerer g...@uclinux.org
There is a few places that the m68k entry code uses the bsrl instruction
to call other functions. That instruction is only supported on 68020 and
higher CPU types. If we use jbsr instead the code will be clean for all
68k and ColdFire CPU types.
Signed-off-by:
From: Greg Ungerer g...@uclinux.org
Some of the entry.S code is common to both MMU and non-MMU builds.
So merge the entry_no.S and entry_mm.S files back into a single file.
With a little code movement we only need a single #ifdef.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
Add a default configuration for the newly supported ColdFire CPUs running
with MMU enabled. This is based on Freescales own M5475EVB demo board.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/configs/m5475evb_defconfig | 62
From: Greg Ungerer g...@uclinux.org
The ret_from_excption code is referenced by its function name, or by a label
set at the start of its code. Modify all uses to consistently just use the
function name ret_from_exception.
This will help when we come to merge the MMU and non-MMU entry code.
m68k: clean up and merge the MMU and non-MMU versions of entry.S
With a little cleanup we can use much of the entry.S code on both the
MMU and non-MMU m68k targets.
---
arch/m68k/kernel/entry.S| 452 +++-
arch/m68k/kernel/entry_mm.S | 422
From: Greg Ungerer g...@uclinux.org
There is a few places that the m68k entry code uses the bsrl instruction
to call other functions. That instruction is only supported on 68020 and
higher CPU types. If we use jbsr instead the code will be clean for all
68k and ColdFire CPU types.
Signed-off-by:
From: Greg Ungerer g...@uclinux.org
The uclinux.c map driver has traditionally been used only on non-MMU based
systems. But there is no fundamental reason it can't be used on systems
running with virtual memory.
Some ColdFire CPU based systems now have full paged MMU hardware and can use
the
From: Greg Ungerer g...@uclinux.org
The uclinux.c mapping driver uses ioremap_nocache() to map its physical
mapping address to a system virtual address. Problem is that the region
it is mapping is not device memory. It is ordinary system RAM. On most
non-MMU systems this doesn't matter, and the
From: Greg Ungerer g...@uclinux.org
Introduce cache_push() and cache_clear() functions for the non-MMU m68k
devices. With these in place we can more easily merge some of the common
m68k arch code.
In particular by reorganizing the __flush_caceh_all() code and separating
the cache push and clear
m68k: clean up and merge arch dma code
Much of the common m68k architecture dma code is the same for the MMU and
non-MMU cases. With a little cleanup of the m68knommu dma code first we
can then merge the two to end up with a single arch dma.c.
I have only tested a small number of ColdFire
From: Greg Ungerer g...@uclinux.org
The majority of the m68k architecture dma code is the same, so merge the
current separated files dma_no.c and dma_mm.c back into a single dma.c
The main alloc and free routines are a little different, so we keep a
single #ifdef based on CONFIG_MMU for them.
Currently the different ColdFire sub-archiectures are split up with a
directory for each family type. Most though only contain a small amount
of code, it just doesn't seem to make any sense to keep them separate.
Move all the ColdFire sub-architecture code into the platform/coldfire
directory,
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
From: Greg Ungerer g...@uclinux.org
We have very large tables in the ColdFire CPU GPIO setup code that essentially
boil down to 2 distinct types of GPIO pin initiaization. Using 2 macros we can
reduce these large tables to at most a dozen lines of setup code, and in quite
a few cases a single
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/520x/gpio.c | 149 ++-
1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/5206/gpio.c | 16 +---
1 files changed, 1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/523x/gpio.c | 264 ++-
1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/5272/gpio.c | 50 ++-
1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/5249/gpio.c | 33 ++---
1 files
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/527x/gpio.c | 604 +++-
1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/5407/gpio.c | 16 +---
1 files changed, 1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
We also need to rename some of the GPIO registers to be consistent with
all other ColdFire parts (we can't use the new GPIO macros
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/5307/gpio.c | 16 +---
1 files changed, 1
From: Greg Ungerer g...@uclinux.org
Modify the GPIO setup table to use the mcfgpio.h macros for table init.
Simplifies code and reduces line count significantly.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/platform/532x/gpio.c | 320 ++-
1
1 - 100 of 170 matches
Mail list logo
