netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dong Aisheng <b29396@freescale.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
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: Wed, 5 Nov 2014 10:03:25 +0800	[thread overview]
Message-ID: <20141105020322.GA18982@shlinux1.ap.freescale.net> (raw)
In-Reply-To: <5458AB65.7000500@pengutronix.de>

On Tue, Nov 04, 2014 at 11:33:09AM +0100, Marc Kleine-Budde wrote:
> 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.
> 

Looks good.
Will do like that.

> > +        * 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?
> 

No, i did not see the issue with dlc > 8 && dlc < 64.

Regards
Dong Aisheng
> 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   |
> 



  parent reply	other threads:[~2014-11-05  2:03 UTC|newest]

Thread overview: 32+ 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 ` [PATCH 2/7] can: m_can: fix the incorrect error messages Dong Aisheng
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-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-11-03 16:52   ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 5/7] can: clear ctrlmode when close candev Dong Aisheng
2014-11-03 16:28   ` Marc Kleine-Budde
2014-11-03 18:25     ` Oliver Hartkopp
2014-11-03 20:47   ` Marc Kleine-Budde
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 19:21   ` Oliver Hartkopp
2014-10-30  2:42     ` Dong Aisheng
2014-10-30 20:32       ` Oliver Hartkopp
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-11-03 16:48   ` Marc Kleine-Budde
2014-11-04  8:25     ` Dong Aisheng
2014-11-04  9:22       ` Marc Kleine-Budde
2014-11-04  9:27         ` Dong Aisheng
2014-11-04 10:33           ` Marc Kleine-Budde
2014-11-04 13:13             ` Oliver Hartkopp
2014-11-04 13:28               ` Marc Kleine-Budde
2014-11-05  2:07               ` Dong Aisheng
2014-11-05  2:03             ` Dong Aisheng [this message]
2014-11-03 16:24 ` [PATCH 1/7] can: m_can: fix possible sleep in napi poll Marc Kleine-Budde
2014-11-03 17:02 ` Marc Kleine-Budde
2014-11-03 18:37   ` Oliver Hartkopp
2014-11-03 20:49     ` Marc Kleine-Budde
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=20141105020322.GA18982@shlinux1.ap.freescale.net \
    --to=b29396@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --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 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).