The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.

That mapping is controlled by an SRAM controller, and that mapping might
not be set by the bootloader, for example if the device wasn't used at all,
or if we're using solutions like the U-Boot's Falcon Boot.

We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory
rate change, if that ever happens.

These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.

This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some
drivers in the kernel.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge "mvebu drivers change for 4.2" from Gregory CLEMENT:

mvebu-mbus: add mv_mbus_dram_info_nooverlap() needed for the new
Marvell crypto driver

* tag 'mvebu-drivers-4.2' of git://git.infradead.org/linux-mvebu:
  bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()

Based on the earlier bug fixes branch, which contains six other
patches already merged into 4.1.

Merge tag 'qcom-soc-for-4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom into next/drivers

Merge "Qualcomm ARM Based SoC Updates for v4.2-1" from Kumar Gala:

* Added Subsystem Power Manager (SPM) driver
* Split out 32-bit specific SCM code
* Added HDCP SCM call

* tag 'qcom-soc-for-4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom:
  firmware: qcom: scm: Add HDCP Support
  firmware: qcom: scm: Split out 32-bit specific SCM code
  ARM: qcom: Add Subsystem Power Manager (SPM) driver

Each CCI model have different event/source codes and formats. This
patch exports this information via the sysfs, which includes the
aliases for the events. The aliases are listed by 'perf list', helping
the users to specify the name of the event instead of the binary
config values.

Each event alias must accompany the 'source' code except for the
following cases :

1) CCI-400 - cycles event, doesn't relate to an interface.
2) CCI-500 - Global events to the CCI. (Fixed source code = 0xf)

Each CCI model provides two sets of attributes(format and event),
which are dynamically populated before registering the PMU, to
allow for the appropriate information.

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

CCI-500 provides 8 event counters which can count any of the
supported events independently. The PMU event id is a 9-bit
value made of two parts.
	bits [8:5] - Source port
			0x0-0x6 Slave Ports
			0x8-0xD Master Ports
			0xf     Global Events to CCI
			0x7,0xe Reserved
	bits [0:4] - Event code (specific to each type of port)

The generic CCI-500 controlling interface remains the same with CCI-400.
However there are some differences in the PMU event counters.
 - No cycle counter
 - Upto 8 counters(4 in CCI-400)
 - Each counter area is 64K(4K in CCI400)
 - The counter0 starts at offset 0x10000 from the base of CCI

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Rename CCI400 specific defintions from CCI_xxx to CCI400_xxx.

Introduce generic ARM_CCI_PMU to cover common code for handling
the CCI PMU.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Given that each CCI has different set of interfaces and
its associated events, it is good to abstract the validation of the
event codes to make it easier to add support for a new CCI model.

This patch also abstracts the mapping of a given event to a counter,
as there are some special counters for certain specific events.

We assume that the fixed hardware counters are always at the beginning,
so that we can use cci_model->fixed_hw_events as an upper bound to given
idx to check if we need to program the counter for an event.

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Adds the PMU model specific counters to the PMU model
abstraction to make it easier to add a new PMU.

The patch cleans up the naming convention used all over
the code.
e.g, CCI_PMU_MAX_HW_EVENTS => maximum number of events that
can be counted at any time, which is in fact the maximum
number of counters available.

Change all such namings to use 'counters' instead of events.

This patch also abstracts the following:

1) Size of a PMU event counter area.
2) Maximum number of programmable counters supported by the PMU model
3) Number of counters which counts fixed events (e.g, cycle
  counter on CCI-400).

Also changes some of the static allocation of the data
structures to dynamic, to accommodate the number of events
supported by a PMU.

Gets rid ofthe CCI_PMU_* defines for the model. All such
data should be accessed via the model abstraction.

Limits the number of counters to the maximum supported
by the 'model'.

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This patch gets rid of the global struct cci_pmu variable and makes
the code use the cci_pmu explicitly. Makes code a bit more robust
and reader friendly.

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Do not enable CCI-400 PMU by default and fix the dependency on PERF_EVENTS
than HW_PERF_EVENTS.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: arm@kernel.org
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge "ARM: mediatek: soc updates for v4.2" from Matthias Brugger:

- pmic wrapper: fix clock handling
- pmic wrapper: fix state machine
- pmic wrapper: fix compile dependency

* tag 'v4.1-next-soc' of https://github.com/mbgg/linux-mediatek:
  soc: mediatek: Add compile dependency to pmic-wrapper
  soc: mediatek: PMIC wrap: Fix register state machine handling
  soc: mediatek: PMIC wrap: Fix clock rate handling

HDCP driver needs to check if secure environment supports HDCP.  If it's
supported, then it requires to program some registers through SCM.
Add qcom_scm_hdcp_available and qcom_scm_hdcp_req to support these
requirements.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>

This commit introduces a variant of the mv_mbus_dram_info() function
called mv_mbus_dram_info_nooverlap(). Both functions are used by
Marvell drivers supporting devices doing DMA, and provide them a
description the DRAM ranges that they need to configure their DRAM
windows.

The ranges provided by the mv_mbus_dram_info() function may overlap
with the I/O windows if there is a lot (>= 4 GB) of RAM
installed. This is not a problem for most of the DMA masters, except
for the upcoming new CESA crypto driver because it does DMA to the
SRAM, which is mapped through an I/O window. For this unit, we need to
have DRAM ranges that do not overlap with the I/O windows.

A first implementation done in commit 1737cac6 ("bus: mvebu-mbus:
make sure SDRAM CS for DMA don't overlap the MBus bridge window"),
changed the information returned by mv_mbus_dram_info() to match this
requirement. However, it broke the requirement of the other DMA
masters than the DRAM ranges should have power of two sizes.

To solve this situation, this commit introduces a new
mv_mbus_dram_info_nooverlap() function, which returns the same
information as mv_mbus_dram_info(), but guaranteed to not overlap with
the I/O windows.

In the end, it gives us two variants of the mv_mbus_dram_info*()
functions:

 - The normal one, mv_mbus_dram_info(), which has been around for many
   years. This function returns the raw DRAM ranges, which are
   guaranteed to use power of two sizes, but will overlap with I/O
   windows. This function will therefore be used by all DMA masters
   (SATA, XOR, Ethernet, etc.) except the CESA crypto driver.

 - The new 'nooverlap' variant, mv_mbus_dram_info_nooverlap(). This
   function returns DRAM ranges after they have been "tweaked" to make
   sure they don't overlap with I/O windows. By doing this tweaking,
   we remove the power of two size guarantee. This variant will be
   used by the new CESA crypto driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

This reverts commit 1737cac6 ("bus: mvebu-mbus: make sure SDRAM CS
for DMA don't overlap the MBus bridge window"), because it breaks DMA
on platforms having more than 2 GB of RAM.

This commit changed the information reported to DMA masters device
drivers through the mv_mbus_dram_info() function so that the returned
DRAM ranges do not overlap with I/O windows.

This was necessary as a preparation to support the new CESA Crypto
Engine driver, which will use DMA for cryptographic operations. But
since it does DMA with the SRAM which is mapped as an I/O window,
having DRAM ranges overlapping with I/O windows was problematic.

To solve this, the above mentioned commit changed the mvebu-mbus to
adjust the DRAM ranges so that they don't overlap with the I/O
windows. However, by doing this, we re-adjust the DRAM ranges in a way
that makes them have a size that is no longer a power of two. While
this is perfectly fine for the Crypto Engine, which supports DRAM
ranges with a granularity of 64 KB, it breaks basically all other DMA
masters, which expect power of two sizes for the DRAM ranges.

Due to this, if the installed system memory is 4 GB, in two
chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB
to a little bit less than 2 GB to not overlap with the I/O windows, in
a way that results in a DRAM range that doesn't have a power of two
size. This means that whenever you do a DMA transfer with an address
located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any
serious DMA activity like simply running:

  for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done

in an ext3 partition mounted over a SATA drive will freeze the system.

Since the new CESA crypto driver that uses DMA has not been merged
yet, the easiest fix is to simply revert this commit. A follow-up
commit will introduce a different solution for the CESA crypto driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 1737cac6 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window")
Cc: <stable@vger.kernel.org> # v4.0+
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Commit a0b5cd4a ("bus: mvebu-mbus: use automatic I/O
synchronization barriers") enabled the usage of automatic I/O
synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the
control registers of MBus windows, but on non io-coherent platforms
(orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in
the window control register is either reserved (all windows except 6
and 7) or enables read-only protection (windows 6 and 7).
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v4.0+
Fixes: a0b5cd4a ("bus: mvebu-mbus: use automatic I/O synchronization barriers")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

The Mamba (like the OpenBlocks AX3) doesn't have a crystal
connected to the internal RTC - let's prevent the kernel from
probing it.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Cc: <stable@vger.kernel.org> # v4.0 +
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

The pmic-wrapper calls the reset controller. If CONFIG_RESET_CONTROLLER
is not set, compilation fails with:
drivers/soc/mediatek/mtk-pmic-wrap.c: In function ‘pwrap_probe’:
drivers/soc/mediatek/mtk-pmic-wrap.c:836:2: error: implicit declaration of function ‘devm_reset_control_get’ [-Werror=implicit-function-declaration]

This patch sets the dependency in the Kconfig file.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

When the PMIC wrapper state machine has read a register it goes into the
"wait for valid clear" (vldclr) state. The state machine stays in this
state until the VLDCLR bit is written to. We should write this bit after
reading a register because the SCPSYS won't let the system go into
suspend as long as the state machine waits for valid clear.

Since now we never leave the state machine in vldclr state we no longer
have to check for this state on pwrap_read/pwrap_write entry and can
remove the corresponding code.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

replace chipselect extension values based on SPI clock with hardcoded SoC
specific values.

The PMIC wrapper has the ability of extending the chipselects by configurable
amounts of time. We configured the values based on the rate of SPI clock, but
this is wrong. The delays should be configured based on the internal PMIC clock
that latches the values from the SPI bus to the internal PMIC registers. By
default this clock is 24MHz. Other clock frequencies are for debugging only
and can be removed from the driver.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

Merge tag 'berlin-simple-mfd-4.2-1' of git://git.infradead.org/users/hesselba/linux-berlin into next/drivers

Merge "Berlin simple-mfd for v4.2" from Sebastian Hesselbarth:
- based on arm-soc drivers/simple-mfd branch
- rework of chip/system ctrl nodes to simple-mfd probing for
  clk, pinctrl, and reset
- add adc node

* tag 'berlin-simple-mfd-4.2-1' of git://git.infradead.org/users/hesselba/linux-berlin:
  ARM: berlin: add an ADC node for the BG2Q
  ARM: berlin: remove useless chip and system ctrl compatibles
  clk: berlin: drop direct of_iomap of nodes reg property
  ARM: berlin: move BG2Q clock node
  ARM: berlin: move BG2CD clock node
  ARM: berlin: move BG2 clock node
  clk: berlin: prepare simple-mfd conversion
  pinctrl: berlin: drop SoC stub provided regmap
  ARM: berlin: move pinctrl to simple-mfd nodes
  pinctrl: berlin: prepare to use regmap provided by syscon
  reset: berlin: drop arch_initcall initialization
  ARM: berlin: move reset to simple-mfd nodes
  reset: berlin: convert to a platform driver
  ARM: berlin: prepare simple-mfd/syscon conversion of sys/chip ctrl nodes
  ARM: berlin: select MFD_SYSCON by default

This patch adds the ADC node for the Berlin BG2Q, using the newly added
Berlin IIO ADC driver.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Now that the rework to have one sub-node per device in the chip and
system controllers is done, their dedicated compatible can be removed.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

The Berlin clock driver was sharing a DT node with the pin controller
and the reset driver. All these devices are now sub-nodes of the chip
controller. This patch rework the Berlin clock driver to allow moving
the Berlin clock DT bindings into their own sub-node of the chip
controller node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

With the introduction of the Berlin simple-mfd controller driver, all
drivers previously sharing the chip and system controller nodes now
have their own sub-node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

With the introduction of the Berlin simple-mfd controller driver, all
drivers previously sharing the chip and system controller nodes now
have their own sub-node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

With the introduction of the Berlin simple-mfd controller driver, all
drivers previously sharing the chip and system controller nodes now
have their own sub-node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Prepare conversion of berlin clk drivers to a simple-mfd sub-node by
checking for parent node compatible. If parent node is "syscon" compatible
use it for of_iomap instead of the own node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

With convertsion to simple-mfd sub-nodes, drop the regmap registration
by SoC stubs.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Now with proper support for simple-mfd probed pinctrl driver, move
to the new soc-pinctrl and system-pinctrl nodes.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

The Berlin pin controller nodes will be simple-mfd probed sub-nodes of
soc-controller and system-controller nodes. The register bank is managed
by syscon, which provides a regmap.

Prepare to get the regmap from syscon parent node instead of SoC stub
provided regmap.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

With proper platform driver probing for berlin reset driver, drop the
arch_initcall workaround.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Now with a proper platform driver for reset and simple-mfd, move to
the new marvell,berlin-reset node.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

The Berlin reset controller was introduced without being a platform
driver because of a needed DT rework: the node describing the reset
controller also describes the pinctrl and clk controllers...

Prepare conversion by adding a platform driver probe to a new
compatible "marvell,berlin2-reset" with syscon regmap.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

The chip and system controller nodes will be handled by simple-mfd based
driver probing. Prepare the conversion by adding "simple-mfd" and "syscon"
compatibles to the corresponding nodes.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

The chip and system controller nodes handle sub-devices, such as the
clock, pinctrl or reset controllers. The drivers handling them need a
regmap provided by syscon. Select it by default when using a Berlin SoC.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>

Since many releases, the modifications of the mvebu and berlin device
tree files are merged through the mvebu subsystem. This patch makes it
official in order to help the contributors using the get_maintainer.pl
to find the accurate peoples.

In the same time, updated the mvebu description which now includes the
kirkwood SoCs and new Armada SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Andrew Lunn <andrew@lunn.ch>

hrtimer_start() will no longer defer already expired timers to the
softirq in 4.2, and the __hrtimer_start_range_ns() function is
getting removed, causing build errors when both the tip tree and
the arm-ccn changes are merged.

This changes the code back to using hrtimer_start, which will
do the right thing after this branch gets merged with the
timers update from tip.

As pointed out after a discussion on the mailing list, the result will
not be worse than the what was there before you pulled my updates, as
the code was using normal hrtimer_start(). It's just when I realised
that it should be pinned I looked at what x86 uncore pmu is doing and
shamelessly (and probably a bit mindlessly) copied the "do not wakeup"
version from there.

[arnd: update commit message]
Reported-by: Mark Brown <mark.brown@arm.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers

Merge "ARM: tegra: Add EMC driver for v4.2-rc1" from Thierry Reding:

This introduces the EMC driver that's required to scale the external
memory frequency.

* tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  memory: tegra: Add EMC frequency debugfs entry
  memory: tegra: Add EMC (external memory controller) driver
  memory: tegra: Add API needed by the EMC driver
  of: Add Tegra124 EMC bindings
  of: Document timings subnode of nvidia,tegra-mc

Merge tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers

Merge "ARM: tegra: RAM code access for v4.2-rc1" from Thierry Reding:

The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.

* tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  soc/tegra: fuse: Add RAM code reader helper
  of: Document long-ram-code property in nvidia,tegra20-apbmisc

Merge tag 'tegra-for-4.2-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers

Merge "ARM: tegra: Memory controller updates for v4.2-rc1" from Thierry Reding:

Adds support for Tegra132 (which is mostly the same as for Tegra124,
except for cache maintenance). debugfs support is also introduced for
the SMMU part of the memory controller, which allows users to inspect
the translation state for SWGROUPs and memory clients.

* tag 'tegra-for-4.2-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  memory: tegra: Disable ARBITRATION_EMEM interrupt
  memory: tegra: Add Tegra132 support
  iommu/tegra-smmu: Add debugfs support
  memory: tegra: Add SWGROUP names