From mboxrd@z Thu Jan 1 00:00:00 1970 From: kernel@martin.sperl.org Subject: Re: [PATCH 0/2] Microchip mcp2517fd can controller driver Date: Sun, 26 Nov 2017 19:29:43 +0100 Message-ID: References: <20171124183509.12810-1-kernel@martin.sperl.org> <3d355c51-09a3-40b8-46bf-8437e26a95f3@hartkopp.net> <263BAF25-3F9A-4BE8-8E19-757B3C22A037@martin.sperl.org> <0c2f4a35-3b86-7ae6-ccc6-2751fa92f497@grandegger.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: Received: from 212-186-180-163.static.upcbusiness.at ([212.186.180.163]:41552 "EHLO cgate.sperl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbdKZS3m (ORCPT ); Sun, 26 Nov 2017 13:29:42 -0500 In-Reply-To: <0c2f4a35-3b86-7ae6-ccc6-2751fa92f497@grandegger.com> Sender: linux-can-owner@vger.kernel.org List-ID: To: Wolfgang Grandegger Cc: Oliver Hartkopp , Marc Kleine-Budde , Rob Herring , Mark Rutland , linux-can@vger.kernel.org, devicetree@vger.kernel.org > On 26.11.2017, at 17:18, Wolfgang Grandegger wrote: > > Hello Martin, > > Am 25.11.2017 um 15:47 schrieb kernel@martin.sperl.org: > > ...snip... >> I see the following counters: >> 7: can0: mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 >> link/can promiscuity 0 >> can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 > > Why do you use "ONE_SHOT" in all your test cases? I did test oneshot and non-oneshot - I just did not document them here, I am just mentioning the issue of dropped frames when the driver is submitting them correctly. Also - for what it is worse - the RX case would not be impacted by one-shot enabled or not. > Did you also check for out-of-order issues, e.g. by using "canfdtest”? As for out of order: yes I have taken extreme care that we do not get out of order packets for all possible cases testing with cangen - there may be one error case where there could be an out of order case in the tx path (unless we want to drop that frame - it would be a MAB case) But until now I did not know about canfdtest, but for all practical purposes it can not test for out-of-order delivery on a 100% saturated bus the way it is working - latencies are too big for that! Still for completeness a quick test from beagleboneblack to a RPI CM3 with a mcp2517fd gives: root@beaglebone:~/can-utils# ./canfdtest -g -vvv can0 -l 32 interface = can0, family = 29, type = 3, proto = 1 0078: [8] 01 02 03 04 05 06 07 08 0078: [8] 02 03 04 05 06 07 08 09 0078: [8] 03 04 05 06 07 08 09 0a 0078: [8] 04 05 06 07 08 09 0a 0b 0078: [8] 05 06 07 08 09 0a 0b 0c 0078: [8] 06 07 08 09 0a 0b 0c 0d 0078: [8] 07 08 09 0a 0b 0c 0d 0e 0078: [8] 08 09 0a 0b 0c 0d 0e 0f 0078: [8] 09 0a 0b 0c 0d 0e 0f 10 0078: [8] 0a 0b 0c 0d 0e 0f 10 11 0078: [8] 0b 0c 0d 0e 0f 10 11 12 0078: [8] 0c 0d 0e 0f 10 11 12 13 0078: [8] 0d 0e 0f 10 11 12 13 14 0078: [8] 0e 0f 10 11 12 13 14 15 0078: [8] 0f 10 11 12 13 14 15 16 0078: [8] 10 11 12 13 14 15 16 17 0078: [8] 11 12 13 14 15 16 17 18 0078: [8] 12 13 14 15 16 17 18 19 0078: [8] 13 14 15 16 17 18 19 1a 0078: [8] 14 15 16 17 18 19 1a 1b 0078: [8] 15 16 17 18 19 1a 1b 1c 0078: [8] 16 17 18 19 1a 1b 1c 1d 0078: [8] 17 18 19 1a 1b 1c 1d 1e 0078: [8] 18 19 1a 1b 1c 1d 1e 1f 0078: [8] 19 1a 1b 1c 1d 1e 1f 20 0078: [8] 1a 1b 1c 1d 1e 1f 20 21 0078: [8] 1b 1c 1d 1e 1f 20 21 22 0078: [8] 1c 1d 1e 1f 20 21 22 23 0078: [8] 1d 1e 1f 20 21 22 23 24 0078: [8] 1e 1f 20 21 22 23 24 25 0078: [8] 1f 20 21 22 23 24 25 26 0078: [8] 20 21 22 23 24 25 26 27 Test messages sent and received: 32 (I can not go to longer tests because I may hit a bug I am just now trying to fix in the current code level). If you are interested in any more specific tests that I should be running, then please list those and I can report them when submitting V2 of the patch set. Just to put everything into perspective: The equipment available to me is: * beagle bone black with c_can * raspberry pi 3 with mcp2515 * raspberry pi CM3 with mcp2517fd * raspberry pi 2 with mcp2517fd * saleae logic analyzer Thanks, Martin