- 06 Feb, 2023 14 commits
-
-
Marc Kleine-Budde authored
"The (Re-)Synchronization Jump Width (SJW) defines how far a resynchronization may move the Sample Point inside the limits defined by the Phase Buffer Segments to compensate for edge phase errors." [1] In other words, this means that the SJW parameter controls the tolerance of the CAN controller to frequency errors compared to other CAN controllers. If the user space does not provide an SJW parameter, the kernel chooses a default value of 1. This has proven to be a good default value for classic CAN controllers, but no longer for modern CAN-FD controllers. In the past there were CAN controllers like the sja1000 with a rather limited range of bit timing parameters. For the standard bit rates this results in the following bit timing parameters: | Bit timing parameters for sja1000 with 8.000000 MHz ref clock | _----+--------------=> tseg1: 1 … 16 | / / _---------=> tseg2: 1 … 8 | | | / _-----=> sjw: 1 … 4 | | | | / _-=> brp: 1 … 64 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 1000000 125 2 3 2 1 1 1000000 0.0% 75.0% 75.0% 0.0% 0x00 0x14 | 800000 125 3 4 2 1 1 800000 0.0% 80.0% 80.0% 0.0% 0x00 0x16 | 666666 125 4 4 3 1 1 666666 0.0% 80.0% 75.0% 6.2% 0x00 0x27 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c | 250000 250 6 7 2 1 2 250000 0.0% 87.5% 87.5% 0.0% 0x01 0x1c | 125000 500 6 7 2 1 4 125000 0.0% 87.5% 87.5% 0.0% 0x03 0x1c | 100000 625 6 7 2 1 5 100000 0.0% 87.5% 87.5% 0.0% 0x04 0x1c | 83333 750 6 7 2 1 6 83333 0.0% 87.5% 87.5% 0.0% 0x05 0x1c | 50000 1250 6 7 2 1 10 50000 0.0% 87.5% 87.5% 0.0% 0x09 0x1c | 33333 1875 6 7 2 1 15 33333 0.0% 87.5% 87.5% 0.0% 0x0e 0x1c | 20000 3125 6 7 2 1 25 20000 0.0% 87.5% 87.5% 0.0% 0x18 0x1c | 10000 6250 6 7 2 1 50 10000 0.0% 87.5% 87.5% 0.0% 0x31 0x1c The attentive reader will notice that the SJW is 1 in most cases, while the Seg2 phase is 2. Both values are given in TQ units, which in turn is a duration in nanoseconds. For example the 500 kbit/s configuration: | nominal real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c the TQ is 125ns, the Phase Seg2 is "2" (== 250ns), the SJW is "1" (== 125 ns). Looking at a more modern CAN controller like a mcp2518fd, it has wider bit timing registers. | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440900 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "1" (== 25ns). Since the kernel chooses a default SJW of 1 regardless of the TQ, this leads to a much smaller SJW and thus much smaller tolerances to frequency errors. To maintain the same oscillator tolerances on controllers with wide bit timing registers, select a default SJW value of Phase Seg2 / 2 unless Phase Seg 1 is less. This results in the following bit timing parameters: | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 5 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440904 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "5" (== 125ns). Which is the same as on the sja1000 controller. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/20230202110854.2318594-15-mkl@pengutronix.de Cc: Mark Bath <mark@baggywrinkle.co.uk> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
According to "The Configuration of the CAN Bit Timing" [1] the SJW "may not be longer than either Phase Buffer Segment". Check SJW against length of both Phase buffers. In case the SJW is greater, report an error via netlink to user space and bail out. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/20230202110854.2318594-14-mkl@pengutronix.deSuggested-by:
Vincent Mailhol <vincent.mailhol@gmail.com> Signed-off-by:
-
Marc Kleine-Budde authored
If the user space has supplied an invalid SJW value (greater than the maximum SJW value), report -EINVAL instead of -ERANGE, this better matches the actual meaning of the error value. Additionally report an error message via netlink to the user space. Link: https://lore.kernel.org/all/20230202110854.2318594-13-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Check each bit timing parameter first individually against their limits and report a meaningful error message via netlink to the user space. In case of an error, return -EINVAL instead of -ERANGE, this corresponds better to the actual meaning of the error value. Link: https://lore.kernel.org/all/20230202110854.2318594-12-mkl@pengutronix.deSuggested-by:
-
Marc Kleine-Budde authored
Factor out the functionality of assigning a SJW default value into can_sjw_set_default() and the checking the SJW limits into can_sjw_check(). This functions will be improved and called from a different function in the following patches. Link: https://lore.kernel.org/all/20230202110854.2318594-11-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This is a preparation patch. In order to pass warning/error messages during netlink calls back to user space, pass the extack struct down the callstack of can_changelink(), the actual error messages will be added in the following ptaches. Link: https://lore.kernel.org/all/20230202110854.2318594-10-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Since commit 51c352bd ("netlink: add support for formatted extack messages") formatted extack messages are supported to inform the user space or warnings/errors during netlink calls. Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the user about the problem. While there, use %u to print unsigned values and improve error message a bit. Link: https://lore.kernel.org/all/20230202110854.2318594-9-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The sample point is a value in tenths of a percent. Meaningful values are between 0 and 1000. Invalid values are rejected and an error message is returned to user space via netlink. Link: https://lore.kernel.org/all/20230202110854.2318594-8-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The CAN driver framework supports either fixed bit rates or bit timing constants. Bail out during driver registration if both are given. Link: https://lore.kernel.org/all/20230202110854.2318594-7-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Implement the function can_bittiming_const_valid() to check the validity of the specified bit timing constant. Call this function from register_candev() to check the bit timing constants during the registration of the CAN interface. Link: https://lore.kernel.org/all/20230202110854.2318594-6-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Clean up the code flow a bit, don't assign err variable but directly return. Remove the unneeded else, too. Link: https://lore.kernel.org/all/20230202110854.2318594-5-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The can_fixup_bittiming() function is used to validate the user-supplied low-level bit timing parameters and calculate the bitrate prescaler (brp) from the requested time quanta (tq) and the CAN clock of the controller. can_fixup_bittiming() selects the best matching integer bit rate prescaler, which may result in a different time quantum than the value specified by the user. Calculate the resulting time quantum and assign it so that the user sees the effective time quantum. Link: https://lore.kernel.org/all/20230202110854.2318594-4-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Commit 1c47fa6b ("can: dev: add a helper function to calculate the duration of one bit") made the constant CAN_SYNC_SEG available in a header file. The magic number 1 in can_fixup_bittiming() represents the width of the sync segment, replace it by CAN_SYNC_SEG to make the code more readable. Link: https://lore.kernel.org/all/20230202110854.2318594-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
Commit 1c47fa6b ("can: dev: add a helper function to calculate the duration of one bit") added the helper function can_bit_time(). Replace open coded variants of can_bit_time() by the helper function. Link: https://lore.kernel.org/all/20230202110854.2318594-2-mkl@pengutronix.deSigned-off-by:
-
- 02 Feb, 2023 26 commits
-
-
Marc Kleine-Budde authored
Lukas Magel <lukas.magel@posteo.net> says: This series of patches introduces the CAN channel ID for the PEAK USB CAN interfaces. The id can be read/written via ethtool and is exposed as a read-only attribute via sysfs. This allows users to set the id via ethtool and write udev rules to match against the sysfs attribute. Part of the patches were originally introduced by Stéphane Grosjean and were modified slightly. See the following threads for the original patches: * https://lore.kernel.org/linux-can/20220128150157.1222850-1-s.grosjean@peak-system.com * https://lore.kernel.org/linux-can/20211117150132.37056-1-s.grosjean@peak-system.com changes since v2: https://lore.kernel.org/all/20221030105939.87658-1-lukas.magel@posteo.net * Fix the issues raised on netdev * Rename user device ID to CAN channel ID to make the 1-to-N mapping between USB device and exposed CAN channels more obvious changes since v1: https://lore.kernel.org/all/20221022213535.8495-1-lukas.magel@posteo.net * Fix type of devid_le in ethtool peak_usb_(get|set)_eeprom * Fix signed-off tags Link: https://lore.kernel.org/all/20221213080309.9013-1-lukas.magel@posteo.net [mkl: added links] Signed-off-by:
-
Lukas Magel authored
The include directives in all source files are reordered alphabetically according to the names of the header files. Signed-off-by:
Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-9-lukas.magel@posteo.net [mkl: move header changes from Patch 3 here] Signed-off-by:
-
Lukas Magel authored
Previously, the CAN channel ID was printed to the kernel log in decimal upon connecting a new PEAK device. This behavior is inconsistent with the hexadecimal format of the CAN channel ID sysfs attribute. This patch updates the log message to output the id in hexadecimal. Signed-off-by:
-
Lukas Magel authored
This patch exports the CAN channel ID as a sysfs attribute. The CAN channel ID is a user-configurable u8/u32 identifier that can be set individually for each CAN interface of a PEAK USB device. Exporting the channel ID as a sysfs attribute allows users to easily read the ID and to write udev rules that can match against the ID. This is especially useful for PEAK USB devices that do not export a serial number at SUB level. Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
-
Stephane Grosjean authored
This patch introduces 3 new functions implementing support for ethtool access to the CAN channel ID of all USB CAN network interfaces managed by the driver. With this patch, it is possible to read/write the CAN channel ID from/to the EEPROM via the ethtool interface. The CAN channel ID is a user-configurable device identifier that can be set individually for each CAN interface of a PEAK USB device. Depending on the device, the identifier has a length of 8 or 32 bit. The identifier is stored in the non-volatile memory of the device. The identifier of a CAN interface can be read/written as an 8 or 32 bit byte string in native (little-endian) byte order, where the length depends on the device type. Signed-off-by:
-
Stephane Grosjean authored
This patch changes the call to unregister_netdev() in peak_usb_disconnect() with unregister_candev(). Signed-off-by:
-
Stephane Grosjean authored
This patch adds callbacks that allow the user to set a new self-defined CAN channel ID to all USB - CAN/CANFD interfaces of PEAK-System managed by this driver, namely: - PCAN-USB - PCAN-USB FD - PCAN-USB Pro FD - PCAN-USB X6 - PCAN-Chip USB - PCAN-USB Pro The callback functions write the CAN channel ID to the non-volatile memory of the devices. Signed-off-by:
-
Stephane Grosjean authored
This patch adds a new function that allows to read the CAN channel ID from the non volatile memory of the USB CAN-FD PEAK devices. The CAN channel ID is a user-configurable u8/u32 identifier value that can be set individually for each PEAK CAN interface. Signed-off-by:
-
Stephane Grosjean authored
The so-called "device id" is a user-defined identifier value that can be set individually for each CAN interface of a PEAK USB device. Contrary to a static serial number, the value can be changed by the user. With this ID, each CAN interface can be uniquely identified even if the USB device does not export a proper serial number or the USB device exports multiple CAN interfaces. In order to not confuse it with the device ID used by the USB core and emphasize the link to the CAN interface, the functions and variables for reading this user-defined value are renamed to CAN channel ID. Signed-off-by:
-
Marc Kleine-Budde authored
Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> says: The CPC-PCIe v3 uses an Asix AX99100 instead of the discontinued PLX PCI9030 bridge chip. This patch series adds support for this card version and cleans some code styling issues. v1: https://lore.kernel.org/all/20230119154528.28425-1-uttenthaler@ems-wuensche.com Link: https://lore.kernel.org/all/20230120112616.6071-1-uttenthaler@ems-wuensche.comSigned-off-by:
-
Gerhard Uttenthaler authored
Added myself as module author Signed-off-by:
Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-9-uttenthaler@ems-wuensche.comSigned-off-by:
-
Gerhard Uttenthaler authored
The reset line from the Asix chip to the SJA1000 is asserted after boot up until it is deasserted by a register write Signed-off-by:
-
Gerhard Uttenthaler authored
Add IRQ enable Signed-off-by:
-
Gerhard Uttenthaler authored
Add CAN controller base registers Signed-off-by:
-
Gerhard Uttenthaler authored
Add functions to read and write SJA1000 registers and also the post irq routine Signed-off-by:
-
Gerhard Uttenthaler authored
Fix the base register defines and their usage for all three card versions Signed-off-by:
-
Gerhard Uttenthaler authored
Add Asix AX99100 PCI IDs and add the v3 to the ems_pci_tbl. Add define for maximum CAN channel count Signed-off-by:
-
Gerhard Uttenthaler authored
Fix code style complained by checkpatch.pl, add Copyright and fix email address Signed-off-by:
-
Marc Kleine-Budde authored
Geert Uytterhoeven <geert+renesas@glider.be> says: This patch series adds support for the CAN-FD interface on the Renesas R-Car V4H (R8A779G0) SoC and support for CAN transceivers described as PHYs to the R-Car CAN-FD driver. It includes several fixes for issues (some minor) detected while adding the support and during testing. More details can be found in the individual patches. This has been tested on the Renesas White-Hawk development board using cansend, candump, and canfdtest: - Channel 0 uses an NXP TJR1443AT CAN transceiver, and works fine, - Channels 1-7 use Microchip MCP2558FD-H/SN CAN transceivers (not mounted for channels 4-7), which do not need explicit description. While channel 1 works fine, channels 2-3 do not seem to work. Hence despite the new fixes, the test results are similar to what Ulrich Hecht reported for R-Car V3U on the Falcon development board before, i.e. only channels 0 and 1 work (FTR, [2] does not help). Whether this is a CAN-FD driver issue, a pin control issue, an IP core issue, or an SoC integration issue is still to be seen... [1] https://lore.kernel.org/all/f53a1bcca637ceeafb04ce3540a605532d3bc34a.1674036164.git.geert+renesas@glider.be [2] commit e3e5bccc92446048 ("can: rcar_canfd: rcar_canfd_configure_afl_rules(): Fix Rx FIFO entry setting") in renesas-bsp/v5.10.147/rcar-5.2.0.rc3. Link: https://lore.kernel.org/all/cover.1674499048.git.geert+renesas@glider.be [mkl: applying patches 1...11 only] Signed-off-by: -
Geert Uytterhoeven authored
rcar_canfd_channel_probe() and rcar_canfd_probe() have many users of "pdev->dev". Introduce shorthands to simplify the code. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/2965edc7992ab54dc6c862910775f3466fca6b29.1674499048.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
This may avoid conflicts when adding or removing files in the future. Signed-off-by:
-
Geert Uytterhoeven authored
On R-Car Gen4 CAN_FD variants, the Common FIFO TX Message Buffer Link (CFTML) field in the Common FIFO Configuration / Control Register (CCFC) register is one bit wider than on older variants. Signed-off-by:
-
Geert Uytterhoeven authored
On R-Car Gen4 CAN_FD variants, the Data Bit Rate Resynchronization Jump Width Control (DSJW) field in the Channel n Data Bitrate Configuration Register (DCFG) register is one bit wider than on older variants. Signed-off-by:
-
Geert Uytterhoeven authored
Despite the name, R-Car V3U (R8A779A0) was the first member of the R-Car Gen4 family. Generalize the support for R-Car V3U to other SoCs in the R-Car Gen4 family by adding a family-specific compatible value, and by replacing all references to "V3U" by "Gen4". Signed-off-by:
-
Geert Uytterhoeven authored
Abstract the different addresses for the Channel n Data Bitrate Configuration Register (DCFG) in the definition of the register macro, like is already done for other register definitions, to simplify code accessing this register. Signed-off-by:
-
Geert Uytterhoeven authored
Each Global Acceptance Filter List Configuration Register (GAFLCFG) contains two fields, and stores the number of channel rules for one channel pair. As R-Car V3U and later can have more than 2 channels, the field selection should be based on the LSB (even or odd) of the channel number, instead of on the full channel number. Fixes: 45721c40 ("can: rcar_canfd: Add support for r8a779a0 SoC") Signed-off-by:
-
