<apritzel>
the PHY uses this clock not only for driving the data plane (RMII/RGMII and the cable side), but apparently also for internal operation, so this clock is needed to be able to discover the PHY on the MDIO bus
<apritzel>
putting the EMAC25M clock in the PHY node will not cut it, as the Linux code still wants to discover the PHY (on the MDIO bus) before enabling its device resources
<apritzel>
which is the same problem as with the reset pin we saw lately on the A133 board, just with the clock this time
<apritzel>
if someone wants to test this: "mw.l 0x2001974 0xc0000000" on the U-Boot prompt, then adding "clk_ignore_unused" to the Linux command line
Schimsalabim has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vagrantc has joined #linux-sunxi
jakllsch has quit [Ping timeout: 480 seconds]
jakllsch has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
<wens>
I wonder if it's because the stmmac mdio part does some stuff on its own
Schimsalabim has joined #linux-sunxi
<wens>
as for clocks under the phy node, there's no generic support for that yet
<tokyovigilante>
seems to have issues during probe, but does complete boot with functional display
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
kepstin has quit [Remote host closed the connection]
kepstin has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
szemzoa has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
tokyovigilante has quit [Remote host closed the connection]
tokyovigilante has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
apritzel: Adding that to my boot.scr worked, now the phy probes and works. Tested (&needed) on the pro+
warpme has joined #linux-sunxi
<BroderTuck>
The version with the code changes, enabling the clock explicitly, also worked. Maybe not needed somehow on the other boards?
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: that's a known issue, but just a warning, so doesn't block you, right?
<apritzel>
the "something fishy here" points to a more complex problem, so we would need some refactoring in the IOMMU driver, IIUC. Not trivial, so if someone wants to dig in on this ...
<apritzel>
BroderTuck: yes, the code changes in the GMAC code paper over the problem, typical Allwinner solution. The MAC code is not the right place for this clock, it should be in the MDIO or PHY code
<apritzel>
and most boards use a (fixed) crystal oscillator for the PHY, so there is nothing to do for software, that's why it hasn't been a problem so far
Robot_ has joined #linux-sunxi
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
BroderTuc1 has joined #linux-sunxi
BroderTuck has quit [Ping timeout: 480 seconds]
BroderTuc1 has quit [Read error: Connection reset by peer]
BroderTuc2 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
<wens>
you could probably expand mdio_device_reset() in drivers/net/phy/mdio_device.c
<wens>
apritzel: your "drop default syscon" patch is still not in net
pmp-p has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
dsimic is now known as Guest21859
dsimic has joined #linux-sunxi
Guest21859 has quit [Ping timeout: 480 seconds]
BroderTuc2 has quit []
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vagrantc has joined #linux-sunxi
warpme is now known as Guest21871
warpme has joined #linux-sunxi
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<tokyovigilante>
apritzel: ok great, yup doesn't affect function. Just wasn't sure if a patch showing a warning was likely to be accepted.
<apritzel>
tokyovigilante: if the patch would introduce that warning, it would not be accepted
<tokyovigilante>
hmm, so I guess it does block me then
<tokyovigilante>
I could always send without the iommu enabled. If it is a known issue was it introduced by a known commit? I didn't see it when I was last working on this circa 6.12
<apritzel>
but IIUC this warning showed up independently of any patches, just because the sunxi IOMMU was always a bit sloppy, and now we want to weed those drivers out, hence the warning
<tokyovigilante>
Otherwise I don't rate my chances of fixing the IOMMU :)
<tokyovigilante>
hmm, ok.
<apritzel>
I think it's 73d2f10957f517e5 that introduced that?
warpme has quit [Ping timeout: 480 seconds]
<apritzel>
or maybe the one that this patch is supposed to fix
<tokyovigilante>
hmm, looks like the warning *may* be spurious, and that patch hasn't landed. I'll pull it in and see if it helps