History log of /arch/m68k/include/asm/gpio.h
Revision Date Author Comments
cf6c31fc5c3de225348742c95cc6185fca20a2f2 29-Apr-2013 Greg Ungerer <gerg@uclinux.org> m68k: only use local gpio_request_one if not using GPIOLIB

Compiling for targets that use the local gpio code (not GPIOLIB) fail to
compile with:

CC arch/m68k/platform/coldfire/device.o
In file included from include/linux/gpio.h:45:0,
from arch/m68k/platform/coldfire/device.c:15:
/home/gerg/new-wave.git/linux-3.x/arch/m68k/include/asm/gpio.h:89:19: error: static declaration of ‘gpio_request_one’ follows non-static declaration
include/asm-generic/gpio.h:195:12: note: previous declaration of ‘gpio_request_one’ was here

Fix by conditionally using the local gpio_request_one() function based on
!CONFIG_GPIOLIB.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
b2dfaa8d33cee9dd4ed78979f5d70063df546101 08-Apr-2013 Greg Ungerer <gerg@uclinux.org> m68k: define a local gpio_request_one() function

Compiling for linux-3.9-rc1 and later fails with:

drivers/gpio/devres.c: In function 'devm_gpio_request_one':
drivers/gpio/devres.c:90:2: error: implicit declaration of function 'gpio_request_one' [-Werror=implicit-function-declaration]

So provide a local gpio_request_one() function. Code largely borrowed from
blackfin's local gpio_request_one() function.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
bea8bcb12da09bd35cdada395d0d0db1aee2ba4c 06-Jun-2012 Steven King <sfking@fdwdc.com> m68knommu: Add support for the Coldfire m5441x.

Add support for the Coldfire 5441x (54410/54415/54416/54417/54418). Currently
we only support noMMU mode. It requires the PIT patch posted previously as it
uses the PIT instead of the dma timer as a clock source so we can get all that
GENERIC_CLOCKEVENTS goodness. It also adds some simple clk definitions and
very simple minded power management. The gpio code is tweeked and some
additional devices are added to devices.c. The Makefile uses -mv4e as
apparently, the only difference a v4m (m5441x) and a v4e is the later has a
FPU, which I don't think should matter to us in the kernel.

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
eac57949947fa24f47a2e993a1dbbfdb573b4301 21-May-2012 Steven King <sfking@fdwdc.com> m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate mcf_gpio_chips.

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, gpiolib can check that it doesn't fall in one of the holes. If thats
important, I think we can still come up with a better way of accomplishing
that.

Also in this patch is some general cleanup and reorganizing of the gpio header
files (I'm sure I must have had a reason why I sometimes used a prefix of
mcf_gpio and other times mcfgpio but for the life of me I can't think of it
now).

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
d85b40948654dee3be1d8e43b0fce511c1b42d78 26-Oct-2011 Mark Brown <broonie@opensource.wolfsonmicro.com> m68k: Fall back to __gpio_to_irq() for non-arch GPIOs

gpiolib provides __gpio_to_irq() to map gpiolib gpios to interrupts - hook
that up on m68k.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
5b2e6555ac3eb58a4e5eb5020471df08f0c42c01 01-Nov-2010 Greg Ungerer <gerg@uclinux.org> m68knommu: make Coldfire 548x support more generic

The ColdFire 547x family of processors is very similar to the ColdFire
548x series. Almost all of the support for them is the same. Make the
code supporting the 548x more gneric, so it will be capable of
supporting both families.

For the most part this is a renaming excerise to make the support
code more obviously apply to both families.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
ea49f8ffae6262e8de9a0d3e9fcdd384156c7e05 20-Sep-2010 Philippe De Muyter <phdm@macqel.be> m68knommu: add basic mmu-less m548x support

Add a very basic mmu-less support for coldfire m548x family. This is perhaps
also valid for m547x family. The port comprises the serial, tick timer and
reboot support. The gpio part compiles but is empty. This gives a functional
albeit limited linux for the m548x coldfire family. This has been tested
on a Freescale M548xEVB Lite board with a M5484 processor and the default
dbug monitor.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
af39bb8b07af83b579c90c09ba3943123cdb4132 20-Jun-2009 sfking@fdwdc.com <sfking@fdwdc.com> core generic GPIO support for Freescale Coldfire processors.

This adds the basic infrastructure used by all of the different Coldfire CPUs.

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>