Re: [PATCH v6 2/4] can: rockchip: add RK3588 CAN support

[Cunhao Lu]

Hi Marc,

> > > Can you attach the TDC to the CAN framework? See commit 5e1663810e11
> > > ("can: mcp251xfd: fix TDC setting for low data bit rates"). And check if
> > > CAN-FD works on the rk3588 works?
> >
> > Could we leave the RK3588 TDC support out of this patch series for now?
> 
> ..and mark the rk3588 as RKCANFD_QUIRK_CANFD_BROKEN for now? Fine with me.

I have finished testing the CAN-FD TDC integration on RK3588.

Enabling TDC makes the transmitter enter bus-off for every TDCO value
tested. This includes the framework value (TDCO=48), TDCO=0, and the
non-zero values 1, 8, 16, 24, 32, 40, 48 and 56. With TDCO=63, only one
frame was received during a 10 second test, so that setting is not usable.

I checked the register definition against Rockchip RK3588 TRM
V1.0-Part1-20220309.pdf. The driver uses CAN_TRANSMIT_DELAY_COMPENSATION at
offset 0x108, with tdc_offset in bits 6:1 and tdc_enable in bit 0, which
matches the TRM. Thus, the failure is not explained by an incorrect register
address or field definition.

The test setup was:

  Board:             embedfire,rk3588-lubancat-5io
  CAN clock:         300 MHz
  Nominal bitrate:   500 kbit/s
  Data bitrate:      5 Mbit/s
  Sample points:     80% nominal, 80% data
  Bus:               can0 and can1 directly connected, 60 Ohm termination

With TDC disabled, about 29,775 frames were received in three seconds with
no bus errors. With TDC enabled, can0 typically reached bus-off after about
15-31 bus errors.

This is a preliminary indication of a problem in the RK3588 CAN IP TDC
path, although it is not sufficient to prove a silicon defect. In
particular, the hardware-measured transmitter delay (TDCV) is not observable
through the registers described by the TRM, so the TDC offset semantics
still need to be verified independently.

TDC is not a mandatory feature for a CAN-FD implementation. It compensates
the TX-to-RX loop delay when that delay would otherwise consume the timing
margin before the normal sample point. Whether it must be enabled depends on
the complete hardware path, including the controller, transceiver, PCB and
bus. It is therefore not required solely because CAN-FD or a particular
data bitrate is used.

On the board used for this test, CAN-FD runs reliably at 5 Mbit/s with TDC
disabled and no lost frames. This demonstrates that RK3588 supports CAN-FD,
while the maximum usable data bitrate still depends on the board design and
its TX-to-RX delay. Boards with a longer delay may need a lower data bitrate,
just as different CAN transceivers have different maximum data-rate
specifications (for example, 8 Mbit/s for some devices and 5 Mbit/s for
others).

In my opinion, enabling CAN-FD support on RK3588 is independent of TDC.
TDC is an optimization for hardware paths that need additional TX-to-RX
delay compensation, rather than a prerequisite for CAN-FD operation. I would
therefore still like to enable CAN-FD support for RK3588 in this series while
keeping TDC disabled. TDC support can be investigated separately in a
follow-up patch once its behavior has been understood.

Best regards,
Cunhao