All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franklin S Cooper Jr <fcooper@ti.com>
To: 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: Franklin S Cooper Jr <fcooper@ti.com>
Subject: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
Date: Fri, 18 Aug 2017 14:39:47 -0500	[thread overview]
Message-ID: <20170818193947.27862-1-fcooper@ti.com> (raw)

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.

 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);
 	}
 
-- 
2.9.4.dirty

WARNING: multiple messages have this Message-ID (diff)
From: Franklin S Cooper Jr <fcooper@ti.com>
To: <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: Franklin S Cooper Jr <fcooper@ti.com>
Subject: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
Date: Fri, 18 Aug 2017 14:39:47 -0500	[thread overview]
Message-ID: <20170818193947.27862-1-fcooper@ti.com> (raw)

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.

 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);
 	}
 
-- 
2.9.4.dirty

             reply	other threads:[~2017-08-18 19:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-18 19:39 Franklin S Cooper Jr [this message]
2017-08-18 19:39 ` [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates Franklin S Cooper Jr
2017-09-13 21:58 ` Franklin S Cooper Jr
2017-09-13 21:58   ` Franklin S Cooper Jr
2017-09-14  5:06   ` Sekhar Nori
2017-09-14  5:06     ` Sekhar Nori
2017-09-18  3:47     ` Yang, Wenyou
2017-09-18  3:47       ` Yang, Wenyou
2017-09-20 20:19       ` Franklin S Cooper Jr
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-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=20170818193947.27862-1-fcooper@ti.com \
    --to=fcooper@ti.com \
    --cc=edumazet@google.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.