i2c issues in 6.18 on R4, but not r4pro (both mt7988 with i2c-mux on i2c2)

Frank Wunderlich (linux) linux at fw-web.de
Thu Oct 30 03:38:22 PDT 2025


Hi

sorry for html-mail, my main email-provider (GMX) sent it as html (have 
enabled text-mail as default in settings) when using web-mailer.

i've noticed i2c-issues (i2c2) on mt7988 BPI-R4 with 6.18. On most 
bootups the i2c-mux is not detected.
 
root at bpi-r4-v11:~
# i2cdetect -y  2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
 
i2c-probe is completed successful (no errors and debugs shown before 
final "return 0;")
 
sometimes the mux came up with same kernel-binary, and i see also other 
devices on same i2c bus, but mostly all devices are not shown when i use 
i2cdetect on the bus.
 
root at bpi-r4-v11:~
# i2cdetect -y  2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: UU -- -- -- -- -- -- --                         
root at bpi-r4-v11:~
# [   58.594846] sfp sfp1: failed to read EEPROM: -ENXIO
 
6.17 seems ok (have not seen the issue there yet).
 
i looked through many commits, reverted some for clock (my own, lauras 
clk_gate,...), pinctrl and the i2c-mux (some reset-related) itself but 
nothing helped.
 
One strange thing is that i have noticed no issues on bpi-r4pro which 
uses same SoC, same config and should use same drivers and configuration 
via dt.
Only diference was the reset for the mux itself in dts as far as i 
see....so tried to disable it to have it nearly same as on r4pro without 
any effect.
 
Maybe you have any idea how i can nail it down?
 
root at bpi-r4-v11:~
# dmesg | grep -i 'sfp\|i2c'
[    0.000000] Machine model: Banana Pi BPI-R4 (2x SFP+)
[    1.600387] i2c_dev: i2c /dev entries driver
[    1.605291] /soc/i2c at 11003000/rt5190a at 64: Fixed dependency cycle(s) 
with /soc/i2c at 11003000/rt5190a at 64/regulators/buck1 #i2c0 seems not 
affected
[   12.685157] platform sfp1: deferred probe pending: (reason unknown)
[   12.691440] platform sfp2: deferred probe pending: (reason unknown)
 
# dmesg | grep -i 'err\|fail\|clk'
... #nothing related to i2c or clk
[    1.623805] pca954x 2-0070: probe failed
....
 
wondered why i2c-clocks are always disabled when i look into the 
clk_summary (also when i2c was working)

root at bpi-r4-v11:~
# cat /sys/kernel/debug/clk/clk_summary | grep -i -B2 INFRA_I2C_BCK
             infra_usb_sys           0       0        0        125000000 
  0          0     50000      N               deviceless                
          i2c_sel                    0       1        0        125000000 
  0          0     50000      N            deviceless                   
             infra_i2c_bck           0       3        0        125000000 
  0          0     50000      N               11005000.i2c              
root at bpi-r4-v11:~

but looking at the driver the clocks are disabled on probe which looks 
strange to me
 
https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/i2c/busses/i2c-mt65xx.c#L1477
 
i guess it is some kind of timing issue where clocks are still disabled 
but not reenabled in mtk_i2c_transfer, but
my debug in this function shows that is called and ret=0 after the 
bulk_enable (and of course flooding console :p ).
maybe some speed-calculation-issue?
 
what i had tried to revert (also my own non-mainline like "convert 
invalid GATE to MUX"), so they seem not the rootcause:
 
d51e7cfca3fe 2025-09-25 i2c: mt65xx: convert set_speed function to void 
Wolfram Sang 
b49218365280 2025-09-06 i2c: mediatek: fix potential incorrect use of 
I2C_MASTER_WRRD Leilk.Liu 
614b1c3cbfb0 2025-06-12 i2c: use inclusive callbacks in struct 
i2c_algorithm Wolfram Sang
 
c90fa5493f7a 2025-07-31 i2c: mux: pca9541: Use I2C adapter timeout value 
for arbitration timeout Manikanta Guntupalli 
94c296776403 2025-06-03 i2c: muxes: pca954x: Reset if (de)select fails 
Wojciech Siudy 
690de2902dca 2025-06-03 i2c: muxes: pca954x: Use reset controller only 
Wojciech Siudy 
 
e504d3bdb3d0 2025-09-15 clk: mediatek: clk-gate: Add ops for gates with 
HW voter Laura Nao 
8ceff24a754a 2025-09-15 clk: mediatek: clk-gate: Refactor 
mtk_clk_register_gate to use mtk_gate struct Laura Nao
 
bd6f4a91401f 2025-09-02 pinctrl: mediatek: moore: replace struct 
function_desc with struct pinfunction Bartosz Golaszewski 
7a24f1f5b214 2025-09-02 pinctrl: mediatek: mt7988: use 
PINCTRL_PIN_FUNCTION() Bartosz Golaszewski
 
regards Frank



More information about the Linux-mediatek mailing list