On Thu, May 19, 2022 at 6:40 AM Torsten Duwe <duwe@xxxxxx> wrote: > > On Wed, 18 May 2022 09:53:58 -0700 > Vasily Khoruzhick <anarsoul@xxxxxxxxx> wrote: > > > On Thu, Apr 28, 2022 at 8:58 AM Torsten Duwe <duwe@xxxxxx> 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
