Re: [RFC] can: Introducing CANFD for af_can & can-raw

[Wolfgang Grandegger <wg@grandegger.com>]

On 03/22/2012 11:13 AM, Kurt Van Dijck wrote:
> On Thu, Mar 22, 2012 at 10:38:40AM +0100, Wolfgang Grandegger wrote:
>> On 03/22/2012 10:24 AM, Kurt Van Dijck wrote:
>>> On Wed, Mar 21, 2012 at 04:05:28PM +0100, Oliver Hartkopp wrote:
>>>> On 21.03.2012 15:56, Wolfgang Grandegger wrote:
>>>>
>>
>>>>>>> 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 doubt this.
>>> EFF & SFF share the same bus. CANFD vs. CAN2.0 is not a per-frame thing. You
>>> have configured it yourself at chip initialization time...
>>
>> Why not? A CANFD capable controller should be able to distinguish
>> between a legacy and a CANFD frame by looking to the BRS bit in the frame.
> Good point!

I got some more infos about the up-coming CAN FD controllers:

- There will be two sets of bit-timing configuration registers.

- They will have configuration bits to disable the FD functions. Then
  they will behave just like legacy CAN controllers. This can only be
  configured before going "bus on" ("clear init").

- When the FD function is enabled, *both* legacy CAN and FD frames
  will be accepted. The *TX* FD function must be enabled separately,
  otherwise legacy CAN frames will be sent. This can be changed while
  running (bus-on).

- This means, on a bus with only CAN FD controllers, both, legacy and FD
  frames can be sent and received. Not sure if that makes sense, though.

- The CAN FD format (DLC up to 64 bytes) and the bit-rate switching can
  be enabled *individually*.

- Per message, there will be three additional bits in the control field:

  - EDL bit: shows if the message is in the CAN FD format.
  - BRS bit: shows if the bit-rate was switched.
  - ESI bit: shows if the sender of the CAN FD-Frames was in error-
             active or error-passive state.

- The bits above need not be set for sending CAN FD frames as they are
  already defined by the selected TX FD modes.

- If EDL=1, DLC has a different meaning.

- RTR frames will always be send in the legacy format.

- Furthermore, there might also be cost-efficient CAN FD controller
  chips which only support 8 bytes per frame (instead of 64). The
  software needs to be aware of that.

See also:

- http://www.can-cia.org/fileadmin/cia/files/icc/13/hartwich.pdf
- http://www.can-cia.org/fileadmin/cia/files/icc/13/oertel.pdf

I think this makes a bit more clear what needs to be done to support CAN
FD on the protocol and driver level. My feeling is still that we should
add a new "struct canfd_frame", which the apps then can specify with
send and recv calls maintaining full backward with "struct can_frame".
For the RX path, skbs for either "canfd_frame" or "can_frame" shall be
allocated depending on the EDL bit (or DLC). We may also want to have an
interface for dynamic bit-rate switching.

Wolfgang.