Netdev Archive on 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 08:59:54 +0900 [thread overview]
Message-ID: <CAMZ6RqJd7Mhg4sJnV+r_1bztiqLAS1oTTzg5cWWEpe4nnupXvw@mail.gmail.com> (raw)
In-Reply-To: <CAMZ6RqL8h5U+qZLS23PHCYNZ3Nq+9_sUQ5jTG=G0VRsaYXbbUQ@mail.gmail.com>
On Tue.17 Aug 2021 à 01:24, Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote:
> 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.
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
prev parent reply other threads:[~2021-08-17 0:00 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
2021-08-16 23:59 ` Vincent MAILHOL [this message]
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=CAMZ6RqJd7Mhg4sJnV+r_1bztiqLAS1oTTzg5cWWEpe4nnupXvw@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 \
--subject='Re: [PATCH v5 4/4] iplink_can: add new CAN FD bittiming parameters: Transmitter Delay Compensation (TDC)' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).