All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>,
	linux-can <linux-can@vger.kernel.org>,
	"Stefan Mätje" <stefan.maetje@esd.eu>,
	netdev <netdev@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 4/4] iplink_can: add new CAN FD bittiming parameters: Transmitter Delay Compensation (TDC)
Date: Tue, 17 Aug 2021 01:24:38 +0900	[thread overview]
Message-ID: <CAMZ6RqL8h5U+qZLS23PHCYNZ3Nq+9_sUQ5jTG=G0VRsaYXbbUQ@mail.gmail.com> (raw)
In-Reply-To: <20210816135113.gpk3fpafiqnhjbw4@pengutronix.de>

On Mon. 16 Aug. 2021 at 22:51, Marc Kleine-Budde <mkl@pengutronix.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.

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

  reply	other threads:[~2021-08-16 16:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-14 10:17 [PATCH v5 0/4] iplink_can: cleaning, fixes and adding TDC support Vincent Mailhol
2021-08-14 10:17 ` [PATCH v5 1/4] iplink_can: fix configuration ranges in print_usage() and add unit Vincent Mailhol
2021-08-14 10:17 ` [PATCH v5 2/4] iplink_can: use PRINT_ANY to factorize code and fix signedness Vincent Mailhol
2021-08-14 10:17 ` [PATCH v5 3/4] iplink_can: print brp and dbrp bittiming variables Vincent Mailhol
2021-08-14 10:17 ` [PATCH v5 4/4] iplink_can: add new CAN FD bittiming parameters: Transmitter Delay Compensation (TDC) Vincent Mailhol
2021-08-14 11:14   ` Marc Kleine-Budde
2021-08-16 11:02     ` Vincent MAILHOL
2021-08-16  8:12   ` Marc Kleine-Budde
2021-08-16 10:40     ` Vincent MAILHOL
2021-08-16 13:51   ` Marc Kleine-Budde
2021-08-16 16:24     ` Vincent MAILHOL [this message]
2021-08-16 23:59       ` Vincent MAILHOL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZ6RqL8h5U+qZLS23PHCYNZ3Nq+9_sUQ5jTG=G0VRsaYXbbUQ@mail.gmail.com' \
    --to=mailhol.vincent@wanadoo.fr \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=stefan.maetje@esd.eu \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.