• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 640 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/AM3352: SDK 8.0 patch question

user4865815
Prodigy 150 points

Part Number: AM3352

Tool/software: Linux

Dear all:

Our product is based on AM3352 and AMSDKv8.0. We find that the CPSW ethernet performance will become slow and the CPU utiliaztion will be 100% after running iperf or vsftpd application a few moment (about one minute).

This problem also be reported in this topic:https://e2e.ti.com/support/arm/sitara_arm/f/791/t/586788

Using SDK 01.00.00.03 can fix this problem. Also, I have found the patch below in AMSDK v8.0 cause the problem.

But I do not understand the reason. Can you give me an explanation:
1. Why this patch about mailbox-wkup_m3 module in AMSDK v8.0 can effect the CPSW ethernet performance and cause the CPU utilization very high ?
2. Which patches in SDK v01.00.00.03 fix this problem ?


=============================================
commit 2e560903e75ef790fd0428dbb53f65a2ee1ad4c6
Author: Dave Gerlach <d-gerlach@ti.com>
Date: Wed Dec 10 04:18:16 2014 +0000

mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

The mailbox framework controls the transmission queue and requires
either its controller implementations or clients to run the state
machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
interrupt as the equivalent of a Tx-done interrupt to run this Tx
queue state-machine.

The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload
certain PM tasks, like doing the necessary operations for Device
PM suspend/resume or for entering lower c-states during cpuidle.

The CPUIdle on AM33xx requires the messages to be sent without
having to trigger the Tx-ready interrupts, as the interrupt
would immediately terminate the CPUIdle operation. Support for
this has been added by introducing a DT quirk, "ti,mbox-send-noirq"
and using it to modify the normal OMAP mailbox controller behavior
on the sub-mailboxes used to communicate with the WkupM3 remote
processor. This also requires the wkup_m3_ipc driver to adjust
its mailbox usage logic to run the Tx state machine.

NOTE:
- AM43xx does not communicate with WkupM3 for CPU Idle, so is
not affected by this behavior. But, it uses the same IPC driver
for PM suspend/resume functionality, so requires the quirk as
well, because of changes to the common wkup_m3_ipc driver.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[s-anna@ti.com: revise logic and update comments/patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

Documentation/devicetree/bindings/mailbox/omap-mailbox.txt | 8 ++++++++
drivers/mailbox/omap-mailbox.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 58 insertions(+), 4 deletions(-)

=============================================

The screenshot (the CPU utiliaztion is 100% when have FTP transfer)

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 150 points
    I have found the follow commit in Processor-SDK-v01.00.00.03 fixed the problem. The comment in the commit have a detail explain for the reason. Thanks very much !

    ================================================
    commit 338a690623badfc3bc3eb6ddc7302e03ab33e6ba
    Author: Dave Gerlach <d-gerlach@ti.com>
    Date: Thu Mar 26 13:41:47 2015 -0500

    ARM: OMAP2+: cpuidle33xx: Change wkup_m3 idle state to avoid MPU PLL bypass

    To get to C1-state in cpuidle am33xx currently uses the wkup_m3 to gate
    the MPU clock domain and bypass the MPU PLL. Because we are not shutting
    off the MPU power domain in this C-state it is possible for both to be
    awake and executing at the same time, and we do not have the ability
    to synchronize execution between the two in the cpuidle path due to
    no interrupt context.

    This leads to racy behavior between the two and in certain instances
    where c1-state is entered often during periods of high cpu activity it
    is possible for the MPU to interfere with the wake path on the wkup_m3,
    which prevents the MPU PLL from being re-locked and causing extreme
    system slowdown.

    Because of this, we must now use a different idle state available on the
    current wkup_m3 firmware (0x190) which does nothing more than put the
    MPU clockdomain to sleep, giving us the same power savings seen
    previously on the MPU power rail but slightly higher power on the
    MPU_PLL voltage rail.

    Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

    arch/arm/mach-omap2/pm33xx.h | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    ================================================