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()
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>
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>
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
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>
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>
Currently, the mvebu-devbus Device Tree binding makes defining the
timing parameters mandatory.
However, in practice, when converting Orion5x platforms to the Device
Tree, we may not necessarily have easy access to the hardware
platforms to fetch those values which were not defined in old-style
board files: all these platforms rely on the bootloader setting the
timing parameters correctly.
In order to facilitate the migration to the Device Tree of this
platform, this commit relaxes the mvebu-devbus Device Tree binding by
introducing a 'devbus,keep-config' boolean property, which, if
defined, will ignore all timing parameters passed in the Device Tree,
and simply rely on the timing values already defined by the
bootloader.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1398202002-28530-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
This commit adds support for the Orion5x family of Marvell processors
into the mvebu-devbus driver. It differs from the already supported
Armada 370/XP by:
* Having a single register (instead of two) for doing all the timing
configuration.
* Having a few less timing configuration parameters.
For this reason, a separate compatible string "marvell,orion-devbus"
is introduced.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1398202002-28530-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The mvebu-devbus driver currently only supports the Armada 370/XP
family, but it can also cover the Orion5x family. However, the Orion5x
family has a different organization of the registers.
Therefore, in preparation to the introduction of Orion5x support, we
separate into two functions the code that 1/ retrieves the timing
parameters from the Device Tree and 2/ applies those timings
parameters into the hardware registers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1398202002-28530-8-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
As noted by Sebastian Hesselbarth, the definitions in mvebu-devbus.c
are not bit definition, but rather shift values, so a _SHIFT prefix
would make more sense. This commit therefore replaces the *_BIT
definitions by *_SHIFT definitions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1398202002-28530-7-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The mvebu-devbus driver currently only supports the Armada 370/XP
family, but it can also cover the Orion5x family. However, the Orion5x
family has a different organization of the register. Therefore, in
preparation to the introduction of Orion5x support, we rename the
Armada 370/XP specific definitions to have an ARMADA_ prefix.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1398202002-28530-6-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
According to the Armada 370 and Armada XP datasheets, the part of the
Device Bus register that configure the bus width should contain 0 for
a 8 bits bus width, and 1 for a 16 bits bus width (other values are
unsupported/reserved).
However, the current conversion done in the driver to convert from a
bus width in bits to the value expected by the register leads to
setting the register to 1 for a 8 bits bus, and 2 for a 16 bits bus.
This mistake was compensated by a mistake in the existing Device Tree
files for Armada 370/XP platforms: they were declaring a 8 bits bus
width, while the hardware in fact uses a 16 bits bus width.
This commit fixes that by adjusting the conversion logic.
This patch fixes a bug that was introduced in
3edad321b1 ('drivers: memory: Introduce
Marvell EBU Device Bus driver'), which was merged in v3.11.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-2-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: 3edad321b1 ('drivers: memory: Introduce Marvell EBU Device Bus driver')
Cc: stable@vger.kernel.org # v3.11+
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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>
commit d2ae2e20fb ("driver/memory:Move
Freescale IFC driver to a common driver") introduces this build
regression into the mpc85xx_defconfig:
drivers/built-in.o: In function `fsl_ifc_nand_remove':
drivers/mtd/nand/fsl_ifc_nand.c:1147: undefined reference to `fsl_ifc_ctrl_dev'
drivers/mtd/nand/fsl_ifc_nand.c:1147: undefined reference to `fsl_ifc_ctrl_dev'
drivers/built-in.o: In function `fsl_ifc_nand_probe':
drivers/mtd/nand/fsl_ifc_nand.c:1031: undefined reference to `fsl_ifc_ctrl_dev'
drivers/mtd/nand/fsl_ifc_nand.c:1031: undefined reference to `fsl_ifc_ctrl_dev'
drivers/built-in.o: In function `match_bank':
drivers/mtd/nand/fsl_ifc_nand.c:1013: undefined reference to `convert_ifc_address'
drivers/built-in.o: In function `fsl_ifc_nand_probe':
drivers/mtd/nand/fsl_ifc_nand.c:1059: undefined reference to `fsl_ifc_ctrl_dev'
drivers/mtd/nand/fsl_ifc_nand.c:1080: undefined reference to `fsl_ifc_ctrl_dev'
drivers/mtd/nand/fsl_ifc_nand.c:1069: undefined reference to `fsl_ifc_ctrl_dev'
drivers/mtd/nand/fsl_ifc_nand.c:1069: undefined reference to `fsl_ifc_ctrl_dev'
make: *** [vmlinux] Error 1
This happens because there is nothing to descend us into the
drivers/memory directory in the mpc85xx_defconfig. It wasn't
selecting CONFIG_MEMORY. So we never built drivers/memory/fsl_ifc.o
and so we have nothing to link the above symbols against.
Since the goal of the original commit was to relocate the driver to
an arch independent location, it only makes sense to relocate the
Kconfig setting there as well. But that alone won't fix the build
failure; for that we ensure whoever selects FSL_IFC also selects MEMORY.
Cc: Prabhakar Kushwaha <prabhakar@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
This branch contains mostly additions and changes to platform enablement
and SoC-level drivers. Since there's sometimes a dependency on device-tree
changes, there's also a fair amount of those in this branch.
Pieces worth mentioning are:
- Mbus driver for Marvell platforms, allowing kernel configuration
and resource allocation of on-chip peripherals.
- Enablement of the mbus infrastructure from Marvell PCI-e drivers.
- Preparation of MSI support for Marvell platforms.
- Addition of new PCI-e host controller driver for Tegra platforms
- Some churn caused by sharing of macro names between i.MX 6Q and 6DL
platforms in the device tree sources and header files.
- Various suspend/PM updates for Tegra, including LP1 support.
- Versatile Express support for MCPM, part of big little support.
- Allwinner platform support for A20 and A31 SoCs (dual and quad Cortex-A7)
- OMAP2+ support for DRA7, a new Cortex-A15-based SoC.
The code that touches other architectures are patches moving
MSI arch-specific functions over to weak symbols and removal of
ARCH_SUPPORTS_MSI, acked by PCI maintainers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSKhYmAAoJEIwa5zzehBx322AP/1ONYs8o8f7/Gzq6lZvTN6T3
0pBTApg6Jfioi3lwKvUAEIcsW82YKQ+UZkbW66GQH6+Ri4aZJKZHuz0+JPU67OJ4
LtSLuzVWrymy2VOOUvAnS/SXkOZw/pHhU4cLNHn1dMndhUL1Uqp9/XwuiHEQyFsP
uOkpcBtIu0EWElov0PKKZ5SWBg8JJs2vy5ydiViGelWHCrZvDDZkWzIsDcBQxJLQ
juzT4+JE+KOu7vKmfw78o6iHoCS2TBRAN9YUCajRb8Wl+out1hrTahHnDWaZ5Mce
EskcQNkJROqFbjD4k3ABN4XGTv2VDmrztIwFe0SEQ7Dz/9ypCrBGT69uI9xIqTXr
GwVRIwAUFTpMupK0gy93z1ajV3N0CXV79out9+jQNUQybYE+czp8QOyhmuc1tZx0
8fn9jlBQe9Vy6yrs39gEcE7nUwrayeyQ+6UvqqwsE2pWZabNAnCMSPX5+QIu+T/3
tQ7+jYmfFeserp1sIDOHOnxfhtW9EI6U9d1h/DUCwrsuFdkL9ha4M/vh9Pwgye98
tBdz0T4yE39AJQwwFWRkv1jcQKcGu6WqJanmvS4KRBksGwuLWxy+ewOnkz2ifS25
ZYSyxAryZRBvQRqlOK11rXPfRcbGcY0MG9lkKX96rGcyWEizgE1DdjxXD8HoIleN
R8heV6GX5OzlFLGX2tKK
=fJ5x
-----END PGP SIGNATURE-----
Merge tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC platform changes from Olof Johansson:
"This branch contains mostly additions and changes to platform
enablement and SoC-level drivers. Since there's sometimes a
dependency on device-tree changes, there's also a fair amount of
those in this branch.
Pieces worth mentioning are:
- Mbus driver for Marvell platforms, allowing kernel configuration
and resource allocation of on-chip peripherals.
- Enablement of the mbus infrastructure from Marvell PCI-e drivers.
- Preparation of MSI support for Marvell platforms.
- Addition of new PCI-e host controller driver for Tegra platforms
- Some churn caused by sharing of macro names between i.MX 6Q and 6DL
platforms in the device tree sources and header files.
- Various suspend/PM updates for Tegra, including LP1 support.
- Versatile Express support for MCPM, part of big little support.
- Allwinner platform support for A20 and A31 SoCs (dual and quad
Cortex-A7)
- OMAP2+ support for DRA7, a new Cortex-A15-based SoC.
The code that touches other architectures are patches moving MSI
arch-specific functions over to weak symbols and removal of
ARCH_SUPPORTS_MSI, acked by PCI maintainers"
* tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (266 commits)
tegra-cpuidle: provide stub when !CONFIG_CPU_IDLE
PCI: tegra: replace devm_request_and_ioremap by devm_ioremap_resource
ARM: tegra: Drop ARCH_SUPPORTS_MSI and sort list
ARM: dts: vf610-twr: enable i2c0 device
ARM: dts: i.MX51: Add one more I2C2 pinmux entry
ARM: dts: i.MX51: Move pins configuration under "iomuxc" label
ARM: dtsi: imx6qdl-sabresd: Add USB OTG vbus pin to pinctrl_hog
ARM: dtsi: imx6qdl-sabresd: Add USB host 1 VBUS regulator
ARM: dts: imx27-phytec-phycore-som: Enable AUDMUX
ARM: dts: i.MX27: Disable AUDMUX in the template
ARM: dts: wandboard: Add support for SDIO bcm4329
ARM: i.MX5 clocks: Remove optional clock setup (CKIH1) from i.MX51 template
ARM: dts: imx53-qsb: Make USBH1 functional
ARM i.MX6Q: dts: Enable I2C1 with EEPROM and PMIC on Phytec phyFLEX-i.MX6 Ouad module
ARM i.MX6Q: dts: Enable SPI NOR flash on Phytec phyFLEX-i.MX6 Ouad module
ARM: dts: imx6qdl-sabresd: Add touchscreen support
ARM: imx: add ocram clock for imx53
ARM: dts: imx: ocram size is different between imx6q and imx6dl
ARM: dts: imx27-phytec-phycore-som: Fix regulator settings
ARM: dts: i.MX27: Remove clock name from CPU node
...
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l;
@@
- res = platform_get_resource(pdev, IORESOURCE_MEM, n);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = platform_get_resource(pdev, IORESOURCE_MEM, n);
e = devm_ioremap_resource(e1, res);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This variable is not being used anywhere and it's only forgotten
garbage that should have been removed in the previous commit:
commit 9b6e4c0a58
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Fri Jul 26 10:17:38 2013 -0300
memory: mvebu-devbus: Remove address decoding window workaround
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
In Tegra30 any memory controller interrupt would cause an infinite loop in the
IRQ handler. Additionally, a garbage pointer was used to read the MC
status registers, which causes wrong values to be printed if a MC error
occurred.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In Tegra20 any memory controller interrupt would cause an
infinite loop in the IRQ handler.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
of_get_property returns value in Big Endian format.
Before using this value it should be converted to little endian
using be32_to_cpup().
Custom configs of emif are read from dt using of_get_property,
but these are not converted to litte endian format.
Correcting the same here.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ERRATA DESCRIPTION :
The EMIF supports power-down state for low power. The EMIF
automatically puts the SDRAM into power-down after the memory is
not accessed for a defined number of cycles and the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
As the EMIF supports automatic output impedance calibration, a ZQ
calibration long command is issued every time it exits active
power-down and precharge power-down modes. The EMIF waits and
blocks any other command during this calibration.
The EMIF does not allow selective disabling of ZQ calibration upon
exit of power-down mode. Due to very short periods of power-down
cycles, ZQ calibration overhead creates bandwidth issues and
increases overall system power consumption. On the other hand,
issuing ZQ calibration long commands when exiting self-refresh is
still required.
WORKAROUND :
Because there is no power consumption benefit of the power-down due
to the calibration and there is a performance risk, the guideline
is to not allow power-down state and, therefore, to not have set
the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
This is applicable only for EMIF4D IP used in OMAP4 Soc's.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The issue was that only the first timings table was added to the
emif platform data at the emif driver registration. All other
timings tables was filled with zeros. Now all emif timings table
are added to the platform data.
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some machine or kernel variants might have missed implementation
of power off handlers. We DONOT want to let the system be in
"out of spec" state in this condition. So, WARN and attempt
a machine restart in the hopes of clearing the out-of-spec
temperature condition.
NOTE: This is not the safest option, but safer than leaving the
system in unstable conditions.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As per JESD209-2E specification for LPDDR2,
http://www.jedec.org/standards-documents/results/jesd209-2E
Table 73, LPDDR2 memories come in two flavors - Standard and
Extended. The Standard types can operate from -25C to +85C
However, beyond that and upto +105C can only be supported by
Extended types.
Unfortunately, it seems there is no info in MR0(device info) or
MR[1,2](device feature) for run time detection of this capability
as far as seen on the spec. Hence, we provide a custom_config
flag to be populated by platforms which have these "extended"
type memories.
For the "Standard" memories, we need to consider MR4 notifications
of temperature triggers >85C as equivalent to thermal shutdown
events (equivalent to Spec specified thermal shutdown events for
"extended" parts).
Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case the custom timings provide values which overflow
the maximum possible field value, warn and use maximum
permissible value.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Program the power management shadow register on freq update
Else the concept of threshold frequencies dont really matter
as the system always uses the performance mode timing for LP
which is programmed in at init time.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver tries to round up the specified timeout cycles to
the next power of 2 value. This should be done defore updating
timeout variable.
Correcting this here.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Aneesh V <aneesh@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, and
__devinitconst, from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code reading the register does not match the code writing to the register,
fix it.
Also fix the coding style in mc_writel() for better readability.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add ifdef CONFIG_DEBUG_FS guard for emif_debugfs_[init|exit], and adds stub
functions for the case CONFIG_DEBUG_FS is not set.
When CONFIG_DEBUG_FS is enabled, debugfs_create_dir and debugfs_create_file
return NULL on failure, fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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>
Introduce a new dev_*_ratelimited() instead of pr_*_ratelimited() for
better info to print.
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Accessing interleaved MC register offsets/ranges are verified. BUG*()s
in accessors can be removed.
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Accessing interleaved MC register offsets/ranges are verified. BUG*()s
in accessors can be removed.
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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>
Make TI_EMIF depends on ARCH_OMAP2PLUS to avoid build breaks on other
architectures. In future if other TI non OMAP socs start using it, the
dependency can be extended.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
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>
Linus Torvalds
Thierry Reding
Tony Lindgren
Nicolas Ferre
Scott Wood
Alexandre Belloni
Thomas Petazzoni
Ivan Khoronzhuk
Paul Gortmaker
Prabhakar Kushwaha
Julia Lawall
Ezequiel Garcia
Tuomas Tynkkynen
Greg Kroah-Hartman
Wolfram Sang
Lokesh Vutla
Grygorii Strashko
Oleksandr Dmytryshyn
Nishanth Menon
Ambresh K
Fabio Porcedda
Hiroshi Doyu
Thierry Reding
Axel Lin
Axel Lin
Stephen Warren
Aneesh V
Santosh Shilimkar