[PATCH RFC 0/2] PCI: rockchip-host: Retry training and hot-reset a JMB585 on RK3399

[Igor Velkov]

Hi Shawn,

Thanks. Deskew makes no difference. Helios64, x2, bind/unbind, variants
alternating every cycle, bad link bring-ups:

  defaults 6/104, auto deskew off + trim 0xf: 5/104
  defaults 6/104, magnitude off: 6/104

Your mail has the magnitude at 0xb, but TRM V1.3 part 2, 17.6.10.1 has
TX_TERMINATION_TRIM there and DESKEW_MAGNITUDE at 0xc, so I wrote 0xc.

DEBUG_DATA_OUT did show something. With Debug Mux Control (0x208) = 5,
share of samples with in_dllp0_data_valid set, 100 ms window after hot reset:

  good bring-ups 0.16% (99), bad bring-ups 51% (3, range 45-53)

The first training looks the same: 0.15% (97) against 47% (5). mgmt_dllp_error,
crc32_error and in_tlp_error stay 0 in all of them. With the mux at 4,
start_replay, replay timeout and dl_protocol_error stay 0 too.

So in a bad bring-up the RC receives a constant error-free stream of DLLPs.
I read that as the JMB585 repeating flow control init because it does not
get what the RC sends, but this bus does not show the DLLP type. It would put
the fault in the RC to JMB585 direction, on x2 only.

Is there an RC transmitter setting worth trying for that, such as swing or
de-emphasis? If not, I will stop looking for the cause here.

Igor