printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
respectively which can be used to generate the two printf arguments
necessary to format the specified cpu/nodemask.

* Line termination only requires one extra space at the end of the
  buffer.  Use PAGE_SIZE - 1 instead of PAGE_SIZE - 2 when formatting.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The mvebu-mbus driver reads the SDRAM window registers, and make the
information about the DRAM CS configuration available to device
drivers using the mv_mbus_dram_info() API. This information is used by
the DMA-capable device drivers to program their address decoding
windows.

Until now, we were basically providing the SDRAM window register
details as is. However, it turns out that the DMA capability of the
CESA cryptographic engine consists in doing DMA being the DRAM and the
crypto SRAM mapped as a MBus window. For this case, it is very
important that the SDRAM CS information does not overlap with the MBus
bridge window.

Therefore, this commit improves the mvebu-mbus driver to make sure we
adjust the SDRAM CS information so that it doesn't overlap with the
MBus bridge window. This problem was reported by Boris Brezillon,
while working on the mv_cesa driver for Armada 37x/38x/XP. We use the
memblock memory information to know where the usable RAM is located,
as this information is guaranteed to be correct on all SoC variants.

We could have used the MBus bridge window registers on Armada 370/XP,
but they are not really used on Armada 375/38x (Cortex-A9 based),
since the PL310 L2 filtering is used instead to discriminate between
RAM accesses and I/O accesses. Therefore, using the memblock
information is more generic and works accross the different platforms.
Reported-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>

On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

To make things even more fun, the hardware designers have chosen to
put the window 13 remap registers in a completely custom location,
using a logic that differs from the one used for all other remappable
windows.

To solve this problem, this commit:

 * Adds a SoC specific function to calculate offset of remap registers
   to the mvebu_mbus_soc_data structure. This function,
   ->win_remap_offset(), returns the offset of the remap registers, or
   MVEBU_MBUS_NO_REMAP if the window does not have the remap
   capability. This new function replaces the previous integer field
   num_remappable_wins, which was insufficient to encode the special
   case of window 13.

 * Adds an implementation of the ->win_remap_offset() function for the
   various SoC families. Some have 2 first windows that are remapable,
   some the 4 first, some the 8 first, and then the Armada XP/375/38x
   case where the 8 first are remapable plus the special window
   13. This is implemented in functions
   generic_mbus_win_remap_2_offset(),
   generic_mbus_win_remap_4_offset(),
   generic_mbus_win_remap_8_offset() and
   armada_xp_mbus_win_remap_offset() respectively.

 * Change the code to use the ->win_remap_offset() function when
   accessing the remap registers, and also to use a newly introduced
   mvebu_mbus_window_is_remappable() helper function that tells
   whether a given window is remapable or not.

 * Separate Armada 370 from XP/375/38X because the window 13 of Armada
   370 does not support the remap capability.

[Thomas: adapted for the mainline kernel, minor clarifications in the
code, reword the commit log.]
Signed-off-by: NMichal Mazur <arg@semihalf.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>

Instead of using explicit I/O synchronization barriers shoehorned
inside the streaming DMA mappings API (in
arch/arm/mach-mvebu/coherency.c), we are switching to use automatic
I/O synchronization barrier.

The primary motivation for this change is that explicit I/O
synchronization barriers are not only needed for streaming DMA
mappings (which can easily be done by overriding the dma_map_ops), but
also for coherent DMA mappings (which is a lot less easy to do, since
the kernel assumes such mappings are coherent and don't require any
sort of cache maintenance operation to ensure the consistency of the
buffers).

Switching to automatic I/O synchronization barriers will also allow us
to use the existing arm_coherent_dma_ops instead of our custom
arm_dma_ops.

In order to use automatic I/O synchronization barriers, this commit
changes mvebu-mbus in two ways:

 - It enables automatic I/O synchronization barriers in the 0x84
   register of the MBus bridge, by enabling such barriers for all MBus
   units. This enables automatic barriers for the on-SoC peripherals
   that are doing DMA.

 - It enables the SyncEnable bit in the MBus windows, so that PCIe
   devices also use automatic I/O synchronization barrier.

This automatic synchronization barrier relies on the assumption that
at least one register of a given hardware unit is read before the
driver accesses the DMA mappings modified by this unit. This
assumption is guaranteed for PCI devices by vertue of the PCI
standard, and we can reasonably verify that this assumption is also
true for the limited number of platform drivers doing DMA used on
Marvell EBU platforms.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>

On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

As a minimal fix for stable, don't use window 13. A full fix will
follow later.

Fixes: fddddb52 ("bus: introduce an Marvell EBU MBus driver")
Cc: <stable@vger.kernel.org> # v3.10+
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>

The arm-cci driver completes the probe sequence even if the cci node is
marked as disabled. Add a check in the driver to honour the cci status
in the device tree.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NSudeep Holla <sudeep.holla@arm.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

On Marvell EBU platforms, when doing suspend/resume, the SDRAM window
configuration must be saved on suspend, and restored on
resume. However, it needs to be restored on resume *before*
re-entering the kernel, because the SDRAM window configuration defines
the layout of the memory. For this reason, it cannot simply be done in
the ->suspend() and ->resume() hooks of the mvebu-mbus driver.

Instead, it needs to be restored by the bootloader "boot info"
mechanism used when resuming. This mechanism allows the kernel to
define a list of (address, value) pairs when suspending, that the
bootloader will restore on resume before jumping back into the kernel.

This commit therefore adds a new function to the mvebu-mbus driver,
called mvebu_mbus_save_cpu_target(), which will be called by the
platform code to make the mvebu-mbus driver save the SDRAM window
configuration in a way that can be understood by the bootloader "boot
info" mechanism.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1416585613-2113-8-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

This commit extends the mvebu-mbus driver to provide suspend/resume
support. Since mvebu-mbus is not a platform_driver, the syscore_ops
mechanism is used to get ->suspend() and ->resume() hooks called into
the driver.

In those hooks, we save and restore the MBus windows state, to make
sure after resume all Mbus windows are properly restored. Note that
while the state of some windows could be gathered by looking again at
the Device Tree (for statically described windows), it is not the case
of dynamically described windows such as the PCIe memory and I/O
windows. Therefore, we take the simple approach of saving and
restoring the registers for all MBus windows.

In addition, the commit extends the Device Tree binding of the MBus
controller, to control the MBus bridge registers (which define which
parts of the physical address space is routed to MBus windows
vs. normal RAM memory). Those registers must be saved and restored
during suspend/resume. The Device Tree binding extension is made is a
backward compatible fashion, but of course, suspend/resume will not
work without the Device Tree update.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1416585613-2113-7-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

This will select the appropriate register layout based on the DT
"compatible" string.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

There are at least 4 incompatible variations of this hardware block,
so let's use the ARB_* constants as a table index instead of hardcoding
specific register offsets.  Also, allow for the possibility of adding
old devices that are missing some of the registers.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

These will be used to abstract out chip-to-chip differences.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

BCM7xxx ARM and MIPS platforms share a similar hardware block for
reporting GISB errors, so they both benefit from the use of this driver.
Conditionally compile the ARM-specific bus error handler so that the
GISB error IRQ handler works on other architectures.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

Commit f1bee783 moved the call to hook_fault_code in
brcmstb_gisb_arb_probe() which now calls a function annotated with __init, so
this one must also be annotated with __init.

In order to avoid introducing another section mismatch, call
platform_driver_probe() manually and remove the .probe assignment from
brcmstb_gisb_arb_driver, this is very similar to what
drivers/pci/host/pci-imx6.c does since we basically have the same constraints
here.

Fixes: f1bee783 ("bus: brcmstb_gisb: register the fault code hook")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Correct returning IRQ_HANDLED unconditionally in the irq handler.
Return IRQ_NONE for some interrupt which we do not expect to be
handled in this handler. This prevents kernel stalling with back
to back spurious interrupts.

Fixes: 2722e56d ("OMAP4: l3: Introduce l3-interconnect error handling driver")
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On certain SoCs such as AM437x SoC, L3_noc error registers are
maintained in power domain such as per domain which looses context as part
of low power state such as RTC+DDR mode. On these platforms when we
mask interrupts which we cannot handle, the source of these interrupts
still remain on resume, however, the flag mux registers now contain
their reset value (unmasked) - this breaks the system with infinite
interrupts since we do not these interrupts to take place ever again.

To handle this: restore the masking of interrupts which we have
already recorded in the system as ones we cannot handle.

Fixes: 2100b595 ("bus: omap_l3_noc: ignore masked out unclearable targets")
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When booting omap3 in device tree mode, we're currently getting
the following errors:

omap_l3_smx omap_l3_smx.0: couldn't request debug irq
omap_l3_smx: probe of omap_l3_smx.0 failed with error -22

This is because we don't have handling in the driver for the
compatible property and instead assume platform data being
passed.

Note that this binding is already documented, and implemented
for the related omap_l3_noc driver for omap4 and later. Looks
like the binding somehow never got never implemented for this
omap_l3_smx driver though.

Let's also remove __exit_p to allow binding and unbinding
of the driver while at it.
Reported-by: NPavel Machek <pavel@ucw.cz>
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The ARM CPU PMUs and the ARM CCI PMU are using the same framework
despite being substantially different in programming model, which makes
it difficult to handle either particularly well.

This patch migrates the ARM CCI PMU driver away from the arm_pmu
framework, matching the style of the CCN PMU driver and other 'uncore'
PMU drivers. This will enable refactoring of the arm_pmu framework to
better support CPU PMUs. Event context migration on hotplug is not yet
added due to a race on event->ctx in the core perf code.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NPunit Agrawal <punit.agrawal@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
[will: fix whitespace issues]
Signed-off-by: NWill Deacon <will.deacon@arm.com>

When the system enters S3, we will lose the GISB timeout value we have
configured, make sure that we do save this timeout value, and restore
this timeout value prior to re-enabling interrupts such that the GISB
timeout interrupt will fire with the expected timeout.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

Commit 44127b77 ("bus: add Broadcom GISB bus arbiter timeout/error
handler") added everything that is required to register an ARM fault
handler for imprecise external aborts, except that there is nothing
calling this currently.

We do not need to export that specific function and have to update
arch/arm/mach-bcm/brcmstb.c to call it, simply, register the fault
handler during the probe() function of the driver.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Because CCN's cycle counter always runs, it will generate
an interrupt on overflow even if the relevant perf event
was not requested, causing a spurious warning message.

Fixed now by warning on only normal counter unwanted
overflows. Also cleaning the overflow mask at init now,
not to warn on event previously requested by firmware.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Commit d4d8819e ("bus: omap_l3_noc: fix masterid detection")
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits to ensure that connIDs map to "Table
13-18. ConnID Values" as provided in Technical Reference Manuals for
OMAP4430(Rev AP, April 2014, SWPU220AP) and OMAP4460(Rev AB, April
2014, SWPU234AB)

Fixes: d4d8819e ("bus: omap_l3_noc: fix masterid detection")
Reported-by: NKristian Otnes <kotnes@cisco.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The function cleaning up an initialized event
was called from the "event_del" handler, instead
of being used as the "destroy" callback. In case of
events group allocation this caused NULL pointer
dereference (as events are added and deleted
multiple times then). Fixed now.
Signed-off-by: NPawel Moll <mail@pawelmoll.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

A message warning a user about wrong vc value was printing
out port instead.
Reported-by: NDrew Richardson <drew.richardson@arm.com>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The bitfield allocation function returns error condition
as a negative value, but in two cases its result
was assigned to an unsigned member of the hw_perf_event
structure, thus the error would not be ever detected.

Fixed by using an intermediate, signed variable.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

In commit ae91d60b, a bug was fixed that
involved converting !x & y to !(x & y).  The code below shows the same
pattern, and thus should perhaps be fixed in the same way.

The Coccinelle semantic patch that makes this change is as follows:

// <smpl>
@@ expression E1,E2; @@
(
  !E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// </smpl>
Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Acked-by: NPunit Agrawal <punit.agrawal@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The CCN driver makes no sense without PERF_EVENTS, and trying to
build it when that option is disabled results in compile errors,
so it's best to just add a strong Kconfig dependency.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Driver providing perf backend for ARM Cache Coherent Network
interconnect. Supports counting all hardware events and crosspoint
watchpoints.

Currently works with CCN-504 only, although there should be
no changes required for CCN-508 (just impossible to test it now).
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

There could be some memory map devices located in
a certain chip select region of the i.MX WEIM.
The devices could be attached to a simple bus(for
example, a AXI bus) whose root node is one child
device tree node of the i.MX WEIM device tree node.
There should be a bridge(very likely, software
transparent) bewteen the i.MX WEIM and the simple bus.
This patch makes the i.MX WEIM driver possible to
populate devices on a simple bus.  In this way, people
may try various IPs(in a FPGA, maybe) outside of i.MX
chips with the i.MX WEIM embedded.
Signed-off-by: NLiu Ying <Ying.Liu@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

devm_request_and_ioremap() was obsoleted by the commit 75096579
("lib: devres: Introduce devm_ioremap_resource()") and has been
deprecated for a long time. So, let's remove this function.
In addition, all usages of devm_request_and_ioremap() are also
removed.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The arm-cci code uses device tree helpers for initialization
that don't work on kernels built without CONFIG_OF. Further,
it contains an inline assembly in cci_enable_port_for_self()
that uses ARMv7 instructions and fails to build when targetting
other ARM instruction set versions.

This works around both issues by limiting the scope of the
Kconfig symbol to platforms that can actually build this driver
cleanly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Shawn Guo <shawn.guo@linaro.org>

The versatile express changes for 3.16 introduced a number of
build regressions for randconfig kernels by not tracking dependencies
between the components right.

This patch tries to rectify that:

* the mach-vexpress code cannot link without the syscfg driver,
  which in turn needs MFD_VEXPRESS_SYSREG
* various drivers call devm_regmap_init_vexpress_config(), which
  has to be exported so it can be used by loadable modules
* the configuration bus uses OF DT helper functions that are not
  available to platforms disable CONFIG_OF
* The sysreg driver exports GPIOs through gpiolib, which can
  be disabled on some platforms.
* The clocksource code cannot be built on platforms that don't
  use modern timekeeping but rely on gettimeoffset.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch adds support for the Broadcom GISB arbiter bus timeout/error
handler. GISB is a proprietary bus used by Broadcom Set Top Box
System-on-a-chip devices (BCM7xxx) which allows multiple masters and
clients to be interfaced with each other.

The bus arbiter offers support for generating two interrupts towards the
host CPU, thus allowing us to "catch" clock gated masters, or masters
being volontarily blocked for powersaving purposes, or do general system
troubleshooting.

We also register a hook with the ARM fault exception handling to allow
printing a more informative message than "imprecise external abort at
0x00000000" for instance.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Components of the Versatile Express platform (configuration
microcontrollers on motherboard and daughterboards in particular)
talk to each other over a custom configuration bus. They
provide miscellaneous functions (from clock generator control
to energy sensors) which are represented as platform devices
(and Device Tree nodes). The transactions on the bus can
be generated by different "bridges" in the system, some
of which are universal for the whole platform (for the price
of high transfer latencies), others restricted to a subsystem
(but much faster).

Until now drivers for such functions were using custom "func"
API, which is being replaced in this patch by regmap calls.
This required:

* a rework (and move to drivers/bus directory, as suggested
  by Samuel and Arnd) of the config bus core, which is much
  simpler now and uses device model infrastructure (class)
  to keep track of the bridges; non-DT case (soon to be
  retired anyway) is simply covered by a special device
  registration function

* the new config-bus driver also takes over device population,
  so there is no need for special matching table for
  of_platform_populate nor "simple-bus" hack in the arm64
  model dtsi file (relevant bindings documentation has
  been updated); this allows all the vexpress devices
  fit into normal device model, making it possible
  to remove plenty of early inits and other hacks in
  the near future

* adaptation of the syscfg bridge implementation in the
  sysreg driver, again making it much simpler; there is
  a special case of the "energy" function spanning two
  registers, where they should be both defined in the tree
  now, but backward compatibility is maintained in the code

* modification of the relevant drivers:

  * hwmon - just a straight-forward API change
  * power/reset driver - API change
  * regulator - API change plus error handling
    simplification
  * osc clock driver - this one required larger rework
    in order to turn in into a standard platform driver
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NMark Brown <broonie@linaro.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NMike Turquette <mturquette@linaro.org>

Add AM4372 information to handle L3 error.

AM4372 has two clk domains 100f and 200s. Provide flagmux and data
associated with it.

NOTE: Timeout doesn't have STDERRLOG_MAIN register. And per hardware
team, L3 timeout error cannot be cleared the normal way (by setting
bit 31 in STDERRLOG_MAIN), instead it may be required to do system
reset. L3 error handler can't help in such scenarios.

Hence indicate timeout target offset as L3_TARGET_NOT_SUPPORTED as
done for undocumented bits.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
     <0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
     <0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

While OMAP4 and OMAP5 had 3 separate clock domains, DRA7 has only 2
and the first one then is internally divided into 2 sub clock domains.

To better represent this in the driver, we use the concept of submodule.

The address defintions in the devicetree is as per the high level
clock domain(module) base, the sub clockdomain/subdomain which shares
the same register space of a clockdomain is marked in the SoC data as
L3_BASE_IS_SUBMODULE.

L3_BASE_IS_SUBMODULE is used as an indication that it's base address is
the same as the parent module and offsets are considered from the same
base address as they are usually intermingled.

Other than the base address, the submodule is same as a module as it is
functionally so.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

L3 error may be triggered using Debug interface (example JTAG) or
due to other errors, for example an opcode fetch (due to function
pointer or stack corruption) or a data access (due to some other
failure). NOC registers contain additional information to help aid
debug information.

With this, we can enhance the error information to more detailed form:
"
L3 Custom Error: MASTER MPU TARGET L4PER2 (Read): Data Access in User mode
during Functional access
"
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Today we get error such as
L3 Custom Error: MASTER MPU TARGET L4PER2

But since the actual instruction triggerring the error Vs the point
at which we report error may not be aligned, it makes sense to try
and provide additional information - example the type of operation
that was attempted to being performed can help narrow the debug down
further.

This helps provide log such as:
L3 Custom Error: MASTER MPU TARGET L4PER2 (Read)
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Errors that cannot be cleared (determined by reading REGERR register)
are currently handled by masking it. Documentation states that REGERR
"Checks which application/debug error sources are active" - it does not
indicate that this is "interrupt status" - masked out status represented
eventually in the irq line to MPU.
For example:

Lets say module 0 bit 8(0x100) was unclearable, we do the mask it from
generating further errors. However in the following cases:
a) bit 9 of Module 0
OR
b) any bit of Module 1+
occur, the interrupt handler wrongly assumes that the raw interrupt
status of module 0 bit 8 is the root cause of the interrupt, and
returns. This causes unhandled interrupt and resultant infinite
interrupts.

Fix this scenario by storing the events we masked out and masking raw
status with masked ones before identifying and handling the error.
Reported-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@gmail.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>