summaryrefslogtreecommitdiffstats
path: root/net/can/bcm.c
diff options
context:
space:
mode:
authorJeroen Hofstee <jhofstee@victronenergy.com>2019-04-29 12:03:32 +0000
committerMarc Kleine-Budde <mkl@pengutronix.de>2019-07-24 10:31:55 +0200
commit4c7f715485159ab8a55b9471fc6fd75db51fd623 (patch)
tree5a357f464547eeb52ac49054c1a49c8ca7eb68cf /net/can/bcm.c
parent915f9666421cf65cc30668fd42760b6f78f9744d (diff)
downloadlinux-4c7f715485159ab8a55b9471fc6fd75db51fd623.tar.gz
linux-4c7f715485159ab8a55b9471fc6fd75db51fd623.tar.bz2
linux-4c7f715485159ab8a55b9471fc6fd75db51fd623.zip
can: ti_hecc: use timestamp based rx-offloading
As already mentioned in [1] and included in [2], there is an off by one issue since the high bank is already enabled when the _next_ mailbox to be read has index 12, so the mailbox being read was 13. The message can therefore go into mailbox 31 and the driver will be repolled until the mailbox 12 eventually receives a msg. Or the message might end up in the 12th mailbox, but then it would become disabled after reading it and only be enabled again in the next "round" after mailbox 13 was read, which can cause out of order messages, since the lower priority mailboxes can accept messages in the meantime. As mentioned in [3] there is a hardware race condition when changing the CANME register while messages are being received. Even when including a busy poll on reception, like in [2] there are still overflows and out of order messages at times, but less then without the busy loop polling. Unlike what the patch suggests, the polling time is not in the microsecond range, but takes as long as a current CAN bus reception needs to finish, so typically more in the fraction of millisecond range. Since the timeout is in jiffies it won't timeout. Even with these additional fixes the driver is still not able to provide a proper FIFO which doesn't drop packages. So change the driver to use rx-offload and base order on timestamp instead of message box numbers. As a side affect, this also fixes [4] and [5]. Before this change messages with a single byte counter were dropped / received out of order at a bitrate of 250kbit/s on an am3517. With this patch that no longer occurs up to and including 1Mbit/s. [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6 [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2 [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5 [4] https://patchwork.ozlabs.org/patch/895956/ [5] https://www.spinics.net/lists/netdev/msg494971.html Cc: Anant Gole <anantgole@ti.com> Cc: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Diffstat (limited to 'net/can/bcm.c')
0 files changed, 0 insertions, 0 deletions