<smaeul>
bjne: you could adapt https://github.com/crust-firmware/crust to do whatever you like with GPIO. you can add new messages to the arm_scpi driver in Linux to control it
<megi>
hmm
<megi>
those comments don't address the real issue, which is that ATF now breaks power sequencing requirements of the ethernet phy on orange pi boards
lurchi__ is now known as lurchi_
<smaeul>
the problem is there's no good existing DT property to use to tell ATF which ones to turn on
<megi>
if ATF wants to enable regulators it should follow the DT and enable all of them, even the gpio ones
<smaeul>
hmm, that may be possible. ATF already has code to set GPIO outputs
<smaeul>
even then it would just be AXP + GPIO, and not any other regulator types
<megi>
on a higher level, if ATF tries to enable devices and just blanketly enabling a bunch of regs without any regard for timing requirements of particular devices is broken
<smaeul>
well ATF is doing what SPL does on other platforms, only that there's no space to put an AXP driver in SPL on sun50i
<megi>
anyway, why would ATF enable ephy by itself if it doesn't have ehternet driver?
<megi>
I can understand enabling it on the request of u-boot
<smaeul>
apritzel's reasoning (that I don't really agree with) is that u-boot proper expects regulators to already be on
<smaeul>
hmm, in u-boot (board/sunxi/board.c) it looks like the choice of which regulators to enable is hardcoded based on the PMIC model
<megi>
it's controlled by u-boot config
<smaeul>
and even if we did that, it wouldn't help H6, because ALDO2 still needs to be on for ethernet to work
<megi>
ideally u-boot ethernet driver would ask atf to enable the regulator, or enable it itself
<smaeul>
megi: the voltage is, but not the list of regulators. so sure, you could set ALDO2 to 0, turning it off, but then Ethernet still doesn't work
<megi>
ethernet doesn't work now either, so...
<megi>
it's just that this can't really be fixed from u-boot
<megi>
u-boot would need to disable the aldo2 wait a bit and then re-enable it along with a gpio controled phy-io regulator
<megi>
so this needs to be fixed in atf, to have a sensible solution
<smaeul>
is there not a reset for the PHY?
<megi>
that does not work after invalid power-up sequence
<megi>
I tried in Linux
<megi>
phy reset gpio is configured in my dts in Linux and phy initialization is still broken whenever phy regulators are enabled with some delay in between
rex_victor has quit [Ping timeout: 252 seconds]
rex_victor has joined #linux-sunxi
<smaeul>
megi: I'd be happy to write up a patch and get it merged in ATF, but I really don't know the best way to proceed here. I suggest emailing Andre (and me), since he's not on IRC
<megi>
smaeul: thanks, I'll send him an e-mail summarising the issue when I get to mainlining the opi3 ethernet again
<anarsoul>
I bet he's out of office :)
skiboy has quit [Quit: Leaving]
florian has quit [Ping timeout: 260 seconds]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
ganbold has joined #linux-sunxi
tllim has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 260 seconds]
ChriChri has quit [Ping timeout: 258 seconds]
ChriChri_ is now known as ChriChri
cnxsoft has joined #linux-sunxi
megi has quit [Ping timeout: 240 seconds]
bjne has quit [Ping timeout: 240 seconds]
dddddd has quit [Ping timeout: 258 seconds]
NeuroScr has quit [Quit: NeuroScr]
victhor has quit [Ping timeout: 248 seconds]
chewitt has joined #linux-sunxi
hell__ has quit [Ping timeout: 250 seconds]
hellsenberg has joined #linux-sunxi
sunilmohan has quit [Ping timeout: 268 seconds]
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
Putti has quit [Ping timeout: 268 seconds]
Xalius_Ph has quit [Quit: Bye]
TheSeven has quit [Ping timeout: 248 seconds]
TheSeven has joined #linux-sunxi
reinforce has joined #linux-sunxi
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 260 seconds]
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 260 seconds]
NeuroScr has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
nexgen has joined #linux-sunxi
selfbg has joined #linux-sunxi
nexgen has quit [Remote host closed the connection]
nexgen has joined #linux-sunxi
montjoie has quit [Ping timeout: 260 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
montjoie has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 265 seconds]
JohnDoe_71Rus has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
<martinayotte>
tuxd3v: picocom support high rates and even custom rates if compiled from sources with -DUSE_CUSTOM_BAUD
<diego_r>
adding "silent" boot parameter often speeds up boot by a couple of seconds, sometimes more, depending on the amount of blah blah
<diego_r>
and systemd stays silent as well, when the kernel parameter is set
<diego_r>
ups, I meant "quiet"
damex has quit [Quit: damex]
AneoX_ has joined #linux-sunxi
damex has joined #linux-sunxi
mhlavink has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
<megi>
bjne: I have basically no delay between serial probe and console registration, and I can't immediately see why there would be any delay from the code - as register_console seems to be called right after serial probe
netlynx has quit [Remote host closed the connection]
omnit has joined #linux-sunxi
bjne has quit [Ping timeout: 260 seconds]
tllim has quit [Ping timeout: 260 seconds]
BenG83 has joined #linux-sunxi
Xalius_Ph has joined #linux-sunxi
BenG83 has quit [Ping timeout: 258 seconds]
dzla has joined #linux-sunxi
dzla has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
jelly-home has quit [Ping timeout: 258 seconds]
jelly-home has joined #linux-sunxi
<suprothunderbolt>
is maineline 5.4 MIPI DSI usable now on A64? I'm running Jagen's patches that work well but I'm occasionally getting an issue at boot which I though was a hardware fault at first but seems like an a race condition: sun6i-mipi-dsi 1ca0000.dsi: can't request region for resource [mem 0x01ca1000-0x01ca1fff]
<suprothunderbolt>
then it fails with: Couldn't map the DPHY encoder registers
omnit has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi
Nemo_bis has quit [Read error: Connection reset by peer]