summaryrefslogtreecommitdiff
path: root/drivers/bus/omap_l3_noc.h
AgeCommit message (Collapse)Author
2015-05-04bus: omap_l3_noc: Fix master id address decoding for OMAP5Suman Anna
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 <s-anna@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instanceIllia Smyrnov
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 <illia.smyrnov@globallogic.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-09-11bus: omap_l3_noc: Fix connID for OMAP4Nishanth Menon
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 <kotnes@cisco.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-05-05bus: omap_l3_noc: Add AM4372 interconnect error dataAfzal Mohammed
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 <d-gerlach@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: Add DRA7 interconnect error dataRajendra Nayak
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 <rnayak@ti.com> [nm@ti.com: bugfixes and generic improvements, documentation] Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: introduce concept of submoduleNishanth Menon
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 <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: Add information about the context of operationNishanth Menon
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 <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: add information about the type of operationNishanth Menon
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 <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: ignore masked out unclearable targetsAfzal Mohammed
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 <hvaibhav@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@gmail.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: make error reporting and handling commonNishanth Menon
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: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: fix masterid detectionNishanth Menon
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: Darren Etheridge <detheridge@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: convert flagmux information into a structureNishanth Menon
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: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: use of_match_data to pick up SoC informationSricharan R
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: Sricharan R <r.sricharan@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> [nm@ti.com: split, refactor and optimize logic] Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: Add support for discountinous flag mux input numbersRajendra Nayak
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: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: convert target information into a structureNishanth Menon
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: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: move L3 master data structure outNishanth Menon
Move the L3 master structure out of the static definition to enable reuse for other SoCs. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: remove iclk from omap_l3 structNishanth Menon
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: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: rename functions and data to omap_l3Sricharan R
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: Sricharan R <r.sricharan@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2014-05-05bus: omap_l3_noc: Fix copyright informationNishanth Menon
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: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Sekhar Nori <nsekhar@ti.com>
2012-09-19drivers: bus: Move the OMAP interconnect driver to drivers/bus/Santosh Shilimkar
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: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>