Pull ARM SoC driver updates from Kevin Hilman:
 "Some of these are for drivers/soc, where we're now putting
  SoC-specific drivers these days.  Some are for other driver subsystems
  where we have received acks from the appropriate maintainers.

  Some highlights:

   - simple-mfd: document DT bindings and misc updates
   - migrate mach-berlin to simple-mfd for clock, pinctrl and reset
   - memory: support for Tegra132 SoC
   - memory: introduce tegra EMC driver for scaling memory frequency
   - misc. updates for ARM CCI and CCN busses"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (48 commits)
  drivers: soc: sunxi: Introduce SoC driver to map SRAMs
  arm-cci: Add aliases for PMU events
  arm-cci: Add CCI-500 PMU support
  arm-cci: Sanitise CCI400 PMU driver specific code
  arm-cci: Abstract handling for CCI events
  arm-cci: Abstract out the PMU counter details
  arm-cci: Cleanup PMU driver code
  arm-cci: Do not enable CCI-400 PMU by default
  firmware: qcom: scm: Add HDCP Support
  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
  ...

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

We currently artificially limit the parsing of GPMC connected
devices based on the device name. Let's stop doing that, it's
confusing as adding devices to .dts files with using normal
names like fpga and usb will currently cause them to not probe.

Cc: Roger Quadros <rogerq@ti.com>
Reported-by: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

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

This file in debugfs can be used to get or set the EMC frequency.
Reading the file will return the currently set frequency in Hz, while
writing the file sets the specified frequency rounded to the next
highest frequency supported by the board.

Will be very useful when tuning memory scaling.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
[treding@nvidia.com: add "emc" debugfs directory]
Signed-off-by: Thierry Reding <treding@nvidia.com>

Implements functionality needed to change the rate of the memory bus
clock.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The EMC driver needs to know the number of external memory devices and
also needs to update the EMEM configuration based on the new rate of the
memory bus.

To know how to update the EMEM config, looks up the values of the burst
regs in the DT, for a given timing.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

As this interrupt is just for development purposes, as the TRM says, and
the sheer amount of interrupts fired can seriously disrupt userspace
when testing the lower frequencies supported by the EMC.

From the TRM:

"There is one performance warning type interrupt: ARBITRATION_EMEM. It
fires when the MC detects that a request has been pending in the Row
Sorter long enough to hit the DEADLOCK_PREVENTION_SLACK_THRESHOLD. In
addition to true performance problems, this interrupt may fire in
situations such as clock-change where the EMC backpressures pending
traffic for long periods of time. This interrupt helps developers
identify and debug performance issues and configuration issues."

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

The memory controller on Tegra132 is very similar to the one found on
Tegra124. But the Denver CPUs don't have an outer cache, so dcache
maintenance is done slightly differently.

Signed-off-by: Thierry Reding <treding@nvidia.com>