From: "Yang, Wenyou" <Wenyou.Yang@Microchip•com>
To: Sekhar Nori <nsekhar@ti•com>,
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: Mon, 18 Sep 2017 11:47:22 +0800 [thread overview]
Message-ID: <532e09ae-775d-e8aa-e468-78e148c650da@Microchip.com> (raw)
In-Reply-To: <a7e301a7-bc54-c348-bdb1-b6a0af41665f@ti.com>
On 2017/9/14 13:06, Sekhar Nori wrote:
> 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.
I tested it on SAMA5D2 Xplained board both with and without this patch,
both work with the 4M bps data bit rate.
>
> 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);
>>> }
>>>
>>>
Regards,
Wenyou Yang
next prev parent reply other threads:[~2017-09-18 3:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
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-14 5:06 ` Sekhar Nori
2017-09-18 3:47 ` Yang, Wenyou [this message]
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=532e09ae-775d-e8aa-e468-78e148c650da@Microchip.com \
--to=wenyou.yang@microchip$(echo .)com \
--cc=b29396@freescale$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=fcooper@ti$(echo .)com \
--cc=linux-can@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mario.huettel@gmx$(echo .)net \
--cc=mkl@pengutronix$(echo .)de \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nsekhar@ti$(echo .)com \
--cc=quentin.schulz@free-electrons$(echo .)com \
--cc=socketcan@hartkopp$(echo .)net \
--cc=wenyou.yang@atmel$(echo .)com \
--cc=wg@grandegger$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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