mbox series

[0/6] Add Microchip MCP25XXFD CAN driver

Message ID 20200610074442.10808-1-manivannan.sadhasivam@linaro.org
Headers show
Series Add Microchip MCP25XXFD CAN driver | expand

Message

Manivannan Sadhasivam June 10, 2020, 7:44 a.m. UTC
Hello,

This series adds CAN network driver support for Microchip MCP25XXFD CAN
Controller with MCP2517FD as the target controller version. This series is
mostly inspired (or taken) from the previous iterations posted by Martin Sperl.
I've trimmed down the parts which are not necessary for the initial version
to ease review. Still the series is relatively huge but I hope to get some
reviews (post -rcX ofc!).

Link to the origial series posted by Martin:
https://www.spinics.net/lists/devicetree/msg284462.html

I've not changed the functionality much but done some considerable amount of
cleanups and also preserved the authorship of Martin for all the patches he has
posted earlier. This series has been tested on 96Boards RB3 platform by myself
and Martin has tested the previous version on Rpi3 with external MCP2517FD
controller.

Thanks,
Mani

Manivannan Sadhasivam (1):
  MAINTAINERS: Add entry for Microchip MCP25XXFD CAN network driver

Martin Sperl (5):
  dt-bindings: can: Document devicetree bindings for MCP25XXFD
  can: mcp25xxfd: Add Microchip MCP25XXFD CAN-FD driver infrastructure
  can: mcp25xxfd: Add support for CAN reception
  can: mcp25xxfd: Add CAN transmission support
  can: mcp25xxfd: Optimize TEF read by avoiding unnecessary SPI
    transfers

 .../bindings/net/can/microchip,mcp25xxfd.yaml |  82 +++
 MAINTAINERS                                   |   8 +
 drivers/net/can/spi/Kconfig                   |   2 +
 drivers/net/can/spi/Makefile                  |   2 +
 drivers/net/can/spi/mcp25xxfd/Kconfig         |   5 +
 drivers/net/can/spi/mcp25xxfd/Makefile        |  11 +
 .../net/can/spi/mcp25xxfd/mcp25xxfd_base.c    | 177 +++++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_base.h    |  14 +
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can.c | 538 ++++++++++++++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can.h |  52 ++
 .../can/spi/mcp25xxfd/mcp25xxfd_can_fifo.c    | 305 ++++++++
 .../can/spi/mcp25xxfd/mcp25xxfd_can_fifo.h    |  16 +
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_id.h  |  69 ++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_int.c | 674 ++++++++++++++++++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_int.h |  18 +
 .../can/spi/mcp25xxfd/mcp25xxfd_can_priv.h    | 144 ++++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_rx.c  | 233 ++++++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_rx.h  |  18 +
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_tx.c  | 653 +++++++++++++++++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_can_tx.h  |  86 +++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_cmd.c | 226 ++++++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_cmd.h |  84 +++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_crc.c |  31 +
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_crc.h |  15 +
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_ecc.c |  74 ++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_ecc.h |  16 +
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_int.c |  71 ++
 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_int.h |  15 +
 .../net/can/spi/mcp25xxfd/mcp25xxfd_priv.h    |  50 ++
 .../net/can/spi/mcp25xxfd/mcp25xxfd_regs.h    | 661 +++++++++++++++++
 30 files changed, 4350 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
 create mode 100644 drivers/net/can/spi/mcp25xxfd/Kconfig
 create mode 100644 drivers/net/can/spi/mcp25xxfd/Makefile
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_base.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_base.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_fifo.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_fifo.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_id.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_int.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_int.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_priv.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_rx.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_rx.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_tx.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_can_tx.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_cmd.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_cmd.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_crc.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_crc.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_ecc.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_ecc.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_int.c
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_int.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_priv.h
 create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd_regs.h

-- 
2.17.1

Comments

Marc Kleine-Budde June 11, 2020, 4:26 p.m. UTC | #1
On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:
> Hello,

> 

> This series adds CAN network driver support for Microchip MCP25XXFD CAN

> Controller with MCP2517FD as the target controller version. This series is

> mostly inspired (or taken) from the previous iterations posted by Martin Sperl.

> I've trimmed down the parts which are not necessary for the initial version

> to ease review. Still the series is relatively huge but I hope to get some

> reviews (post -rcX ofc!).

> 

> Link to the origial series posted by Martin:

> https://www.spinics.net/lists/devicetree/msg284462.html

> 

> I've not changed the functionality much but done some considerable amount of

> cleanups and also preserved the authorship of Martin for all the patches he has

> posted earlier. This series has been tested on 96Boards RB3 platform by myself

> and Martin has tested the previous version on Rpi3 with external MCP2517FD

> controller.


I initially started looking at Martin's driver and it was not using several
modern CAN driver infrastructures. I then posted some cleanup patches but Martin
was not working on the driver any more. Then I decided to rewrite the driver,
that is the one I'm hoping to mainline soon.

Can you give it a try?

https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41

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 |
Marc Kleine-Budde June 11, 2020, 8:30 p.m. UTC | #2
On 6/11/20 6:26 PM, Marc Kleine-Budde wrote:
> I initially started looking at Martin's driver and it was not using several

> modern CAN driver infrastructures. I then posted some cleanup patches but Martin

> was not working on the driver any more. Then I decided to rewrite the driver,

> that is the one I'm hoping to mainline soon.


Seems the driver still suffers from the same problems the last time I looked at it:

I'm on a raspi4 with a mcp2518fd connected to spi0 cs0 and cs1.

Running a canfdtest -vg can0; canfdtest -v can1. It  runs into this problem on a
unloaded system and scaling_governor=performance  within minutes:

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: Something is wrong - we got a TEF interrupt but we were not able to detect a finished fifo

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: Something is wrong - we got a TEF interrupt but we were not able to detect a finished fifo

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 6 not pending - tef data: id: 00000078 flags: 00000c08, ts: 0addbed3 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 7 not pending - tef data: id: 00000078 flags: 00000e08, ts: 0addc2e5 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 1 not pending - tef data: id: 00000078 flags: 00000208, ts: 0addc701 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 2 not pending - tef data: id: 00000078 flags: 00000408, ts: 0addcb1b - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced


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 |
Marc Kleine-Budde June 12, 2020, 11:27 a.m. UTC | #3
On 6/11/20 10:30 PM, Marc Kleine-Budde wrote:
> On 6/11/20 6:26 PM, Marc Kleine-Budde wrote:

>> I initially started looking at Martin's driver and it was not using several

>> modern CAN driver infrastructures. I then posted some cleanup patches but Martin

>> was not working on the driver any more. Then I decided to rewrite the driver,

>> that is the one I'm hoping to mainline soon.

> 

> Seems the driver still suffers from the same problems the last time I looked at it:

> 

> I'm on a raspi4 with a mcp2518fd connected to spi0 cs0 and cs1.

> 

> Running a canfdtest -vg can0; canfdtest -v can1. It  runs into this problem on a

> unloaded system and scaling_governor=performance  within minutes:

> 

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: Something is wrong - we got a TEF interrupt but we were not able to detect a finished fifo

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: Something is wrong - we got a TEF interrupt but we were not able to detect a finished fifo

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 6 not pending - tef data: id: 00000078 flags: 00000c08, ts: 0addbed3 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 7 not pending - tef data: id: 00000078 flags: 00000e08, ts: 0addc2e5 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 1 not pending - tef data: id: 00000078 flags: 00000208, ts: 0addc701 - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced

>> Jun 11 21:27:08 rpi4 kernel: mcp25xxfd spi0.0 can1: tefif: fifo 2 not pending - tef data: id: 00000078 flags: 00000408, ts: 0addcb1b - this may be a problem with spi signal quality- try reducing spi-clock speed if this can get reproduced


Further two mcp2517 on the rpi4, unloaded system, performance dovernor running
cansequence -v can0 -p; cansequence can1 -v; gives:

> Jun 12 12:17:53 rpi4 kernel: mcp25xxfd spi1.0: ECC single bit error at 800

> Jun 12 12:17:53 rpi4 kernel: mcp25xxfd spi1.0: ECC single bit error at 800

> Jun 12 12:17:54 rpi4 kernel: mcp25xxfd spi1.0: ECC double bit error at 800

> Jun 12 12:17:54 rpi4 kernel: mcp25xxfd spi1.0: unidentified system interrupt - intf =  b91a1118

> Jun 12 12:17:54 rpi4 kernel: mcp25xxfd spi1.0: ECC double bit error at 800


I don't see these problems with my driver.

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 |
Kurt Van Dijck June 17, 2020, 4:59 p.m. UTC | #4
On do, 11 jun 2020 18:26:19 +0200, Marc Kleine-Budde wrote:
> On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:

> > Hello,

> > 

> > This series adds CAN network driver support for Microchip MCP25XXFD CAN

> > Controller with MCP2517FD as the target controller version. This series is

> > mostly inspired (or taken) from the previous iterations posted by Martin Sperl.

> > I've trimmed down the parts which are not necessary for the initial version

> > to ease review. Still the series is relatively huge but I hope to get some

> > reviews (post -rcX ofc!).

> > 

> > Link to the origial series posted by Martin:

> > https://www.spinics.net/lists/devicetree/msg284462.html

> > 

> > I've not changed the functionality much but done some considerable amount of

> > cleanups and also preserved the authorship of Martin for all the patches he has

> > posted earlier. This series has been tested on 96Boards RB3 platform by myself

> > and Martin has tested the previous version on Rpi3 with external MCP2517FD

> > controller.

> 

> I initially started looking at Martin's driver and it was not using several

> modern CAN driver infrastructures. I then posted some cleanup patches but Martin

> was not working on the driver any more. Then I decided to rewrite the driver,

> that is the one I'm hoping to mainline soon.

> 

> Can you give it a try?

> 

> https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41


Hi Marc,

I'm in the process of getting a Variscite imx8m mini SOM online, with
MCP2517FD. The 4.19 kernel that comes with it, has a driver that is
clearly inspired by the one of Martin Sperl (not investigated too much
yet). I have problems of probing the chip when the bus is under full
load (under not full load, the probing only occasionally fails) due to
the modeswitch test.

Is there a real difference in yours between the rpi and sunxi branches?
Is there much evolution since -36 or would you mind to backport your
latest -42 to 4.19?

I will work on this the upcoming days. I can't do extensive tests, but
rather a works-for-me test that includes bitrate probe.
I only have 1 such board right now, and no other FD hardware.

Kurt
> 

> Marc
Marc Kleine-Budde June 17, 2020, 10:36 p.m. UTC | #5
On 6/17/20 6:59 PM, Kurt Van Dijck wrote:
> I'm in the process of getting a Variscite imx8m mini SOM online, with


Have your heard about the imx8m plus? It has CAN cores! We have a board in the
office to play with. :)

> MCP2517FD. The 4.19 kernel that comes with it, has a driver that is


You shall not start projects with 1,5 years old kernel.
And you probably shall not use vendor kernel for new projects.
:D

> clearly inspired by the one of Martin Sperl (not investigated too much

> yet). I have problems of probing the chip when the bus is under full

> load (under not full load, the probing only occasionally fails) due to

> the modeswitch test.

> 

> Is there a real difference in yours between the rpi and sunxi branches?


The sunxi branch has some sunxi SPI driver improvements, the rpi branch some for
the raspi SPI drivers. All branches with the same -xx should have the same
mcp25xxfd driver.

With the exception the latest version is v5.6-rpi/mcp25xxfd-20200607-41, which
is cleaned up for mainlining (it has the logging and dump stuff removed).

> Is there much evolution since -36 or would you mind to backport your

> latest -42 to 4.19?


Not much, some bus off cleanups, however I've backported all changes to
v4.19-rpi/mcp25xxfd-20200429-41 (debug and log is still included).

When you port this to your mx8 take all from (including)

    097701d1ea4f can: dev: avoid long lines
to
    v4.19-rpi/mcp25xxfd-20200429-41

> I will work on this the upcoming days. I can't do extensive tests, but

> rather a works-for-me test that includes bitrate probe.

> I only have 1 such board right now, and no other FD hardware.


Great, looking for feedback! Especially how the driver copes with your fully
loaded bus test.

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 |
Manivannan Sadhasivam June 18, 2020, 8:55 a.m. UTC | #6
Hi,

On 0611, Marc Kleine-Budde wrote:
> On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:

> > Hello,

> > 

> > This series adds CAN network driver support for Microchip MCP25XXFD CAN

> > Controller with MCP2517FD as the target controller version. This series is

> > mostly inspired (or taken) from the previous iterations posted by Martin Sperl.

> > I've trimmed down the parts which are not necessary for the initial version

> > to ease review. Still the series is relatively huge but I hope to get some

> > reviews (post -rcX ofc!).

> > 

> > Link to the origial series posted by Martin:

> > https://www.spinics.net/lists/devicetree/msg284462.html

> > 

> > I've not changed the functionality much but done some considerable amount of

> > cleanups and also preserved the authorship of Martin for all the patches he has

> > posted earlier. This series has been tested on 96Boards RB3 platform by myself

> > and Martin has tested the previous version on Rpi3 with external MCP2517FD

> > controller.

> 

> I initially started looking at Martin's driver and it was not using several

> modern CAN driver infrastructures. I then posted some cleanup patches but Martin

> was not working on the driver any more. Then I decided to rewrite the driver,

> that is the one I'm hoping to mainline soon.

> 


So how should we proceed from here? It is okay for me to work on adding some
features and also fixing the issues you've reported so far. But I want to reach
a consensus before moving forward.

If you think that it makes sense to go with your set of patches, then I need an
estimate on when you'll post the first revision.

> Can you give it a try?

> 

> https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41

> 


Sure thing. Will do.

Thanks,
Mani

> 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 |
Manivannan Sadhasivam June 18, 2020, 12:06 p.m. UTC | #7
Hi,

On 0611, Marc Kleine-Budde wrote:
> On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:

> > Hello,

> > 

> > This series adds CAN network driver support for Microchip MCP25XXFD CAN

> > Controller with MCP2517FD as the target controller version. This series is

> > mostly inspired (or taken) from the previous iterations posted by Martin Sperl.

> > I've trimmed down the parts which are not necessary for the initial version

> > to ease review. Still the series is relatively huge but I hope to get some

> > reviews (post -rcX ofc!).

> > 

> > Link to the origial series posted by Martin:

> > https://www.spinics.net/lists/devicetree/msg284462.html

> > 

> > I've not changed the functionality much but done some considerable amount of

> > cleanups and also preserved the authorship of Martin for all the patches he has

> > posted earlier. This series has been tested on 96Boards RB3 platform by myself

> > and Martin has tested the previous version on Rpi3 with external MCP2517FD

> > controller.

> 

> I initially started looking at Martin's driver and it was not using several

> modern CAN driver infrastructures. I then posted some cleanup patches but Martin

> was not working on the driver any more. Then I decided to rewrite the driver,

> that is the one I'm hoping to mainline soon.

> 

> Can you give it a try?

> 

> https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41

> 


Tested this version on my board with MCP2518FD and it works fine. I'm okay with
moving forward with your version and would like to contribute. Please let me
know how we can move forward.

Thanks,
Mani

> 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 |
Kurt Van Dijck June 18, 2020, 12:30 p.m. UTC | #8
On do, 18 jun 2020 00:36:29 +0200, Marc Kleine-Budde wrote:
> On 6/17/20 6:59 PM, Kurt Van Dijck wrote:

> > I'm in the process of getting a Variscite imx8m mini SOM online, with

> 

> Have your heard about the imx8m plus? It has CAN cores! We have a board in the

> office to play with. :)

> 

> > MCP2517FD. The 4.19 kernel that comes with it, has a driver that is

> 

> You shall not start projects with 1,5 years old kernel.

> And you probably shall not use vendor kernel for new projects.

> :D


your rpi kernel starts of v4.19.119 (or so), where the variscite starts
of v4.19.35.
The result was quite some list of merge conflicts, on top of a vendor
kernel, so I took your advise and switched to the latest and greatest
5.7.3.
Luckily, we need no sound (yet) and no video. :-)

> 

> Not much, some bus off cleanups, however I've backported all changes to

> v4.19-rpi/mcp25xxfd-20200429-41 (debug and log is still included).

> 

> When you port this to your mx8 take all from (including)

> 

>     097701d1ea4f can: dev: avoid long lines

> to

>     v4.19-rpi/mcp25xxfd-20200429-41

> 


I'll merge one of your latest ...

Kurt
Marc Kleine-Budde June 18, 2020, 12:35 p.m. UTC | #9
On 6/18/20 2:30 PM, Kurt Van Dijck wrote:
> On do, 18 jun 2020 00:36:29 +0200, Marc Kleine-Budde wrote:

>> On 6/17/20 6:59 PM, Kurt Van Dijck wrote:

>>> I'm in the process of getting a Variscite imx8m mini SOM online, with

>>

>> Have your heard about the imx8m plus? It has CAN cores! We have a board in the

>> office to play with. :)

>>

>>> MCP2517FD. The 4.19 kernel that comes with it, has a driver that is

>>

>> You shall not start projects with 1,5 years old kernel.

>> And you probably shall not use vendor kernel for new projects.

>> :D

> 

> your rpi kernel starts of v4.19.119 (or so), where the variscite starts

> of v4.19.35.


You're missing some stable backports for the kernel then.

> The result was quite some list of merge conflicts, on top of a vendor

> kernel, so I took your advise and switched to the latest and greatest

> 5.7.3.


\o/

> Luckily, we need no sound (yet) and no video. :-)


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 |
Manivannan Sadhasivam June 20, 2020, 2:43 a.m. UTC | #10
On Thu, Jun 18, 2020 at 02:25:33PM +0530, Manivannan Sadhasivam wrote:
> Hi,

> 

> On 0611, Marc Kleine-Budde wrote:

> > On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:

> > > Hello,

> > > 

> > > This series adds CAN network driver support for Microchip MCP25XXFD CAN

> > > Controller with MCP2517FD as the target controller version. This series is

> > > mostly inspired (or taken) from the previous iterations posted by Martin Sperl.

> > > I've trimmed down the parts which are not necessary for the initial version

> > > to ease review. Still the series is relatively huge but I hope to get some

> > > reviews (post -rcX ofc!).

> > > 

> > > Link to the origial series posted by Martin:

> > > https://www.spinics.net/lists/devicetree/msg284462.html

> > > 

> > > I've not changed the functionality much but done some considerable amount of

> > > cleanups and also preserved the authorship of Martin for all the patches he has

> > > posted earlier. This series has been tested on 96Boards RB3 platform by myself

> > > and Martin has tested the previous version on Rpi3 with external MCP2517FD

> > > controller.

> > 

> > I initially started looking at Martin's driver and it was not using several

> > modern CAN driver infrastructures. I then posted some cleanup patches but Martin

> > was not working on the driver any more. Then I decided to rewrite the driver,

> > that is the one I'm hoping to mainline soon.

> > 

> 

> So how should we proceed from here? It is okay for me to work on adding some

> features and also fixing the issues you've reported so far. But I want to reach

> a consensus before moving forward.

> 

> If you think that it makes sense to go with your set of patches, then I need an

> estimate on when you'll post the first revision.

> 


Ping!

> > Can you give it a try?

> > 

> > https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41

> > 

> 

> Sure thing. Will do.

> 

> Thanks,

> Mani

> 

> > 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 |
Kurt Van Dijck June 22, 2020, 10:25 a.m. UTC | #11
Hey Marc,

On do, 18 jun 2020 14:35:28 +0200, Marc Kleine-Budde wrote:
> On 6/18/20 2:30 PM, Kurt Van Dijck wrote:

> > On do, 18 jun 2020 00:36:29 +0200, Marc Kleine-Budde wrote:

> >> On 6/17/20 6:59 PM, Kurt Van Dijck wrote:

> >>> I'm in the process of getting a Variscite imx8m mini SOM online, with

> >>

> >> Have your heard about the imx8m plus? It has CAN cores! We have a board in the

> >> office to play with. :)

> >>

> >>> MCP2517FD. The 4.19 kernel that comes with it, has a driver that is

> >>

> >> You shall not start projects with 1,5 years old kernel.

> >> And you probably shall not use vendor kernel for new projects.

> >> :D

> > 

> > your rpi kernel starts of v4.19.119 (or so), where the variscite starts

> > of v4.19.35.

> 

> You're missing some stable backports for the kernel then.

> 

> > The result was quite some list of merge conflicts, on top of a vendor

> > kernel, so I took your advise and switched to the latest and greatest

> > 5.7.3.

> 

> \o/


I got my board up with a 5.7, despite device-tree problems completely
unrelated to CAN.
It seems to work well with a fully-loaded CAN bus (cangen -g0 ...).
So that is a real improvement.
I will need to add the listen-only mode soon.

Kurt
Marc Kleine-Budde June 22, 2020, 10:55 a.m. UTC | #12
On 6/22/20 12:25 PM, Kurt Van Dijck wrote:
> I got my board up with a 5.7, despite device-tree problems completely

> unrelated to CAN.


\o/

> It seems to work well with a fully-loaded CAN bus (cangen -g0 ...).

> So that is a real improvement.


Can I add your Tested-by?

> I will need to add the listen-only mode soon.


Patches are always welcome!

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 |
Marc Kleine-Budde June 22, 2020, 11:41 a.m. UTC | #13
On 6/18/20 2:06 PM, Manivannan Sadhasivam wrote:
>> https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41

>>

> 

> Tested this version on my board with MCP2518FD and it works fine. I'm okay with

> moving forward with your version and would like to contribute. Please let me

> know how we can move forward.


Can I add your Tested-by?

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 |
Marc Kleine-Budde June 22, 2020, 11:47 a.m. UTC | #14
On 6/18/20 10:55 AM, Manivannan Sadhasivam wrote:
> So how should we proceed from here? It is okay for me to work on adding some

> features and also fixing the issues you've reported so far. But I want to reach

> a consensus before moving forward.

> 

> If you think that it makes sense to go with your set of patches, then I need an

> estimate on when you'll post the first revision.


Done, I've posted my current version, which is -41.

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 |
Kurt Van Dijck June 22, 2020, 12:30 p.m. UTC | #15
On ma, 22 jun 2020 12:55:41 +0200, Marc Kleine-Budde wrote:
> Date:   Mon, 22 Jun 2020 12:55:41 +0200

> From: Marc Kleine-Budde <mkl@pengutronix.de>

> To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,

>  wg@grandegger.com, kernel@martin.sperl.org, linux-can@vger.kernel.org,

>  netdev@vger.kernel.org, linux-kernel@vger.kernel.org

> Subject: Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver

> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101

>  Thunderbird/68.9.0

> 

> On 6/22/20 12:25 PM, Kurt Van Dijck wrote:

> > I got my board up with a 5.7, despite device-tree problems completely

> > unrelated to CAN.

> 

> \o/

> 

> > It seems to work well with a fully-loaded CAN bus (cangen -g0 ...).

> > So that is a real improvement.

> 

> Can I add your Tested-by?

yes.
> 

> > I will need to add the listen-only mode soon.

> 

> Patches are always welcome!

> 

> 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 |
Kurt Van Dijck June 22, 2020, 12:43 p.m. UTC | #16
Marc,

I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of
the single other node).
The SPI peripheral does not use DMA :-(.
Do you have, by accident, some freescale SPI fixes lying around?

It's not the biggest problem on my side, but is proves the system not
being guarded against load.

Kurt

On ma, 22 jun 2020 14:30:31 +0200, Kurt Van Dijck wrote:
> 

> On ma, 22 jun 2020 12:55:41 +0200, Marc Kleine-Budde wrote:

> > On 6/22/20 12:25 PM, Kurt Van Dijck wrote:

> > > I got my board up with a 5.7, despite device-tree problems completely

> > > unrelated to CAN.

> > 

> > \o/

> > 

> > > It seems to work well with a fully-loaded CAN bus (cangen -g0 ...).

> > > So that is a real improvement.

> > 

> > Can I add your Tested-by?

> yes.

> > 

> > > I will need to add the listen-only mode soon.

> > 

> > Patches are always welcome!

> > 

> > regards,

> > Marc
Marc Kleine-Budde June 22, 2020, 12:54 p.m. UTC | #17
On 6/22/20 2:43 PM, Kurt Van Dijck wrote:
> I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of

> the single other node).


Single other node? Who's ACKing the CAN frames?

> The SPI peripheral does not use DMA :-(.


The SPI messages are quite small, so DMA wont help either. Getting rid of the
IRQ and polling for completion is the way to go.

> Do you have, by accident, some freescale SPI fixes lying around?


nope

> It's not the biggest problem on my side, but is proves the system not

> being guarded against load.


Do you have freq scaling activated?

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 |
Kurt Van Dijck June 22, 2020, 1:26 p.m. UTC | #18
On ma, 22 jun 2020 14:54:15 +0200, Marc Kleine-Budde wrote:
> On 6/22/20 2:43 PM, Kurt Van Dijck wrote:

> > I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of

> > the single other node).

> 

> Single other node? Who's ACKing the CAN frames?


hence the back-to-back burst.

> 

> > The SPI peripheral does not use DMA :-(.

> 

> The SPI messages are quite small, so DMA wont help either. Getting rid of the

> IRQ and polling for completion is the way to go.

> 

> > Do you have, by accident, some freescale SPI fixes lying around?

> 

> nope

> 

> > It's not the biggest problem on my side, but is proves the system not

> > being guarded against load.

> 

> Do you have freq scaling activated?


Not yet.

The device tree needs upgrading ... grrr

> 

> 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 |
Marc Kleine-Budde June 22, 2020, 1:41 p.m. UTC | #19
On 6/22/20 3:26 PM, Kurt Van Dijck wrote:
> On ma, 22 jun 2020 14:54:15 +0200, Marc Kleine-Budde wrote:

>> On 6/22/20 2:43 PM, Kurt Van Dijck wrote:

>>> I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of

>>> the single other node).

>>

>> Single other node? Who's ACKing the CAN frames?

> 

> hence the back-to-back burst.


Just wanted to be sure if I understood correctly. Nice testcase btw!

>>> The SPI peripheral does not use DMA :-(.

>>

>> The SPI messages are quite small, so DMA wont help either. Getting rid of the

>> IRQ and polling for completion is the way to go.

>>

>>> Do you have, by accident, some freescale SPI fixes lying around?

>>

>> nope

>>

>>> It's not the biggest problem on my side, but is proves the system not

>>> being guarded against load.

>>

>> Do you have freq scaling activated?

> 

> Not yet.

> 

> The device tree needs upgrading ... grrr


Without freq scaling the imx core is supposed to run at full speed, which is
better for bursty SPI traffic than starting clocked down into a burst....

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 |