This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

omap_l3_noc interrupt

Other Parts Discussed in Thread: DRA746, DRA742

We're using a DRA746 (at least, I'm *pretty* sure that's the one...), and we're seeing something odd from time to time.

We get a "WARNING: MASTER MPU TARGET HOST CLK2 (Idle): At address: 0x00000000: Data Access in User mode during Functional Access".  The address isn't always zero depending on the source.

We understand the "MASTER MPU" but what is the "TARGET HOST CLK2"?

We cannot find anything in the manual that shows a CLK2 as such.  There's HOST_CLK1_1, HOST_CLK1_2, and HOST_CLK2_1.  Should the label read "HOST CLK2 1"?  

Most importantly, what causes this?  We've seen it happen in a few cases. When it happens during a USB2 access (via the USB3 controller), the warning message never stops, which for all intents and purposes makes the system unusable.  It's been observed during an I2C access (it happened two times in a row back-to-back during a set of I2C transactions), and it's been observed happening during other uses which don't lock up the system.

Thanks,

Matt Gessner

  • Matt,
    I moved your question to the OMAP forums. You should get a quicker answer here.
    -Clancy
  • host_clk1, 2 definition is unique to DRA7 and not OMAP5.

  • Clancy,
    It's been a few weeks now. Can you please move this back to the automotive forums? There's been no new information here.
    Thanks,
    -Matt
  • Matt,

    Thanks for reaching out. I'll try to find someone who can help.

    -Clancy
  • Hello Matt,

    About your questions:

    Q1: We cannot find anything in the manual that shows a CLK2 as such.  There's HOST_CLK1_1, HOST_CLK1_2, and HOST_CLK2_1.  Should the label read "HOST CLK2 1"?  


    I suggest you to see L3_MAIN Interconnect Integration in TRM.

    The L3 interconnect is divided into two clock domains L3_CLK1 and L3_CLK2. CLK1 domain is further
    splitted into two sub groups:
    • L3_CLK1_1: Low-power domain
    • L3_CLK1_2: Peripherals and multimedia
    • L3_CLK2: Instrumentation (debug)

    L3_CLK1_1 -> HOST_CLK1_1

    L3_CLK1_2 -> HOST_CLK1_2

    L3_CLK2 -> HOST_CLK2_1


    My point of view about your issue with I2C interface:

    I assume that this issue is not caused by Interconnect module. I suggest you to check I2C addresses.

    Best regards,

    Yanko

  • Yanko,

    Thank you for your reply. Thanks for explaining the clock naming confusion.

    With regards to my original question, however, no one seems to be able to explain where this message comes from. What does it mean??

    Also, with regards to I2C, there is nothing wrong with the addressing.

    Also, please re-read the original message, where it explains that when trying to access the USB2 port on the USB3 controller, sometimes this interrupt message continues forever, and makes the system unusable. Can you shed any light on this condition?

    Thanks.

    Best regards,

    Matt
  • Hello Matt,

    In OMAP based devices as DRA7xx, the I2C hardware may shared with other coprocessors.  This means that the MPU will still recieve interrupts if a coprocessor  is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -> runtime_suspend() (and
    re-enable them in -> runtime_resume().) This part based on an original patch from Shubhrajyoti Datta.

    NOTE: for proper sharing the I2C with  a coprocessor, this driver still needs hwspinlock support added.

    I suggest you to see this patch - http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251558.html

    See also this discussion - http://e2e.ti.com/support/omap/f/849/t/333590

    What is your HW board with DRA7xx?

    If you use your custom made board, I suggest you to check the PU/PD resistors configurations for I2C.

    For example see a similar patch for OMAP - http://review.omapzoom.org/#/c/20003/

    Best regards,

    Yanko

  • We are also facing similar L3 error in kernel (see log below). We're running Linux kernel + u-boot on custom board with DRA742 SoC. SYSBOOT pins are configured for eMMC boot.

    After investigation it turned out this L3 error was occured before 1st bootloader (i.e. in ROM code). The value of L3_FLAGMUX_REGERR0 register (which is 0x4480360C) was read immediately after "reset:" label, in u-boot's arch/arm/cpu/armv7/start.S file, and this value is 0x00000040. So it looks like L3 error occurred on ROM code executing stage. Later we see L3 error message in kernel.

    It would be great to hear any suggestions about why it can happen and how to fix it.

    Kernel log:
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    [ 0.275482] WARNING: at ..../android-3.8/drivers/bus/omap_l3_noc.c:183 l3_interrupt_handler+0x3a0/0x460()
    [ 0.275482] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Read): Data Access in User mode during Functional access
    [ 0.275482] Modules linked in:
    [ 0.275512] [<c00154cc>] (unwind_backtrace+0x0/0xf0) from [<c0036da0>] (warn_slowpath_common+0x4c/0x64)
    [ 0.275512] [<c0036da0>] (warn_slowpath_common+0x4c/0x64) from [<c0036e4c>] (warn_slowpath_fmt+0x30/0x40)
    [ 0.275543] [<c0036e4c>] (warn_slowpath_fmt+0x30/0x40) from [<c01c248c>] (l3_interrupt_handler+0x3a0/0x460)
    [ 0.275543] [<c01c248c>] (l3_interrupt_handler+0x3a0/0x460) from [<c0081698>] (handle_irq_event_percpu+0x50/0x194)
    [ 0.275573] [<c0081698>] (handle_irq_event_percpu+0x50/0x194) from [<c0081818>] (handle_irq_event+0x3c/0x5c)
    [ 0.275573] [<c0081818>] (handle_irq_event+0x3c/0x5c) from [<c008451c>] (handle_fasteoi_irq+0x98/0x158)
    [ 0.275604] [<c008451c>] (handle_fasteoi_irq+0x98/0x158) from [<c0081070>] (generic_handle_irq+0x20/0x30)
    [ 0.275604] [<c0081070>] (generic_handle_irq+0x20/0x30) from [<c000eeac>] (handle_IRQ+0x4c/0xb0)
    [ 0.275604] [<c000eeac>] (handle_IRQ+0x4c/0xb0) from [<c00084d4>] (gic_handle_irq+0x28/0x5c)
    [ 0.275634] [<c00084d4>] (gic_handle_irq+0x28/0x5c) from [<c044bd80>] (__irq_svc+0x40/0x74)
    [ 0.275634] Exception stack(0xe8877ce0 to 0xe8877d28)
    [ 0.275634] 7ce0: e8806250 60000113 00070007 00000000 e8806200 e8912b00 e8806250 00000020
    [ 0.275665] 7d00: 0000002a e8806230 60000113 e8912c18 00000000 e8877d28 c0082b7c c044b60c
    [ 0.275665] 7d20: 60000113 ffffffff
    [ 0.275665] [<c044bd80>] (__irq_svc+0x40/0x74) from [<c044b60c>] (_raw_spin_unlock_irqrestore+0x2c/0x54)
    [ 0.275695] [<c044b60c>] (_raw_spin_unlock_irqrestore+0x2c/0x54) from [<c0082b7c>] (__setup_irq+0x1ac/0x440)
    [ 0.275695] [<c0082b7c>] (__setup_irq+0x1ac/0x440) from [<c0082eb4>] (request_threaded_irq+0xa4/0x130)
    [ 0.275726] [<c0082eb4>] (request_threaded_irq+0xa4/0x130) from [<c0084b5c>] (devm_request_threaded_irq+0x50/0x90)
    [ 0.275726] [<c0084b5c>] (devm_request_threaded_irq+0x50/0x90) from [<c01c2048>] (omap_l3_probe+0x1d4/0x278)
    [ 0.275726] [<c01c2048>] (omap_l3_probe+0x1d4/0x278) from [<c024fef8>] (platform_drv_probe+0x18/0x1c)
    [ 0.275756] [<c024fef8>] (platform_drv_probe+0x18/0x1c) from [<c024ecac>] (driver_probe_device+0x74/0x210)
    [ 0.275756] [<c024ecac>] (driver_probe_device+0x74/0x210) from [<c024d3fc>] (bus_for_each_drv+0x44/0x8c)
    [ 0.275787] [<c024d3fc>] (bus_for_each_drv+0x44/0x8c) from [<c024ec00>] (device_attach+0x74/0x8c)
    [ 0.275787] [<c024ec00>] (device_attach+0x74/0x8c) from [<c024e27c>] (bus_probe_device+0x84/0xa8)
    [ 0.275817] [<c024e27c>] (bus_probe_device+0x84/0xa8) from [<c024cb58>] (device_add+0x4c4/0x590)
    [ 0.275817] [<c024cb58>] (device_add+0x4c4/0x590) from [<c0303794>] (of_platform_device_create_pdata+0x58/0x80)
    [ 0.275817] [<c0303794>] (of_platform_device_create_pdata+0x58/0x80) from [<c030389c>] (of_platform_bus_create+0xe0/0x164)
    [ 0.275848] [<c030389c>] (of_platform_bus_create+0xe0/0x164) from [<c030397c>] (of_platform_populate+0x5c/0x9c)
    [ 0.275848] [<c030397c>] (of_platform_populate+0x5c/0x9c) from [<c061924c>] (omap_generic_init+0x28/0x1e0)
    [ 0.275878] [<c061924c>] (omap_generic_init+0x28/0x1e0) from [<c060c3a8>] (customize_machine+0x1c/0x28)
    [ 0.275878] [<c060c3a8>] (customize_machine+0x1c/0x28) from [<c00087b8>] (do_one_initcall+0x100/0x168)
    [ 0.275878] [<c00087b8>] (do_one_initcall+0x100/0x168) from [<c0609938>] (kernel_init_freeable+0xf8/0x1c8)
    [ 0.275909] [<c0609938>] (kernel_init_freeable+0xf8/0x1c8) from [<c043efe4>] (kernel_init+0x8/0xe4)
    [ 0.275909] [<c043efe4>] (kernel_init+0x8/0xe4) from [<c000e018>] (ret_from_fork+0x14/0x3c)
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  • Hello Semen,

    I suggest you to read L3_FLAGMUX_REGERR0 and check which source set a flag.
    Check the addresses:
    0x4480 350C ==> CLK1_FLAGMUX_CLK1_1
    0x4480 360C ==> CLK1_FLAGMUX_CLK1_2
    0x4500 020C ==> CLK2_FLAGMUX_CLK2_1

    Afterwards, see in Table 14-24. Interconnect Flag Mapping in TRM to define which module is source of this issue.
    Then check module's driver implementation.

    Best regards,
    Yanko