gmane.linux.uclinux.devel

[PATCH] m68knommu: Add quirk and force fec to useRMII mode for m5441x.

Steven King — 2012-05-23T21:52:40

The m5441x enet-fec aren't quite the same as the fec found on other Coldfire 
parts, so we need a quirk to help the fec do the right thing and on the 
twr-mcf5441x atleast, we need to force the phy into RMII mode.


Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/platform/coldfire/device.c |   19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/platform/coldfire/device.c b/arch/m68k/platform/coldfire/device.c
index 11ecd23..ab88b69 100644
--- a/arch/m68k/platform/coldfire/device.c
+++ b/arch/m68k/platform/coldfire/device.c
< at >< at > -13,6 +13,7 < at >< at >
 #include <linux/io.h>
 #include <linux/spi/spi.h>
 #include <linux/gpio.h>
+#include <linux/fec.h>
 #include <asm/traps.h>
 #include <asm/coldfire.h>
 #include <asm/mcfsim.h>
< at >< at > -89,6 +90,18 < at >< at > static struct platform_device mcf_uart = {
 };
 
 #ifdef CONFIG_FEC
+
+#ifdef CONFIG_M5441x
+#define FEC_NAME"enet-fec"
+static struct fec_platform_data fec_pdata = {
+.phy= PHY_INTERFACE_MODE_RMII,
+};
+#define FEC_PDA

[RFC/PATCH] m68knommu: add support for Coldfire m5441x

Steven King — 2012-05-23T02:03:59

The 5441x (54410/54415/54416/54417/54418) is similar to the 532x in the same 
way the 532x is similar to the 5208; it doesn't have either IPSBAR nor MBAR, 
instead everything resides at a fixed address.  Many of the registers common 
between the 5441x and the 532x live at the same address as the 532x, but of 
course the 5441x has a v4e core, cache and mmu, along with 10 uarts! 6 i2c 
controllers, 4 dma capable spi controllers, usb and much more.  This patch is 
just a quick and dirty hack to get it booting on the twr-mcf5441x board.  Its 
currently nommu only (well, I havent even tried it with the mmu),  It doesnt 
include support for the 2 fec controllers, the ones on the 5441x are just 
slightly different in some non obvious way so they dont quite work yet.

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/Kconfig.cpu                   |    7 +
 arch/m68k/Kconfig.machine               |    1 -
 arch/m68k/Makefile                      |    1 +
 arch/m68k/include/asm/gpio.h            |   11 +-

[RFC/PATCH] m68knommu: refactor Coldfire GPIO not torequire GPIOLIB, eliminate mcf_gpio_chips.

Steven King — 2012-05-21T20:10:19

If we're not connecting external GPIO extenders via i2c or spi or whatever, we 
probably don't need GPIOLIB.  If we provide an alternate implementation of 
the GPIOLIB functions to use when only on-chip GPIO is needed, we can change 
ARCH_REQUIRE_GPIOLIB to ARCH_WANTS_OPTIONAL_GPIOLIB so that GPIOLIB becomes 
optional.

The downside is that in the GPIOLIB=n case, we lose all error checking done by 
gpiolib, ie multiply allocating the gpio, free'ing gpio etc., so that the 
only checking that can be done is if we reference a gpio on an external part. 
Targets that need the extra error checking can still select GPIOLIB=y.

For the case where GPIOLIB=y, we can simplify the table of gpio chips to use a 
single chip, eliminating the tables of chips in the 5xxx.c files.  The 
original motivation for the definition of multiple chips was to match the way 
many of the Coldfire variants defined their gpio as a spare array in memory.  
However, all this really gains us is some error checking when we request a 
gpio, gpi

[PATCH V3] m68knommu: driver for Freescale ColdfireI2C controller.

Steven King — 2012-05-17T02:10:35

D'oh!  I really dropped the ball on this, but I figure better late than never ;-).

Changes since V2:

drivers/i2c/busses/i2c-coldfire.c:
* As Ben suggested, making the interrupt handler do most of the message
  processing and wake the thread when its done vastly improves performance.
* preliminary support for PM_RUNTIME; but as there isn't arch support for for 
  PM_RUNTIME it doesn't do anything yet.
* fixed a bug when the driver would hang on waiting for bus busy if the bus
  never went busy.

drivers/i2c/busses/Kconfig:
* its easier to list the Coldfire MCUs that don't have I2C.

arch/m68k/include/asm/mcfi2c.h:
* moved the defines for the various Coldfire MCUs to the specific header
   file for the various Coldfire MCUs. 


Support for the Freescale Coldfire I2C controller.

Signed-off-by: Steven King <sfking< at >fedc.com>
---
 arch/m68k/include/asm/mcfi2c.h    |   15 ++
 drivers/i2c/busses/Kconfig        |   10 +
 drivers/i2c/busses/Makefile       |    1 +
 drivers/i2c/busses/i2c-coldfire.c |  497 +++++++++

[PATCH] m68k: add a defconfig for the M5475EVBColdFire with MMU board

2012-05-15T06:42:58

From: Greg Ungerer <gerg< at >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 <gerg< at >uclinux.org>
---
 arch/m68k/configs/m5475evb_defconfig |   62 ++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)
 create mode 100644 arch/m68k/configs/m5475evb_defconfig

diff --git a/arch/m68k/configs/m5475evb_defconfig b/arch/m68k/configs/m5475evb_defconfig
new file mode 100644
index 0000000..c5018a6
--- /dev/null
+++ b/arch/m68k/configs/m5475evb_defconfig
< at >< at > -0,0 +1,62 < at >< at >
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+CONFIG_SYSCTL_SYSCALL=y
+# CONFIG_KALLSYMS is not set
+# CONFIG_HOTPLUG is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_SHMEM is not set
+# CONF

[PATCH] mtd: clean up uclinux.c map driver

2012-05-15T04:08:48

From: Greg Ungerer <gerg< at >uclinux.org>

Perform a number of cleanups on the uclinux.c map driver.
No structural or semantic changes, only minor cleanups.

. insert appropriate prefix into printk() calls
. remove redundant "if" checks in the module exit code
. remove unnecessary includes
. make the struct uclinux_ram_map static
. cast the virtual address calculations to keep them sparse clean

Signed-off-by: Greg Ungerer <gerg< at >uclinux.org>
---
 drivers/mtd/maps/uclinux.c |   34 +++++++++++++---------------------
 1 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 6d43c75..d91b5b4 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
< at >< at > -12,19 +12,16 < at >< at >
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
-#include <linux/fs.h>
 #include <linux/mm.h>
-#include <linux/major.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/map.h>
 #include <linux/mtd/partitions.h>
-#include <asm/io.h>
 
 /***

Latest GCC toolchain for m68k

Luis Alves — 2012-05-14T15:07:52

Hi,

I'm currently using the 'experimental' pre-built gcc toolchain from
<http://www.uclinux.org/pub/uClinux/arm-elf-tools/tools-20080626/m68k-uclinux-tools-20080626.sh>
to build my uClinux-dist.

I've never found any issue with that package, so I didn't even bother
to build my own toolchain.

But now I'm wondering: Is there a newer/better pre-built toolchain, or
sorces for building a more recent one.


Thanks,
Luis
_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[RFC] m68knommu: Add support for the Freescalem5253demo board.

Steven King — 2012-05-14T00:50:04

Basic support for the m5253demo board from Freescale.  This is a work in
progress, currently only the dm9000 ethernet interface is supported.  More
patches to come ;)

This patch is against the v3.4-rc6 for_next branch of the m68knommu.git

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/Kconfig.machine               |    7 ++
 arch/m68k/include/asm/io_no.h           |    8 ++
 arch/m68k/include/asm/m525xsim.h        |    4 +
 arch/m68k/platform/coldfire/Makefile    |    1 +
 arch/m68k/platform/coldfire/m5253demo.c |  125 +++++++++++++++++++++++++++++++
 5 files changed, 145 insertions(+)

diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 7cdf6b0..10c97dc 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
< at >< at > -252,6 +252,13 < at >< at > config M5249C3
 help
   Support for the Motorola M5249C3 board.
 
+config M5253DEMO
+bool "Freescale M5253DEMO board support"
+depends on M525x
+select FREESCALE
+help
+  Support for the Freescale M5253DEMO board.
+
 config

[RFC] m68knommu: add support for Coldfire 5251/5253.

Steven King — 2012-05-14T00:44:44

The 5251/5253 is quite similar to the 5249, adding basic support for it is
fairly trivial.  This is a work in progress, not much support for anything
beyond the basic Coldfire core is implemented yet, but more patches to
come ;)

This patch is against the v3.4-rc6 for_next branch of the m68knommu.git

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/Kconfig.cpu                   |    8 ++
 arch/m68k/Makefile                      |    1 +
 arch/m68k/include/asm/dma.h             |    4 +-
 arch/m68k/include/asm/gpio.h            |    6 +-
 arch/m68k/include/asm/m525xsim.h        |  195 +++++++++++++++++++++++++++++++
 arch/m68k/include/asm/mcfsim.h          |    3 +
 arch/m68k/include/asm/mcfuart.h         |    4 +-
 arch/m68k/platform/coldfire/Makefile    |    1 +
 arch/m68k/platform/coldfire/head.S      |    6 +-
 arch/m68k/platform/coldfire/intc-525x.c |   91 +++++++++++++++
 arch/m68k/platform/coldfire/m525x.c     |   58 +++++++++
 drivers/spi/Kconfig                     |    2 +-
 12 files ch

[PATCH] spi: refactor spi-coldfire-qspi to use SPIqueue framework.

Steven King — 2012-05-10T16:26:55

Use the new SPI queue framework; remove use of workqueue, replace
mcfqspi_transfer with mcfqspi_transfer_one_message, add
mcfqspi_prepare_transfer_hw and mcfqspi_unprepare_transfer_hw, update power
management routines.

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 drivers/spi/spi-coldfire-qspi.c |  255 +++++++++++++++++---------------------
 1 files changed, 114 insertions(+), 141 deletions(-)

diff --git a/drivers/spi/spi-coldfire-qspi.c b/drivers/spi/spi-coldfire-qspi.c
index 6eee64a..b2d4b9e 100644
--- a/drivers/spi/spi-coldfire-qspi.c
+++ b/drivers/spi/spi-coldfire-qspi.c
< at >< at > -25,12 +25,12 < at >< at >
 #include <linux/errno.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
-#include <linux/workqueue.h>
 #include <linux/delay.h>
 #include <linux/io.h>
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/spi/spi.h>
+#include <linux/pm_runtime.h>
 
 #include <asm/coldfire.h>
 #include <asm/mcfsim.h>
< at >< at > -78,10 +78,7 < at >< at > struct mcfqspi {
 
 wait_queue_head_t waitq;
 
-struct work_struc

[PATCH 1/2] mtd: fix wrong usage of ioremap_nocache()in uclinux.c map driver

2012-05-10T06:55:28

From: Greg Ungerer <gerg< at >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 mapping is always a 1:1
translation of the address.

But if we want to use the uclinux.c mapping driver on real MMU enabled
systems we should be using phys_to_virt() for the translation, since that
is really what we are doing. So change it to do that.

Signed-off-by: Greg Ungerer <gerg< at >uclinux.org>
---
 drivers/mtd/maps/uclinux.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index cfff454..6d43c75 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
< at >< at > -68,10 +68,10 < at >< at > static int __init uclinux_mtd_init(void)
 printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n",
        (int) mapp->phys, (int) map

[PATCH v2] m68knommu: enable qspi support whenSPI_COLDFIRE_QSPI = m

Steven King — 2012-05-06T19:22:53

Enable Coldfire QSPI support when SPI_COLDFIRE_QSPI is built as a module.

This version of the patch combines changes to the config files and  device.c
and uses IF_ENABLED (thanks to Sam Ravnborg for the suggestion).

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/platform/520x/config.c     |    6 +++---
 arch/m68k/platform/523x/config.c     |    6 +++---
 arch/m68k/platform/5249/config.c     |    6 +++---
 arch/m68k/platform/527x/config.c     |    6 +++---
 arch/m68k/platform/528x/config.c     |    6 +++---
 arch/m68k/platform/532x/config.c     |    6 +++---
 arch/m68k/platform/coldfire/device.c |    6 +++---
 7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/m68k/platform/520x/config.c b/arch/m68k/platform/520x/config.c
index 2359478..09df4b8 100644
--- a/arch/m68k/platform/520x/config.c
+++ b/arch/m68k/platform/520x/config.c
< at >< at > -22,7 +22,7 < at >< at >
 
 /***************************************************************************/
 
-#ifdef CONFIG_SPI_COLDFIRE_QSPI
+#if IS_ENABLED

[PATCH] m68knommu: enable device config whenSPI_COLDFIRE_QSPI=m

Steven King — 2012-05-06T00:34:42

Hi Greg,

The qspi consolidation omitted support for device initialization when the qspi
is built as a module.

Signed-off-by: Steven King <sfking< at >fdwdc.com>

---
 arch/m68k/platform/520x/config.c |    6 +++---
 arch/m68k/platform/523x/config.c |    6 +++---
 arch/m68k/platform/5249/config.c |    6 +++---
 arch/m68k/platform/527x/config.c |    6 +++---
 arch/m68k/platform/528x/config.c |    6 +++---
 arch/m68k/platform/532x/config.c |    6 +++---
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/m68k/platform/520x/config.c b/arch/m68k/platform/520x/config.c
index 2359478..621fe15 100644
--- a/arch/m68k/platform/520x/config.c
+++ b/arch/m68k/platform/520x/config.c
< at >< at > -22,7 +22,7 < at >< at >
 
 /***************************************************************************/
 
-#ifdef CONFIG_SPI_COLDFIRE_QSPI
+#if defined(CONFIG_SPI_COLDFIRE_QSPI) || defined(CONFIG_SPI_COLDFIRE_QSPI_MODULE)
 
 static void __init m520x_qspi_init(void)
 {
< at >< at > -35,7 +35,7 < at >< at > static void __init m520x_qspi_init(void)
 write

[PATCH] m68knommu: enable device init whenSPI_COLDFIRE_QSPI = m

Steven King — 2012-05-05T21:00:24

Hi Greg,

The qspi consolidation omitted support for device initialization when the qspi
is built as a module.

Signed-off-by: Steven King <sfking< at >fdwdc.com>

---
 arch/m68k/platform/coldfire/device.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/platform/coldfire/device.c b/arch/m68k/platform/coldfire/device.c
index 7af9736..a8c50b0 100644
--- a/arch/m68k/platform/coldfire/device.c
+++ b/arch/m68k/platform/coldfire/device.c
< at >< at > -121,7 +121,7 < at >< at > static struct platform_device mcf_fec1 = {
 #endif /* MCFFEC_BASE1 */
 #endif /* CONFIG_FEC */
 
-#ifdef CONFIG_SPI_COLDFIRE_QSPI
+#if defined(CONFIG_SPI_COLDFIRE_QSPI) || defined(CONFIG_SPI_COLDFIRE_QSPI_MODULE)
 /*
  *The ColdFire QSPI module is an SPI protocol hardware block used
  *on a number of different ColdFire CPUs.
< at >< at > -284,7 +284,7 < at >< at > static struct platform_device *mcf_devices[] __initdata = {
 &mcf_fec1,
 #endif
 #endif
-#ifdef CONFIG_SPI_COLDFIRE_QSPI
+#if defined(CONFIG_SPI_COLDFIRE_QSPI) || defined(CONFIG_SPI_CO

m528x qspi definition fix

Steven King — 2012-05-05T20:40:44

Hi Greg,

The consolidation of the qspi code missed a definition for 528x.

Signed-off-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/include/asm/m528xsim.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/m68k/include/asm/m528xsim.h 
b/arch/m68k/include/asm/m528xsim.h
index 569476f..7c92dc4 100644
--- a/arch/m68k/include/asm/m528xsim.h
+++ b/arch/m68k/include/asm/m528xsim.h
< at >< at > -86,7 +86,7 < at >< at >
 /*
  *QSPI module.
  */
-#defineMCFQSPI_IOBASE(MCF_IPSBAR + 0x340)
+#defineMCFQSPI_BASE(MCF_IPSBAR + 0x340)
 #defineMCFQSPI_SIZE0x40
 
 #defineMCFQSPI_CS0147
_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

rrdtool: crashing when rendering graphics (m68ktarget)

Luis Alves — 2012-05-04T09:58:03

Hi,

I've tried the 'rrdtool' included in the latest uClinux dist (20120401).
Creating the database, inserting and fetching values work fine, but
when I try to create a .png chart it do one of these two things:
1) Crash the kernel (I'm almost sure it writes in bad memory locations)
2) Give an 'Address Error' trap.

Before I start to dig the code to find the issue (if I ever get time
to do it), has anyone used this tool in a m68k target? If yes, does it
work good?
What about in other nommu targets?

Thanks,
Luis
_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Blackfin: fast OS restore?

Jerry Evans — 2012-05-01T13:32:54

Hello. I'm writing firmware for a BF526 based device that has to operate 
in very low power mode for extended periods of time. Prototypes 
typically sleep for ~30s, keeping code in SDRAM in self-refresh mode, 
wake for a few seconds to do the necessary processing, then return to 
sleep. With existing code we can restore operations in 60-100ms.

Is anyone aware of any techniques (hacks?) that would allow uClinux to 
be restored in similar time-frames? Or what reasonable time frames might 
be for uClinux?

Any help greatly appreciated.

Jerry.


_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Running linux with mmu disabled on arm (AT91).

Paul Chavent — 2012-05-01T15:24:48

Hi.

I'd like to try linux on an AT91SAM9G20 (i have a linuxstamp board), with MMU disabled (the Hyok-Sung Choi & Hee-Chul Yun paper demonstrate that it could be possible).

All the code seems to be present in the kernel...
So i would like to share my experience.

(1) I had to make two little changes in the kernel code :
     - I'm not able to change the REMAP_VECTOR_TO_DRAM. I have submitted the problem to the kbuild mailing list (http://www.spinics.net/lists/linux-kbuild/msg06153.html).
     - The soc_detect code that init the at91_soc_initdata structure is never called. Later this structure is used unitialized.
     I'm currently using the joined patch as a workaround. Someone can review it please ?

(2) I used to run the module with a "classic system" based on linux + eglibc, and i needed only one toolchain (arm-xxx-linux-gnueabi) for the kernel and the userspace apps.
     I found that for the nommu case i wasn't able to build the kernel with the userspace toolchain.
     So I had to build 2 toolchain,

Blackfin: Fast OS restore

2012-05-01T14:12:53

I'm writing firmware for a BF526 based device that has to operate in 
very low power mode for extended periods of time. Prototypes typically 
sleep for ~30s, keeping code in SDRAM in self-refresh mode, wake for a 
few seconds to do the necessary processing, then return to sleep. With 
existing code we can restore operations in 60-100ms.

Is anyone aware of any techniques (hacks?) that would allow uClinux to 
be restored in similar time-frames? Or what reasonable time frames might 
be for uClinux?

Any help greatly appreciated.

Jerry.


_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

something is wrong

Martin Mensch — 2012-04-26T18:59:26

Hi, something seems to be wrong with this list.
I am subscribed for months now an didn't get anything except a monthly (?) password reminder. I guess I set this behaviour in my profile. But now I seem to get everything.
Did you change something lately?

Martin
_______________________________________________
uClinux-dev mailing list
uClinux-dev< at >uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev< at >uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[PATCH v2 01/22] m68knommu: introduce macros tosimplify ColdFire GPIO table initialization

2012-04-26T13:14:51

From: Greg Ungerer <gerg< at >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 table entry.

Introduce these 2 macros into the existing mcfgpio.h header.

Signed-off-by: Greg Ungerer <gerg< at >uclinux.org>
Acked-by: Steven King <sfking< at >fdwdc.com>
---
 arch/m68k/include/asm/mcfgpio.h |   54 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/m68k/include/asm/mcfgpio.h b/arch/m68k/include/asm/mcfgpio.h
index ee5e4cc..cd28830 100644
--- a/arch/m68k/include/asm/mcfgpio.h
+++ b/arch/m68k/include/asm/mcfgpio.h
< at >< at > -37,4 +37,58 < at >< at > void mcf_gpio_set_value_fast(struct gpio_chip *, unsigned, int);
 int mcf_gpio_request(struct gpio_chip *, unsigned);
 void mcf_gpio_free(struct gpio_chip *, unsigned);
 
+/*
+ *Define macros to ease the pain of setting u