Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates - Marc Kleine-Budde

From: Marc Kleine-Budde <mkl@pengutronix.de>
To: "Ramesh Shanmugasundaram"
	<ramesh.shanmugasundaram@bp.renesas.com>,
	"Sekhar Nori" <nsekhar@ti.com>,
	"Franklin S Cooper Jr" <fcooper@ti.com>,
	"Mario Hüttel" <mario.huettel@gmx.net>,
	"Yang, Wenyou" <Wenyou.Yang@Microchip.com>,
	"wg@grandegger.com" <wg@grandegger.com>,
	"socketcan@hartkopp.net" <socketcan@hartkopp.net>,
	"quentin.schulz@free-electrons.com"
	<quentin.schulz@free-electrons.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Wenyou Yang <wenyou.yang@atmel.com>,
	Dong Aisheng <b29396@freescale.com>,
	"Quadros, Roger" <rogerq@ti.com>
Subject: Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
Date: Thu, 19 Oct 2017 11:21:29 +0200	[thread overview]
Message-ID: <832feb2d-3712-c394-805a-1ddabd89890e@pengutronix.de> (raw)
In-Reply-To: <KL1PR0601MB20386197BA2733930329257BC3420@KL1PR0601MB2038.apcprd06.prod.outlook.com>

[-- Attachment #1.1: Type: text/plain, Size: 2149 bytes --]

On 10/19/2017 10:04 AM, Ramesh Shanmugasundaram wrote:
>>> Sounds reasonable. What's the status of this series?
>>
>> I have had some offline discussions with Franklin on this, and I am not
>> fully convinced that DT is the way to go here (although I don't have the
>> agreement with Franklin there).
>>
>> There are two components in configuring the secondary sample point. It is
>> the transceiver loopback delay and an offset (example half of the bit time
>> in data phase).
>>
>> While the transceiver loopback delay is pretty board dependent (and thus
>> amenable to DT encoding), I am not quite sure the offset can be configured
>> in DT because its not really board dependent.
>>
>> Unfortunately, offset calculation does not seem to be an exact science.
>> There are recommendations ranging from using 50% of bit time to making it
>> same as the sample point configured. This means users who need to change
>> the SSP due to offset variations need to change  their DT even without
>> anything changing on their board.
>>
>> Since we have a netlink socket interface to configure sample point, I
>> wonder if that should be extended to configure SSP too (or at least the
>> offset part of SSP)?
> 
> +1
> > I also wonder how a default TDCO setting in DT would help.

For a given board with a given transceiver and layout and proper values
in the supplied DT the higher bitrates would work out of the box.

> Is the driver going to hard code the Tq settings as well for the
> most commonly used bitrate?

What's Tq in this context. Time Quanta?

> A link up start-up script (using netlink) would help setting a
> default TDCO along with other params if this is the main concern.

There are various ways to setup these values. Plain old start-up scripts
are one of them, systemd-networkd or network manager are others.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]