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>
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>
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>
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>
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>
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>
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>
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>
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>
Nishanth Menon