[v5,2/7] can: bittiming: allow TDC{V,O} to be zero and add can_tdc_const::tdc{v,o,f}_min

Commit Message

Vincent Mailhol Aug. 15, 2021, 3:32 a.m. UTC

ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
compensation" that "the configuration range for [the] SSP position
shall be at least 0 to 63 minimum time quanta."

Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
TDCO to hold zero value in order to honor SSP's minimum possible
value.

However, current implementation assigned special meaning to TDCV and
TDCO's zero values:
  * TDCV = 0 -> TDCV is automatically measured by the transceiver.
  * TDCO = 0 -> TDC is off.

In order to allow for those values to really be zero and to maintain
current features, we introduce two new flags:
  * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
    automatic measurement of TDCV.
  * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
    manual configuration of TDCV. N.B.: current implementation failed
    to provide an option for the driver to indicate that only manual
    mode was supported.

TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
can_tdc_is_enabled() which is also introduced in this patch.

Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
struct can_tdc_const. While we are not convinced that those three
fields could be anything else than zero, we can imagine that some
controllers might specify a lower bound on these. Thus, those minimums
are really added "just in case".

Comments of struct can_tdc and can_tdc_const are updated accordingly.

Finally, the changes are applied to the etas_es58x driver.

Signed-off-by: Vincent Mailhol <[e-mail]>
---
 drivers/net/can/dev/bittiming.c           | 10 ++--
 drivers/net/can/usb/etas_es58x/es58x_fd.c |  7 ++-
 include/linux/can/bittiming.h             | 64 +++++++++++++++++------
 include/linux/can/dev.h                   |  4 ++
 include/uapi/linux/can/netlink.h          |  2 +
 5 files changed, 65 insertions(+), 22 deletions(-)

Comments

Marc Kleine-Budde Aug. 16, 2021, 8:42 a.m. UTC | #1

On 15.08.2021 12:32:43, Vincent Mailhol wrote:
> ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
> compensation" that "the configuration range for [the] SSP position
> shall be at least 0 to 63 minimum time quanta."
> 
> Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
> TDCO to hold zero value in order to honor SSP's minimum possible
> value.
> 
> However, current implementation assigned special meaning to TDCV and
> TDCO's zero values:
>   * TDCV = 0 -> TDCV is automatically measured by the transceiver.
>   * TDCO = 0 -> TDC is off.
> 
> In order to allow for those values to really be zero and to maintain
> current features, we introduce two new flags:
>   * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
>     automatic measurement of TDCV.
>   * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
>     manual configuration of TDCV. N.B.: current implementation failed
>     to provide an option for the driver to indicate that only manual
>     mode was supported.
> 
> TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
> CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
> can_tdc_is_enabled() which is also introduced in this patch.

Nitpick: We can only say that TDC is disabled, if the driver supports
the TDC interface at all, which is the case if tdc_const is set.

> Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
> struct can_tdc_const. While we are not convinced that those three
> fields could be anything else than zero, we can imagine that some
> controllers might specify a lower bound on these. Thus, those minimums
> are really added "just in case".

I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
-64...63.

Marc

Vincent Mailhol Aug. 16, 2021, 10:24 a.m. UTC | #2

On Mon. 16 Aug 2021 at 17:42, Marc Kleine-Budde <[e-mail]> wrote:
> On 15.08.2021 12:32:43, Vincent Mailhol wrote:
> > ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
> > compensation" that "the configuration range for [the] SSP position
> > shall be at least 0 to 63 minimum time quanta."
> >
> > Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
> > TDCO to hold zero value in order to honor SSP's minimum possible
> > value.
> >
> > However, current implementation assigned special meaning to TDCV and
> > TDCO's zero values:
> >   * TDCV = 0 -> TDCV is automatically measured by the transceiver.
> >   * TDCO = 0 -> TDC is off.
> >
> > In order to allow for those values to really be zero and to maintain
> > current features, we introduce two new flags:
> >   * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
> >     automatic measurement of TDCV.
> >   * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
> >     manual configuration of TDCV. N.B.: current implementation failed
> >     to provide an option for the driver to indicate that only manual
> >     mode was supported.
> >
> > TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
> > CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
> > can_tdc_is_enabled() which is also introduced in this patch.
>
> Nitpick: We can only say that TDC is disabled, if the driver supports
> the TDC interface at all, which is the case if tdc_const is set.

I would argue that saying that a device does not support TDC is
equivalent to saying that TDC is always disabled for that device.
Especially, the function can_tdc_is_enabled() can be used even if
the device does not support TDC (even if there is no benefit
doing so).

Do you still want me to rephrase this part?

> > Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
> > struct can_tdc_const. While we are not convinced that those three
> > fields could be anything else than zero, we can imagine that some
> > controllers might specify a lower bound on these. Thus, those minimums
> > are really added "just in case".
>
> I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> -64...63.

Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
value which is relative to the sample point.
| SSP = TDCV + absolute TDCO
|     = TDCV + SP + relative TDCO

Consequently:
| relative TDCO = absolute TDCO - SP

Which is also why TDCO can be negative.

I added an helper function can_tdc_get_relative_tdco() in the
fourth path of this series:
https://lore.kernel.org/linux-can/[e-mail]/T/#u

Devices which use the absolute TDCO can directly use
can_priv->tdc.tdco. Devices which use the relative TDCO such as
the mcp251xfd should use this helper function instead.

However, you will still need to convert the TDCO valid range from
relative values to absolute ones. In your case 0..127.


Yours sincerely,
Vincent

Marc Kleine-Budde Aug. 16, 2021, 12:25 p.m. UTC | #3

On 16.08.2021 19:24:43, Vincent MAILHOL wrote:
> On Mon. 16 Aug 2021 at 17:42, Marc Kleine-Budde <[e-mail]> wrote:
> > On 15.08.2021 12:32:43, Vincent Mailhol wrote:
> > > ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
> > > compensation" that "the configuration range for [the] SSP position
> > > shall be at least 0 to 63 minimum time quanta."
> > >
> > > Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
> > > TDCO to hold zero value in order to honor SSP's minimum possible
> > > value.
> > >
> > > However, current implementation assigned special meaning to TDCV and
> > > TDCO's zero values:
> > >   * TDCV = 0 -> TDCV is automatically measured by the transceiver.
> > >   * TDCO = 0 -> TDC is off.
> > >
> > > In order to allow for those values to really be zero and to maintain
> > > current features, we introduce two new flags:
> > >   * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
> > >     automatic measurement of TDCV.
> > >   * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
> > >     manual configuration of TDCV. N.B.: current implementation failed
> > >     to provide an option for the driver to indicate that only manual
> > >     mode was supported.
> > >
> > > TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
> > > CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
> > > can_tdc_is_enabled() which is also introduced in this patch.
> >
> > Nitpick: We can only say that TDC is disabled, if the driver supports
> > the TDC interface at all, which is the case if tdc_const is set.
> 
> I would argue that saying that a device does not support TDC is
> equivalent to saying that TDC is always disabled for that device.
> Especially, the function can_tdc_is_enabled() can be used even if
> the device does not support TDC (even if there is no benefit
> doing so).
> 
> Do you still want me to rephrase this part?
> 
> > > Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
> > > struct can_tdc_const. While we are not convinced that those three
> > > fields could be anything else than zero, we can imagine that some
> > > controllers might specify a lower bound on these. Thus, those minimums
> > > are really added "just in case".
> >
> > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > -64...63.
> 
> Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> value which is relative to the sample point.

I don't read the documentation this way....

> | SSP = TDCV + absolute TDCO
> |     = TDCV + SP + relative TDCO
> 
> Consequently:
> | relative TDCO = absolute TDCO - SP

In the mcp15xxfd family manual
(http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:

| DTSEG1  15 DTQ
| DTSEG2   4 DTQ
| TDCO    15 DTQ

The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
tseg1, which is correct), and relative tdco would be 0:

| mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0

Here the output with the patched ip tool:

| 4: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
|     link/can  promiscuity 0 minmtu 0 maxmtu 0 
|     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100 
|           bitrate 500000 sample-point 0.875
|           tq 25 prop-seg 34 phase-seg1 35 phase-seg2 10 sjw 1 brp 1
|           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
|           dbitrate 2000000 dsample-point 0.750
|           dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1 dbrp 1
|           tdco 15
|           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
|           tdco 0..127
|           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0


> Which is also why TDCO can be negative.
> 
> I added an helper function can_tdc_get_relative_tdco() in the
> fourth path of this series:
> https://lore.kernel.org/linux-can/[e-mail]/T/#u
> 
> Devices which use the absolute TDCO can directly use
> can_priv->tdc.tdco. Devices which use the relative TDCO such as
> the mcp251xfd should use this helper function instead.

Don't think so....

> However, you will still need to convert the TDCO valid range from
> relative values to absolute ones. In your case 0..127.

Marc

Marc Kleine-Budde Aug. 16, 2021, 12:33 p.m. UTC | #4

On 16.08.2021 14:25:19, Marc Kleine-Budde wrote:
> > > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > > -64...63.
> > 
> > Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> > value which is relative to the sample point.
> 
> I don't read the documentation this way....
> 
> > | SSP = TDCV + absolute TDCO
> > |     = TDCV + SP + relative TDCO
> > 
> > Consequently:
> > | relative TDCO = absolute TDCO - SP
> 
> In the mcp15xxfd family manual
> (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
> in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:
> 
> | DTSEG1  15 DTQ
> | DTSEG2   4 DTQ
> | TDCO    15 DTQ
> 
> The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
> tseg1, which is correct), and relative tdco would be 0:
> 
> | mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0
> 
> Here the output with the patched ip tool:

Sorry, the previous output was not using the sample points of the
example in the data sheet, this is the fixed output:

| 6: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
|     link/can  promiscuity 0 minmtu 0 maxmtu 0 
|     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100 
|           bitrate 500000 sample-point 0.800
|           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
|           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
|           dbitrate 2000000 dsample-point 0.800
|           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
|           tdco 16
|           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
|           tdco 0..127
|           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0 

Marc

Marc Kleine-Budde Aug. 16, 2021, 1:43 p.m. UTC | #5

On 16.08.2021 14:33:09, Marc Kleine-Budde wrote:
> On 16.08.2021 14:25:19, Marc Kleine-Budde wrote:
> > > > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > > > -64...63.
> > > 
> > > Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> > > value which is relative to the sample point.
> > 
> > I don't read the documentation this way....
> > 
> > > | SSP = TDCV + absolute TDCO
> > > |     = TDCV + SP + relative TDCO
> > > 
> > > Consequently:
> > > | relative TDCO = absolute TDCO - SP
> > 
> > In the mcp15xxfd family manual
> > (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
> > in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:
> > 
> > | DTSEG1  15 DTQ
> > | DTSEG2   4 DTQ
> > | TDCO    15 DTQ
> > 
> > The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
> > tseg1, which is correct), and relative tdco would be 0:
> > 
> > | mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0
> > 
> > Here the output with the patched ip tool:
> 
> Sorry, the previous output was not using the sample points of the
> example in the data sheet, this is the fixed output:
> 
> | 6: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> |     link/can  promiscuity 0 minmtu 0 maxmtu 0 
> |     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100 
> |           bitrate 500000 sample-point 0.800
> |           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
> |           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> |           dbitrate 2000000 dsample-point 0.800
> |           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
> |           tdco 16
> |           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> |           tdco 0..127
> |           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0 

The following sequence doesn't clear "tdcv" properly:

| ip link set dev mcp251xfd0 down; \
| ip link set mcp251xfd0 txqueuelen 10 up type can \
|     sample-point 0.8 bitrate 500000  \
|     dsample-point 0.8 dbitrate 2000000 fd on \
|     tdc-mode manual tdco 11 tdcv 22
| 
| ip link set dev mcp251xfd0 down; \
| ip link set mcp251xfd0 txqueuelen 10 up type can \
|     sample-point 0.8 bitrate 500000  \
|     dsample-point 0.8 dbitrate 2000000 fd on

| Aug 16 15:10:43 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=manual
| Aug 16 15:10:43 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready
| Aug 16 15:10:59 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=16 tdcv=22 mode=automatic
| Aug 16 15:10:59 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready

neither does "tdc-mode off":

| Aug 16 15:12:18 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=off
| Aug 16 15:12:18 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready

---

We have 4 operations:
- tdc-mode off                  switch off tdc altogether
- tdc-mode manual tdco X tdcv Y configure X and Y for tdco and tdcv
- tdc-mode auto tdco X          configure X tdco and
                                controller measures tdcv automatically
- /* nothing */                 configure default value for tdco
                                controller measures tdcv automatically

The /* nothing */ operation is what the old "ip" tool does, so we're
backwards compatible here (using the old "ip" tool on an updated
kernel/driver).

At first glance it's a bit non-intuitive that you have to specify
nothing for the "full" automatic mode.

Oh, I just noticed:

| ip link set dev mcp251xfd0 down; \
| ip link set mcp251xfd0 txqueuelen 10 up type can \
|     sample-point 0.8 bitrate 500000  \
|     dsample-point 0.8 dbitrate 2000000 fd on \
|     tdc-mode manual tdco 11 tdcv 22

followed by:

| ip link set dev mcp251xfd0 down; \
| ip link set mcp251xfd0 txqueuelen 10 up type can

We stay in manual mode:

| Aug 16 15:27:47 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=manual

| 8: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
|     link/can  promiscuity 0 minmtu 0 maxmtu 0 
|     can <FD,TDC_AUTO,TDC_MANUAL> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100 
|           bitrate 500000 sample-point 0.800
|           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
|           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
|           dbitrate 2000000 dsample-point 0.800
|           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
|           tdcv 22 tdco 11
|           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
|           tdcv 0..63 tdco 0..63
|           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0 

I have to give "fd on" + the bit timing parameters to go to the full
automatic mode again:

| Aug 16 15:32:46 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=16 tdcv=22 mode=automatic


Does it make sense to let "mode auto" without a tdco value switch the
controller into full automatic mode and /* nothing */ not tough the tdc
config at all? If the full automatic mode is power on default mode, then
new kernel/drivers are compatible with old the old ip tool.

regards,
Marc

Stefan Mätje Aug. 16, 2021, 1:49 p.m. UTC | #6

Hi Vincent,

I would like to add some comments below:

Am Montag, den 16.08.2021, 14:25 +0200 schrieb Marc Kleine-Budde:
> On 16.08.2021 19:24:43, Vincent MAILHOL wrote:
> > On Mon. 16 Aug 2021 at 17:42, Marc Kleine-Budde <[e-mail]> wrote:
> > > On 15.08.2021 12:32:43, Vincent Mailhol wrote:
> > > > ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
> > > > compensation" that "the configuration range for [the] SSP position
> > > > shall be at least 0 to 63 minimum time quanta."
> > > > 
> > > > Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
> > > > TDCO to hold zero value in order to honor SSP's minimum possible
> > > > value.
> > > > 
> > > > However, current implementation assigned special meaning to TDCV and
> > > > TDCO's zero values:
> > > >   * TDCV = 0 -> TDCV is automatically measured by the transceiver.
> > > >   * TDCO = 0 -> TDC is off.
> > > > 
> > > > In order to allow for those values to really be zero and to maintain
> > > > current features, we introduce two new flags:
> > > >   * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
> > > >     automatic measurement of TDCV.
> > > >   * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
> > > >     manual configuration of TDCV. N.B.: current implementation failed
> > > >     to provide an option for the driver to indicate that only manual
> > > >     mode was supported.
> > > > 
> > > > TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
> > > > CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
> > > > can_tdc_is_enabled() which is also introduced in this patch.
> > > 
> > > Nitpick: We can only say that TDC is disabled, if the driver supports
> > > the TDC interface at all, which is the case if tdc_const is set.
> > 
> > I would argue that saying that a device does not support TDC is
> > equivalent to saying that TDC is always disabled for that device.
> > Especially, the function can_tdc_is_enabled() can be used even if
> > the device does not support TDC (even if there is no benefit
> > doing so).
> > 
> > Do you still want me to rephrase this part?
> > 
> > > > Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
> > > > struct can_tdc_const. While we are not convinced that those three
> > > > fields could be anything else than zero, we can imagine that some
> > > > controllers might specify a lower bound on these. Thus, those minimums
> > > > are really added "just in case".
> > > 
> > > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > > -64...63.
> > 
> > Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> > value which is relative to the sample point.
> 
> I don't read the documentation this way....

@Vincent: I have to agree with Marc here. Perhaps my email
https://lore.kernel.org/linux-can/[e-mail]/
was also misleading. I also referred there to a MicroChip Excel sheet
(https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2517FD%20Bit%20Time%20Calculations%20-%20UG.xlsx)
that describes the calculation of the bit timing and the TDCO. The values calculated 
there correspond to the SPO from the above email. Microchip calculates the TDCO as
TDCO = (DPRSEG + DPH1SEG) * DBRP.
Thus, as already discussed, negative values are not purposeful.

Sorry, that that email was misleading. So far I've seen now only the ESDACC 
controller has a "relative" TDCO register value where a negative value may
be sensible.

> > > SSP = TDCV + absolute TDCO
> > >     = TDCV + SP + relative TDCO
> > 
> > Consequently:
> > > relative TDCO = absolute TDCO - SP
> 
> In the mcp15xxfd family manual
> (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
> in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:
> 
> > DTSEG1  15 DTQ
> > DTSEG2   4 DTQ
> > TDCO    15 DTQ
> 
> The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
> tseg1, which is correct), and relative tdco would be 0:
> 
> > mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0
> 
> Here the output with the patched ip tool:
> 
> > 4: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> >     link/can  promiscuity 0 minmtu 0 maxmtu 0 
> >     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100 
> >           bitrate 500000 sample-point 0.875
> >           tq 25 prop-seg 34 phase-seg1 35 phase-seg2 10 sjw 1 brp 1
> >           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> >           dbitrate 2000000 dsample-point 0.750
> >           dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1 dbrp 1
> >           tdco 15
> >           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> >           tdco 0..127
> >           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0
> 
> 
> > Which is also why TDCO can be negative.
> > 
> > I added an helper function can_tdc_get_relative_tdco() in the
> > fourth path of this series:
> > https://lore.kernel.org/linux-can/[e-mail]/T/#u
> > 
> > Devices which use the absolute TDCO can directly use
> > can_priv->tdc.tdco. Devices which use the relative TDCO such as
> > the mcp251xfd should use this helper function instead.
> 
> Don't think so....

@Vincent: Perhaps you should not implement this helper function as it is only needed
for the ESDACC so far.

> > However, you will still need to convert the TDCO valid range from
> > relative values to absolute ones. In your case 0..127.
> 
> Marc
> 

Stefan

Vincent Mailhol Aug. 16, 2021, 2:10 p.m. UTC | #7

On Mon. 16 Aug 2021 at 21:33, Marc Kleine-Budde <[e-mail]> wrote:
> On 16.08.2021 14:25:19, Marc Kleine-Budde wrote:
> > > > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > > > -64...63.
> > >
> > > Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> > > value which is relative to the sample point.
> >
> > I don't read the documentation this way....
> >
> > > | SSP = TDCV + absolute TDCO
> > > |     = TDCV + SP + relative TDCO
> > >
> > > Consequently:
> > > | relative TDCO = absolute TDCO - SP
> >
> > In the mcp15xxfd family manual
> > (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
> > in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:
> >
> > | DTSEG1  15 DTQ
> > | DTSEG2   4 DTQ
> > | TDCO    15 DTQ
> >
> > The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
> > tseg1, which is correct), and relative tdco would be 0:
> >
> > | mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0
> >
> > Here the output with the patched ip tool:
>
> Sorry, the previous output was not using the sample points of the
> example in the data sheet, this is the fixed output:
>
> | 6: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> |     link/can  promiscuity 0 minmtu 0 maxmtu 0
> |     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
> |           bitrate 500000 sample-point 0.800
> |           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
> |           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> |           dbitrate 2000000 dsample-point 0.800
> |           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
> |           tdco 16
> |           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> |           tdco 0..127
> |           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0

After the discussion I had with Stefan, I assumed mcp251xxfd also
used relative TDCO.  However, in the mcp15xxfd family manual,
Equation 3-10: "Secondary Sample Point" on page 18 states that:

| SSP = TDCV + TDCO

As I commented above, this is the formula of the absolute
TDCO. Furthermore, in the example you shared, TDCO is
16 (absolute), not 0 (relative).

*BUT*, if this is the absolute TDCO, I just do not get how it can
be negative (I already elaborated on this in the past: if you
subtract from TDCV, you are measuring the previous bit...)

Another thing which is misleading to me is that the mcp15xxfd
family manual lists the min and max values for most of the
bittiming parameters but not for TDCO.

Finally, I did a bit of research and found that:
http://ww1.microchip.com/downloads/en/DeviceDoc/Section_56_Controller_Area_Network_with_Flexible_Data_rate_DS60001549A.pdf

This is *not* the mcp25xxfd datasheet but it is still from
Microship and as you will see, it is mostly similar to the
mcp25xxfd except for, you guessed it, the TDCO.

It reads:
| TDCMOD<1:0>: Transmitter Delay Compensation Mode bits
| Secondary Sample Point (SSP).
| 10 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
| 11 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
| 01 = Manual; Do not measure, use TDCV plus TDCO from the register
| 00 = Disable

| TDCO<6:0>: Transmitter Delay Compensation Offset bits
| Secondary Sample Point (SSP). Two's complement; offset can be
positive, zero, or negative.
| 1111111 = -64 x SYSCLK
| .
| .
| .
| 0111111 = 63 x SYSCLK
| .
| .
| .
| 0000000 = 0 x SYSCLK

Here, you can clearly see that the TDCO has the exact same range
as the one of the mcp25xxfd but the description of TDCMOD
changes, telling us that:

| SSP = TDCV (measured delay) + CFDxDBTCFG.TSEG1 (sample point) + TDCO

Which means this is a relative TDCO.

I just do not get how two documents from Microchip can have the
TDCO relative range of -64..63 but use a different formula. I am
sorry but at that point, I just do not understand what is going
on with your controller...

Marc Kleine-Budde Aug. 16, 2021, 2:30 p.m. UTC | #8

On 16.08.2021 23:10:29, Vincent MAILHOL wrote:
[...]
> After the discussion I had with Stefan, I assumed mcp251xxfd also
> used relative TDCO.  However, in the mcp15xxfd family manual,
> Equation 3-10: "Secondary Sample Point" on page 18 states that:
> 
> | SSP = TDCV + TDCO
> 
> As I commented above, this is the formula of the absolute
> TDCO. Furthermore, in the example you shared, TDCO is
> 16 (absolute), not 0 (relative).

ACK

> *BUT*, if this is the absolute TDCO, I just do not get how it can
> be negative (I already elaborated on this in the past: if you
> subtract from TDCV, you are measuring the previous bit...)
> 
> Another thing which is misleading to me is that the mcp15xxfd
> family manual lists the min and max values for most of the
> bittiming parameters but not for TDCO.
> 
> Finally, I did a bit of research and found that:
> http://ww1.microchip.com/downloads/en/DeviceDoc/Section_56_Controller_Area_Network_with_Flexible_Data_rate_DS60001549A.pdf

Interesting. This data sheet is older than the one of the mcp2518fd.

> This is *not* the mcp25xxfd datasheet but it is still from
> Microship and as you will see, it is mostly similar to the
> mcp25xxfd except for, you guessed it, the TDCO.
> 
> It reads:
> | TDCMOD<1:0>: Transmitter Delay Compensation Mode bits
> | Secondary Sample Point (SSP).
> | 10 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> | 11 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> | 01 = Manual; Do not measure, use TDCV plus TDCO from the register
> | 00 = Disable
> 
> | TDCO<6:0>: Transmitter Delay Compensation Offset bits
> | Secondary Sample Point (SSP). Two's complement; offset can be
> positive, zero, or negative.
> | 1111111 = -64 x SYSCLK
> | .
> | .
> | .
> | 0111111 = 63 x SYSCLK
> | .
> | .
> | .
> | 0000000 = 0 x SYSCLK
> 
> Here, you can clearly see that the TDCO has the exact same range
> as the one of the mcp25xxfd but the description of TDCMOD
> changes, telling us that:
> 
> | SSP = TDCV (measured delay) + CFDxDBTCFG.TSEG1 (sample point) + TDCO
> 
> Which means this is a relative TDCO.
> 
> I just do not get how two documents from Microchip can have the
> TDCO relative range of -64..63 but use a different formula. I am
> sorry but at that point, I just do not understand what is going
> on with your controller...

Me neither. I'll ask my microchip contact.

regards,
Marc

Vincent Mailhol Aug. 16, 2021, 3:49 p.m. UTC | #9

On Mon. 16 Aug 2021 at 22:43, Marc Kleine-Budde <[e-mail]> wrote:
> On 16.08.2021 14:33:09, Marc Kleine-Budde wrote:
> > On 16.08.2021 14:25:19, Marc Kleine-Budde wrote:
> > ...
> The following sequence doesn't clear "tdcv" properly:
>
> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can \
> |     sample-point 0.8 bitrate 500000  \
> |     dsample-point 0.8 dbitrate 2000000 fd on \
> |     tdc-mode manual tdco 11 tdcv 22
> |
> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can \
> |     sample-point 0.8 bitrate 500000  \
> |     dsample-point 0.8 dbitrate 2000000 fd on
>
> | Aug 16 15:10:43 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=manual
> | Aug 16 15:10:43 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready
> | Aug 16 15:10:59 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=16 tdcv=22 mode=automatic
> | Aug 16 15:10:59 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready

This is intended. Documentation of can_tdc::tdcv states that:
 *      CAN_CTRLMODE_TDC_AUTO is set: The transceiver dynamically
 *      measures @tdcv for each transmitted CAN FD frame and the
 *      value provided here should be ignored.

And indeed, here you are in automatic mode, so can_tdc::tdcv
should be ignored. And, if you do:

| ip --details link show mcp251xfd0

TDCV should not be reported (unless you implemented the callback
function do_get_auto_tdcv(), in which case, it will report
whatever value was measured by your controller).

> neither does "tdc-mode off":
>
> | Aug 16 15:12:18 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=off
> | Aug 16 15:12:18 rpi4b8 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): mcp251xfd0: link becomes ready

Same here. can_tdc doc reads:
 *    N.B. CAN_CTRLMODE_TDC_AUTO and CAN_CTRLMODE_TDC_MANUAL are
 *    mutually exclusive. Only one can be set at a time. If both
 *    CAN_TDC_CTRLMODE_AUTO and CAN_TDC_CTRLMODE_MANUAL are unset,
 *    TDC is disabled and all the values of this structure should be
 *    ignored.

Indeed, both CAN_TDC_CTRLMODE_{AUTO,MANUAL} are unset so all the
fields of can_tdc shall be ignored. You can also confirm that the
netlink interface does not report any tof he TDC parameters.

That said, if you want me to clear the garbage values, I can do
so. I will just add some code with no actual purpose to the
netlink interface.

> ---
>
> We have 4 operations:
> - tdc-mode off                  switch off tdc altogether
> - tdc-mode manual tdco X tdcv Y configure X and Y for tdco and tdcv
> - tdc-mode auto tdco X          configure X tdco and
>                                 controller measures tdcv automatically
> - /* nothing */                 configure default value for tdco
>                                 controller measures tdcv automatically

The "nothing" does one more thing: it decides whether TDC should
be activated or not.

> The /* nothing */ operation is what the old "ip" tool does, so we're
> backwards compatible here (using the old "ip" tool on an updated
> kernel/driver).

That's true but this isn't the real intent. By doing this design,
I wanted the user to be able to transparently use TDC while
continuing to use the exact same ip commands she or he is used
to using.

> At first glance it's a bit non-intuitive that you have to specify
> nothing for the "full" automatic mode.

I have the opposite opinion: at the end, the TDC is no more than
one other bittiming parameter. The current interface requires, at
minimum, to turn "fd" flag on and to specify the dbittiming and
voila. I want to keep the number of required command line to a
minimum. This way, the TL;DR users would still get a working
environment on CAN buses with high bitrates.

For example, when you want the sample-point to be automatically
calculated, you give "nothing". You do not have to
state "sample-point auto" or anything else. I want the same for
the TDC.

> Oh, I just noticed:
>
> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can \
> |     sample-point 0.8 bitrate 500000  \
> |     dsample-point 0.8 dbitrate 2000000 fd on \
> |     tdc-mode manual tdco 11 tdcv 22
>
> followed by:
>
> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can
>
> We stay in manual mode:
>
> | Aug 16 15:27:47 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=manual
>
> | 8: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> |     link/can  promiscuity 0 minmtu 0 maxmtu 0
> |     can <FD,TDC_AUTO,TDC_MANUAL> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100

That's a bug. It should be impossible to have both TDC_AUTO and
TDC_MANUAL at the same time.

> |           bitrate 500000 sample-point 0.800
> |           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
> |           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> |           dbitrate 2000000 dsample-point 0.800
> |           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
> |           tdcv 22 tdco 11
> |           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> |           tdcv 0..63 tdco 0..63
> |           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0

Sorry, but can I confirm what you did here? You stated that you
did those four commands in this order:

> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can \
> |     sample-point 0.8 bitrate 500000  \
> |     dsample-point 0.8 dbitrate 2000000 fd on \
> |     tdc-mode manual tdco 11 tdcv 22
> | ip link set dev mcp251xfd0 down; \
> | ip link set mcp251xfd0 txqueuelen 10 up type can

So now, you should be in Classical CAN (fd flag off) but the
results of iproute2 shows that FD is on... Is there one missing
step?

> I have to give "fd on" + the bit timing parameters to go to the full
> automatic mode again:
>
> | Aug 16 15:32:46 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=16 tdcv=22 mode=automatic
>
>
> Does it make sense to let "mode auto" without a tdco value switch the
> controller into full automatic mode and /* nothing */ not tough the tdc
> config at all? If the full automatic mode is power on default mode, then
> new kernel/drivers are compatible with old the old ip tool.

If we do so, some users will forget to turn it on. Now, this
might not be a big issue, but in the near future, when CAN buses
with high bitrate (4M or more) reach production, you will start
to see complains online of users not understanding why they get
errors on their bus (because the average user will have no clue
of what TDC is). I tried to propose the most dummy proofed
approach (the compatibility with old ip tools is not the goal).

> regards,
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   | https://www.pengutronix.de  |
> Vertretung West/Dortmund         | Phone: [phone]     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   [phone]-5555 |

Vincent Mailhol Aug. 16, 2021, 3:56 p.m. UTC | #10

On Mon. 16 Aug 2021 at 22:49, Stefan Mätje <[e-mail]> wrote:
> Hi Vincent,
>
> I would like to add some comments below:
>
> Am Montag, den 16.08.2021, 14:25 +0200 schrieb Marc Kleine-Budde:
> > On 16.08.2021 19:24:43, Vincent MAILHOL wrote:
> > > On Mon. 16 Aug 2021 at 17:42, Marc Kleine-Budde <[e-mail]> wrote:
> > > > On 15.08.2021 12:32:43, Vincent Mailhol wrote:
> > > > > ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
> > > > > compensation" that "the configuration range for [the] SSP position
> > > > > shall be at least 0 to 63 minimum time quanta."
> > > > >
> > > > > Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
> > > > > TDCO to hold zero value in order to honor SSP's minimum possible
> > > > > value.
> > > > >
> > > > > However, current implementation assigned special meaning to TDCV and
> > > > > TDCO's zero values:
> > > > >   * TDCV = 0 -> TDCV is automatically measured by the transceiver.
> > > > >   * TDCO = 0 -> TDC is off.
> > > > >
> > > > > In order to allow for those values to really be zero and to maintain
> > > > > current features, we introduce two new flags:
> > > > >   * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
> > > > >     automatic measurement of TDCV.
> > > > >   * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
> > > > >     manual configuration of TDCV. N.B.: current implementation failed
> > > > >     to provide an option for the driver to indicate that only manual
> > > > >     mode was supported.
> > > > >
> > > > > TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
> > > > > CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
> > > > > can_tdc_is_enabled() which is also introduced in this patch.
> > > >
> > > > Nitpick: We can only say that TDC is disabled, if the driver supports
> > > > the TDC interface at all, which is the case if tdc_const is set.
> > >
> > > I would argue that saying that a device does not support TDC is
> > > equivalent to saying that TDC is always disabled for that device.
> > > Especially, the function can_tdc_is_enabled() can be used even if
> > > the device does not support TDC (even if there is no benefit
> > > doing so).
> > >
> > > Do you still want me to rephrase this part?
> > >
> > > > > Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
> > > > > struct can_tdc_const. While we are not convinced that those three
> > > > > fields could be anything else than zero, we can imagine that some
> > > > > controllers might specify a lower bound on these. Thus, those minimums
> > > > > are really added "just in case".
> > > >
> > > > I'm not sure, if we talked about the mcp251xfd's tcdo, valid values are
> > > > -64...63.
> > >
> > > Yes! Stefan shed some light on this. The mcp251xfd uses a tdco
> > > value which is relative to the sample point.
> >
> > I don't read the documentation this way....
>
> @Vincent: I have to agree with Marc here. Perhaps my email
> https://lore.kernel.org/linux-can/[e-mail]/
> was also misleading. I also referred there to a MicroChip Excel sheet
> (https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2517FD%20Bit%20Time%20Calculations%20-%20UG.xlsx)
> that describes the calculation of the bit timing and the TDCO. The values calculated
> there correspond to the SPO from the above email. Microchip calculates the TDCO as
> TDCO = (DPRSEG + DPH1SEG) * DBRP.
> Thus, as already discussed, negative values are not purposeful.
>
> Sorry, that that email was misleading. So far I've seen now only the ESDACC
> controller has a "relative" TDCO register value where a negative value may
> be sensible.

So many misleading things on this absolute/relative TDCO topic.
But be sure of one thing: your help has been precious!

> > > > SSP = TDCV + absolute TDCO
> > > >     = TDCV + SP + relative TDCO
> > >
> > > Consequently:
> > > > relative TDCO = absolute TDCO - SP
> >
> > In the mcp15xxfd family manual
> > (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf)
> > in the 2mbit/s data bit rate example in table 3-5 (page 21) it says:
> >
> > > DTSEG1  15 DTQ
> > > DTSEG2   4 DTQ
> > > TDCO    15 DTQ
> >
> > The mcp251xfd driver uses 15, the framework calculates 16 (== Sync Seg+
> > tseg1, which is correct), and relative tdco would be 0:
> >
> > > mcp251xfd_set_bittiming: tdco=15, priv->tdc.tdc=16, relative_tdco=0
> >
> > Here the output with the patched ip tool:
> >
> > > 4: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> > >     link/can  promiscuity 0 minmtu 0 maxmtu 0
> > >     can <FD,TDC_AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
> > >           bitrate 500000 sample-point 0.875
> > >           tq 25 prop-seg 34 phase-seg1 35 phase-seg2 10 sjw 1 brp 1
> > >           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> > >           dbitrate 2000000 dsample-point 0.750
> > >           dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1 dbrp 1
> > >           tdco 15
> > >           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> > >           tdco 0..127
> > >           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0
> >
> >
> > > Which is also why TDCO can be negative.
> > >
> > > I added an helper function can_tdc_get_relative_tdco() in the
> > > fourth path of this series:
> > > https://lore.kernel.org/linux-can/[e-mail]/T/#u
> > >
> > > Devices which use the absolute TDCO can directly use
> > > can_priv->tdc.tdco. Devices which use the relative TDCO such as
> > > the mcp251xfd should use this helper function instead.
> >
> > Don't think so....
>
> @Vincent: Perhaps you should not implement this helper function as it is only needed
> for the ESDACC so far.

Lets first wait for the response from Microchip and if indeed
mcp25xxfd does not use a relative TDCO, I am fine to remove this
from the series. In such a case, do not hesitate to steal the patch
for your ESD driver.


Yours sincerely,
Vincent

Vincent Mailhol Aug. 16, 2021, 4:04 p.m. UTC | #11

Hi Marc,

I answered too quickly in one paragraph.

On Tue. 17 Aug 2021 at 00:49, Vincent MAILHOL
<[e-mail]> wrote:
> On Mon. 16 Aug 2021 at 22:43, Marc Kleine-Budde <[e-mail]> wrote:
...
> > Oh, I just noticed:
> >
> > | ip link set dev mcp251xfd0 down; \
> > | ip link set mcp251xfd0 txqueuelen 10 up type can \
> > |     sample-point 0.8 bitrate 500000  \
> > |     dsample-point 0.8 dbitrate 2000000 fd on \
> > |     tdc-mode manual tdco 11 tdcv 22
> >
> > followed by:
> >
> > | ip link set dev mcp251xfd0 down; \
> > | ip link set mcp251xfd0 txqueuelen 10 up type can
> >
> > We stay in manual mode:
> >
> > | Aug 16 15:27:47 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=11 tdcv=22 mode=manual
> >
> > | 8: mcp251xfd0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
> > |     link/can  promiscuity 0 minmtu 0 maxmtu 0
> > |     can <FD,TDC_AUTO,TDC_MANUAL> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
>
> That's a bug. It should be impossible to have both TDC_AUTO and
> TDC_MANUAL at the same time.
>
> > |           bitrate 500000 sample-point 0.800
> > |           tq 25 prop-seg 31 phase-seg1 32 phase-seg2 16 sjw 1 brp 1
> > |           mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1
> > |           dbitrate 2000000 dsample-point 0.800
> > |           dtq 25 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 dbrp 1
> > |           tdcv 22 tdco 11
> > |           mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1
> > |           tdcv 0..63 tdco 0..63
> > |           clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus spi parentdev spi0.0
>
> Sorry, but can I confirm what you did here? You stated that you
> did those four commands in this order:
>
> > | ip link set dev mcp251xfd0 down; \
> > | ip link set mcp251xfd0 txqueuelen 10 up type can \
> > |     sample-point 0.8 bitrate 500000  \
> > |     dsample-point 0.8 dbitrate 2000000 fd on \
> > |     tdc-mode manual tdco 11 tdcv 22
> > | ip link set dev mcp251xfd0 down; \
> > | ip link set mcp251xfd0 txqueuelen 10 up type can
>
> So now, you should be in Classical CAN (fd flag off) but the
> results of iproute2 shows that FD is on... Is there one missing
> step?

Please ignore this part. I misread the latest command and thought
you were configuring it as classical CAN. You just did a network
down / up.

I will troubleshoot this tomorrow.

> > I have to give "fd on" + the bit timing parameters to go to the full
> > automatic mode again:
> >
> > | Aug 16 15:32:46 rpi4b8 kernel: mcp251xfd spi0.0 mcp251xfd0: mcp251xfd_set_bittiming: tdco=16 tdcv=22 mode=automatic

Yours sincerely,
Vincent

Vincent Mailhol Aug. 17, 2021, 1:12 a.m. UTC | #12

Hi Marc,

This patch fixes the bug you just encountered: having both TDC_AUTO
and TDC_MANUAL set at the same time. I also cleaned all garbage
data in struct can_tdc because that was trivial.

This patch is meant to be squashed into:
commit ca7200319a90 ("can: netlink: add interface for CAN-FD
Transmitter Delay Compensation (TDC)")

For now, I am just sharing it here so that you can continue your
testing. I will resend the full series after we finish current
ongoing discussion.

Signed-off-by: Vincent Mailhol <[e-mail]>
---
 drivers/net/can/dev/netlink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/dev/netlink.c b/drivers/net/can/dev/netlink.c
index f05745c96b9c..d8cefe7d354c 100644
--- a/drivers/net/can/dev/netlink.c
+++ b/drivers/net/can/dev/netlink.c
@@ -204,6 +204,7 @@ static int can_changelink(struct net_device *dev,
struct nlattr *tb[],
         }
     }

+    priv->ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
     if (data[IFLA_CAN_CTRLMODE]) {
         struct can_ctrlmode *cm;
         u32 ctrlstatic;
@@ -239,8 +240,6 @@ static int can_changelink(struct net_device *dev,
struct nlattr *tb[],
             dev->mtu = CAN_MTU;
             memset(&priv->data_bittiming, 0,
                    sizeof(priv->data_bittiming));
-            memset(&priv->tdc, 0, sizeof(priv->tdc));
-            priv->ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
         }

         tdc_mask = cm->mask & CAN_CTRLMODE_TDC_MASK;
@@ -326,6 +325,7 @@ static int can_changelink(struct net_device *dev,
struct nlattr *tb[],
         priv->termination = termval;
     }

+    memset(&priv->tdc, 0, sizeof(priv->tdc));
     if (data[IFLA_CAN_TDC]) {
         /* Use the provided TDC parameters */
         err = can_tdc_changelink(dev, data[IFLA_CAN_TDC], extack);

Marc Kleine-Budde Aug. 17, 2021, 9:43 a.m. UTC | #13

On 16.08.2021 16:30:52, Marc Kleine-Budde wrote:
> > Finally, I did a bit of research and found that:
> > http://ww1.microchip.com/downloads/en/DeviceDoc/Section_56_Controller_Area_Network_with_Flexible_Data_rate_DS60001549A.pdf

> > This is *not* the mcp25xxfd datasheet but it is still from
> > Microship and as you will see, it is mostly similar to the
> > mcp25xxfd except for, you guessed it, the TDCO.
> > 
> > It reads:
> > | TDCMOD<1:0>: Transmitter Delay Compensation Mode bits
> > | Secondary Sample Point (SSP).
> > | 10 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> > | 11 = Auto; measure delay and add CFDxDBTCFG.TSEG1; add TDCO
> > | 01 = Manual; Do not measure, use TDCV plus TDCO from the register
> > | 00 = Disable
> > 
> > | TDCO<6:0>: Transmitter Delay Compensation Offset bits
> > | Secondary Sample Point (SSP). Two's complement; offset can be
> > positive, zero, or negative.
> > | 1111111 = -64 x SYSCLK
> > | .
> > | .
> > | .
> > | 0111111 = 63 x SYSCLK
> > | .
> > | .
> > | .
> > | 0000000 = 0 x SYSCLK
> > 
> > Here, you can clearly see that the TDCO has the exact same range
> > as the one of the mcp25xxfd but the description of TDCMOD
> > changes, telling us that:
> > 
> > | SSP = TDCV (measured delay) + CFDxDBTCFG.TSEG1 (sample point) + TDCO
> > 
> > Which means this is a relative TDCO.

Good catch! Microchip is investigating this.

regards,
Marc

Marc Kleine-Budde Aug. 17, 2021, 8:01 p.m. UTC | #14

On 17.08.2021 00:49:35, Vincent MAILHOL wrote:
> > We have 4 operations:
> > - tdc-mode off                  switch off tdc altogether
> > - tdc-mode manual tdco X tdcv Y configure X and Y for tdco and tdcv
> > - tdc-mode auto tdco X          configure X tdco and
> >                                 controller measures tdcv automatically
> > - /* nothing */                 configure default value for tdco
> >                                 controller measures tdcv automatically
> 
> The "nothing" does one more thing: it decides whether TDC should
> be activated or not.
> 
> > The /* nothing */ operation is what the old "ip" tool does, so we're
> > backwards compatible here (using the old "ip" tool on an updated
> > kernel/driver).
> 
> That's true but this isn't the real intent. By doing this design,
> I wanted the user to be able to transparently use TDC while
> continuing to use the exact same ip commands she or he is used
> to using.

Backwards compatibility using an old ip tool on a new kernel/driver must
work. In case of the mcp251xfd the tdc mode must be activated and tdcv
set to the automatic calculated value and tdco automatically measured.

Marc

Vincent Mailhol Aug. 18, 2021, 9:22 a.m. UTC | #15

On Wed. 18 Aug 2021 at 05:01, Marc Kleine-Budde <[e-mail]> wrote:
>
> On 17.08.2021 00:49:35, Vincent MAILHOL wrote:
> > > We have 4 operations:
> > > - tdc-mode off                  switch off tdc altogether
> > > - tdc-mode manual tdco X tdcv Y configure X and Y for tdco and tdcv
> > > - tdc-mode auto tdco X          configure X tdco and
> > >                                 controller measures tdcv automatically
> > > - /* nothing */                 configure default value for tdco
> > >                                 controller measures tdcv automatically
> >
> > The "nothing" does one more thing: it decides whether TDC should
> > be activated or not.
> >
> > > The /* nothing */ operation is what the old "ip" tool does, so we're
> > > backwards compatible here (using the old "ip" tool on an updated
> > > kernel/driver).
> >
> > That's true but this isn't the real intent. By doing this design,
> > I wanted the user to be able to transparently use TDC while
> > continuing to use the exact same ip commands she or he is used
> > to using.
>
> Backwards compatibility using an old ip tool on a new kernel/driver must
> work.

I am not trying to argue against backward compatibility :)
My comment was just to point out that I had other intents as well.

> In case of the mcp251xfd the tdc mode must be activated and tdcv
> set to the automatic calculated value and tdco automatically measured.

Sorry but I am not sure if I will follow you. Here, do you mean
that "nothing" should do the "fully automated" calculation?

In your previous message, you said:

> Does it make sense to let "mode auto" without a tdco value switch the
> controller into full automatic mode and /* nothing */ not tough the tdc
> config at all?

So, you would like this behavior:

| "nothing" -> TDC is off (not touch the tdc config at all)
| mode auto, no tdco provided -> kernel decides between TDC_AUTO and TDC off.
| mode auto, tdco provided -> TDC_AUTO
| mode manual, tdcv and tdco provided -> TDC_MANUAL
| mode off is not needed anymore (redundant with "nothing")
(TDCF left out of the picture intentionally)

Correct?

If you do so, I see three issues:

1/ Some of the drivers already implement TDC. Those will
automatically do a calculation as long as FD is on. If "nothing"
now brings TDC off, some users will find themselves with some
error on the bus after the iproute2 update if they continue using
the same command.

2/ Users will need to read and understand how to use the TDC
parameters of iproute2. And by experience, too many people just
don't read the doc. If I can make the interface transparent and
do the correct thing by default ("nothing"), I prefer to do so.

3/ Final one is more of a nitpick. The mode auto might result in
TDC being off. If we have a TDC_AUTO flag, I would expect the
auto mode to always set that flag (unless error occurs). I see
this to be slightly counter intuitive (I recognize that my
solution also has some aspects which are not intuitive, I just
want to point here that none are perfect).


To be honest, I really preferred the v1 of this series where
there were no tdc-mode {auto,manual,off} and where the "off"
behavior was controlled by setting TDCO to zero. However, as we
realized, zero is a valid value and thus, I had to add all this
complexity just to allow that damn zero value.


Yours sincerely,
Vincent

Marc Kleine-Budde Aug. 18, 2021, 12:29 p.m. UTC | #16

On 18.08.2021 18:22:33, Vincent MAILHOL wrote:
> > Backwards compatibility using an old ip tool on a new kernel/driver must
> > work.
> 
> I am not trying to argue against backward compatibility :)
> My comment was just to point out that I had other intents as well.
> 
> > In case of the mcp251xfd the tdc mode must be activated and tdcv
> > set to the automatic calculated value and tdco automatically measured.
> 
> Sorry but I am not sure if I will follow you. Here, do you mean
> that "nothing" should do the "fully automated" calculation?

Sort of.
The use case is the old ip tool with a driver that supports tdc, for
CAN-FD to work it must be configured in fully automated mode.

> In your previous message, you said:
> 
> > Does it make sense to let "mode auto" without a tdco value switch the
> > controller into full automatic mode and /* nothing */ not tough the tdc
> > config at all?
> 
> So, you would like this behavior:
> 
> | mode auto, no tdco provided -> kernel decides between TDC_AUTO and TDC off.

NACK - mode auto, no tdco -> TDC_AUTO with tdco calculated by the kernel

> | mode auto, tdco provided -> TDC_AUTO

ACK - TDC_AUTO with user supplied tdco

> | mode manual, tdcv and tdco provided -> TDC_MANUAL

ACK - TDC_MANUAL with tdco and tdcv user provided

> | mode off is not needed anymore (redundant with "nothing")
> (TDCF left out of the picture intentionally)

NACK - TDC is switched off

> | "nothing" -> TDC is off (not touch the tdc config at all)

NACK - do not touch TDC setting, use previous setting

> Correct?

See above. Plus a change that addresses your issue 1/ from below.

If driver supports TDC it should be initially brought into TDC auto
mode, if no TDC mode is given. Maybe we need an explizit TDC off to make
that work.

> If you do so, I see three issues:
> 
> 1/ Some of the drivers already implement TDC. Those will
> automatically do a calculation as long as FD is on. If "nothing"
> now brings TDC off, some users will find themselves with some
> error on the bus after the iproute2 update if they continue using
> the same command.

Nothing would mean "do not touch" and as TDC auto is default a new ip
would work out of the box. Old ip will work, too. Just failing to decode
TDC_AUTO...

> 2/ Users will need to read and understand how to use the TDC
> parameters of iproute2. And by experience, too many people just
> don't read the doc. If I can make the interface transparent and
> do the correct thing by default ("nothing"), I prefer to do so.

ACK, see above

> 3/ Final one is more of a nitpick. The mode auto might result in
> TDC being off. If we have a TDC_AUTO flag, I would expect the
> auto mode to always set that flag (unless error occurs). I see
> this to be slightly counter intuitive (I recognize that my
> solution also has some aspects which are not intuitive, I just
> want to point here that none are perfect).

What are the corner cases where TDC_AUTO results in TDC off?

> To be honest, I really preferred the v1 of this series where
> there were no tdc-mode {auto,manual,off} and where the "off"
> behavior was controlled by setting TDCO to zero. However, as we
> realized, zero is a valid value and thus, I had to add all this
> complexity just to allow that damn zero value.

Maybe we should not put the TDC mode _not_ into ctrl-mode, but info a
dedicated tdc-mode (which is not bit-field) inside the struct tdc?

Marc

Vincent Mailhol Aug. 18, 2021, 2:17 p.m. UTC | #17

On Wed. 18 Aug 2021 at 21:29, Marc Kleine-Budde <[e-mail]> wrote:
> On 18.08.2021 18:22:33, Vincent MAILHOL wrote:
> > > Backwards compatibility using an old ip tool on a new kernel/driver must
> > > work.
> >
> > I am not trying to argue against backward compatibility :)
> > My comment was just to point out that I had other intents as well.
> >
> > > In case of the mcp251xfd the tdc mode must be activated and tdcv
> > > set to the automatic calculated value and tdco automatically measured.
> >
> > Sorry but I am not sure if I will follow you. Here, do you mean
> > that "nothing" should do the "fully automated" calculation?
>
> Sort of.
> The use case is the old ip tool with a driver that supports tdc, for
> CAN-FD to work it must be configured in fully automated mode.

The current patch does that: "nothing" means that both TDC_AUTO
and TDC_MANUAL are not set, same as what an old ip tool would
do. And that triggers the default (fully automated) mode (call
can_calc_tdco()).

> > In your previous message, you said:
> >
> > > Does it make sense to let "mode auto" without a tdco value switch the
> > > controller into full automatic mode and /* nothing */ not tough the tdc
> > > config at all?
> >
> > So, you would like this behavior:
> >
> > | mode auto, no tdco provided -> kernel decides between TDC_AUTO and TDC off.
>
> NACK - mode auto, no tdco -> TDC_AUTO with tdco calculated by the kernel

Currently, the tdco calculation is paired with the decision to
enable or not TDC. If dbrp is one or two, then do the tdco
calculation, else, TDC is off (c.f. can_calc_tdco()). This
behaviour is to follow ISO 11898-1 which states that TDC is only
applicable if data BRP is one or two. In the current patch I
allow to have TDC enabled with a dbrp greater than 2 only if the
tdco is provided by the user (i.e. I allow the user to forcefully
go against ISO but the automatic calculation guarantees
compliance).

So what do you suggest to do when drbp is greater than 2? Still
enable TDC (and violate ISO standard) or return an error
code (e.g. -ENOTSUPP)?

> > | mode auto, tdco provided -> TDC_AUTO
>
> ACK - TDC_AUTO with user supplied tdco
>
> > | mode manual, tdcv and tdco provided -> TDC_MANUAL
>
> ACK - TDC_MANUAL with tdco and tdcv user provided
>
> > | mode off is not needed anymore (redundant with "nothing")
> > (TDCF left out of the picture intentionally)
>
> NACK - TDC is switched off

Same as the current patch then :)

> > | "nothing" -> TDC is off (not touch the tdc config at all)
>
> NACK - do not touch TDC setting, use previous setting

Sorry but I still fail to understand your definition of "do not
touch".

The first time you start a device, all the structures are zeroed
out meaning that TDC is off to begin with.  So the first time the
user do something like:

| ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on

If you "do not touch" TDC it means that all TDC values stays at
zero, i.e. TDC stays off. This would contradict point 1/.

> > Correct?
>
> See above. Plus a change that addresses your issue 1/ from below.
>
> If driver supports TDC it should be initially brought into TDC auto
> mode, if no TDC mode is given. Maybe we need an explizit TDC off to make
> that work.
>
> > If you do so, I see three issues:
> >
> > 1/ Some of the drivers already implement TDC. Those will
> > automatically do a calculation as long as FD is on. If "nothing"
> > now brings TDC off, some users will find themselves with some
> > error on the bus after the iproute2 update if they continue using
> > the same command.
>
> Nothing would mean "do not touch" and as TDC auto is default a new ip
> would work out of the box. Old ip will work, too. Just failing to decode
> TDC_AUTO...

See above: if you "do not touch", my understanding is that the
old ip tool will indefinitely keep TDC to its initial value:
everything zeroed out.

To turn TDC auto, you will eventually call can_calc_tdco() and
that will touch something.

> > 2/ Users will need to read and understand how to use the TDC
> > parameters of iproute2. And by experience, too many people just
> > don't read the doc. If I can make the interface transparent and
> > do the correct thing by default ("nothing"), I prefer to do so.
>
> ACK, see above
>
> > 3/ Final one is more of a nitpick. The mode auto might result in
> > TDC being off. If we have a TDC_AUTO flag, I would expect the
> > auto mode to always set that flag (unless error occurs). I see
> > this to be slightly counter intuitive (I recognize that my
> > solution also has some aspects which are not intuitive, I just
> > want to point here that none are perfect).
>
> What are the corner cases where TDC_AUTO results in TDC off?

dbrp greater than 2 (see above).

> > To be honest, I really preferred the v1 of this series where
> > there were no tdc-mode {auto,manual,off} and where the "off"
> > behavior was controlled by setting TDCO to zero. However, as we
> > realized, zero is a valid value and thus, I had to add all this
> > complexity just to allow that damn zero value.
>
> Maybe we should not put the TDC mode _not_ into ctrl-mode, but info a
> dedicated tdc-mode (which is not bit-field) inside the struct tdc?

If you do so, then you would need both a tdcmode and a
tdcmode_supported in order for the device to announce which modes
it supports (same as the ctrlmode and ctrlmode_supported in
can_priv). I seriously thought about this option but it seemed
like reinventing the wheel for me.

Also, it needs to be bit field to differentiate between a device
which would only support manual mode, one device which would only
support auto mode and one device which would support both.


Yours sincerely,
Vincent

Vincent Mailhol Aug. 20, 2021, 6:12 a.m. UTC | #18

On Wed. 18 Aug 2021 at 23:17, Vincent MAILHOL
<[e-mail]> wrote:
> On Wed. 18 Aug 2021 at 21:29, Marc Kleine-Budde <[e-mail]> wrote:
> > On 18.08.2021 18:22:33, Vincent MAILHOL wrote:
> > > > Backwards compatibility using an old ip tool on a new kernel/driver must
> > > > work.
> > >
> > > I am not trying to argue against backward compatibility :)
> > > My comment was just to point out that I had other intents as well.
> > >
> > > > In case of the mcp251xfd the tdc mode must be activated and tdcv
> > > > set to the automatic calculated value and tdco automatically measured.
> > >
> > > Sorry but I am not sure if I will follow you. Here, do you mean
> > > that "nothing" should do the "fully automated" calculation?
> >
> > Sort of.
> > The use case is the old ip tool with a driver that supports tdc, for
> > CAN-FD to work it must be configured in fully automated mode.
>
> The current patch does that: "nothing" means that both TDC_AUTO
> and TDC_MANUAL are not set, same as what an old ip tool would
> do. And that triggers the default (fully automated) mode (call
> can_calc_tdco()).
>
> > > In your previous message, you said:
> > >
> > > > Does it make sense to let "mode auto" without a tdco value switch the
> > > > controller into full automatic mode and /* nothing */ not tough the tdc
> > > > config at all?
> > >
> > > So, you would like this behavior:
> > >
> > > | mode auto, no tdco provided -> kernel decides between TDC_AUTO and TDC off.
> >
> > NACK - mode auto, no tdco -> TDC_AUTO with tdco calculated by the kernel
>
> Currently, the tdco calculation is paired with the decision to
> enable or not TDC. If dbrp is one or two, then do the tdco
> calculation, else, TDC is off (c.f. can_calc_tdco()). This
> behaviour is to follow ISO 11898-1 which states that TDC is only
> applicable if data BRP is one or two. In the current patch I
> allow to have TDC enabled with a dbrp greater than 2 only if the
> tdco is provided by the user (i.e. I allow the user to forcefully
> go against ISO but the automatic calculation guarantees
> compliance).
>
> So what do you suggest to do when drbp is greater than 2? Still
> enable TDC (and violate ISO standard) or return an error
> code (e.g. -ENOTSUPP)?
>
> > > | mode auto, tdco provided -> TDC_AUTO
> >
> > ACK - TDC_AUTO with user supplied tdco
> >
> > > | mode manual, tdcv and tdco provided -> TDC_MANUAL
> >
> > ACK - TDC_MANUAL with tdco and tdcv user provided
> >
> > > | mode off is not needed anymore (redundant with "nothing")
> > > (TDCF left out of the picture intentionally)
> >
> > NACK - TDC is switched off
>
> Same as the current patch then :)
>
> > > | "nothing" -> TDC is off (not touch the tdc config at all)
> >
> > NACK - do not touch TDC setting, use previous setting
>
> Sorry but I still fail to understand your definition of "do not
> touch".
>
> The first time you start a device, all the structures are zeroed
> out meaning that TDC is off to begin with.  So the first time the
> user do something like:
>
> | ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on
>
> If you "do not touch" TDC it means that all TDC values stays at
> zero, i.e. TDC stays off. This would contradict point 1/.
>
> > > Correct?
> >
> > See above. Plus a change that addresses your issue 1/ from below.
> >
> > If driver supports TDC it should be initially brought into TDC auto
> > mode, if no TDC mode is given. Maybe we need an explizit TDC off to make
> > that work.
> >
> > > If you do so, I see three issues:
> > >
> > > 1/ Some of the drivers already implement TDC. Those will
> > > automatically do a calculation as long as FD is on. If "nothing"
> > > now brings TDC off, some users will find themselves with some
> > > error on the bus after the iproute2 update if they continue using
> > > the same command.
> >
> > Nothing would mean "do not touch" and as TDC auto is default a new ip
> > would work out of the box. Old ip will work, too. Just failing to decode
> > TDC_AUTO...
>
> See above: if you "do not touch", my understanding is that the
> old ip tool will indefinitely keep TDC to its initial value:
> everything zeroed out.
>
> To turn TDC auto, you will eventually call can_calc_tdco() and
> that will touch something.
>
> > > 2/ Users will need to read and understand how to use the TDC
> > > parameters of iproute2. And by experience, too many people just
> > > don't read the doc. If I can make the interface transparent and
> > > do the correct thing by default ("nothing"), I prefer to do so.
> >
> > ACK, see above
> >
> > > 3/ Final one is more of a nitpick. The mode auto might result in
> > > TDC being off. If we have a TDC_AUTO flag, I would expect the
> > > auto mode to always set that flag (unless error occurs). I see
> > > this to be slightly counter intuitive (I recognize that my
> > > solution also has some aspects which are not intuitive, I just
> > > want to point here that none are perfect).
> >
> > What are the corner cases where TDC_AUTO results in TDC off?
>
> dbrp greater than 2 (see above).
>
> > > To be honest, I really preferred the v1 of this series where
> > > there were no tdc-mode {auto,manual,off} and where the "off"
> > > behavior was controlled by setting TDCO to zero. However, as we
> > > realized, zero is a valid value and thus, I had to add all this
> > > complexity just to allow that damn zero value.
> >
> > Maybe we should not put the TDC mode _not_ into ctrl-mode, but info a
> > dedicated tdc-mode (which is not bit-field) inside the struct tdc?
>
> If you do so, then you would need both a tdcmode and a
> tdcmode_supported in order for the device to announce which modes
> it supports (same as the ctrlmode and ctrlmode_supported in
> can_priv). I seriously thought about this option but it seemed
> like reinventing the wheel for me.
>
> Also, it needs to be bit field to differentiate between a device
> which would only support manual mode, one device which would only
> support auto mode and one device which would support both.

I just realized something. If the user first sets the TDC
parameters and then does another command without any data
bittiming parameters provided, then the TDC parameters will be
recalculated but the other data bittiming parameters would remain
unchanged.

Example:
$ ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on
tdcv 33 tdco 16 tdc-mode manual
$ ip link set can0 type can bitrate 500000

Here, can_calc_tdco() will be triggered resulting in a switch to
TDC_AUTO mode.
In this scenario, it is not normal to only have the TDC
recalculated but not the other data bittiming parameters. Is it
what you were trying to explain when saying "do not touch"?

I am preparing a new series with below behavior:

* data bittiming not provided: TDC parameters unchanged
* data bittiming provided: (unchanged from current behavior)
    - tdc-mode not provided: do can_calc_tdco (fully automated)
    - tdc-mode auto and tdco provided: TDC_AUTO
    - tdc-mode manual and both of tdcv and tdco provided: TDC_MANUAL

N.B. TDC parameters must be provided together with data bittiming
parameters, e.g. data bittiming not provided + TDC parameters is
an invalid command.

Does that make more sense?


Yours sincerely,
Vinent

Patch

diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c
index f49170eadd54..7dbda411915a 100644
--- a/drivers/net/can/dev/bittiming.c
+++ b/drivers/net/can/dev/bittiming.c
@@ -182,9 +182,12 @@  void can_calc_tdco(struct net_device *dev)
 	struct can_tdc *tdc = &priv->tdc;
 	const struct can_tdc_const *tdc_const = priv->tdc_const;
 
-	if (!tdc_const)
+	if (!tdc_const ||
+	    !(priv->ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO))
 		return;
 
+	priv->ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
+
 	/* As specified in ISO 11898-1 section 11.3.3 "Transmitter
 	 * delay compensation" (TDC) is only applicable if data BRP is
 	 * one or two.
@@ -193,9 +196,10 @@  void can_calc_tdco(struct net_device *dev)
 		/* Reuse "normal" sample point and convert it to time quanta */
 		u32 sample_point_in_tq = can_bit_time(dbt) * dbt->sample_point / 1000;
 
+		if (sample_point_in_tq < tdc_const->tdco_min)
+			return;
 		tdc->tdco = min(sample_point_in_tq, tdc_const->tdco_max);
-	} else {
-		tdc->tdco = 0;
+		priv->ctrlmode |= CAN_CTRLMODE_TDC_AUTO;
 	}
 }
 #endif /* CONFIG_CAN_CALC_BITTIMING */
diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
index af042aa55f59..4f0cae29f4d8 100644
--- a/drivers/net/can/usb/etas_es58x/es58x_fd.c
+++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
@@ -428,7 +428,7 @@  static int es58x_fd_enable_channel(struct es58x_priv *priv)
 		es58x_fd_convert_bittiming(&tx_conf_msg.data_bittiming,
 					   &priv->can.data_bittiming);
 
-		if (priv->can.tdc.tdco) {
+		if (can_tdc_is_enabled(&priv->can)) {
 			tx_conf_msg.tdc_enabled = 1;
 			tx_conf_msg.tdco = cpu_to_le16(priv->can.tdc.tdco);
 			tx_conf_msg.tdcf = cpu_to_le16(priv->can.tdc.tdcf);
@@ -505,8 +505,11 @@  static const struct can_bittiming_const es58x_fd_data_bittiming_const = {
  * Register" from Microchip.
  */
 static const struct can_tdc_const es58x_tdc_const = {
+	.tdcv_min = 0,
 	.tdcv_max = 0, /* Manual mode not supported. */
+	.tdco_min = 0,
 	.tdco_max = 127,
+	.tdcf_min = 0,
 	.tdcf_max = 127
 };
 
@@ -523,7 +526,7 @@  const struct es58x_parameters es58x_fd_param = {
 	.clock = {.freq = 80 * CAN_MHZ},
 	.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK | CAN_CTRLMODE_LISTENONLY |
 	    CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_FD | CAN_CTRLMODE_FD_NON_ISO |
-	    CAN_CTRLMODE_CC_LEN8_DLC,
+	    CAN_CTRLMODE_CC_LEN8_DLC | CAN_CTRLMODE_TDC_AUTO,
 	.tx_start_of_frame = 0xCEFA,	/* FACE in little endian */
 	.rx_start_of_frame = 0xFECA,	/* CAFE in little endian */
 	.tx_urb_cmd_max_len = ES58X_FD_TX_URB_CMD_MAX_LEN,
diff --git a/include/linux/can/bittiming.h b/include/linux/can/bittiming.h
index 9de6e9053e34..9e20260611cc 100644
--- a/include/linux/can/bittiming.h
+++ b/include/linux/can/bittiming.h
@@ -19,6 +19,9 @@ 
 /* Megahertz */
 #define CAN_MHZ 1000000UL
 
+#define CAN_CTRLMODE_TDC_MASK					\
+	(CAN_CTRLMODE_TDC_AUTO | CAN_CTRLMODE_TDC_MANUAL)
+
 /*
  * struct can_tdc - CAN FD Transmission Delay Compensation parameters
  *
@@ -33,29 +36,43 @@ 
  *
  * This structure contains the parameters to calculate that SSP.
  *
- * @tdcv: Transmitter Delay Compensation Value. Distance, in time
- *	quanta, from when the bit is sent on the TX pin to when it is
- *	received on the RX pin of the transmitter. Possible options:
+ * -+----------- one bit ----------+-- TX pin
+ *  |<--- Sample Point --->|
+ *
+ *                         --+----------- one bit ----------+-- RX pin
+ *  |<-------- TDCV -------->|
+ *                           |<------- TDCO ------->|
+ *  |<----------- Secondary Sample Point ---------->|
+ *
+ * @tdcv: Transmitter Delay Compensation Value. The time needed for
+ *	the signal to propagate, i.e. the distance, in time quanta,
+ *	from the start of the bit on the TX pin to when it is received
+ *	on the RX pin. @tdcv depends on the controller modes:
+ *
+ *	  CAN_CTRLMODE_TDC_AUTO is set: The transceiver dynamically
+ *	  measures @tdcv for each transmitted CAN FD frame and the
+ *	  value provided here should be ignored.
  *
- *	  0: automatic mode. The controller dynamically measures @tdcv
- *	  for each transmitted CAN FD frame.
+ *	  CAN_CTRLMODE_TDC_MANUAL is set: use the fixed provided @tdcv
+ *	  value.
  *
- *	  Other values: manual mode. Use the fixed provided value.
+ *	N.B. CAN_CTRLMODE_TDC_AUTO and CAN_CTRLMODE_TDC_MANUAL are
+ *	mutually exclusive. Only one can be set at a time. If both
+ *	CAN_TDC_CTRLMODE_AUTO and CAN_TDC_CTRLMODE_MANUAL are unset,
+ *	TDC is disabled and all the values of this structure should be
+ *	ignored.
  *
  * @tdco: Transmitter Delay Compensation Offset. Offset value, in time
  *	quanta, defining the distance between the start of the bit
  *	reception on the RX pin of the transceiver and the SSP
  *	position such that SSP = @tdcv + @tdco.
  *
- *	If @tdco is zero, then TDC is disabled and both @tdcv and
- *	@tdcf should be ignored.
- *
  * @tdcf: Transmitter Delay Compensation Filter window. Defines the
- *	minimum value for the SSP position in time quanta. If SSP is
- *	less than @tdcf, then no delay compensations occur and the
- *	normal sampling point is used instead. The feature is enabled
- *	if and only if @tdcv is set to zero (automatic mode) and @tdcf
- *	is configured to a value greater than @tdco.
+ *	minimum value for the SSP position in time quanta. If the SSP
+ *	position is less than @tdcf, then no delay compensations occur
+ *	and the normal sampling point is used instead. The feature is
+ *	enabled if and only if @tdcv is set to zero (automatic mode)
+ *	and @tdcf is configured to a value greater than @tdco.
  */
 struct can_tdc {
 	u32 tdcv;
@@ -67,19 +84,32 @@  struct can_tdc {
  * struct can_tdc_const - CAN hardware-dependent constant for
  *	Transmission Delay Compensation
  *
- * @tdcv_max: Transmitter Delay Compensation Value maximum value.
- *	Should be set to zero if the controller does not support
- *	manual mode for tdcv.
+ * @tdcv_min: Transmitter Delay Compensation Value minimum value. If
+ *	the controller does not support manual mode for tdcv
+ *	(c.f. flag CAN_CTRLMODE_TDC_MANUAL) then this value is
+ *	ignored.
+ * @tdcv_max: Transmitter Delay Compensation Value maximum value. If
+ *	the controller does not support manual mode for tdcv
+ *	(c.f. flag CAN_CTRLMODE_TDC_MANUAL) then this value is
+ *	ignored.
+ *
+ * @tdco_min: Transmitter Delay Compensation Offset minimum value.
  * @tdco_max: Transmitter Delay Compensation Offset maximum value.
  *	Should not be zero. If the controller does not support TDC,
  *	then the pointer to this structure should be NULL.
+ *
+ * @tdcf_min: Transmitter Delay Compensation Filter window minimum
+ *	value. If @tdcf_max is zero, this value is ignored.
  * @tdcf_max: Transmitter Delay Compensation Filter window maximum
  *	value. Should be set to zero if the controller does not
  *	support this feature.
  */
 struct can_tdc_const {
+	u32 tdcv_min;
 	u32 tdcv_max;
+	u32 tdco_min;
 	u32 tdco_max;
+	u32 tdcf_min;
 	u32 tdcf_max;
 };
 
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 27b275e463da..0be982fd22fb 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -88,6 +88,10 @@  struct can_priv {
 #endif
 };
 
+static inline bool can_tdc_is_enabled(const struct can_priv *priv)
+{
+	return !!(priv->ctrlmode & CAN_CTRLMODE_TDC_MASK);
+}
 
 /* helper to define static CAN controller features at device creation time */
 static inline void can_set_static_ctrlmode(struct net_device *dev,
diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
index f730d443b918..004cd09a7d49 100644
--- a/include/uapi/linux/can/netlink.h
+++ b/include/uapi/linux/can/netlink.h
@@ -101,6 +101,8 @@  struct can_ctrlmode {
 #define CAN_CTRLMODE_PRESUME_ACK	0x40	/* Ignore missing CAN ACKs */
 #define CAN_CTRLMODE_FD_NON_ISO		0x80	/* CAN FD in non-ISO mode */
 #define CAN_CTRLMODE_CC_LEN8_DLC	0x100	/* Classic CAN DLC option */
+#define CAN_CTRLMODE_TDC_AUTO		0x200	/* CAN transiver automatically calculates TDCV */
+#define CAN_CTRLMODE_TDC_MANUAL		0x400	/* TDCV is manually set up by user */
 
 /*
  * CAN device statistics