Date:   Tue, 17 Aug 2021 08:59:54 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        linux-can <linux-can@...r.kernel.org>,
        Stefan Mätje <stefan.maetje@....eu>,
        netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 4/4] iplink_can: add new CAN FD bittiming parameters:
 Transmitter Delay Compensation (TDC)

On Tue.17 Aug 2021 à 01:24, Vincent MAILHOL <mailhol.vincent@...adoo.fr> wrote:
> On Mon. 16 Aug. 2021 at 22:51, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> > On 14.08.2021 19:17:28, Vincent Mailhol wrote:
> > > 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).
>
> > >         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

Powered by blists - more mailing lists