On Thu, Jul 28, 2022 at 11:02 AM Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > > 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? I think they are adapter specific. This is what the can232_ver3_Manual.pdf reports: sxxyy[CR] Setup with BTR0/BTR1 CAN bit-rates where xx and yy is a hex value. This command is only active if the CAN channel is closed. xx BTR0 value in hex yy BTR1 value in hex Example: s031C[CR] Setup CAN with BTR0=0x03 & BTR1=0x1C which equals to 125Kbit. But I think the example is misleading because IMHO it depends on the adapter's controller (0x31C -> 125Kbit). > > > 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? No, the manual can232_ver3_Manual.pdf does not contain any others. What about defining a device tree node for the slcan (foo adapter): slcan { compatible = "can,slcan"; /* bit rate btr0btr1 */ additional-bitrates = < 33333 0x0123 80000 0x4567 83333 0x89ab 150000 0xcd10 175000 0x2345 200000 0x6789> }; So that the can_priv::bitrate_cons array (dynamically created) will contain the bitrates 10000, 20000, 50000, 100000, 125000, 250000, 500000, 800000, 1000000 /* end of standards bitrates, use S command */ 33333, /* use s command, btr 0x0123 */ 80000, /* use s command, btr 0x4567 */ 83333, /* use s command, btr 0x89ab */ 150000, /* use s command, btr 0xcd10 */ 175000, /* use s command, btr 0x2345 */ 200000 /* use s command, btr 0x6789 */ }; So if a standard bitrate is requested, the S command is used, otherwise the s command with the associated btr. Thanks and regards, Dario > > 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 | -- Dario Binacchi Embedded Linux Developer dario.binacchi@xxxxxxxxxxxxxxxxxxxx __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info@xxxxxxxxxxxxxxxxxxxx www.amarulasolutions.com
