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

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

Il 30/10/25 11:38, Frank Wunderlich (linux) ha scritto:
> 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@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@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@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?
> 

Did you check if there's any clock, or power rail, or power domain, that you are
missing in some node perhaps?

Could be that something is getting powered off temporarily and gifting you with
this "amazing" issue...

> root@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@11003000/rt5190a@64: Fixed dependency cycle(s) with /soc/ 
> i2c@11003000/rt5190a@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)
> 

That is something for which I can give you a clear answer....

> root@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@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

...Not strange at all...

> 
> 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 ).

...because on MediaTek, the I2C controllers are "kinda standalone" - meaning that
they work as long as they're powered up, with their main clock being either some
internal XO or the clk26m or a clock derived from that (it's bogus, as that is an
IP implementation detail that nobody has, if not MediaTek's HW engineering dept,
and it's not relevant anyway so we don't even need to really know if not for pure
curiosity).

The basic "unclocked" functionality of the I2C controller(s) in MediaTek SoCs is
XFER detection (not sure if they can do buffering as well while the AP-driven
clocks are off).

As a small side note: I think MediaTek are not the only ones doing that, but this
is an entirely different story and it's just for your own curiosity, in case.

The I2C clocks therefore are only enabling the CPU to perform read/write(/modify)
operations on the I2C Controller registers, which also include DMA transfers.

Speaking of DMA, is there really no support for apdma_sync in MT7988a? ;-)

> maybe some speed-calculation-issue?
> 

Could also be, but if it was that, and directly related to I2C, you'd get errors
during communication even when your PCA954X device actually gets probed, because
whatever calculation is ran, it's always going to be the same across reboots.

All that I'm saying here, though, ignores hardware issues. So, if you're using a
board that is not final, or a final board that has HW issues (not only as in your
own unit, but as a design mistake of some sort) it's a different story.

I am bringing up the HW question just because "better safe than sorry", but if
using something not final.. I'm mostly sure that you would've said that already
and tried with.. well, final hardware, before seeking for help here anyway :-)

Cheers!
Angelo

> 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