On 28.07.2022 09:36:21, Dario Binacchi wrote: > > Most of the other CAN drivers write the BTR values into the register of > > the hardware. How are these BTR values transported into the driver? > > > > There are 2 ways: > > > > 1) - user space configures a bitrate > > - the kernel calculates with the "struct can_bittiming_const" [1] given > > by driver and the CAN clock rate the low level timing parameters. > > > > [1] https://elixir.bootlin.com/linux/v5.18/source/include/uapi/linux/can/netlink.h#L47 > > > > 2) - user space configures low level bit timing parameter > > (Sample point in one-tenth of a percent, Time quanta (TQ) in > > nanoseconds, Propagation segment in TQs, Phase buffer segment 1 in > > TQs, Phase buffer segment 2 in TQs, Synchronisation jump width in > > TQs) > > - the kernel calculates the Bit-rate prescaler from the given TQ and > > CAN clock rate > > > > Both ways result in a fully calculated "struct can_bittiming" [2]. The > > driver translates this into the hardware specific BTR values and writes > > the into the registers. > > > > If you know the CAN clock and the bit timing const parameters of the > > slcan's BTR register you can make use of the automatic BTR calculation, > > too. Maybe the framework needs some tweaking if the driver supports both > > fixed CAN bit rate _and_ "struct can_bittiming_const". > > Does it make sense to use the device tree The driver doesn't support DT and DT only works for static serial interfaces. > to provide the driver with those > parameters required for the automatic calculation of the BTR (clock rate, > struct can_bittiming_const, ...) that depend on the connected > controller? The device tree usually says it's a CAN controller compatible to X and the following clock(s) are connected. The driver for CAN controller X knows the bit timing const. Some USB CAN drivers query the bit timing const from the USB device. > In this way the solution should be generic and therefore scalable. I > think we should also add some properties to map the calculated BTR > value on the physical register of the controller. The driver knows how to map the "struct can_bittiming" to the BTR register values of the hardware. What does the serial protocol say to the BTR values? Are these standard SJA1000 layout with 8 MHz CAN clock or are those adapter specific? > Or, use the device tree to extend the bittates supported by the controller > to the fixed ones (struct can_priv::bitrate_const)? The serial protocol defines fixed bit rates, no need to describe them in the DT: | 0 10 Kbit/s | 1 20 Kbit/s | 2 50 Kbit/s | 3 100 Kbit/s | 4 125 Kbit/s | 5 250 Kbit/s | 6 500 Kbit/s | 7 800 Kbit/s | 8 1000 Kbit/s Are there more bit rates? 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 |
Attachment:
signature.asc
Description: PGP signature
