Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbdG1ND6 (ORCPT ); Fri, 28 Jul 2017 09:03:58 -0400 Received: from relay-b01.edpnet.be ([212.71.1.221]:40156 "EHLO relay-b01.edpnet.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751822AbdG1NDz (ORCPT ); Fri, 28 Jul 2017 09:03:55 -0400 X-ASG-Debug-ID: 1501247033-0a7ff55c34e4a190001-xx1T2L X-Barracuda-Envelope-From: dev.kurt@vandijck-laurijssen.be X-Barracuda-Effective-Source-IP: 77.109.102.73.adsl.dyn.edpnet.net[77.109.102.73] X-Barracuda-Apparent-Source-IP: 77.109.102.73 Date: Fri, 28 Jul 2017 15:02:31 +0200 From: Kurt Van Dijck To: Oliver Hartkopp Cc: Franklin S Cooper Jr , Andrew Lunn , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-can@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de, robh+dt@kernel.org, quentin.schulz@free-electrons.com, sergei.shtylyov@cogentembedded.com Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Message-ID: <20170728130231.GA10680@airbook.vandijck-laurijssen.be> X-ASG-Orig-Subj: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Mail-Followup-To: Oliver Hartkopp , Franklin S Cooper Jr , Andrew Lunn , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-can@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de, robh+dt@kernel.org, quentin.schulz@free-electrons.com, sergei.shtylyov@cogentembedded.com MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Barracuda-Connect: 77.109.102.73.adsl.dyn.edpnet.net[77.109.102.73] X-Barracuda-Start-Time: 1501247033 X-Barracuda-URL: https://212.71.1.221:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 2353 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.41407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2295 Lines: 58 > > On 07/28/2017 06:57 AM, Kurt Van Dijck wrote: > > >So while _a_ transceiver may be spec'd to 1MBit during arbitration, > >CAN FD packets may IMHO exceed that speed during data phase. > > When the bitrate is limited to 1Mbit/s you are ONLY allowed to use 1Mbit/s > in the data section too (either with CAN or CAN FD). My point is that the requirements posed to a transceiver differ between arbitration & data phase for CAN FD. So while a transceiver does not know about CAN FD, it may allow higher bitrates for the data phase. > > >That was the whole point of CAN FD: exceed the limits required for > >correct arbitration on transceiver & wire. > > No. CAN FD is about a different frame format with up to 64 bytes AND the > possibility to increase the bitrate in the data section of the frame. > > >So I do not agree on the single bandwidth limitation. > > The transceiver provides a single maximum bandwidth. It's an ISO Layer 1 > device. > > >The word 'max-arbitration-bitrate' makes the difference very clear. > > I think you are mixing up ISO layer 1 and ISO layer 2. In order to provide higher data throughput without putting extra limits on transceiver & wire, the requirement for the round-trip delay to be within 1 bittime has been eliminated, but only for the data phase when arbitration is over. So layer 2 (CAN FD) has been adapted to circumvent the layer 1 (transceiver + wire) limitations. In fact, the round-trip delay requirement never actually did matter for plain CAN during data bits either. CAN FD just makes use of that, but is therefore incompatible on the wire. I forgot the precise wording, but this is the principle that Bosch explained on the CAN conference in Nurnberg several years ago, or at least this is how I remembered it :-) I haven't followed the developments of transceivers, but with the above principle in mind, it's obvious that any transceiver allows higher bitrates during the data segment because the TX-to-RX line delay must not scale with the bitrate. In reality, maybe not all transceivers will mention this in their datasheet. So whether you call it 'max-arbitration-bitrate' & 'max-data-bitrate' or 'max-bitrate' & 'max-data-bitrate' does not really matter (I prefer 1st) but you will one day need 2 bitrates. Kind regards, Kurt