2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-16 09:13:55 +08:00
Commit Graph

12 Commits

Author SHA1 Message Date
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
Linus Torvalds
b1bf7d4d1b GPIO driver changes for v3.5 merge window
Lots of gpio changes, both to core code and drivers.  Changes do touch
 architecture code to remove the need for separate arm/gpio.h includes
 in most architectures.  Some new drivers are added, and a number of
 gpio drivers are converted to use irq_domains for gpio inputs used as
 interrupts.  Device tree support has been amended to allow multiple
 gpio_chips to use the same device tree node.  Remaining changes are
 primarily bug fixes.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJPvpFBAAoJEEFnBt12D9kB50EP/0q2co+Ddlz4DWM07TLMgTw8
 eCSi79+oB85RcE+0FlAo/SJu9VlYDKSLT3wMbIyycfJi3cUtOb+hay0j+wxcn4bz
 G2qXj2Het5rX6hFI2tSCvJfDqMwU0wEygn9a6a/bw3VGSOIVmMTmRswrbbBcFzVu
 8xobviN7LANLEZyhd4Ip5YfrcWH9ABmmhZX7ihn1AJubVL47xGo0uds9ZFX1sAKB
 Zyr80+BeUK7mhZ74UUfQHtS+x24JD62OLM9eaQN0/BBAqBewQJlxhMakPbTGmcuO
 Vy3CPmZiWw6tdVWgKvxE7cIXLI4YbB2B6w2TRJBBkFAlz4RsO2bFU/ibEv1vg9YE
 oxAUelMj0INdY4iRT135fDJTIGauWon22Tqd2MVtun4r6fwcL0BgFYN6yCMtEqbx
 bpYkKTi6tdyE7k2Ph+carCIuw9SwOk/4pm1xCWC0k6YdAnRE0zykCLvAuAabpmzs
 i/H1jcp/F4KSYldEoDlGYG4lFZiISthxOy9l6/d4GrBj723attrmztolMfrpFLF6
 XPTf7HODQFmZ6n7mBIjCg4hoqydAYyKcW7lROc7DKkEXIWOeeeA+EoTytkwPLLz5
 CBLoZfDoqUT8xa2vv4MZ/+G9chSDi5vMryqEYi9tXMbVEZW31xqh6hxk0xPMcY13
 qVAaRlcz49AQjWq/0vR4
 =U6hj
 -----END PGP SIGNATURE-----

Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6

Pull GPIO driver changes from Grant Likely:
 "Lots of gpio changes, both to core code and drivers.

  Changes do touch architecture code to remove the need for separate
  arm/gpio.h includes in most architectures.

  Some new drivers are added, and a number of gpio drivers are converted
  to use irq_domains for gpio inputs used as interrupts.  Device tree
  support has been amended to allow multiple gpio_chips to use the same
  device tree node.

  Remaining changes are primarily bug fixes."

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (33 commits)
  gpio/generic: initialize basic_mmio_gpio shadow variables properly
  gpiolib: Remove 'const' from data argument of gpiochip_find()
  gpio/rc5t583: add gpio driver for RICOH PMIC RC5T583
  gpiolib: quiet gpiochip_add boot message noise
  gpio: mpc8xxx: Prevent NULL pointer deref in demux handler
  gpio/lpc32xx: Add device tree support
  gpio: Adjust of_xlate API to support multiple GPIO chips
  gpiolib: Implement devm_gpio_request_one()
  gpio-mcp23s08: dbg_show: fix pullup configuration display
  Add support for TCA6424A
  gpio/omap: (re)fix wakeups on level-triggered GPIOs
  gpio/omap: fix broken context restore for non-OFF mode transitions
  gpio/omap: fix missing check in *_runtime_suspend()
  gpio/omap: remove cpu_is_omapxxxx() checks from *_runtime_resume()
  gpio/omap: remove suspend/resume callbacks
  gpio/omap: remove retrigger variable in gpio_irq_handler
  gpio/omap: remove saved_wakeup field from struct gpio_bank
  gpio/omap: remove suspend_wakeup field from struct gpio_bank
  gpio/omap: remove saved_fallingdetect, saved_risingdetect
  gpio/omap: remove virtual_irq_start variable
  ...

Conflicts:
	drivers/gpio/gpio-samsung.c
2012-05-24 14:01:46 -07:00
Mark Brown
7563bbf89d gpiolib/arches: Centralise bolierplate asm/gpio.h
Rather than requiring architectures that use gpiolib but don't have any
need to define anything custom to copy an asm/gpio.h provide a Kconfig
symbol which architectures must select in order to include gpio.h and
for other architectures just provide the trivial implementation directly.

This makes it much easier to do gpiolib updates and is also a step towards
making gpiolib APIs available on every architecture.

For architectures with existing boilerplate code leave a stub header in
place which warns on direct inclusion of asm/gpio.h and includes
linux/gpio.h to catch code that's doing this.  Direct inclusion of
asm/gpio.h has long been deprecated.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Jonas Bonn <jonas@southpole.se>
Acked-by: Tony Luck <tony.luck@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-05-11 18:00:14 -06:00
Masanari Iida
6b2aac42b2 Fix typo in various Kconfig file
Correct spelling typo in various Kconfig file.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-04-16 14:40:08 +02:00
Greg Ungerer
1f7034b961 m68k: allow ColdFire 547x and 548x CPUs to be built with MMU enabled
The ColdFire 547x and 548x CPUs have internal MMU hardware. All code
to support this is now in, so we can build kernels with it enabled.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
2011-12-30 10:20:50 +10:00
Geert Uytterhoeven
ad8f955daf m68k/Kconfig: Separate classic m68k and coldfire early
While you can build multiplatform kernels for machines with classic
m68k processors, you cannot mix support for classic m68k and coldfire
processors. To avoid such hybrid kernels, introduce CONFIG_M68KCLASSIC
as an antipole for CONFIG_COLDFIRE, and make all specific processor
support depend on one of them.
All classic m68k machine support also needs to depend on this.

The defaults (CONFIG_M68KCLASSIC if MMU, CONFIG_COLDFIRE if !MMU) are
chosen such to make most of the existing configs build and work.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-30 10:20:49 +10:00
Greg Ungerer
e08d703cc2 m68k: modify user space access functions to support ColdFire CPUs
Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.

The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.

Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.

The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Matt Waddel <mwaddel@yahoo.com>
Acked-by: Kurt Mahan <kmahan@xmission.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-12-30 10:20:21 +10:00
Greg Ungerer
84f3fb7a2a m68k: handle presence of 64bit mul/div instructions cleanly
The traditional 68000 processors and the newer reduced instruction set
ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
divide instructions. This is not a difference based on the presence of
a hardware MMU or not.

Create a new config symbol to mark that a CPU type doesn't support the
longer multiply/divide instructions. Use this then as a basis for using
the fast 64bit based divide (in div64.h) and for linking in the extra
libgcc functions that may be required (mulsi3, divsi3, etc).

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-12-24 21:47:57 +10:00
Greg Ungerer
7f73bafc46 m68k: simpler m68k and ColdFire CPU's can use generic csum code
We have two implementations of the IP checksuming code for the m68k arch.
One uses the more advanced instructions available in 68020 and above
processors, the other uses the simpler instructions available on the
original 68000 processors and the modern ColdFire processors.

This simpler code is pretty much the same as the generic lib implementation
of the IP csum functions. So lets just switch over to using that. That
means we can completely remove the checksum_no.c file, and only have the
local fast code used for the more complex 68k CPU family members.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-24 21:47:57 +10:00
Greg Ungerer
5717a02bec m68k: selection of GENERIC_ATOMIC64 is not MMU specific
The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the
MMU being present and enabled. It is a property of certain CPU families.
So select it based on those CPU types being selected.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-24 21:47:57 +10:00
Greg Ungerer
0e152d8050 m68k: reorganize Kconfig options to improve mmu/non-mmu selections
The current mmu and non-mmu Kconfig files can be merged to form
a more general selection of options. The current break up of options
is due to the simple brute force merge from the m68k and m68knommu
arch directories.

Many of the options are not at all specific to having the MMU enabled
or not. They are actually associated with a particular CPU type or
platform type.

Ultimately as we support all processors with the MMU disabled we need
many of these options to be selectable without the MMU option enabled.
And likewise some of the ColdFire processors, which currently are only
supported with the MMU disabled, do have MMU hardware, and will need
to have options selected on CPU type, not MMU disabled.

This patch removes the old mmu and non-mmu Kconfigs and instead breaks
up the configuration into four areas: cpu, machine, bus, devices.

The Kconfig.cpu lists all the options associated with selecting a CPU,
and includes options specific to each CPU type as well.

Kconfig.machine lists all options associated with selecting a machine
type. Almost always the machines selectable is restricted by the chosen
CPU.

Kconfig.bus contains options associated with selecting bus types on the
various machine types. That includes PCI bus, PCMCIA bus, etc.

Kconfig.devices contains options for drivers and driver associated
options.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-10-18 14:22:25 +10:00