From: Faiz Abbas <faiz_abbas@ti.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
wg@grandegger.com, robh+dt@kernel.org, mark.rutland@arm.com
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
nsekhar@ti.com, fcooper@ti.com, robh@kernel.org,
Wenyou.Yang@microchip.com, sergei.shtylyov@cogentembedded.com
Subject: Re: [PATCH v6 4/6] can: m_can: Support higher speed CAN-FD bitrates
Date: Wed, 3 Jan 2018 18:25:28 +0530 [thread overview]
Message-ID: <dce9ff7d-239b-9ae3-a738-d4fec4249c86@ti.com> (raw)
In-Reply-To: <f2a063cd-9456-c21d-2544-02179e0f4f27@pengutronix.de>
Hi,
On Tuesday 02 January 2018 07:05 PM, Marc Kleine-Budde wrote:
> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>> From: Franklin S Cooper Jr <fcooper@ti.com>
>>
>> During test transmitting using CAN-FD at high bitrates (> 2 Mbps)
>> would fail. 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 with the correct value for the transmitter delay
>> compensation offset (tdco). What impacts the tdco value isn't 100% clear
>> but to calculate it you use an equation defined in the MCAN User's Guide.
>>
>> The user guide mentions that this register needs to be set based on clock
>> values, secondary sample point and the data bitrate. One of the key
>> variables that can't automatically be determined is the secondary
>> sample point (ssp). This ssp is similar to the sp but is specific to this
>> transmitter delay compensation mode. The guidelines for configuring
>> ssp is rather vague but via some CAN test it appears for DRA76x that putting
>> the value same as data sampling point works.
>>
>> The CAN-CIA's "Bit Time Requirements for CAN FD" paper presented at
>> the International CAN Conference 2013 indicates that this TDC mode is
>> only needed for data bit rates above 2.5 Mbps. Therefore, only enable
>> this mode when the data bit rate is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> drivers/net/can/m_can/m_can.c | 41 ++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index 53e764f..371ffc1 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -127,6 +127,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_TDCF_SHIFT)
>> +
>> /* Test Register (TEST) */
>> #define TEST_LBCK BIT(4)
>>
>> @@ -991,7 +997,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>> const struct can_bittiming *bt = &priv->can.bittiming;
>> const struct can_bittiming *dbt = &priv->can.data_bittiming;
>> u16 brp, sjw, tseg1, tseg2;
>> - u32 reg_btp;
>> + u32 reg_btp, tdco, ssp;
>
> Please move the tdco and the ssp into "if (dbt->bitrate > 2500000)" scope.
Ok.
>
> Initialize "reg_btp = 0", see below.
>
>> + bool enable_tdc = false;
>
> Please remove, see below.
>
>>
>> brp = bt->brp - 1;
>> sjw = bt->sjw - 1;
>> @@ -1006,9 +1013,41 @@ 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.
>> + * This is mentioned in the "Bit Time Requirements for CAN FD"
>> + * paper presented at the International CAN Conference 2013
>> + */
>> + if (dbt->bitrate > 2500000) {
>> + /* Use the same value of secondary sampling point
>> + * as the data sampling point
>> + */
>> + ssp = dbt->sample_point;
>> +
>> + /* Equation based on Bosch's M_CAN User Manual's
>> + * Transmitter Delay Compensation Section
>> + */
>> + tdco = (priv->can.clock.freq / 1000) *
>> + ssp / dbt->bitrate;
>> +
>> + /* Max valid TDCO value is 127 */
>> + if (tdco > 127) {
>> + netdev_warn(dev, "TDCO value of %u is beyond maximum limit. Disabling Transmitter Delay Compensation mode\n",
>
> "maximum limit"? Either "maximum" or "limit" should be enough. If the
> value is above 127, does it make sense to disable the tdco completely?
I guess we can put the closest possible value (127) so that the ssp
calculated by the IP is as close to the chosen one as possible.
>
>> + tdco);
>> + } else {
>> + enable_tdc = true;
>
> Why not set "reg_btp |= DBTP_TDC;" here directly?
>
>> + 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);
>
> Adjust this to "reg_btp |=".
>
>> +
>> + if (enable_tdc)
>> + reg_btp |= DBTP_TDC;
>
> Please remove.
Sure, will remove.
Thanks,
Faiz
next prev parent reply other threads:[~2018-01-03 12:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 13:31 [PATCH v6 0/6] Add M_CAN Support for Dra76 platform Faiz Abbas
[not found] ` <1513949488-13026-1-git-send-email-faiz_abbas-l0cyMroinI0@public.gmane.org>
2017-12-22 13:31 ` [PATCH v6 1/6] can: dev: Add support for limiting configured bitrate Faiz Abbas
2018-01-02 13:00 ` Marc Kleine-Budde
2018-01-03 12:19 ` Faiz Abbas
2018-01-02 16:15 ` Marc Kleine-Budde
[not found] ` <8d973da8-df40-e37e-377f-50666db382fe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2018-01-03 12:21 ` Faiz Abbas
2017-12-22 13:31 ` [PATCH v6 5/6] dt-bindings: can: m_can: Document new can transceiver binding Faiz Abbas
2017-12-22 13:31 ` [PATCH v6 2/6] can: m_can: Add call to of_can_transceiver Faiz Abbas
2017-12-22 13:31 ` [PATCH v6 3/6] can: m_can: Add PM Runtime Faiz Abbas
2018-01-02 16:07 ` Marc Kleine-Budde
[not found] ` <aea8638a-c847-b55e-ff2d-37999980ba7b-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2018-01-03 12:39 ` Faiz Abbas
[not found] ` <1308ee81-a1e9-ac5a-2d97-334fa825ef8d-l0cyMroinI0@public.gmane.org>
2018-01-03 14:25 ` Marc Kleine-Budde
2018-01-03 15:06 ` Faiz Abbas
2018-01-03 15:17 ` Marc Kleine-Budde
[not found] ` <cb306ae5-87c5-f6ef-0c40-3b47e208d256-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2018-01-04 15:17 ` Faiz Abbas
[not found] ` <6bdaab16-cb16-e039-473c-52dd295bd4ba-l0cyMroinI0@public.gmane.org>
2018-01-04 15:18 ` Marc Kleine-Budde
2018-01-05 1:23 ` Yang, Wenyou
2017-12-22 13:31 ` [PATCH v6 4/6] can: m_can: Support higher speed CAN-FD bitrates Faiz Abbas
2018-01-02 13:35 ` Marc Kleine-Budde
2018-01-03 12:55 ` Faiz Abbas [this message]
2017-12-22 13:31 ` [PATCH v6 6/6] dt-bindings: can: can-transceiver: Document new binding Faiz Abbas
2017-12-29 3:38 ` [PATCH v6 0/6] Add M_CAN Support for Dra76 platform Yang, Wenyou
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=dce9ff7d-239b-9ae3-a738-d4fec4249c86@ti.com \
--to=faiz_abbas@ti.com \
--cc=Wenyou.Yang@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=fcooper@ti.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=sergei.shtylyov@cogentembedded.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;
as well as URLs for NNTP newsgroup(s).