Thread (12 messages) flat view 12 messages, 2 authors, 2021-08-17

Re: [PATCH v5 4/4] iplink_can: add new CAN FD bittiming parameters: Transmitter Delay Compensation (TDC)

From: Vincent MAILHOL <hidden>
Date: 2021-08-17 00:00:09
Also in: linux-can, lkml

On Tue.17 Aug 2021 à 01:24, Vincent MAILHOL [off-list ref] wrote:
On Mon. 16 Aug. 2021 at 22:51, Marc Kleine-Budde [off-list ref] wrote:
quoted
On 14.08.2021 19:17:28, Vincent Mailhol wrote:
quoted
At high bit rates, the propagation delay from the TX pin to the RX pin
of the transceiver causes measurement errors: the sample point on the
RX pin might occur on the previous bit.

This issue is addressed in ISO 11898-1 section 11.3.3 "Transmitter
delay compensation" (TDC).

This patch brings command line support to nine TDC parameters which
were recently added to the kernel's CAN netlink interface in order to
implement TDC:
  - IFLA_CAN_TDC_TDCV_MIN: Transmitter Delay Compensation Value
    minimum value
  - IFLA_CAN_TDC_TDCV_MAX: Transmitter Delay Compensation Value
    maximum value
  - IFLA_CAN_TDC_TDCO_MIN: Transmitter Delay Compensation Offset
    minimum value
  - IFLA_CAN_TDC_TDCO_MAX: Transmitter Delay Compensation Offset
    maximum value
  - IFLA_CAN_TDC_TDCF_MIN: Transmitter Delay Compensation Filter
    window minimum value
  - IFLA_CAN_TDC_TDCF_MAX: Transmitter Delay Compensation Filter
    window maximum value
  - IFLA_CAN_TDC_TDCV: Transmitter Delay Compensation Value
  - IFLA_CAN_TDC_TDCO: Transmitter Delay Compensation Offset
  - IFLA_CAN_TDC_TDCF: Transmitter Delay Compensation Filter window

All those new parameters are nested together into the attribute
IFLA_CAN_TDC.

A tdc-mode parameter allow to specify how to operate. Valid options
are:

  * auto: the transmitter automatically measures TDCV. As such, TDCV
    values can not be manually provided. In this mode, the user must
    specify TDCO and may also specify TDCF if supported.

  * manual: Use the TDCV value provided by the user are used. In this
    mode, the user must specify both TDCV and TDCO and may also
    specify TDCF if supported.

  * off: TDC is explicitly disabled.

  * tdc-mode parameter omitted (default mode): the kernel decides
    whether TDC should be enabled or not and if so, it calculates the
    TDC values. TDC parameters are an expert option and the average
    user is not expected to provide those, thus the presence of this
    "default mode".

TDCV is always reported in manual mode. In auto mode, TDCV is reported
only if the value is available. Especially, the TDCV might not be
available if the controller has no feature to report it or if the
value in not yet available (i.e. no data sent yet and measurement did
not occur).

TDCF is reported only if tdcf_max is not zero (i.e. if supported by the controller).

For reference, here are a few samples of how the output looks like:

$ ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on tdco 7 tdcf 8 tdc-mode auto

$ ip --details link show can0
1:  can0: <NOARP,ECHO> mtu 72 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <FD,TDC_AUTO> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
              ^^^^^^^^
This is just the supported mode(s), right?
No, this is the active mode. It should display either TDC_AUTO or
TDC_MANUAL. If both are displayed as you previously experienced,
it is a bug (I will fix).
quoted
quoted
        bitrate 1000000 sample-point 0.750
        tq 12 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 brp 1
        ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
        dbitrate 8000000 dsample-point 0.700
        dtq 12 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1 dbrp 1
        tdco 7 tdcf 8
        ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp_inc 1
        tdco 0..127 tdcf 0..127
        clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Is there a way to figure out, which tdc mode is currently active?

AFAICS just implicitly:
- tdco + tdcv   -> manual
- tdco          -> automatic
- neither       -> off

correct?
If the TDC const values are reported (at least tdco) the controller
supports TDC.

The flags listed between brackets <FD, TDC_AUTO, CC-LEN8-DLC, ...>
are the active flags (this is not only true for TDC but also for
all other ctrlmodes).

There is no way to know which of the modes are supported. The
reason is that netlink only reports
can_priv->ctrlmode (c.f. IFLA_CAN_CTRLMODE), not
can_priv->ctrlmode_supported. We would need to add a
IFLA_CAN_CTRLMODE_SUPPORTED to the netlink interface in order to
confirm the supported mode.
On a second thought, it is actually possible to deduce some of
the supported modes (not all) through the can_tdc_const values
because tdcv_{min,max} are only reported if
CAN_CTRLMODE_TDC_MANUAL is supported.
So:

  - both tdcv_{min,max} and tdco_{min,max} reported ->
    CAN_CTRLMODE_TDC_MANUAL is supported for
    sure. CAN_CTRLMODE_TDC_AUTO might or might not be supported.

  - only tdco_{min,max} reported -> only CAN_CTRLMODE_TDC_AUTO is
    supported (that's the case for the es58x device).

  - none reported -> device is not TDC capable.

  - tdcf_{min,max} reported -> device supports TDCF and the
    reverse is also true.

  - other combinations are incorrect and should not be reported.
Currently, the only ways are to either look at the kernel source
code or to test the command and see whether it is supported or
not.


Yours sincerely,
Vincent
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help