Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220726210217.3368497-1-dario.binacchi@amarulasolutions.com>
 <20220726210217.3368497-9-dario.binacchi@amarulasolutions.com>
 <20220727113054.ffcckzlcipcxer2c@pengutronix.de> <20220727192839.707a3453.max@enpas.org>
 <20220727182414.3mysdeam7mtnqyfx@pengutronix.de> <CABGWkvoE8i--g_2cNU6ToAfZk9WE6uK-nLcWy7J89hU6RidLWw@mail.gmail.com>
 <20220728090228.nckgpmfe7rpnfcyr@pengutronix.de>
In-Reply-To: <20220728090228.nckgpmfe7rpnfcyr@pengutronix.de>
From:   Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Thu, 28 Jul 2022 12:23:04 +0200
Message-ID: <CABGWkvoYR67MMmqZ6bRLuL3szhVb-gMwuAy6Z4YMkaG0yw6Sdg@mail.gmail.com>
Subject: Re: [RFC PATCH v3 8/9] can: slcan: add support to set bit time
 register (btr)
To:     Marc Kleine-Budde <mkl@pengutronix.de>
Cc:     Max Staudt <max@enpas.org>, linux-kernel@vger.kernel.org,
        linux-can@vger.kernel.org,
        Oliver Hartkopp <socketcan@hartkopp.net>,
        michael@amarulasolutions.com,
        Amarula patchwork <linux-amarula@amarulasolutions.com>,
        Jeroen Hofstee <jhofstee@victronenergy.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Wolfgang Grandegger <wg@grandegger.com>, netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jul 28, 2022 at 11:02 AM Marc Kleine-Budde <mkl@pengutronix.de> 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@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

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

www.amarulasolutions.com