> 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" > > > 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). I bet your physical layer specialist understands the details way better than I do :-) 1 value it is then. Kind regards, Kurt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
