From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: linux-can@vger.kernel.org
Subject: Re: Testing two MCP2518FD's on i.MX8MM
Date: Tue, 15 Jun 2021 09:15:57 +0200 [thread overview]
Message-ID: <20210615071557.o7fjkleuk777otvm@pengutronix.de> (raw)
In-Reply-To: <CAOMZO5D3suvPzaMq3Fx9LKDC9mzb-0w6i3EbQum-ozczdY-EPQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]
On 12.06.2021 12:10:19, Fabio Estevam wrote:
> I am trying to run CAN stress tests on an i.MX8MM-based board that
> has two mcp2518fd chips. I am using linux-next 20210607 and this is
> the ecspi dts:
>
> https://pastebin.com/raw/YVvuqAAc
>
> Then I launch the test script:
> ./cantest start
>
> This is the script content:
> https://pastebin.com/raw/hc8gKgUf
>
> The problem is that RX FIFO overflow happens:
>
> [ 128.559485] mcp251xfd spi0.0 can0: RX-0: FIFO overflow.
> [ 128.573478] mcp251xfd spi0.0 can0: RX-0: FIFO overflow.
> [ 128.584787] mcp251xfd spi0.0 can0: RX-0: FIFO overflow.
>
> and also cansequence errors:
> # 2020-02-09 01:41:15:368 sequence CNT: 2779938, RX: 8 expected: 34 missing: 230 skt overfl d: 0 a: 0 delta: 230 incident: 6 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 136
> 2020-02-09 01:41:15:368 sequence CNT: 9, RX: 34 expected: 9 missing: 25 skt overfl d: [ 899.794388] mcp251xfd spi0.0 can0: RX-0: FIFO overflow.
> 0 a: 0 delta: 25 incident: 7 seq_wrap RX: 10860 [ 899.804780] mcp251xfd spi0.0 can0: RX-0: FIFO overflow.
> sequ_wrap_expected: 10860 overall lost: 161
> 2020-02-09 01:41:15:370 sequence CNT: 40, RX: 9 expected: 40 missing: 225 skt overfl d: 0 a: 0 delta: 225 incident: 8 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 130
> 2020-02-09 01:41:15:392 sequence CNT: 137, RX: 105 expected: 137 missing: 224 skt overfl d: 0 a: 0 delta: 224 incident: 9 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 98
> 2020-02-09 01:41:15:396 sequence CNT: 137, RX: 145 expected: 137 missing: 8 skt overfl d: 0 a: 0 delta: 8 incident: 10 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 106
> 2020-02-09 01:41:15:403 sequence CNT: 160, ERRORFRAME 20000004 00 01 00 00 00 00 00 00
> 2020-02-09 01:41:15:414 sequence CNT: 192, ERRORFRAME 20000004 00 01 00 00 00 00 00 00
> 2020-02-09 01:41:15:414 sequence CNT: 192, RX: 210 expected: 192 missing: 18 skt overfl d: 0 a: 0 delta: 18 incident: 11 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 124
> 2020-02-09 01:41:15:416 sequence CNT: 220, RX: 222 expected: 220 missing: 2 skt overfl d: 0 a: 0 delta: 2 incident: 12 seq_wrap RX: 10860 sequ_wrap_expected: 10860 overall lost: 126
>
> I have applied this series to get SPI DMA to work on i.MX8MM:
> https://patches.linaro.org/cover/417924/
>
> I have also tried SPI PIO mode instead of DMA, but it does not help.
>
> Any ideas of what can be done to improve this?
The imx SPI driver has quite some overhead, when it comes to small SPI
transfers. The mcp251fd driver performs much better with the SPI IP
cores on the raspi, which have quite good optimized drivers.
Hook up a scope to the SPI's clock and chip select lines of the imx,
you'll see the time between end of transfer until the chip select is
inactive is longer than the SPI transfer itself.
I expect most bang for the buck can be archived by adding an IRQ less
busy polling transfer mode, which kicks in below a certain SPI transfer
length.
On the mcp251xfd driver side, there is some room for optimization. The
basic idea is to reduce the number of SPI transfers by combining several
reads into one transfer. This can be done in some places.
For peak loads in CAN-2.0 mode it would be interesting to make use of
the remaining RAM for a 2nd FIFO.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-06-15 7:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOMZO5CwS-cO3W148YHVYFwcL3QC8oFJfeQBb+WN=QgEPU7AsQ@mail.gmail.com>
2021-06-12 15:10 ` Testing two MCP2518FD's on i.MX8MM Fabio Estevam
2021-06-15 7:15 ` Marc Kleine-Budde [this message]
2021-06-21 12:24 ` Fabio Estevam
2021-06-21 12:37 ` Marc Kleine-Budde
2021-06-21 13:07 ` Fabio Estevam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210615071557.o7fjkleuk777otvm@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=festevam@gmail.com \
--cc=linux-can@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.