All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Pisa <pisa@cmp.felk.cvut.cz>
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, Petr Porazil <porazil@volny.cz>,
	Han Xu <han.xu@nxp.com>, Mingkai Hu <mingkai.hu@nxp.com>,
	Chris Packham <chris.packham@alliedtelesis.co.nz>,
	Tiago Brusamarello <tiago.brusamarello@datacom.ind.br>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: CAN FD controllers (M-CAN tcan4x5x as well as Microchip mcp251xfd) fails on iMX6 eCSPI interface
Date: Mon, 22 Mar 2021 10:45:40 +0100	[thread overview]
Message-ID: <202103221045.40634.pisa@cmp.felk.cvut.cz> (raw)
In-Reply-To: <20210322083128.ehblmvyxo5rggeno@pengutronix.de>

Hello Marc,

thanks much for the fast reply.

On Monday 22 of March 2021 09:31:28 Marc Kleine-Budde wrote:
> On 22.03.2021 09:06:52, Pavel Pisa wrote:
> > my colleague at Elektroline.cz works on design of iMX6
> > based system with CAN FD support realized by tcan4x5x
> > chip connected to eCSPI. It seems that there are problems
> > with eCSPI DMA stucks and other troubles. When the same
> > chip (or even Microchip's mcp251xfd) is connected to
> > other (less industry sound platforms) as Allwinner etc...
> > drivers seems to work reliably, but tests on iMX6 results
> > in failures. They consider fast redesign to slCAN connected
> > second Microchip MCU to resolve critical problem for the
> > project now....
>
> Don't use slcan, just don't.

Yes, I agree with it and argued it to my colleagues but they are
so frustrated by more problems in iMX6 and imxRT erratas that they
believe that serial port has highest probability to not been broken.

> - If you want to stick to the SPI, use a mcp2518fd.
> - If you don't need CAN-FD, attach a stm32f042 or f072 via USB. There is
>   a open source firmware and Linux drivers.

They have Microchip PIC32 for power management in the design and quite
good experience with it, so they can use little more advanced one
with CAN FD and use it at CAN interface. The idea to use SPI connected
MCU (in my case NXP LPC) come to my mind at LinCAN era when everybody
used MCP2515 with horrible single register operation overhead.
Can you suggest SPI protocol for CAN, CAN FD MCU connection as the
SocketCAN interface? Is there plan for CAN FD version?
Anyway if the problems are caused by NXP SPI, then they can creep
in still.

> - If you need CAN-FD, use a more modern stm32. I think some of the "G"
>   series have CAN-FD. But the firmware and Linux drivers are not
>   adopted, yet.

We have solved and mainlined CAN FD on imxRT on NuttX and Microchip
SAME70 (mainlining to NuttX expected soon) so we can reuse these.

> Expect quite some CPU load for the SPI based CAN controllers, due to the
> high Linux SPI overhead and the not that optimized imx SPI host driver.

Yes, I am not fan of these solution (you know our CTU CAN FD effort,
hopefully headers generator rewrite comes to the table next month),
but Elektroline company needs industrial range system and could not
wait for iMX8X with CAN FD controllers at the project start time.

> > The setup on 5.7 kernel partially works
>
> For the tcan4x5x better use latest v5.12 plus this series:
> https://lore.kernel.org/linux-can/20210308102427.63916-1-torin@maxiluxsyste
>ms.com/

Thanks, we will test that for sure but for production we probably
need to backport to 5.10 because it has chance for serious LTS
support from Civil Infrastructure Platform (adding Pavel to CC)
for standard and even better preempt-RT kernels.

> If the SPI DMA makes troubles, deactivate it. I think the tcan4x5x driver
> uses single tcan4x5x register reads, which results in small SPI
> transfers, so DMA brings no benefits.

Yes, we try that. I have some reminiscence form old time that we have
done some similar tricks on imx53 to make it work in infussion system demo.

Again thanks much for fast response,

                Pavel
--
                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://dce.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/


  reply	other threads:[~2021-03-22  9:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22  8:06 CAN FD controllers (M-CAN tcan4x5x as well as Microchip mcp251xfd) fails on iMX6 eCSPI interface Pavel Pisa
2021-03-22  8:31 ` Marc Kleine-Budde
2021-03-22  9:45   ` Pavel Pisa [this message]
2021-03-22 10:53     ` Marc Kleine-Budde

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=202103221045.40634.pisa@cmp.felk.cvut.cz \
    --to=pisa@cmp.felk.cvut.cz \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=han.xu@nxp.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mingkai.hu@nxp.com \
    --cc=mkl@pengutronix.de \
    --cc=pavel@ucw.cz \
    --cc=porazil@volny.cz \
    --cc=tiago.brusamarello@datacom.ind.br \
    /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.