summaryrefslogtreecommitdiffstats
path: root/arch/m68k/include/asm/mcfgpio.h
Commit message (Collapse)AuthorAgeFilesLines
* m68knommu: Implement gpio support for m54xx.Steven King2014-05-261-4/+8
| | | | | Singed-off-by: Steven King <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: create and use a common M53xx ColdFire class of CPUsGreg Ungerer2013-04-291-5/+5
| | | | | | | | | | | | | 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 definitions. Create a CONFIG_M53xx option that is enabled to support any of the common 532x and 537x CPU types. Convert the current users of CONFIG_M532x to use CONFIG_M53xx instead. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: Add support for the Coldfire m5441x.Steven King2012-07-161-8/+22
| | | | | | | | | | | | | | 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>
* m68knommu: Add support for the Coldfire 5251/5253Steven King2012-07-161-4/+4
| | | | | | | Basic support for the Coldfire 5251/5253. Signed-off-by: Steven king <sfking@fdwdc.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: refactor Coldfire GPIO not to require GPIOLIB, eliminate ↵Steven King2012-07-161-68/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* m68knommu: make duplicated ColdFire GPIO init code common for allGreg Ungerer2012-05-201-0/+3
| | | | | | | | | The code that adds each ColdFire platforms GPIO signals is duplicated in each platforms specific code. Remove it from each platforms code and put a single version in the existing ColdFire gpio subsystem init code. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Steven King <sfking@fdwdc.com>
* m68knommu: introduce macros to simplify ColdFire GPIO table initializationGreg Ungerer2012-05-201-0/+54
| | | | | | | | | | | | 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@uclinux.org> Acked-by: Steven King <sfking@fdwdc.com>
* core generic GPIO support for Freescale Coldfire processors.sfking@fdwdc.com2009-09-101-0/+40
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>
OpenPOWER on IntegriCloud