Post Go back to editing

MAX3421 High CPU Load Embedded Linux

Category: Hardware
Product Number: MAX3421E

Running no any other application under Linux. the Max3421 driver uses to 25%-27% CPU time. (Host mode).

When running a graphical app, when a device is plugged in the performance impact is visible in stuttering of the graphics rendering.

The stuttering does not happen when there are no USB devices connected to it.

What could be root causes for this ? Could it be poor signal quality ?

The USB device itself is doing nothing.

We use the Keyes board with MAX3421 and run it at max 12MHz . it  is connected with some wires to a SPI header on the embedded board.

connected USB devices themselves run fine.

Sometimes  when a device is connected, Linux prompt many messages such as , after a while this may stop.

  306.624318] hub 3-0:1.0: hub_suspend
[  306.703367] hub 1-0:1.0: hub_resume
[  306.705707] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  306.719144] hub 1-0:1.0: hub_suspend
[  306.922223] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
[  306.926641] usb usb4-port1: status 0101, change 0001, 12 Mb/s
[  306.968361] hub 2-0:1.0: hub_resume
[  306.970610] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  306.985082] hub 2-0:1.0: hub_suspend
[  307.280638] usb usb4-port1: debounce total 175ms stable 100ms status 0x100
[  307.286746] hub 3-0:1.0: hub_resume
[  307.289878] usb usb3-port1: status 0507 change 0000
[  307.300580] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  307.305033] usb 3-1: usb auto-resume
[  307.390123] usb 3-1: Waited 0ms for CONNECT
[  307.393438] usb 3-1: finish resume
[  307.397568] hub 3-1:1.0: hub_resume
[  307.407799] hub 3-1:1.0: state 7 ports 4 chg 0000 evt 0000
[  307.413293] hub 3-1:1.0: hub_suspend
[  307.418249] usb 3-1: usb auto-suspend, wakeup 1
[  307.419942] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
[  307.427345] usb usb4-port1: status 0100, change 0001, 12 Mb/s
[  307.449813] hub 3-0:1.0: hub_suspend
[  307.549392] hub 1-0:1.0: hub_resume
[  307.551879] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  307.565172] hub 1-0:1.0: hub_suspend
[  307.629171] usb usb4-port1: debounce total 100ms stable 100ms status 0x100
[  307.692639] hub 2-0:1.0: hub_resume
[  307.695061] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  307.709188] hub 2-0:1.0: hub_suspend
[  307.714617] hub 3-0:1.0: hub_resume
[  307.716820] usb usb3-port1: status 0507 change 0000
[  307.727682] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  307.736547] usb 3-1: usb auto-resume
[  307.828114] usb 3-1: Waited 0ms for CONNECT
[  307.830922] usb 3-1: finish resume
[  307.835378] hub 3-1:1.0: hub_resume
[  307.841310] hub 3-1:1.0: state 7 ports 4 chg 0000 evt 0000
[  307.847105] hub 3-1:1.0: hub_suspend
[  307.851916] usb 3-1: usb auto-suspend, wakeup 1
[  307.887920] hub 3-0:1.0: hub_suspend
[  307.927766] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0002
[  307.932145] usb usb4-port1: status 0100, change 0001, 12 Mb/s
[  307.958175] hub 1-0:1.0: hub_resume
[  307.960498] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  307.975480] hub 1-0:1.0: hub_suspend
[  307.993972] systemd-journald[315]: Data hash table of /run/log/journal/d649c09102144cf38944c92ea4dba7d8/system.journal has a fill level at 75.0 (10923 of 14563 items, 8388608 file size, 767 bytes per hash table item), suggesting rotation.
[  308.021853] systemd-journald[315]: /run/log/journal/d649c09102144cf38944c92ea4dba7d8/system.journal: Journal header limits reached or header out-of-date, rotating.
[  308.319526] hub 2-0:1.0: hub_resume
[  308.321908] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[  308.336125] usb usb4-port1: debounce total 200ms stable 100ms status 0x101
[  308.342367] hub 2-0:1.0: hub_suspend
[  308.415785] usb usb4-port1: not reset yet, waiting 60ms
[  308.495579] usb usb4-port1: not reset yet, waiting 200ms
[  308.714632] usb usb4-port1: not reset yet, waiting 200ms
[  308.933841] usb usb4-port1: not reset yet, waiting 200ms

  • Hi,

    Which is the SPI bus operation frequency you use? Is it 26 Mhz?

    The function which is causing you high load is the main thread of the driver max3421_spi_thread.

    You can also check if the interrupts raised by the MAX driver are coming with a high rate "cat /proc/interrupts"

  • When a USB device is plugged in there are two counters increasing a lot.

    stm32gpio about 4000/second

    about 12000/second

    The device tree is set as 12MHz max due to concerns of potential signal quality when using wires to connect the board.

    spi-max-frequency = <12000000>;

    There are no dmesg messages after those that occurred after connecting the device. The device itself is working properly.

    When running at 26Mhz, the error appears   max3421-hcd spi0.0: bad rev 0x89. so it seems that causes a problem with SPI connection or other reasons.. At 12Mhz devices get enumerated (USB drives copy/ files etc.. and others) though at the expense of very high CPU load.

  • Hi,

    Even 12MHz over jumper wires is not ideal.

    It looks like you get a lot of GPIO interrupts and a lot of SPI transactions and that is the culprit for high CPU load.

    You can also check if the STM32 spi driver has support for burst transfers and maybe some DMA offload.

  • Thanks, Understand wires ares not ideal, it was just a POC to the kernel running with it. but notices the CPU loads, so that's why ask. Not sure what is SPI Bulk transfer, if that meant DMA then SPI is set in Full duplex mode and in the DT for DMA it is like this, thus suppose it's running DMA. Cannot find any other options in the DT bindings information for MAX or SPI.

    // /delete-property/dmas;
    // /delete-property/dma-names;

    AFAIK This is the vanilla MAX3421  Linux driver. Tried with 16Mhz and it is the same  I am not familiar with the MAx3421 driver itself, so trying to understand, how to determine the source of interrupts. Perhaps they indicate error condition ?  Is it normal that the SPI interface uses many interrupts /transactions ? Since I don't have a reference for a "good" interface, what would be a normal amount ? P.S: Working on a PCB layout with the MAX3421  rule out potential SI issues,