kernel/linux.git/drivers/bus/omap_l3_noc.h, branch v6.18.18

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_320.RULE

2022-06-10T12:51:36+00:00

Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

bus: omap_l3_noc: Fix master id address decoding for OMAP5

2015-05-04T17:21:01+00:00

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: Suman Anna Acked-by: Nishanth Menon Signed-off-by: Tony Lindgren

bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance

2015-05-04T17:21:01+00:00

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: Illia Smyrnov Signed-off-by: Nishanth Menon Signed-off-by: Tony Lindgren

bus: omap_l3_noc: Fix connID for OMAP4

2014-09-11T17:43:39+00:00

Commit d4d8819e205854c ("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: d4d8819e205854c ("bus: omap_l3_noc: fix masterid detection") Reported-by: Kristian Otnes Signed-off-by: Nishanth Menon Signed-off-by: Tony Lindgren

bus: omap_l3_noc: Add AM4372 interconnect error data

2014-05-05T19:34:37+00:00

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: Dave Gerlach Signed-off-by: Afzal Mohammed Signed-off-by: Sekhar Nori Signed-off-by: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori

bus: omap_l3_noc: Add DRA7 interconnect error data

2014-05-05T19:34:26+00:00

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: Rajendra Nayak [nm@ti.com: bugfixes and generic improvements, documentation] Signed-off-by: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori

bus: omap_l3_noc: introduce concept of submodule

2014-05-05T19:34:20+00:00

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: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori

bus: omap_l3_noc: Add information about the context of operation

2014-05-05T19:34:15+00:00

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: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori

bus: omap_l3_noc: add information about the type of operation

2014-05-05T19:34:09+00:00

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: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori

bus: omap_l3_noc: ignore masked out unclearable targets

2014-05-05T19:34:03+00:00

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: Vaibhav Hiremath Signed-off-by: Afzal Mohammed Tested-by: Vaibhav Hiremath Signed-off-by: Sekhar Nori Signed-off-by: Nishanth Menon Tested-by: Sekhar Nori