Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

[Oliver Hartkopp]

Hi Kurt,

On 07/28/2017 09:41 PM, Kurt Van Dijck wrote:

> > The transceiver is an analog device that needs to support faster
> > switching frequency (FETs) including minimizing delay to support CAN-FD
> > ie higher bitrate. From the transceiver perspective the bits for
> > "arbitration" and "data" look exactly the same. Since it can't
> > differentiate between the two (at the physical layer) then the actual
> > limit isn't specific to which part/type of the CAN message is being
> > sent. Rather its just a single overall max bitrate limit.
>
> I must disagree here.
> The transceiver is an analog device that performs 2 functions:
> propagate tx bits to CAN wire, and propagate CAN wire state
> (dominant/recesive) to rx bits.
>
> I'll rephrase the above explanation to fit your argument:
> During arbitration, both directions are required, and needs to propagate
> within 1 bit time. The transceiver doesn't know, it just performs to
> best effort.
> During data, the round-trip timing requirement of layer2 is relaxed.
> The transceiver still doesn't know, it still performs to best effort.
> Due to the relaxed round-trip timing requirement, the same transceiver
> can suddenly allow higher bitrates. The transceiver didn't change, the
> requirement did change.
> This is what I meant earlier with "layer2 has been adapted to circumvent
> layer1 limitations"
>
> Was I successfull in transcoding my thoughts onto email :-) ?

Yes. But it's not relevant.

I talked to our CAN transceiver & CAN physical layer specialist who was 
involved in the ISO activities too.

We just need ONE value: max-bitrate

The CAN transceiver is qualified to provide this bitrate. That's it.
There's nothing special with the arbitration bitrate - we don't even 
need to outline any CAN FD capability.

The other things like 'loop delay compensation' are done in the CAN 
controller. The better the transceiver get's the bits 'in shape' the 
higher it can be qualified. But from the SoC/Controller/Linux view we 
only need the max-bitrate value to double check with the CAN controllers 
bitrate configuration request (which was Franklins intention).

Best regards,
Oliver