<apritzel>
wens: yes, I dimly remember seeing this once before, but was wondering if you found the issue? The function offset (+0xe94) in your dump does not make sense in my vmlinux
harry888 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
harry888 has quit [Ping timeout: 480 seconds]
harry888 has joined #linux-sunxi
warpme has quit []
<wens>
maps to line 216: int irq_mux = irq_bank_muxes[bank];
<wens>
also happens on line 169 (patched in my kernel already)
<wens>
basically you need to factor in pin_base on the R_PIO
cnxsoft has quit [Ping timeout: 480 seconds]
<wens>
have you seen the mmc stall thing before?
harry888 has quit [Ping timeout: 480 seconds]
harry888 has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
<wens>
hmm, adding clk_ignore_unused made things work
harry888 has quit [Ping timeout: 480 seconds]
<apritzel>
wens: do you mean for the SD card? or eMMC? SD cards worked for me (and others)
<wens>
SD card
<apritzel>
mmh, missing clocks is interesting, though (I could imagine regulators), wonder which one it is? I have added a dev_info() call in the loop in drivers/clk/clk.c:clk_disable_unused_subtree(), to list the clocks that get disabled
<apritzel>
wens: thanks! So among the four clocks that might be related, the pll-periph0-xxxM have no gates. I wonder if it's either apb0 or mbus, then? MBUS seems to be provide a clock for every DMA master, maybe there is some hidden dependency to MMC?
harry888 has quit [Ping timeout: 480 seconds]
<wens>
can apb0 be disabled?
<wens>
I thought those bus clocks didn't have gates
<wens>
it looks like we did mark mbus as critical in previous socs
<wens>
oh, I'll also send patches for the KASAN warnings
evgeny_boger has quit [Ping timeout: 480 seconds]
<wens>
and I think I also found a way to make the dual pmic situation work, or at least for two "axp20x-regulator" devices
harry888 has joined #linux-sunxi
<wens>
just let the axp313/axp323 one have an ID
iscle has quit [Ping timeout: 480 seconds]
harry888 has quit [Ping timeout: 480 seconds]
<wens>
marking mbus as critical fixed things
harry888 has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit []
evgeny_boger has joined #linux-sunxi
harry888 has quit [Ping timeout: 480 seconds]
<apritzel>
wens: that's a good find, many thanks!
harry888 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
harry888 has quit [Ping timeout: 480 seconds]
<wens>
as for the spi situation, it seems like the buffer count was originally in the FIFO status register, but they probably increased the size of the buffer and thus ran out of bits and had to move it
harry888 has joined #linux-sunxi
harry888 has quit [Ping timeout: 480 seconds]
harry888 has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #linux-sunxi
LordKalma has quit []
LordKalma has joined #linux-sunxi
LordKalma has quit []
LordKalma has joined #linux-sunxi
swiftgeek has quit [Remote host closed the connection]
swiftgeek has joined #linux-sunxi
harry888 has joined #linux-sunxi
harry888 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
harry888 has joined #linux-sunxi
harry888 has quit [Ping timeout: 480 seconds]
arti_ has joined #linux-sunxi
harry888 has joined #linux-sunxi
arti has quit [Ping timeout: 480 seconds]
harry888 has quit [Ping timeout: 480 seconds]
iscle has joined #linux-sunxi
harry888 has joined #linux-sunxi
apritzel has joined #linux-sunxi
vveapon has quit [Ping timeout: 480 seconds]
wingrime1 has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
<apritzel>
wens: ouch, you are right: on every other SoC the MBUS clock is marked CRITICAL, but I completely missed that on the A523!
<apritzel>
regarding SPI: well, the new TX field is actually shorter than the old one, and the RX stayed at 8 bit, with only 6 of them used, so I don't a real reason for moving it
<apritzel>
though it fits in the usual AW hardware design - random incompatible changes for no apparent reason
<apritzel>
and I was utterly confused because the old register and its bits are still around and even documented - that's why I missed that on my first round of checks