The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:

  1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
     11 bits on OMAP5 as against 8 bits on OMAP4, with the master
     NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
     field.
  2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
     input sources on OMAP5. The common DEBUGSS source is at a
     different input on each SoC.

Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015)
has updates for this information.

With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: NIllia Smyrnov <illia.smyrnov@globallogic.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

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>

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>

The logic between handling CUSTOM_ERROR and STANDARD_ERROR is just the
reporting style.

So make it generic, simplify and standardize the reporting with both
master and target information printed to log.

Handle the register address difference for master code for standard
error and custom error as well.

While at it, fix a minor indentation error.
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>

As per Documentation (OMAP4+), then masterid is infact encoded as
follows:
"L3_TARG_STDERRLOG_MSTADDR[7:0] STDERRLOG_MSTADDR stores the NTTP
master address. The master address is the concatenation of Prefix &
Initiator ConnID. It is defined on 8 bits. The 6 MSBs are used to
distinguish the different initiators."

So, when we matchup currently with the master ID list, we never get a
proper match other than when MPU is the master (thanks to 0).

Now, on other platforms such as AM437x, this tends to be bits[5:0].

Fix this by using the relevant 6MSBits to identify the master ID for
standard and custom errors.
Reported-by: NDarren Etheridge <detheridge@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>

This allows us to encompass target information and flag mux offset that
points to the target information into a singular structure. This saves
us the need to look up two different arrays indexed by module ID for
information.

This allows us to reduce the static target information allocation to
just the ones that are documented.
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>

DRA7xx SoC has the same l3-noc interconnect ip (as OMAP4 and OMAP5), but
AM437x SoC has just 2 modules instead of 3 which other SoCs have.

So, stop using direct access of array indices and use of->match data and
simplify implementation to benefit future usage.

While at it, rename a few very generic variables to make them omap
specific. This helps us differentiate from DRA7 and AM43xx data in the
future.

NOTE: None of the platforms that use omap_l3_noc are non-device tree
anymore. So, it is safe to assume OF match here.
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[nm@ti.com: split, refactor and optimize logic]
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>

On DRA7, unlike on OMAP4 and OMAP5, the flag mux input numbers used
to indicate the source of errors are not continous. Have a way in the
driver to catch these and WARN the user of the flag mux input thats
either undocumented or wrong.

In the similar vein, Timeout errors in AM43x can't be cleared per h/w
team, neither does it have a STDERRLOG_MAIN to clear the error.

Further, the mux bit offset might not even be indexed into our array
of known mux input description, in which case we'd have a abort.

So, define a static range check for bit description and any definition
which has target_name set to NULL (the ones that are not populated or
ones that are specifically marked in the case of discontinous input
numbers), can handle the same gracefully. Upon occurance of error from
such sources, mask it. Otherwise, we'd have an infinite interrupt
source without any means to clear it.

NOTE: follow on patch ensures that these masked bits are ignored.

[nm@ti.com: rebase, squash and improve]
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@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>

Currently the target instance information is organized indexed by bit
field offset into multiple arrays.

1. We currently have offsets specific to each target associated with each
clock domains are in seperate arrays:

l3_targ_inst_clk1
l3_targ_inst_clk2
l3_targ_inst_clk3

2. Then they are organized per master index in l3_targ.

3. We have names in l3_targ_inst_name as an array to array of strings
corresponding to the above with offsets.

Simplify the same by defining a structure for information containing
both target offset and name. this is then stored in arrays per domain
and organized into an array indexed off domain.

The array is still indexed based on bit field offset.
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>

Move the L3 master structure out of the static definition to enable
reuse for other SoCs.
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>

we do not use iclk directly anymore. And, even if we had to, we
should be using pm_runtime APIs to do the same to be completely SoC
independent.
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>

Since omap_l3_noc driver is now being used for OMAP5 and reusable with
DRA7 and AM437x, using omap4 specific naming is misleading.
Signed-off-by: NSricharan R <r.sricharan@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>

This is an embarrassing patch :(.

Texas Corporation does not make OMAP. Texas Instruments Inc does.

For that matter I dont seem to be able to find a Texas Corporation on
the internet either.

While at it, update coverage to the current year and update the template
to remove redundant information and use the standard boiler plate
licensing.
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>

OMAP interconnect drivers are used for the interconnect error handling.
Since they are bus driver, lets move it to newly created drivers/bus.
Tested-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

The initiator id gets logged in the l3 target registers for custom error.
So print it to aid debugging.

Based on a internal patch by Devaraj Rangasamy <dev@ti.com>
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Fix below sparse warnings from the l3-noc and l3-smx error handlers
files.

arch/arm/mach-omap2/omap_l3_smx.h:209:22: warning: symbol 'omap3_l3_app_bases' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_smx.h:308:22: warning: symbol 'omap3_l3_debug_bases' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_smx.h:325:2: warning: incorrect type in initializer (different address spaces)
arch/arm/mach-omap2/omap_l3_smx.h:325:2:    expected unsigned int [usertype] *
arch/arm/mach-omap2/omap_l3_smx.h:325:2:    got unsigned int [noderef] [toplevel] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_smx.h:326:2: warning: incorrect type in initializer (different address spaces)
arch/arm/mach-omap2/omap_l3_smx.h:326:2:    expected unsigned int [usertype] *
arch/arm/mach-omap2/omap_l3_smx.h:326:2:    got unsigned int [noderef] [toplevel] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_smx.h:324:5: warning: symbol 'omap3_l3_bases' was not declared. Should it be static?
  CC      arch/arm/mach-omap2/omap_l3_smx.o
  CHECK   arch/arm/mach-omap2/omap_l3_noc.c
arch/arm/mach-omap2/omap_l3_noc.c:73:13: warning: symbol '__v' shadows an earlier one
arch/arm/mach-omap2/omap_l3_noc.c:73:13: originally declared here
arch/arm/mach-omap2/omap_l3_noc.c:83:20: warning: symbol '__v' shadows an earlier one
arch/arm/mach-omap2/omap_l3_noc.c:83:20: originally declared here
arch/arm/mach-omap2/omap_l3_noc.c:90:5: warning: symbol '__v' shadows an earlier one
arch/arm/mach-omap2/omap_l3_noc.c:90:5: originally declared here
arch/arm/mach-omap2/omap_l3_noc.h:39:5: warning: symbol 'l3_flagmux' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.h:46:5: warning: symbol 'l3_targ_inst_clk1' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.h:54:5: warning: symbol 'l3_targ_inst_clk2' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.h:75:5: warning: symbol 'l3_targ_inst_clk3' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.h:79:6: warning: symbol 'l3_targ_inst_name' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.h:112:5: warning: symbol 'l3_targ' was not declared. Should it be static?
arch/arm/mach-omap2/omap_l3_noc.c:72:11: warning: cast removes address space of expression
arch/arm/mach-omap2/omap_l3_noc.c:73:13: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap2/omap_l3_noc.c:73:13:    expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_noc.c:73:13:    got unsigned int
arch/arm/mach-omap2/omap_l3_noc.c:83:20: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap2/omap_l3_noc.c:83:20:    expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_noc.c:83:20:    got unsigned int
arch/arm/mach-omap2/omap_l3_noc.c:90:5: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap2/omap_l3_noc.c:90:5:    expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_noc.c:90:5:    got unsigned int
arch/arm/mach-omap2/omap_l3_noc.c:96:5: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap2/omap_l3_noc.c:96:5:    expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_noc.c:96:5:    got unsigned int
arch/arm/mach-omap2/omap_l3_noc.c:108:5: warning: incorrect type in argument 1 (different base types)
arch/arm/mach-omap2/omap_l3_noc.c:108:5:    expected void const volatile [noderef] <asn:2>*<noident>
arch/arm/mach-omap2/omap_l3_noc.c:108:5:    got unsigned int
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reported-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>

The indentation problems in the l3 noc and smx
error handler files are fixed.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reported-by: NPaul Walmsley <paul@pwsan.com>

* Changed the way of accessing L3 target
  registers from standard base rather
  than relative to STDERRLOG_MAIN.

* Use ffs() to find error source from
  the L3_FLAGMUX_REGERRn register.

* Remove extra l3_base[] entry.

* Modified L3 custom error message.
Signed-off-by: NTodd Poynor <toddpoynor@google.com>
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

The driver provides the information regarding the ocp errors
that gets logged in the interconnect. The error information
gives the detail regarding the target that was attempted
to be accessed and its corresponding address.
Signed-off-by: Nsricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NBenoit Cousson <b-cousson@ti.com>