On Thu, Jul 28, 2022 at 11:02 AM Marc Kleine-Budde [off-list ref] wrote:

On 28.07.2022 09:36:21, Dario Binacchi wrote:

quoted

quoted

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.

quoted

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.

quoted

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).

quoted

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@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com