1
0
Fork 0
Commit Graph

9 Commits (8e8e69d67e5fad1a1edf97acebd649a6c8f1febd)

Author SHA1 Message Date
Thomas Gleixner 8e8e69d67e treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 285
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation version 2 of the license this program
  is distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 100 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141900.918357685@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05 17:36:37 +02:00
Steven King 83c6bdb827 m68knommu: Implement gpio support for m54xx.
Singed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2014-05-26 13:28:38 +10:00
Greg Ungerer 6eac402783 m68knommu: create and use a common M53xx ColdFire class of CPUs
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>
2013-04-29 09:17:58 +10:00
Steven King bea8bcb12d 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>
2012-07-16 09:59:21 +10:00
Steven King 04e037aa4e m68knommu: Add support for the Coldfire 5251/5253
Basic support for the Coldfire 5251/5253.

Signed-off-by: Steven king <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16 09:59:21 +10:00
Steven King eac5794994 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>
2012-07-16 09:59:21 +10:00
Greg Ungerer f23c144d42 m68knommu: make duplicated ColdFire GPIO init code common for all
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>
2012-05-20 21:21:47 +10:00
Greg Ungerer c269d4efaa m68knommu: introduce macros to simplify ColdFire GPIO table initialization
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>
2012-05-20 21:21:35 +10:00
sfking@fdwdc.com af39bb8b07 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>
2009-09-10 12:01:22 +10:00