Hi all,
This patch series adds CAN-FD Transceiver Delay Compensation support to
the R-Car CAN-FD driver, after the customary cleanups and refactorings.
This has been tested on R-Car V4H (White Hawk), V4M (Gray Hawk Single),
and E3 (Ebisu-4D[1]), using various data bit rates. Without proper TDC
configuration, transmitting at 8 Mbps makes the CAN-FD controller enter
BUS-OFF state. The TDCV value as measured by the CAN-FD controller is 4
on all boards tested (base clock 40 MHz, i.e. 25 ns period), and ca. 90
ns as measured by a logic analyzer on Gray Hawk Single.
Note that the BSP (predating upstream TDC support), uses a much simpler
method: for transfer rates >= 5 Mbps on R-Car Gen4, it enables TDC with
a hardcoded (hardware) TDCO value of 2 (i.e. actual 3), which matches
the behavior of this series at 8 Mbps.
Thanks for your comments!
[1] r8a77990.dtsi configures the CANFD core clock to 40 MHz, limiting
transfer rates to 4 Mbps. Enable support for 8 Mbps by adding to
ebisu.dtsi:
&canfd {
assigned-clock-rates = <80000000>;
}
Geert Uytterhoeven (9):
can: rcar_canfd: Consistently use ndev for net_device pointers
can: rcar_canfd: Use ndev parameter in rcar_canfd_set_bittiming()
can: rcar_canfd: Add helper variable ndev to rcar_canfd_rx_pkt()
can: rcar_canfd: Add helper variable dev to
rcar_canfd_reset_controller()
can: rcar_canfd: Simplify data access in rcar_canfd_{ge,pu}t_data()
can: rcar_canfd: Repurpose f_dcfg base for other registers
can: rcar_canfd: Share config code in rcar_canfd_set_bittiming()
can: rcar_canfd: Return early in rcar_canfd_set_bittiming() when not
FD
can: rcar_canfd: Add support for Transceiver Delay Compensation
drivers/net/can/rcar/rcar_canfd.c | 193 +++++++++++++++++++-----------
1 file changed, 126 insertions(+), 67 deletions(-)
--
2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
