summaryrefslogtreecommitdiff
path: root/arch/m68k/include/asm/gpio.h
AgeCommit message (Collapse)Author
2013-05-29m68k: only use local gpio_request_one if not using GPIOLIBGreg Ungerer
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>
2013-04-09m68k: define a local gpio_request_one() functionGreg Ungerer
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>
2012-07-16m68knommu: Add support for the Coldfire m5441x.Steven King
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>
2012-07-16m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate ↵Steven King
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>
2011-12-24m68k: Fall back to __gpio_to_irq() for non-arch GPIOsMark Brown
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>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-01-05m68knommu: make Coldfire 548x support more genericGreg Ungerer
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>
2010-10-21m68knommu: add basic mmu-less m548x supportPhilippe De Muyter
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>
2009-09-10core generic GPIO support for Freescale Coldfire processors.sfking@fdwdc.com
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>