Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700204

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> - 2017-07-28 15:10 +0200
  Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Oliver Hartkopp <socketcan@hartkopp.net> - 2017-07-28 20:40 +0200
    Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Franklin S Cooper Jr <fcooper@ti.com> - 2017-07-28 21:00 +0200
      Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> - 2017-07-28 21:50 +0200
        Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Oliver Hartkopp <socketcan@hartkopp.net> - 2017-07-31 19:10 +0200
          Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> - 2017-08-01 09:20 +0200

csiph-web