Commit Graph

14 Commits

Author SHA1 Message Date
Linus Torvalds
fe78c54b47 ARM: SoC/OMAP GPMC driver cleanup and move for 3.19
The GPMC driver has traditionally been considered a part of the
 OMAP platform code and tightly interweaved with some of the boards.
 
 With this cleanup, it has finally come to the point where it makes
 sense to move it out of arch/arm into drivers/memory, where we already
 have other drivers for similar hardware. The cleanups are still
 ongoing, with the goal of eventually having a standalone driver
 that does not require an interface to architecture code.
 
 This is a separate branch because of dependencies on multiple other
 branches, and to keep the drivers changes separate from the normal
 cleanups.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIVAwUAVIcj7mCrR//JCVInAQIEtBAAoxn09fc4oeyBy9HeAgcQSxglqlyiJzTG
 YeIYN3Hz9kCRh/KDG35OQDD0Zv6Yw3m4QLYym5x/W2atMl+7AwBOUKGAi6neEHzv
 DbhvmAr8/2I+3RnUQDAxcbqY/p3/sSatWsPgwrgXWmGJHQm5Ur/IfUcnOmqfA6w4
 xag8EdwX43zxUCF7MFTdD5Vo4uzoYNtPaPHpEtFBn/UkGMolktUCXZPBD1DvgQEP
 Mdy9yKhpYy/6N/k8ZQUCfD177GW5mJMNDrQN3e+vdqJ05NBBfiORhJCxilo74FVQ
 NpX7I4AoYqgc+c0xJpQSZF2bAfAt53Ac8bPG6fNAf1GCw7O8ryjNybHWw9hK1mr3
 aS4EEVsC3UJh/d6NAhbPWfB4reL9WqUgGapN8AiVsurt1Rj+eAp6mCY3qM37kPs4
 feGBbCL0lfEPVKTWHskcdUjxxcSsj1xTPM/VDvitITjgINfv6EqUHDLPRT9V7ta1
 VVbFwIgshScam2T5AolMd1CB8mkaTkkbZFnMqz93lFs43vltJFFqJOCnfPKsYgMz
 gf4sJ8/029sUJV2yjEHHMQNyurpGPqJ+BHa6bCLX82ERePFNJvBnm8Zm+kizNbD2
 CGN38tysXOxKL6jIqT9D0bKO40w1dLJjamsl1SfesDBijZChhF77Lnpwx/EKtj+/
 jYSRIijpCWk=
 =U4Fz
 -----END PGP SIGNATURE-----

Merge tag 'omap-gpmc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC/OMAP GPMC driver cleanup and move from Arnd Bergmann:
 "The GPMC driver has traditionally been considered a part of the OMAP
  platform code and tightly interweaved with some of the boards.

  With this cleanup, it has finally come to the point where it makes
  sense to move it out of arch/arm into drivers/memory, where we already
  have other drivers for similar hardware.  The cleanups are still
  ongoing, with the goal of eventually having a standalone driver that
  does not require an interface to architecture code.

  This is a separate branch because of dependencies on multiple other
  branches, and to keep the drivers changes separate from the normal
  cleanups"

* tag 'omap-gpmc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  memory: gpmc: Move omap gpmc code to live under drivers
  ARM: OMAP2+: Move GPMC initcall to devices.c
  ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
  ARM: OMAP2+: Remove unnecesary include in GPMC driver
  ARM: OMAP2+: Drop board file for 3430sdp
  ARM: OMAP2+: Drop board file for ti8168evm
  ARM: OMAP2+: Drop legacy code for gpmc-smc91x.c
  ARM: OMAP2+: Require proper GPMC timings for devices
  ARM: OMAP2+: Show bootloader GPMC timings to allow configuring the .dts file
  ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select
  ARM: OMAP2+: gpmc: Sanity check GPMC fck on probe
  ARM: OMAP2+: gpmc: Keep Chip Select disabled while configuring it
  ARM: OMAP2+: gpmc: Always enable A26-A11 for non NAND devices
  ARM: OMAP2+: gpmc: Error out if timings fail in gpmc_probe_generic_child()
  ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg()
2014-12-09 16:57:56 -08:00
Thierry Reding
8918465163 memory: Add NVIDIA Tegra memory controller support
The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.

Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
custom API or a generic subsystem) to allow clients to register latency
requirements.

This driver also registers an IOMMU (SMMU) that's implemented by the
memory controller. It is supported on Tegra30, Tegra114 and Tegra124
currently. Tegra20 has a GART instead.

The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
is a unidirectional, special-purpose DMA master. A SWGROUP represents a
set of memory clients that form a logical functional unit corresponding
to a single device. Typically a device has two clients: one client for
read transactions and one client for write transactions, but there are
also devices that have only read clients, but many of them (such as the
display controllers).

Because there is no 1:1 relationship between memory clients and devices
the driver keeps a table of memory clients and the SWGROUPs that they
belong to per SoC. Note that this is an exception and due to the fact
that the SMMU is tightly integrated with the rest of the Tegra SoC. The
use of these tables is discouraged in drivers for generic IOMMU devices
such as the ARM SMMU because the same IOMMU could be used in any number
of SoCs and keeping such tables for each SoC would not scale.

Acked-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-04 16:11:47 +01:00
Tony Lindgren
1864019379 memory: gpmc: Move omap gpmc code to live under drivers
Just move to drivers as further clean-up can now happen there
finally.

Let's also add Roger and me to the MAINTAINERS so we get
notified for any patches related to GPMC.

Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-11-28 12:54:39 -08:00
Nicolas Ferre
e657ce689a AT91 reset, poweroff and ram drivers
This tag holds the various new drivers introduced to move code that used to be
 in mach-at91 over to the proper frameworks.
 
 These files are the reboot and poweroff code for all AT91 SoCs but the RM9200,
 and the ram controller driver is not doing much at the time, except for grabing
 the RAM clock in order to leave it always enabled.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJTx4LlAAoJEBx+YmzsjxAggooP/0xIMF568hWNLWMOBLNyeXLP
 SJUCBZw1kLqhw8K3nPV5GAmfGxgCCZ3uvUfMdIgJzSN+NtcuvQR2+ui2Bj1nzRRQ
 y6ZAmoHEJHveNd3SoLpuE5s4KFwTBFblcBXHVSwIZzMcCioBxFWtcPupkIVoqt/z
 s/gN5w9BsSCvqjtmYSTp8XTza9y7hx9Pmdpc1uzkP/WJbXtxyQX50NlpILQ1r7WW
 WNOMRXOpv/JH+EHFtS7vMMvn+fQ94RVI209+Z2wez13H87C8MZF4N972vRHkmBuG
 Uv2ZowFRo8T0YjJZfmyfWyg3C9fMOcQeOURAGO/FIavf0WJ+7/hmdZ9jymTpaA3b
 WwZ+qgajMMdOk2ojW36vfueOqeuXx7bxGKWocXO/Rk00ZpN8Y2qFqmsJL5WNYVoN
 SDod+nzYHA4ShyZFDiXoAf3R/+gjb9RvCJ0ZvjkdHUeU8GYHhXjDLPp1Ng7oDBut
 szDE8FfWGpb5UsjFSdKfSsU2Xp3lqZ6fv89qiGYGwz7OqKRz2E0d8zm/EHoD87RR
 jx9e4pWvk++Vouk/zCRZVb+HrGtN9FbZKfRq6xx1pAO+V2NCmq8ttcPH2BuN1K3T
 quFRb6YBTfNfgVKPjbPsQ4QOuCR4juIZSubRhQEi7/Uie5aR/9q6Lz/pYbzitYjJ
 qHR5nj7sL/WwJlfgFgbi
 =YBPz
 -----END PGP SIGNATURE-----

Merge tag 'at91-drivers-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux

Pull AT91 reset, poweroff and ram drivers from Maxime Ripard:
 "This tag holds the various new drivers introduced to move code that used to be
  in mach-at91 over to the proper frameworks.

  These files are the reboot and poweroff code for all AT91 SoCs but the RM9200,
  and the ram controller driver is not doing much at the time, except for grabing
  the RAM clock in order to leave it always enabled."

Conflicts:
	arch/arm/mach-at91/Kconfig
2014-08-25 15:35:26 +02:00
Scott Wood
54afbec0d5 memory: Freescale CoreNet Coherency Fabric error reporting driver
The CoreNet Coherency Fabric is part of the memory subsystem on
some Freescale QorIQ chips.  It can report coherency violations (e.g.
due to misusing memory that is mapped noncoherent) as well as
transactions that do not hit any local access window, or which hit a
local access window with an invalid target ID.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@freescale.com>
2014-07-29 19:26:30 -05:00
Alexandre Belloni
e81b6abebc memory: add a driver for atmel ram controllers
Atmel SoCs have one or multiple RAM controllers that need one or multiple clocks
to run.
This driver handle those clocks.

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2014-07-15 11:43:42 +02:00
Ivan Khoronzhuk
5a7c81547c memory: ti-aemif: introduce AEMIF driver
Add new AEMIF driver for EMIF16 Texas Instruments controller.
The EMIF16 module is intended to provide a glue-less interface to
a variety of asynchronous memory devices like ASRA M, NOR and NAND
memory. A total of 256M bytes of any of these memories can be
accessed at any given time via 4 chip selects with 64M byte access
per chip select.

Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR
are not supported.

This controller is used on SoCs like Davinci, Keysone2

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-28 16:47:21 -08:00
Prabhakar Kushwaha
d2ae2e20fb driver/memory:Move Freescale IFC driver to a common driver
Freescale IFC controller has been used for mpc8xxx. It will be used
 for ARM-based SoC as well. This patch moves the driver to driver/memory
 and fix the header file includes.

  Also remove module_platform_driver() and  instead call
  platform_driver_register() from subsys_initcall() to make sure this module
  has been loaded before MTD partition parsing starts.

Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-18 12:20:45 -08:00
Ezequiel Garcia
3edad321b1 drivers: memory: Introduce Marvell EBU Device Bus driver
Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and
Discovery (mv78xx0) supports a Device Bus controller to access several
kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA).

This commit adds a driver to handle this controller. So far only
Armada 370, Armada XP and Discovery SoCs are supported.

The driver must be registered through a device tree node;
as explained in the binding document.

For each child node in the device tree, this driver will:
  * set timing parameters
  * register a child device
  * setup an address decoding window, using the mbus driver

Keep in mind the address decoding window setup is only a temporary hack.
This code will be removed from this devbus driver as soon as a proper device
tree binding for the mbus driver is added.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-21 10:11:56 -07:00
Stephen Warren
7c304d7e24 memory: fix build when CONFIG_OF && !CONFIG_DDR
Commit e6b42eb "memory: emif: add device tree support to emif driver"
added drivers/memory/of_memory.c, which references tables defined in
lib/jedec_ddr_data.c. of_memory.c is compiled when CONFIG_OF, whereas
jedec_ddr_data.c is compiled when CONFIG_DDR. This breaks the build
when CONFIG_OF is defined but not CONFIG_DDR:

drivers/built-in.o: In function `of_get_ddr_timings':
drivers/memory/of_memory.c:138: undefined reference to `lpddr2_jedec_timings'
drivers/built-in.o: In function `of_get_min_tck':
drivers/memory/of_memory.c:62: undefined reference to `lpddr2_jedec_min_tck'
make: *** [vmlinux] Error 1

To solve this, only compile of_memory.c when CONFIG_OF && CONFIG_DDR,
otherwise, stub out the functions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 11:57:19 -07:00
Aneesh V
e6b42eb6a6 memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.

Reviewed-by: Benoit Cousson <b-cousson@ti.com>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-04 16:14:31 -07:00
Hiroshi DOYU
af4681097b ARM: tegra30: Add Tegra Memory Controller(MC) driver
Tegra Memory Controller(MC) driver for Tegra30
Added to support MC General interrupts, mainly for IOMMU(SMMU).

Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-10 14:46:09 -07:00
Hiroshi DOYU
c542fb79fb ARM: tegra20: Add Tegra Memory Controller(MC) driver
Tegra Memory Controller(MC) driver for Tegra20
Added to support MC General interrupts, mainly for IOMMU(GART).

Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-10 14:43:53 -07:00
Aneesh V
7ec944538d memory: emif: add basic infrastructure for EMIF driver
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.

Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.

Signed-off-by: Aneesh V <aneesh@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Benoit Cousson <b-cousson@ti.com>
[santosh.shilimkar@ti.com: Moved to drivers/memory from drivers/misc]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-02 00:10:49 -07:00