On 25.01.2023 11:25:48, Stefan Althöfer wrote: > > Taken from one of your traces is data below We have a tef fifo size > > of 4, so yeah in this scenario it's expected to have TEF full > > situations. A larger TEF/Faster SPI/better SPI utilization would all > > reduce the occurrence of the issue. > > I was pretty sure that my application never has more than three frames > on the fly - having sent three frames I wait for the first to be > arrived before I sent the next. The driver takes care of flow control, no matter how many CAN frames you send. If you send too many you'll get a -ENOBUFS. > However, it seems that the RX IRQ processing is faster than than the TX IRQ > processing and I am sending the next frame when the TX event fifo has not yet > been read. ACK, the RX IRQ is processed before the TEF (TX complete IRQ), as we cannot do flow control on the RX. > As "buffer full" is no error (as opposed to buffer overflow), should this really be > a non debug kernel message? Some other means of getting such statistics appreciated > (see my posting " mcp251xfd diagnostic outputs"). In the mainline version of the driver you'll get these error messages, if the TEF doesn't contain the expected sequence number, probably because the TX FIFO STA register shows a too big TX FIFO head index. The root cause of this error wasn't known, so an error message is printed. Feel free to test this series: | https://lore.kernel.org/all/20230124152729.814840-1-mkl@xxxxxxxxxxxxxx It uses a similar workaround as in the RX FIFO STA workaround. 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:
signature.asc
Description: PGP signature
