[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220728090228.nckgpmfe7rpnfcyr@pengutronix.de>
Date: Thu, 28 Jul 2022 11:02:28 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Dario Binacchi <dario.binacchi@...rulasolutions.com>
Cc: Max Staudt <max@...as.org>, linux-kernel@...r.kernel.org,
linux-can@...r.kernel.org,
Oliver Hartkopp <socketcan@...tkopp.net>,
michael@...rulasolutions.com,
Amarula patchwork <linux-amarula@...rulasolutions.com>,
Jeroen Hofstee <jhofstee@...tronenergy.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Wolfgang Grandegger <wg@...ndegger.com>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH v3 8/9] can: slcan: add support to set bit time
register (btr)
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 |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists