All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Dong Aisheng <b29396@freescale.com>
Cc: linux-can@vger.kernel.org, wg@grandegger.com,
	varkabhadram@gmail.com, netdev@vger.kernel.org,
	socketcan@hartkopp.net, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
Date: Tue, 04 Nov 2014 11:33:09 +0100	[thread overview]
Message-ID: <5458AB65.7000500@pengutronix.de> (raw)
In-Reply-To: <20141104092651.GC8060@shlinux1.ap.freescale.net>

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>>>> It should be possible to change the for loop to go always to 8, or
>>>> simply unroll the loop:
>>>>
>>>> /* errata description goes here */
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>>>
>>>
>>> Yes, i tried to fix it as follows.
>>>
>>> /* FIXME: we meet an IC issue that we have to write the full 8
>>>  * bytes (whatever value for the second word) in Message RAM to
>>>  * avoid bit error for transmit data less than 4 bytes
>>>  */
>>> if (cf->len <= 4) {
>>>         m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
>>>                          *(u32 *)(cf->data + 0));
>>>         m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
>>>                          *(u32 *)(cf->data + 4));
>>> } else {
>>>         for (i = 0; i < cf->len; i += 4)
>>>                 m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
>>>                                  *(u32 *)(cf->data + i));
>>>
>>> Will update the patch.
>>
>> Both branches of the above if are doing the same thing, I think you can
>> replace the while if ... else ... for with this:
>>
> 
> Not the same thing.
> The later one will cover payload up to 64 bytes.

Doh! I'm not used to CAN-FD, yet :) However, I'll apply this fix before
adding the CAN-FD support.

>> /* errata description goes here */
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>
>> However if writing to DATA(0) and DATA(1) once in the open() function is
>> enough this code should stay as it is.
> 
> I tried put them into open() function and the quick test showed it worked.
> 
> Do you think it's ok to put things into open() function for this issue
> as follows?
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 065e4f1..ca55988 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)
>         /* set bittiming params */
>         m_can_set_bittiming(dev);
> 
> +       /* We meet an IC issue that we have to write the full 8

At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.

> +        * bytes (whatever value for the second word) in Message RAM to
> +        * avoid bit error for transmit data less than 4 bytes at the first
> +        * time. By initializing the first 8 bytes of tx buffer before using
> +        * it can avoid such issue.
> +        */
> +       m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
> +       m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
> +
>         m_can_config_endisable(priv, false);
>  }

Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?

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: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: mkl@pengutronix.de (Marc Kleine-Budde)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
Date: Tue, 04 Nov 2014 11:33:09 +0100	[thread overview]
Message-ID: <5458AB65.7000500@pengutronix.de> (raw)
In-Reply-To: <20141104092651.GC8060@shlinux1.ap.freescale.net>

On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>>>> It should be possible to change the for loop to go always to 8, or
>>>> simply unroll the loop:
>>>>
>>>> /* errata description goes here */
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>>>
>>>
>>> Yes, i tried to fix it as follows.
>>>
>>> /* FIXME: we meet an IC issue that we have to write the full 8
>>>  * bytes (whatever value for the second word) in Message RAM to
>>>  * avoid bit error for transmit data less than 4 bytes
>>>  */
>>> if (cf->len <= 4) {
>>>         m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
>>>                          *(u32 *)(cf->data + 0));
>>>         m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
>>>                          *(u32 *)(cf->data + 4));
>>> } else {
>>>         for (i = 0; i < cf->len; i += 4)
>>>                 m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
>>>                                  *(u32 *)(cf->data + i));
>>>
>>> Will update the patch.
>>
>> Both branches of the above if are doing the same thing, I think you can
>> replace the while if ... else ... for with this:
>>
> 
> Not the same thing.
> The later one will cover payload up to 64 bytes.

Doh! I'm not used to CAN-FD, yet :) However, I'll apply this fix before
adding the CAN-FD support.

>> /* errata description goes here */
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>
>> However if writing to DATA(0) and DATA(1) once in the open() function is
>> enough this code should stay as it is.
> 
> I tried put them into open() function and the quick test showed it worked.
> 
> Do you think it's ok to put things into open() function for this issue
> as follows?
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 065e4f1..ca55988 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)
>         /* set bittiming params */
>         m_can_set_bittiming(dev);
> 
> +       /* We meet an IC issue that we have to write the full 8

At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.

> +        * bytes (whatever value for the second word) in Message RAM to
> +        * avoid bit error for transmit data less than 4 bytes at the first
> +        * time. By initializing the first 8 bytes of tx buffer before using
> +        * it can avoid such issue.
> +        */
> +       m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
> +       m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
> +
>         m_can_config_endisable(priv, false);
>  }

Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?

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   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141104/f4b29b02/attachment-0001.sig>

  reply	other threads:[~2014-11-04 10:33 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-29 10:45 [PATCH 1/7] can: m_can: fix possible sleep in napi poll Dong Aisheng
2014-10-29 10:45 ` Dong Aisheng
2014-10-29 10:45 ` Dong Aisheng
2014-10-29 10:45 ` [PATCH 2/7] can: m_can: fix the incorrect error messages Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-11-03 16:25   ` Marc Kleine-Budde
2014-11-03 16:25     ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 3/7] can: m_can: add .ndo_change_mtu function Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-11-03 16:49   ` Marc Kleine-Budde
2014-11-03 16:49     ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 4/7] can: m_can: add a bit delay after setting CCCR_INIT bit Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-11-03 16:52   ` Marc Kleine-Budde
2014-11-03 16:52     ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 5/7] can: clear ctrlmode when close candev Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-11-03 16:28   ` Marc Kleine-Budde
2014-11-03 16:28     ` Marc Kleine-Budde
2014-11-03 16:28     ` Marc Kleine-Budde
2014-11-03 18:25     ` Oliver Hartkopp
2014-11-03 18:25       ` Oliver Hartkopp
2014-11-03 18:25       ` Oliver Hartkopp
2014-11-03 20:47   ` Marc Kleine-Budde
2014-11-03 20:47     ` Marc Kleine-Budde
2014-11-04  8:27     ` Dong Aisheng
2014-11-04  8:27       ` Dong Aisheng
2014-11-04  8:27       ` Dong Aisheng
2014-10-29 10:45 ` [PATCH 6/7] can: m_can: update to support CAN FD features Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 19:21   ` Oliver Hartkopp
2014-10-29 19:21     ` Oliver Hartkopp
2014-10-30  2:42     ` Dong Aisheng
2014-10-30  2:42       ` Dong Aisheng
2014-10-30  2:42       ` Dong Aisheng
2014-10-30 20:32       ` Oliver Hartkopp
2014-10-30 20:32         ` Oliver Hartkopp
2014-11-04  7:12         ` Dong Aisheng
2014-11-04  7:12           ` Dong Aisheng
2014-10-29 10:45 ` [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-10-29 10:45   ` Dong Aisheng
2014-11-03 16:48   ` Marc Kleine-Budde
2014-11-03 16:48     ` Marc Kleine-Budde
2014-11-04  8:25     ` Dong Aisheng
2014-11-04  8:25       ` Dong Aisheng
2014-11-04  8:25       ` Dong Aisheng
2014-11-04  9:22       ` Marc Kleine-Budde
2014-11-04  9:22         ` Marc Kleine-Budde
2014-11-04  9:27         ` Dong Aisheng
2014-11-04  9:27           ` Dong Aisheng
2014-11-04  9:27           ` Dong Aisheng
2014-11-04 10:33           ` Marc Kleine-Budde [this message]
2014-11-04 10:33             ` Marc Kleine-Budde
2014-11-04 13:13             ` Oliver Hartkopp
2014-11-04 13:13               ` Oliver Hartkopp
2014-11-04 13:28               ` Marc Kleine-Budde
2014-11-04 13:28                 ` Marc Kleine-Budde
2014-11-05  2:07               ` Dong Aisheng
2014-11-05  2:07                 ` Dong Aisheng
2014-11-05  2:07                 ` Dong Aisheng
2014-11-05  2:03             ` Dong Aisheng
2014-11-05  2:03               ` Dong Aisheng
2014-11-05  2:03               ` Dong Aisheng
2014-11-03 16:24 ` [PATCH 1/7] can: m_can: fix possible sleep in napi poll Marc Kleine-Budde
2014-11-03 16:24   ` Marc Kleine-Budde
2014-11-03 17:02 ` Marc Kleine-Budde
2014-11-03 17:02   ` Marc Kleine-Budde
2014-11-03 18:37   ` Oliver Hartkopp
2014-11-03 18:37     ` Oliver Hartkopp
2014-11-03 20:49     ` Marc Kleine-Budde
2014-11-03 20:49       ` Marc Kleine-Budde
2014-11-03 21:12       ` Oliver Hartkopp
2014-11-03 21:12         ` Oliver Hartkopp

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=5458AB65.7000500@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=b29396@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    --cc=varkabhadram@gmail.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 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.