2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-23 04:34:11 +08:00
Commit Graph

28 Commits

Author SHA1 Message Date
Linus Torvalds
977b58e1dd Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu updates from Greg Ungerer:
 "The bulk of the changes are generalizing the ColdFire v3 core support
  and adding in 537x CPU support.  Also a couple of other bug fixes, one
  to fix a reintroduction of a past bug in the romfs filesystem nommu
  support."

* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68knommu: enable Timer on coldfire 532x
  m68knommu: fix ColdFire 5373/5329 QSPI base address
  m68knommu: add support for configuring a Freescale M5373EVB board
  m68knommu: add support for the ColdFire 537x family of CPUs
  m68knommu: make ColdFire M532x platform support more v3 generic
  m68knommu: create and use a common M53xx ColdFire class of CPUs
  m68k: remove unused asm/dbg.h
  m68k: Set ColdFire ACR1 cache mode depending on kernel configuration
  romfs: fix nommu map length to keep inside filesystem
  m68k: clean up unused "config ROMVECSIZE"
2013-05-10 07:22:35 -07:00
Greg Ungerer
e9d9dc6ac2 m68knommu: add support for the ColdFire 537x family of CPUs
The ColdFire 537x family is very similar internally to the ColdFire 532x
family. So with just a little extra configuration we can configure and
target them as well.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2013-04-29 09:17:58 +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
Alexandre Courbot
765278b7d5 m68k: coldfire: use gpiolib
Force use of gpiolib for Coldfire, as a step towards the deprecation of
GENERIC_GPIO.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
2013-03-21 15:16:46 +09:00
Linus Torvalds
aed606e3bc Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu updates from Greg Ungerer:
 "This one has a major restructuring of the non-mmu 68000 support.

  It merges all the related SoC types that use the original 68000 cpu
  core internally so they can share the same core code.  It also allows
  for supporting the original stand alone 68000 cpu in its own right.

  There is also a generalization of the clock support of the ColdFire
  parts, some merging of common ColdFire code, and a couple of bug fixes
  as well."

* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68knommu: modify clock code so it can be used by all ColdFire CPU types
  m68knommu: add clock definitions for 54xx ColdFire CPU types
  m68knommu: add clock definitions for 5407 ColdFire CPU types
  m68knommu: add clock definitions for 5307 ColdFire CPU types
  m68knommu: add clock definitions for 528x ColdFire CPU types
  m68knommu: add clock definitions for 527x ColdFire CPU types
  m68knommu: add clock definitions for 5272 ColdFire CPU types
  m68knommu: add clock definitions for 525x ColdFire CPU types
  m68knommu: add clock definitions for 5249 ColdFire CPU types
  m68knommu: add clock definitions for 523x ColdFire CPU types
  m68knommu: add clock definitions for 5206 ColdFire CPU types
  m68knommu: add clock creation support macro for other ColdFire CPUs
  m68k: fix unused variable warning in mempcy.c
  m68knommu: make non-MMU page_to_virt() return a void *
  m68knommu: merge ColdFire 5249 and 525x definitions
  m68knommu: disable MC68000 cpu target when MMU is selected
  m68knommu: allow for configuration of true 68000 based systems
  m68knommu: platform code merge for 68000 core cpus
2012-12-16 17:42:21 -08:00
Luis Alves
9da1a84a91 m68knommu: disable MC68000 cpu target when MMU is selected
As pointed out by Geert, MC68000 target needs to be disabled when
MMU support is enabled.

From Geert:

This needs a "depends on !MMU".
Else allmodconfig will select it, causing -m68000 to be passed to the assembler,
which may break the build depending on your version of binutils, a.o.

arch/m68k/kernel/entry.S:186: Error: invalid instruction for this
architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030
[68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `bfextu
%sp@(50){#0,#4},%d0' ignored
arch/m68k/kernel/entry.S:211: Error: invalid operand mode for this
architecture; needs 68020 or higher -- statement `jbsr
@(sys_call_table,%d0:l:4)@(0)' ignored

Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/7416877/

Signed-off-by: Luis Alves <ljalvs@gmail.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05 10:51:20 +10:00
Luis Alves
4674e8d385 m68knommu: allow for configuration of true 68000 based systems
Allow the M68000 option to be user configurable, for systems based on
the original stand alone 68000 CPU.

Signed-off-by: Luis Alves <ljalvs@gmail.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-12-05 10:49:50 +10:00
Kees Cook
112f8b1294 arch/m68k: remove CONFIG_EXPERIMENTAL
This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.

CC: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2012-11-14 08:50:54 +01:00
Greg Ungerer
42b1b94635 m68k: select CONFIG_GENERIC_ATOMIC64 for all m68k CPU types
There is no specific atomic64 support code for any m68k CPUs, so we should
select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection
of this and select it for all m68k.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2012-08-17 10:04:24 +10:00
Greg Ungerer
e7d6582e04 m68knommu: select CONFIG_HAVE_CLK for ColdFire CPU types
The ColdFire CPU sub-arch has kernel clk code support, so select
CONFIG_HAVE_CLK.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-08-17 10:04:23 +10:00
Linus Torvalds
587a9e1f95 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k updates from Geert Uytterhoeven.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
  m68k: Make sys_atomic_cmpxchg_32 work on classic m68k
  m68k/apollo: Rename "timer" to "apollo_timer"
  zorro: Remove unused zorro_bus.devices
  m68k: Remove never used asm/shm.h
  m68k/sun3: Remove unselectable code in prom_init()
  m68k: Use asm-generic version of <asm/sections.h>
  m68k: Replace m68k-specific _[se]bss by generic __bss_{start,stop}
  mtd/uclinux: Use generic __bss_stop instead of _ebss
  m68knommu: Allow ColdFire CPUs to use unaligned accesses
  m68k: Remove five unused headers
  m68k: CPU32 does not support unaligned accesses
  m68k: Introduce config option CPU_HAS_NO_UNALIGNED
  m68k: delay, muldi3 - Use CONFIG_CPU_HAS_NO_MULDIV64
  m68k: Move CPU_HAS_* config options
  m68k: Remove duplicate FPU config option
  m68knommu: Clean up printing of sections
  m68k: Use asm-generic version of <asm/types.h>
  m68k: Use Kbuild logic to import asm-generic headers
2012-08-03 10:52:41 -07: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
dfe1d26d4a m68knommu: Allow ColdFire CPUs to use unaligned accesses
All of the current Linux supported ColdFire CPUs handle unaligned
memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option
selection for ColdFire. If we ever support a specific ColdFire CPU
that does not support unaligned accesses then we can insert the
CONFIG_CPU_HAS_NO_UNALIGNED for that specific CPU type.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2012-06-27 09:28:50 +02:00
Geert Uytterhoeven
7df0d27f3d m68k: CPU32 does not support unaligned accesses
Hence select CPU_HAS_NO_UNALIGNED

Reported-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>
2012-06-10 10:18:33 +02:00
Geert Uytterhoeven
9f1f118035 m68k: Introduce config option CPU_HAS_NO_UNALIGNED
Use CONFIG_CPU_HAS_NO_UNALIGNED instead of open coding CONFIG_M68000 ||
CONFIG_COLDFIRE

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>
2012-06-10 10:18:32 +02:00
Geert Uytterhoeven
022613e0b0 m68k: Move CPU_HAS_* config options
They belong together with the CPU selection

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>
2012-06-10 10:18:29 +02: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