Thread (5 messages) 5 messages, 2 authors, 2021-06-21

Re: Testing two MCP2518FD's on i.MX8MM

From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: 2021-06-21 12:37:12

On 21.06.2021 09:24:31, Fabio Estevam wrote:
quoted
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.
Thanks for your reply.

I do see some RCU related errors every time the application is launched:
[...]
Any ideas how these RCU errors could be fixed?
Can you test if
https://lore.kernel.org/r/20210621123436.2897023-1-mkl@pengutronix.de (local)
fixes your problem? We still have to check if lockdep complains...

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 |

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help