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.

TCAN4551-Q1: Linux driver has low performance

Part Number: TCAN4551-Q1
Other Parts Discussed in Thread: TCAN4550, TCAN4552

Tool/software:

Hi

We are observing low performance in the Linux driver for this part with our SOC. We are using an older Linux kernel on the SOC, but have backported the code as per a newer version of the available driver from the Linux kernel.

Is there a performance patch that is available for this part to improve the reception performance?

I could see in some other forum posts that there is some improved driver that can be made available.

Can TI team support on this?

  • Hello Anadi,

    By "low performance" I am assuming you are referring to the overall maximum CAN message bandwidth that can be supported.  The primary limitation to this is the SPI communication between the TCAN4551-Q1 and the MCU that is required to transfer the CAN message data between the devices and to read and write device registers.

    The TCAN4551-Q1 supports multi-word SPI R/W transactions for consecutive register and MRAM address locations.  However, the initial Linux driver only used the single-word communication that requires an address word for each register and MRAM data word that is transferred and is somewhat inefficient. 

    A revision to the driver was developed to use multi-word communication when possible and to improve the efficiency as much as possible.  These updates were submitted to the Linux community for review and upstreaming into the Linux Kernel, but I do not know the status of this process and whether it has been upstreamed already.

    Can you tell me specifically the version numbers of the Linux Kernel version and Driver you are using?  I don't know what "older" and "newer" means and whether we have anything to provide beyond what you already have.

    Regards,

    Jonathan

  • Dear Jonathan,

    Aplogies for the incomplete information.

    We are using the Linux 4.18 kernel
    We have backported from the 6.9.3
    m_can - drivers/net/can/m_can - Linux source code (v6.9.3) - Bootlin

    Can you please support with the details of the enchanced version that you have implemented?

  • By "low performance" I am assuming you are referring to the overall maximum CAN message bandwidth that can be supported.

    We see a significant packet drop from the bus and the data fetch over the bus takes a very long time.

    We need to reduce the time required to read the data over the SPI. The improved multiword read enhancement that you have indicated, may allow us to improve the performance of the data reception.

  • Hello Anadi,

    Thanks for the version information, and you may already have access to the updated drivers which was accepted in the final v6.6 release.  Here is the last info I have from the developers about this patch.

    The driver is integrated in the tcan4550 driver:

    drivers/net/can/m_can/tcan4x5x-core.c

    It can be enabled with the config symbol 'CAN_M_CAN_TCAN4X5X'.

    For the devicetree the compatible should be:

    compatible = "ti,tcan4552", "ti,tcan4x5x";

    I hope this helps.

    Regards,

    Jonathan

  • Dear Jonathan,

    Thanks for the update.

    I think we have already used the latest version.

    Are there any other pointers for improvements e.g FIFO access / other possible enhancements.

    Regards

    Anadi

  • Hi Anadi,

    Have you done any analysis on the SPI communication with a scope or logic analyzer to see if there are any long pauses or gaps that could be addressed?  We have seen that some SPI drivers have a delay after pulling the chip select signal low before starting communication, and again a delay after communication is over. We have also seen gaps within the SPI communication if the driver sends the data out in 8-bit or 16-bit increments.  All of these types of delays can add up to significant amount of time and reduce the overall bandwidth.

    Generally, using multi-word SPI reads/writes will help reduce the overhead, so this is best performed for transferring and entire TX buffer in a single SPI multi-word write, and likewise when reading an entire message from the RX buffers.

    I've seen some applications where multiple RX message buffers were read after using the watermark fill level as the interrupt, but this can add a small delay in the reception of a message if the watermark level has not yet been reached.

    Implementing message filtering to prevent unnecessary messages from being process is helpful.  Also using dedicated RX buffers for common messages can prevent the need for the MCU to first read the Get Index for a specific message before retrieving the message because the buffer address is already known.

    Increasing the SPI data rate to the fastest supported rate that can be reliably achieved reduces overall time.  The TCAN4550's maximum SPI rate is 18MHz.

    These are a few ideas to explore.

    Regards,

    Jonathan