05 May, 2015

2 commits

  • 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

    Suman Anna
     
  • 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

    Illia Smyrnov
     

12 Sep, 2014

1 commit

  • 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

    Nishanth Menon
     

06 May, 2014

16 commits

  • 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

    Afzal Mohammed
     
  • DRA7 is distinctly different from OMAP4 in terms of masters and clock
    domain organization. There two main clock domains which is divided as
    follows:
    is clk1 and clk2 is the sub clock domain
    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

    Rajendra Nayak
     
  • 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

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

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

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

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

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

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

    Nishanth Menon
     
  • 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
    Signed-off-by: Rajendra Nayak
    [nm@ti.com: split, refactor and optimize logic]
    Signed-off-by: Nishanth Menon
    Acked-by: Santosh Shilimkar
    Acked-by: Peter Ujfalusi
    Tested-by: Darren Etheridge
    Tested-by: Sekhar Nori

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

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

    Nishanth Menon
     
  • Move the L3 master structure out of the static definition to enable
    reuse for other SoCs.

    Signed-off-by: Nishanth Menon
    Acked-by: Santosh Shilimkar
    Acked-by: Peter Ujfalusi
    Tested-by: Darren Etheridge
    Tested-by: Sekhar Nori

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

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

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

    Nishanth Menon
     

19 Sep, 2012

1 commit