From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Hartkopp Subject: Re: [RFC] can: Introducing CANFD for af_can & can-raw Date: Wed, 21 Mar 2012 16:05:28 +0100 Message-ID: <4F69EE38.9000904@hartkopp.net> References: <20120321091055.GA433@vandijck-laurijssen.be> <20120321110502.GA3372@vandijck-laurijssen.be> <4F69BEE3.2040705@pengutronix.de> <20120321120846.GB3372@vandijck-laurijssen.be> <4F69CA74.3020607@pengutronix.de> <4F69D5D2.5080003@hartkopp.net> <20120321135339.GB6428@vandijck-laurijssen.be> <4F69EC19.7090205@grandegger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mo-p00-ob.rzone.de ([81.169.146.162]:18497 "EHLO mo-p00-ob.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756936Ab2CUPFc (ORCPT ); Wed, 21 Mar 2012 11:05:32 -0400 In-Reply-To: <4F69EC19.7090205@grandegger.com> Sender: linux-can-owner@vger.kernel.org List-ID: To: Wolfgang Grandegger Cc: Marc Kleine-Budde , dev@sebastianhaas.info, linux-can@vger.kernel.org On 21.03.2012 15:56, Wolfgang Grandegger wrote: > Hi, > > > As I see it, the main difference to standard CAN is the bit-rate > switching for transferring just the data bytes using alternate > bit-timing parameters. Yes. You have two sets of bittiming registers one for the normal operation and for arbitration and the second for the data &crc section in the case of enabled FD mode. And in the FD mode you have up to 64 byte payload. >> I think of some differences: >> * no RTR allowed. >> * ESI bit. > > Also DLC=9 means 12 bytes, DLC=10 means 16 bytes, DLC=15 means 64 bytes. > This may even change in the final spec. Yep! > >>> 3. Will these differences be visible in the CAN registers? Is this relevant? >> Without hardware, it's a bit early to predict. I guess it will be visible, but >> not relevant since that's driver stuff. > > As CANFD controllers also supports CAN2.0 frames, they must provide the > the relevant information somehow, similar to EFF and SFF. > >> I did not get into real drivers yet... >>> >>> What i got from the iCC was that when you have a partly migrated network and >>> you want to run e.g. a fast firmware upload between two CAN FD capable nodes, >>> the other (standard CAN 2.0b) nodes have to be in listen only mode to not jam >>> the bus with error frames. > > Due to the bit-rate switching, a assume. Yes - the 'old' controllers would put error frames on the fast payload data. > >>> After the firmware upload all the CAN nodes switch back to CAN2.0b mode (which >>> has to be done by root netlink access). >> Since CANFD is not bus compatible, the chip must go down & up. It really depends >> on the chips & drivers to combine CAN2.0 & CANFD. >> As Marc already suggested, CANFD could be a ctrlmode. > > I also see this problem. > >>> IMO we need to introduce a new struct canfd_frame >> IMO we need not to introduce a new struct since they are logically equivalent. >> >> I created an old can20b_frame just to compute the sizeof. >> I'd go for a combined can_frame that could hold both. > > Well, I see it as an extension of the standard CAN and therefore I was > also thinking about an extra "struct canfd_frame". The size is more than > 3 times larger and we may only allocate the extra space if it's really > required. I'm also thinking about the impact on queues, etc. Yes. Additionally we need to have a proper distinction between can_frame and canfd_frame when we play with recvmmsg in the future. > >>> It should be no problem to move to canfd_frame inside the kernel but if we >>> come to the point that we get to the userspace ABI there should be no tricky >>> way to check lengths or flags or return values are are not needed to be >>> checked with the current ABI now. >>> >>> When there's a defined socket API that makes use of struct can_frame (like >>> can_raw, can_bcm, can_gw - but not isotp! \o/ ) we need to >>> >>> - duplicate the socket API - like CAN_RAWFD (ugly) >>> - switch the frame size (e.g. via sockopt) >>> - a third unknown idea ... >> When you look at my patch, you can see that only a recompile of candump with >> the bigger can_frame is all what is between me and a virtual CANFD bus. >> Candump does not really need to care about the CANFD mode. >> I think it can do both types of busses as in >> >> $ candump any > > Well, candump is a simple application and it does not really care about > the payload. This is different for real legacy application, I think, > which assumes a payload of 8 bytes only. My words :-) > >>> E.g. when having a CAN FD aware candump/cansend application, it can try to >>> switch the socket to CAN FD. >> Since CANFD is a different bus, selecting a bus (like 'can0') implicetely selects >> the CANFD mode. IMHO, from that point on, there's no difference for candump with >> a legacy CAN2.0 bus. So why make things complicated. > > See above. Also, I think CANFD has been invented to support a fast > transfer mode for special purposes which will be selected from time to > time making the bus incompatible with legacy CAN controllers. > When you have an entire CAN bus where all nodes support CAN FD this is nice also. But the current implementation will remain the standard for years too. >>> on an older kernel that does not support CAN FD ... >>> >>> I think it's much more tricky to find a proper solution here. >> As I mentioned before, I just use CAN_RAW with this. Actually, I just >> ran a real CAN program that I wrote years ago. It still operates! > > Would you program still run if the payload is bigger than 8 bytes? > I agree with Oliver. puh. Time for a coffee :-) Regards, Oliver