summaryrefslogtreecommitdiff
path: root/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
AgeCommit message (Collapse)Author
2024-06-28can: mcp251xfd: tef: prepare to workaround broken TEF FIFO tail index erratumMarc Kleine-Budde
This is a preparatory patch to work around a problem similar to erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. Erratum DS80000789E 6 says "reading of the FIFOCI bits in the FIFOSTA register for an RX FIFO may be corrupted". However observation shows that this problem is not limited to RX FIFOs but also effects the TEF FIFO. When handling the TEF interrupt, the driver reads the FIFO header index from the TEF FIFO STA register of the chip. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old CAN transmit complete events that were already processed to be re-processed. Instead of reading and trusting the head index, read the head index and calculate the number of CAN frames that were supposedly received - replace mcp251xfd_tef_ring_update() with mcp251xfd_get_tef_len(). The mcp251xfd_handle_tefif() function reads the CAN transmit complete events from the chip, iterates over them and pushes them into the network stack. The original driver already contains code to detect old CAN transmit complete events, that will be updated in the next patch. Cc: Stefan Althöfer <Stefan.Althoefer@janztec.com> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-06-28can: mcp251xfd: rx: add workaround for erratum DS80000789E 6 of mcp2518fdMarc Kleine-Budde
This patch tries to works around erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old, already processed CAN frames or new, incompletely written CAN frames to be (re-)processed. To work around this issue, keep a per FIFO timestamp [1] of the last valid received CAN frame and compare against the timestamp of every received CAN frame. If an old CAN frame is detected, abort the iteration and mark the number of valid CAN frames as processed in the chip by incrementing the FIFO's tail index. Further tests showed that this workaround can recognize old CAN frames, but a small time window remains in which partially written CAN frames [2] are not recognized but then processed. These CAN frames have the correct data and time stamps, but the DLC has not yet been updated. [1] As the raw timestamp overflows every 107 seconds (at the usual clock rate of 40 MHz) convert it to nanoseconds with the timecounter framework and use this to detect stale CAN frames. Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com [2] Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-06-28can: mcp251xfd: rx: prepare to workaround broken RX FIFO head index erratumMarc Kleine-Budde
This is a preparatory patch to work around erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. When handling the RX interrupt, the driver iterates over all pending FIFOs (which are implemented as ring buffers in hardware) and reads the FIFO header index from the RX FIFO STA register of the chip. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old CAN frames that were already processed, or new, incompletely written CAN frames to be (re-)processed. Instead of reading and trusting the head index, read the head index and calculate the number of CAN frames that were supposedly received - replace mcp251xfd_rx_ring_update() with mcp251xfd_get_rx_len(). The mcp251xfd_handle_rxif_ring() function reads the received CAN frames from the chip, iterates over them and pushes them into the network stack. Prepare that the iteration can be stopped if an old CAN frame is detected. The actual code to detect old or incomplete frames and abort will be added in the next patch. Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-06-28can: mcp251xfd: clarify the meaning of timestampMarc Kleine-Budde
The mcp251xfd chip is configured to provide a timestamp with each received and transmitted CAN frame. The timestamp is derived from the internal free-running timer, which can also be read from the TBC register via SPI. The timer is 32 bits wide and is clocked by the external oscillator (typically 20 or 40 MHz). To avoid confusion, we call this timestamp "timestamp_raw" or "ts_raw" for short. Using the timecounter framework, the "ts_raw" is converted to 64 bit nanoseconds since the epoch. This is what we call "timestamp". This is a preparation for the next patches which use the "timestamp" to work around a bug where so far only the "ts_raw" is used. Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-06-28can: mcp251xfd: move mcp251xfd_timestamp_start()/stop() into ↵Marc Kleine-Budde
mcp251xfd_chip_start/stop() The mcp251xfd wakes up from Low Power or Sleep Mode when SPI activity is detected. To avoid this, make sure that the timestamp worker is stopped before shutting down the chip. Split the starting of the timestamp worker out of mcp251xfd_timestamp_init() into the separate function mcp251xfd_timestamp_start(). Call mcp251xfd_timestamp_init() before mcp251xfd_chip_start(), move mcp251xfd_timestamp_start() to mcp251xfd_chip_start(). In this way, mcp251xfd_timestamp_stop() can be called unconditionally by mcp251xfd_chip_stop(). Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-06-21can: mcp251xfd: fix infinite loop when xmit failsVitor Soares
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Link: https://lore.kernel.org/all/20240517134355.770777-1-ivitro@gmail.com [mkl: use more imperative wording in patch description] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-17can: mcp251xfd: __mcp251xfd_chip_set_mode(): increase poll timeoutFedor Ross
The mcp251xfd controller needs an idle bus to enter 'Normal CAN 2.0 mode' or . The maximum length of a CAN frame is 736 bits (64 data bytes, CAN-FD, EFF mode, worst case bit stuffing and interframe spacing). For low bit rates like 10 kbit/s the arbitrarily chosen MCP251XFD_POLL_TIMEOUT_US of 1 ms is too small. Otherwise during polling for the CAN controller to enter 'Normal CAN 2.0 mode' the timeout limit is exceeded and the configuration fails with: | $ ip link set dev can1 up type can bitrate 10000 | [ 731.911072] mcp251xfd spi2.1 can1: Controller failed to enter mode CAN 2.0 Mode (6) and stays in Configuration Mode (4) (con=0x068b0760, osc=0x00000468). | [ 731.927192] mcp251xfd spi2.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying. | [ 731.938101] A link change request failed with some changes committed already. Interface can1 may have been left with an inconsistent configuration, please check. | RTNETLINK answers: Connection timed out Make MCP251XFD_POLL_TIMEOUT_US timeout calculation dynamic. Use maximum of 1ms and bit time of 1 full 64 data bytes CAN-FD frame in EFF mode, worst case bit stuffing and interframe spacing at the current bit rate. For easier backporting define the macro MCP251XFD_FRAME_LEN_MAX_BITS that holds the max frame length in bits, which is 736. This can be replaced by can_frame_bits(true, true, true, true, CANFD_MAX_DLEN) in a cleanup patch later. Fixes: 55e5b97f003e8 ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Fedor Ross <fedor.ross@ifm.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20230717-mcp251xfd-fix-increase-poll-timeout-v5-1-06600f34c684@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: mcp251xfd: regmap: optimizing transfer size for CRC transfers size 1Thomas Kopp
For CRC transfers with size 1 it is more efficient to use the write_safe command instead of the write_crc command. This saves the length byte on the SPI transfer. changes since v1: https://lore.kernel.org/all/20230127124258.2764-1-thomas.kopp@microchip.com - change logic to remove 1 level of indention Link: https://lore.kernel.org/all/20230202141811.2581795-1-mkl@pengutronix.de Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-19can: mcp251xfd: silence clang's -Wunaligned-access warningVincent Mailhol
clang emits a -Wunaligned-access warning on union mcp251xfd_tx_ojb_load_buf. The reason is that field hw_tx_obj (not declared as packed) is being packed right after a 16 bits field inside a packed struct: | union mcp251xfd_tx_obj_load_buf { | struct __packed { | struct mcp251xfd_buf_cmd cmd; | /* ^ 16 bits fields */ | struct mcp251xfd_hw_tx_obj_raw hw_tx_obj; | /* ^ not declared as packed */ | } nocrc; | struct __packed { | struct mcp251xfd_buf_cmd_crc cmd; | struct mcp251xfd_hw_tx_obj_raw hw_tx_obj; | __be16 crc; | } crc; | } ____cacheline_aligned; Starting from LLVM 14, having an unpacked struct nested in a packed struct triggers a warning. c.f. [1]. This is a false positive because the field is always being accessed with the relevant put_unaligned_*() function. Adding __packed to the structure declaration silences the warning. [1] https://github.com/llvm/llvm-project/issues/55520 Link: https://lore.kernel.org/all/20220518114357.55452-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Reported-by: kernel test robot <lkp@intel.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-04-19can: mcp251xfd: add support for mcp251863Marc Kleine-Budde
The MCP251863 device is a CAN-FD controller (MCP2518FD) with an integrated transceiver (ATA6563). This patch add support for the new device. Link: https://lore.kernel.org/all/20220419072805.2840340-3-mkl@pengutronix.de Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: ring: increase number of RX-FIFOs to 3 and increase max ↵Marc Kleine-Budde
TX-FIFO depth to 16 This patch increases the number of RX-FIFOs to 3 and the max TX-FIFO depth to 16. This leads to the following default ring configuration. CAN-2.0 mode: | FIFO setup: TEF: 0x400: 8*12 bytes = 96 bytes | FIFO setup: RX-0: FIFO 1/0x460: 32*20 bytes = 640 bytes | FIFO setup: RX-1: FIFO 2/0x6e0: 32*20 bytes = 640 bytes | FIFO setup: RX-2: FIFO 3/0x960: 16*20 bytes = 320 bytes | FIFO setup: TX: FIFO 4/0xaa0: 8*16 bytes = 128 bytes | FIFO setup: free: 224 bytes CAN-FD mode: | FIFO setup: TEF: 0x400: 4*12 bytes = 48 bytes | FIFO setup: RX-0: FIFO 1/0x430: 16*76 bytes = 1216 bytes | FIFO setup: RX-1: FIFO 2/0x8f0: 4*76 bytes = 304 bytes | FIFO setup: TX: FIFO 3/0xa20: 4*72 bytes = 288 bytes | FIFO setup: free: 192 bytes With the previously added ethtool ring configuration support the RAM on the chip can now be runtime configured between RX and TX buffers. Link: https://lore.kernel.org/20220313083640.501791-13-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: add TX IRQ coalescing ethtool supportMarc Kleine-Budde
This patch adds support ethtool based configuration for the TX IRQ coalescing added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-12-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: add TX IRQ coalescing supportMarc Kleine-Budde
This patch adds TX IRQ coalescing support to the driver. The implemented algorithm is similar to the RX IRQ coalescing support added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-11-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: add RX IRQ coalescing ethtool supportMarc Kleine-Budde
This patch adds support ethtool based configuration for the RX IRQ coalescing added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: add RX IRQ coalescing supportMarc Kleine-Budde
This patch adds RX IRQ coalescing support to the driver. The mcp251xfd chip doesn't support proper hardware based coalescing, so this patch tries to implemented it in software. The RX-FIFO offers a "FIFO not empty" interrupt, which is used if no coalescing is active. With activated RX IRQ coalescing the "FIFO not empty" interrupt is disabled in the RX IRQ handler and the "FIFO half full" or "FIFO full interrupt" (depending on RX max coalesced frames IRQ) is used instead. To avoid RX CAN frame starvation a hrtimer is setup with RX coalesce usecs IRQ,on timer expiration the "FIFO not empty" is enabled again. Support for ethtool configuration is added in the next patch. Link: https://lore.kernel.org/20220313083640.501791-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: ring: add support for runtime configurable RX/TX ring parametersMarc Kleine-Budde
This patch adds runtime configurable RX and TX ring parameters via ethtool to the driver. Link: https://lore.kernel.org/20220313083640.501791-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: update macros describing ring, FIFO and RAM layoutMarc Kleine-Budde
So far the configuration of the hardware FIFOs is hard coded and depend only on the selected CAN mode (CAN-2.0 or CAN-FD). This patch updates the macros describing the ring, FIFO and RAM layout to prepare for the next patches that add support for runtime configurable ring parameters via ethtool. Link: https://lore.kernel.org/20220313083640.501791-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: ring: prepare support for runtime configurable RX/TX ring ↵Marc Kleine-Budde
parameters This patch prepares the driver for runtime configurable RX and TX ring parameters. The actual runtime config support will be added in the next patch. Link: https://lore.kernel.org/20220313083640.501791-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-03-13can: mcp251xfd: ethtool: add supportMarc Kleine-Budde
This patch adds basic ethtool support (to query the current and maximum ring parameters) to the driver. Link: https://lore.kernel.org/20220313083640.501791-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: mcp251xfd_priv: introduce macros specifying the number of ↵Marc Kleine-Budde
supported TEF/RX/TX rings This patch introduces macros to define the number of supported TEF, RX and TX rings. As well as some assertions as sanity checks. Link: https://lore.kernel.org/all/20220217103826.2299157-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: prepare for multiple RX-FIFOsMarc Kleine-Budde
This patch prepares the driver to use more than one RX-FIFO. Having a bigger RX buffer is beneficial in high load situations, where the system temporarily cannot keep up reading CAN frames from the chip. Using a bigger RX buffer also allows to implement RX IRQ coalescing, which will be added in a later patch series. If using more than 1 RX-FIFO the driver has to figure out, which FIFOs have RX'ed CAN frames pending. This is indicated by a set bit in the RXIF register, which is positioned directly after the interrupt status register INT. If more than 1 RX-FIFO is used, the driver reads both registers in 1 transfer. The mcp251xfd_handle_rxif() function iterates over all RX rings and reads out the RX'ed CAN frames for for all pending FIFOs. To keep the logic for the 1 RX-FIFO only case in mcp251xfd_handle_rxif() simple, the driver marks that FIFO pending in mcp251xfd_ring_init(). The chip has a dedicated RX interrupt line to signal pending RX'ed frames. If connected to an input GPIO and the driver will skip the initial read of the interrupt status register (INT) and directly read the pending RX'ed frames if the line is active. The driver assumes the 1st RX-FIFO pending (a read of the RXIF register would re-introduce the skipped initial read of the INT register). Any other pending RX-FIFO will be served in the main interrupt handler. Link: https://lore.kernel.org/all/20220217103826.2299157-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: mcp251xfd_ring_init(): checked RAM usage of ring setupMarc Kleine-Budde
With this patch the usage of the on-chip RAM is checked. In the current driver the FIFO setup is fixed and always fits into the RAM. With an upcoming patch series the ring and FIFO setup will be more dynamic. Although using more RAM than available should not happen, but add this safety check, just in case. Link: https://lore.kernel.org/all/20220217103826.2299157-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: change order of TX and RX FIFOsMarc Kleine-Budde
This patch actually changes the order of the TX and RX FIFOs. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: ring: prepare to change order of TX and RX FIFOsMarc Kleine-Budde
This patch improves the initialization of the TX and RX rings. The initialization functions are now called with pointers to the next free address (in the on chip RAM) and next free hardware FIFO. The rings are initialized using these values and the pointers are modified to point to the next free elements. This means the order of the mcp251xfd_ring_init_*() functions specifies the order of the rings in the hardware FIFO. This makes it possible to change the order of the TX and RX FIFOs, which is done in the next patch. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-4-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: introduce struct mcp251xfd_tx_ring::nr and ::fifo_nr and ↵Marc Kleine-Budde
make use of it This patch removes the hard coded assumption that the TX ring uses hardware FIFO 1. This allows the hardware FIFO 1 to be used for RX and the next free FIFO for TX. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-02-24can: mcp251xfd: add support for internal PLLMarc Kleine-Budde
The PLL is enabled if the configured clock is less than or equal to 10 times the max clock frequency. The device will operate with two different SPI speeds. A slow speed determined by the clock without the PLL enabled, and a fast speed derived from the frequency with the PLL enabled. Link: https://lore.kernel.org/all/20220207131047.282110-16-mkl@pengutronix.de Link: https://lore.kernel.org/all/20201015124401.2766-3-mas@csselectronics.com Co-developed-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Magnus Aagaard Sørensen <mas@csselectronics.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: introduce and make use of mcp251xfd_is_fd_mode()Marc Kleine-Budde
This patch replaces the open coded check, if the chip's FIFOs are configured for CAN-FD mode, by the newly introduced function mcp251xfd_is_fd_mode(). Link: https://lore.kernel.org/all/20220105154300.1258636-14-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: move ring init into separate functionMarc Kleine-Budde
This patch moves the ring initialization from the mcp251xfd core file into a separate one to make the driver a bit more orderly. Link: https://lore.kernel.org/all/20220105154300.1258636-13-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: move chip FIFO init into separate fileMarc Kleine-Budde
This patch moves the chip FIFO initialization from the mcp251xfd core file into a separate one to make the driver a bit more orderly. Link: https://lore.kernel.org/all/20220105154300.1258636-12-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: move TEF handling into separate fileMarc Kleine-Budde
This patch moves the TEF handling from the mcp251xfd core file into a separate one to make the driver a bit more orderly. Link: https://lore.kernel.org/all/20220105154300.1258636-11-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: move TX handling into separate fileMarc Kleine-Budde
This patch moves the TX handling from the mcp251xfd core file into a separate one to make the driver a bit more orderly. Link: https://lore.kernel.org/all/20220105154300.1258636-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: move RX handling into separate fileMarc Kleine-Budde
This patch moves the RX handling from the mcp251xfd core file into a separate one to make the driver a bit more orderly. Link: https://lore.kernel.org/all/20220105154300.1258636-9-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-08can: mcp251xfd: mcp251xfd.h: sort function prototypesMarc Kleine-Budde
The .c files in the Makefile are ordered alphabetically. This patch groups the function prototypes by their corresponding .c file and brings the into the same order. Link: https://lore.kernel.org/all/20220105154300.1258636-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-08-19can: mcp251xfd: mark some instances of struct mcp251xfd_priv as constMarc Kleine-Budde
With the patch 07ff4aed015c ("time/timecounter: Mark 1st argument of timecounter_cyc2time() as const") some instances of the struct mcp251xfd_priv can be marked as const. This patch marks these as const. Link: https://lore.kernel.org/r/20210813091027.159379-1-mkl@pengutronix.de Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: mcp251xfd: add HW timestamp infrastructureMarc Kleine-Budde
This patch add the HW timestamping infrastructure. The mcp251xfd has a free running timer of 32 bit width, running at max 40MHz, which wraps around every 107 seconds. The current timestamp is latched into RX and TEF objects automatically be the CAN controller. This patch sets up a cyclecounter, timecounter and delayed worker infrastructure (which runs every 45 seconds) to convert the timer into a proper 64 bit based ns timestamp. Link: https://lore.kernel.org/r/20210304160328.2752293-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: mcp251xfd: mcp251xfd_get_timestamp(): move to mcp251xfd.hMarc Kleine-Budde
This is a preparation patch, it moves the mcp251xfd_get_timestamp() function into the mcp251xfd.h file. Link: https://lore.kernel.org/r/20210304160328.2752293-5-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: mcp251xfd: move netdevice.h to mcp251xfd.hMarc Kleine-Budde
The netdevice.h header is needed in mcp251xfd.h, so that it can be included without further headers. Link: https://lore.kernel.org/r/20210304160328.2752293-4-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-30can: mcp251xfd: add dev coredump supportMarc Kleine-Budde
For easier debugging this patch adds dev coredump support to the driver. A dev coredump is generated in case the chip fails to start or an error in the interrupt handler is detected. The dev coredump consists of all chip registers and chip memory, as well as the driver's internal state of the TEF-, RX- and TX-FIFOs, it can be analyzed with the mcp251xfd-dump tool of the can-utils: https://github.com/linux-can/can-utils/tree/master/mcp251xfd Link: https://lore.kernel.org/r/20210304160328.2752293-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-29can: mcp251xfd: add missing _MASK postfix to MCP251XFD_OBJ_FLAGS_DLCMarc Kleine-Budde
As MCP251XFD_OBJ_FLAGS_DLC is a mask, add the missing _MASK postfix, that all other masks in the driver have. Link: https://lore.kernel.org/r/20210128104644.2982125-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-29can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bitMarc Kleine-Budde
Reduce the number of separate SPI core requests when setting the UINC bit in the TEF FIFO, and instead batch them up into a single SPI core request. Link: https://lore.kernel.org/r/20201126132144.351154-6-mkl@pengutronix.de Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-29can: mcp251xfd: move struct mcp251xfd_tef_ring definitionMarc Kleine-Budde
This patch moves the struct mcp251xfd_tef_ring upwards, so that the union mcp251xfd_write_reg_buf and struct spi_transfer can be made members of it. Link: https://lore.kernel.org/r/20201126132144.351154-5-mkl@pengutronix.de Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-29can: mcp251xfd: struct mcp251xfd_priv::tef to array of length 1Marc Kleine-Budde
This patch converts the struct mcp251xfd_tef_ring member within the struct mcp251xfd_priv into an array of length one. This way all rings (tef, tx and rx) can be accessed in the same way. Link: https://lore.kernel.org/r/20201126132144.351154-4-mkl@pengutronix.de Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-29can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bitUrsula Maplehurst
Reduce the number of separate SPI core requests when setting the UINC bit in the RX FIFO, and instead batch them up into a single SPI core request. Link: https://github.com/marckleinebudde/linux/issues/4 Link: https://lore.kernel.org/r/20201126132144.351154-3-mkl@pengutronix.de Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Ursula Maplehurst <ursula@kangatronix.co.uk> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-29can: mcp251xfd: mcp25xxfd_ring_alloc(): add define instead open coding the ↵Marc Kleine-Budde
maximum number of RX objects This patch add a define for the maximum number of RX objects instead of open coding it. Link: https://lore.kernel.org/r/20201126132144.351154-2-mkl@pengutronix.de Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename all remaining occurrence to mcp251xfdMarc Kleine-Budde
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all non user facing occurrence of "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD". [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-09-30can: mcp251xfd: rename driver files and subdir to mcp251xfdMarc Kleine-Budde
In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes the name of the driver subdir and the individual files accordinly. [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>