mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: Franklin S Cooper Jr <fcooper@ti.com>, <wg@grandegger.com>,
	<mkl@pengutronix.de>, <mario.huettel@gmx.net>,
	<socketcan@hartkopp.net>, <quentin.schulz@free-electrons.com>,
	<edumazet@google.com>, <linux-can@vger.kernel.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Wenyou Yang <wenyou.yang@atmel.com>, Dong Aisheng <b29396@freescale.com>
Subject: Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
Date: Thu, 14 Sep 2017 10:36:18 +0530	[thread overview]
Message-ID: <a7e301a7-bc54-c348-bdb1-b6a0af41665f@ti.com> (raw)
In-Reply-To: <4f8f6b64-b2a2-b9dc-665c-f1c155daf994@ti.com>


On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
> 
> 
> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>> resulted in errors. Scoping the signals I noticed that only a single bit
>> was being transmitted and with a bit more investigation realized the actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the Transmitter
>> Delay Compensation Mode as defined in the MCAN User's Guide. When this
>> mode is used the User's Guide indicates that the Transmitter Delay
>> Compensation Offset register should be set. The document mentions that this
>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>
>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>> Therefore, only enable this mode and only set TDCO when the data bit rate
>> is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>> I'm pretty surprised that this hasn't been implemented already since
>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>> supports up to 10 Mbps.
>>
>> So it will be nice to get comments from users of this driver to understand
>> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
>> If they haven't what did they do to get around it if they needed higher
>> speeds.
>>
>> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
>> everything still works at 5 Mbps which is the max speed of my CAN
>> transceiver.
> 
> ping. Anyone has any thoughts on this?

I added Dong who authored the m_can driver and Wenyou who added the only
in-kernel user of the driver for any help.

Thanks,
Sekhar

>>
>>  drivers/net/can/m_can/m_can.c | 24 +++++++++++++++++++++++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index f4947a7..720e073 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
>>  #define DBTP_DSJW_SHIFT		0
>>  #define DBTP_DSJW_MASK		(0xf << DBTP_DSJW_SHIFT)
>>  
>> +/* Transmitter Delay Compensation Register (TDCR) */
>> +#define TDCR_TDCO_SHIFT		8
>> +#define TDCR_TDCO_MASK		(0x7F << TDCR_TDCO_SHIFT)
>> +#define TDCR_TDCF_SHIFT		0
>> +#define TDCR_TDCF_MASK		(0x7F << TDCR_TDCO_SHIFT)
>> +
>>  /* Test Register (TEST) */
>>  #define TEST_LBCK		BIT(4)
>>  
>> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  	const struct can_bittiming *dbt = &priv->can.data_bittiming;
>>  	u16 brp, sjw, tseg1, tseg2;
>>  	u32 reg_btp;
>> +	u32 enable_tdc = 0;
>> +	u32 tdco;
>>  
>>  	brp = bt->brp - 1;
>>  	sjw = bt->sjw - 1;
>> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
>>  		sjw = dbt->sjw - 1;
>>  		tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
>>  		tseg2 = dbt->phase_seg2 - 1;
>> +
>> +		/* TDC is only needed for bitrates beyond 2.5 MBit/s
>> +		 * Specified in the "Bit Time Requirements for CAN FD" document
>> +		 */
>> +		if (dbt->bitrate > 2500000) {
>> +			enable_tdc = DBTP_TDC;
>> +			/* Equation based on Bosch's M_CAN User Manual's
>> +			 * Transmitter Delay Compensation Section
>> +			 */
>> +			tdco = priv->can.clock.freq / (dbt->bitrate * 2);
>> +			m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
>> +		}
>> +
>>  		reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
>>  			(tseg1 << DBTP_DTSEG1_SHIFT) |
>> -			(tseg2 << DBTP_DTSEG2_SHIFT);
>> +			(tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
>> +
>>  		m_can_write(priv, M_CAN_DBTP, reg_btp);
>>  	}
>>  
>>

  reply	other threads:[~2017-09-14  5:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-18 19:39 Franklin S Cooper Jr
2017-09-13 21:58 ` Franklin S Cooper Jr
2017-09-14  5:06   ` Sekhar Nori [this message]
2017-09-18  3:47     ` Yang, Wenyou
2017-09-20 20:19       ` Franklin S Cooper Jr
2017-09-20 21:37         ` Mario Hüttel
2017-09-21  0:48           ` Franklin S Cooper Jr
2017-10-18 12:44             ` Marc Kleine-Budde
2017-10-18 13:24               ` Sekhar Nori
2017-10-18 14:17                 ` Franklin S Cooper Jr
2017-10-19  5:07                   ` Sekhar Nori
2017-10-19  9:13                     ` Marc Kleine-Budde
2017-10-19 11:09                       ` Sekhar Nori
2017-10-19 11:32                         ` Marc Kleine-Budde
2017-10-19 13:54                           ` Franklin S Cooper Jr
2017-10-19 14:55                             ` Marc Kleine-Budde
2017-10-19 15:40                               ` Franklin S Cooper Jr
2017-10-20 12:14                               ` Sekhar Nori
2017-10-19 11:14                       ` Oliver Hartkopp
2017-10-19 11:26                         ` Marc Kleine-Budde
2017-10-19 18:35                           ` Oliver Hartkopp
2017-10-19 19:54                             ` Mario Hüttel
2017-10-19 20:17                               ` Oliver Hartkopp
2017-10-19  8:04                 ` Ramesh Shanmugasundaram
2017-10-19  9:21                   ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7e301a7-bc54-c348-bdb1-b6a0af41665f@ti.com \
    --to=nsekhar@ti.com \
    --cc=b29396@freescale.com \
    --cc=edumazet@google.com \
    --cc=fcooper@ti.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.huettel@gmx.net \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=quentin.schulz@free-electrons.com \
    --cc=socketcan@hartkopp.net \
    --cc=wenyou.yang@atmel.com \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®