On Thu, May 19, 2022 at 6:40 AM Torsten Duwe duwe@lst.de wrote:
On Wed, 18 May 2022 09:53:58 -0700 Vasily Khoruzhick anarsoul@gmail.com wrote:
On Thu, Apr 28, 2022 at 8:58 AM Torsten Duwe duwe@lst.de wrote:
power on the eDP bridge? Could there be any leftovers from that mechanism? I use a hacked-up U-Boot with a procedure similar to the kernel driver as fixed by this change.
I was asking because I recall an ugly hack in some ATF code to power up the chip correctly. Did you patch ATF, and maybe call functions of it at runtime?
Initially it's powered on by ATF on system power up. ATF parses DTB and finds the regulators that it needs to enable and enables them. It's done in ATF because u-boot SPL didn't have enough space to fit in the AXP803 driver. It's only done at startup and once linux takes over, ATF doesn't touch these regulators.
But the main question is: does this patch in any way worsen the situation on the pinebook?
I don't think it worsens anything, but according to the datasheet the change makes no sense. Could you try increasing T2 instead of changing the power sequence?
According to the datasheet, there is also T3, I realise now. The diagram talks about "System Clock", but both Teres and Pinebook have a passive resonator circuit there. Correct me if I'm wrong, but without chip power, there is little to resonate. What if that driving clock circuit is powered by Vdd25? Maybe the earlier provision of 2V5 is enough for Teres' Q4, but Pinebook X4 takes even longer? The start-up times can be in the range of milliseconds.
That's plausible, but can you please try just increasing the delays without changing the power sequence?
Torsten