ftg has quit [Read error: Connection reset by peer]
Luke-Jr has joined #linux-sunxi
lvrp16__ has quit [Server closed connection]
lvrp16__ has joined #linux-sunxi
diveben has quit [Server closed connection]
diveben has joined #linux-sunxi
mripard_ has joined #linux-sunxi
narmstrong has quit [Server closed connection]
narmstrong has joined #linux-sunxi
mripard has quit [Ping timeout: 480 seconds]
arnd has quit [Server closed connection]
arnd has joined #linux-sunxi
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #linux-sunxi
Luke-Jr has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-sunxi
sm53 has quit [Ping timeout: 480 seconds]
sm53 has joined #linux-sunxi
Luke-Jr has joined #linux-sunxi
mehdix has quit []
mehdix has joined #linux-sunxi
jakllsch has quit [Server closed connection]
jakllsch has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
linusw__ has quit [Server closed connection]
linusw__ has joined #linux-sunxi
Luke-Jr has joined #linux-sunxi
apritzel has joined #linux-sunxi
Turl has quit [Server closed connection]
Turl has joined #linux-sunxi
cyrozap has quit [Server closed connection]
cyrozap has joined #linux-sunxi
Luke-Jr has quit [Read error: Connection reset by peer]
smaeul has quit [Server closed connection]
smaeul has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #linux-sunxi
macromorgan has quit [Server closed connection]
macromorgan has joined #linux-sunxi
tnovotny has joined #linux-sunxi
anarsoul has quit [Server closed connection]
anarsoul has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-sunxi
Luke-Jr has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Luke-Jr has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Daaanct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Luke-Jr has quit [Read error: Connection reset by peer]
<ynezz>
apritzel: IIRC neither v2022.01 or v2022.04-rc4 work for me currently, CONFIG_GMAC_TX_DELAY=4 is needed
<ynezz>
libv: I would say, that this tx delay is needed due to the combination of a crappy gmac, phy and pcb
Luke-Jr has joined #linux-sunxi
<ynezz>
apritzel: BTW according to your suggestion on the list I've tried following detection http://sprunge.us/HYVgtE and it works
<ynezz>
apritzel: but it probably needs some device/board specific ifdef as well, otherwise it might screw up setups of other boards using same PHY but having different delay/phy-mode needs
<ynezz>
apritzel: or maybe just some additional model/boardname DT check/
Luke-Jr has quit [Ping timeout: 480 seconds]
Nemo_bis has quit [Ping timeout: 480 seconds]
<libv>
ynezz: yes, but if we just detect on the basis of phy, then we might go wrong
<libv>
if the traces have changed, then that is due to a board revision
<libv>
so then poking the spi rom or whatever is needed, which is probably why olimex did it that way
<libv>
ynezz: and i ran into this myself, as did plaes who iirc told me about it
<libv>
but that was somewhere in 2019 already, according to the wiki history, before the world went mad
<libv>
so i am a bit hazy on the details
Luke-Jr has joined #linux-sunxi
Nemo_bis has joined #linux-sunxi
<ynezz>
libv: IIUC there are "only" 3 revision groups worth handling, Rev. A-E with Realtek RTL8211CL, Rev. F-G2 with Realtek RTL8211E, Rev. H-L and above with Micrel KSZ9031
sm53 has quit [Ping timeout: 480 seconds]
<ynezz>
so it would probably ok to keep current state quo for those revisions with Realtek PHY <= G2 and handle revisions H >= with that Micrel foo
<libv>
i have looked at the logic of the olimex code now, and yes, you and apritzel are right
<ynezz>
then if someone needs to handle different subrevision settings, we would probably need to use eeprom based solution
<ynezz>
but I simply assume, that new users are going to buy devices with Micrel revisions
<libv>
there are tons of lime2s out there
<ynezz>
I mean, if you place order for new device today, you're likely going to end with revision using Micrel PHY
<libv>
so if uboot is able to figure out which phy it is talking to, then that indeed should suffice
<libv>
another option is to create two new configs
<libv>
and rename the current -rev_a-e
<ynezz>
in that case, I would prefer to have different DT
<libv>
or that
<ynezz>
and I did exactly that for kernel, it was rejected
<ynezz>
preference is to have new config/DT for revH+ revisions
<ynezz>
anyway, if we can handle that with some simple enough quirk in the code, it's much better
<ynezz>
makes downstream distro handling much easier etc.
<ynezz>
honestly this is all very subjective, it as well depends what you're talking to on the other end, on the RX side
<ynezz>
probably some other issue with gmac/phy config
<ynezz>
all I know it was working just fine with 4.19, had uptime over 1y, using that device almost daily as a scratch NAS/SSD
bauen1 has joined #linux-sunxi
ftg has joined #linux-sunxi
<apritzel>
ynezz: thanks, the patch was what I had in mind, roughly
Daanct12 has joined #linux-sunxi
Daaanct12 has quit [Read error: Connection reset by peer]
<apritzel>
and yes, we protect that with some LIME2 specific Kconfig symbol, as we do for other boards already
<apritzel>
so mainline Linux works with "rgmii" PHY mode?
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
ynezz: and thanks for confirming the status of RevK in U-Boot. While it's unfortunate that is still doesn't work, it's not a regression, so I can push the two fix patches
<apritzel>
ynezz: we can recommend the CONFIG_GMAC_TX_DELAY=4 as a workaround, and try to fix this properly for the merge window
<apritzel>
ynezz: you don't happen to have a Realtek Lime2 board, do you?
JohnDoe_71Rus has quit []
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit []
cp--- has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Read error: Connection reset by peer]
Danct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
hlauer has joined #linux-sunxi
<apritzel>
ynezz: jernej: libv: so some reading later: the Micrel PHY does not have a default TX delay
<apritzel>
this is in contrast to Realtek PHYs, which can be (and usually are) configured by resistors on the board
<apritzel>
hence we either need to manually program a delay in the PHY's pad skew register (as the Linux driver does)
<apritzel>
or cheat and use the MAC's TX delay, as U-Boot does
<libv>
apritzel: why are u-boot and the kernel handling this differently?
<libv>
historic reasons? does the latter not require any logic beyond knowing what board it is?
<libv>
historic reasons == "i don't know, they just do" :)
<apritzel>
interestingly the kernel does not even seem to touch the GMAC clk register ...
<apritzel>
so it seems to rely on U-boot setting
<apritzel>
I am about to double check / verify this
<apritzel>
in the R40 (which is quite similar in that regard), there is a solution, with a syscon trick in the kernel
<libv>
quite the mess :)
<apritzel>
to me it looks like it was just made to work (TM), which was probably reasonable before that rgmii DT change
<apritzel>
I mean that change that broke every board ...
<apritzel>
so the upstream solution for the Lime2 seems to be to port the pad skew register setup code from Linux to the U-Boot Micrel PHY driver
<apritzel>
then try to use rgmii-id for everyone: U-Boot and Linux, Realtek and Micrel
<apritzel>
ah, so there is this separate allwinner,sun7i-a20-gmac-clk, which at least sets the basics of this register, but does not program any delay