Hi, On Thu, Aug 18, 2016 at 3:03 PM, Heiko Stuebner <heiko at sntech.de> wrote: > Hi Doug, > > Am Donnerstag, 18. August 2016, 11:56:01 CEST schrieb Douglas Anderson: >> On rk3288 it was important that powerdown and powerup counts for the >> CPU/GPU in the kernel because: > > somehow this sentence seems to miss some verb or so :-) Sigh. I guess I can't type. On rk3288 it was important that powerdown and powerup counts for the CPU/GPU be set in the kernel because: >> * The power on default was crazy long. >> * We couldn't rely on the firmware to set this up because really this >> wasn't the firmware's job--the kernel was the only one that really >> cared about bringing up / down CPUs and the GPU and doing suspend / >> resume (which involves bringing up / down CPUs). >> >> On newer ARM systems (like rk3399) ARM Trusted Firmware is in charge of >> bringing up and down the CPUs and it really should be in charge of >> setting all these counts right. After all ATF is in charge of suspend / >> resume and CPU up / down. Let's get out of the way and let ATF do its >> job. >> >> A few other motivations for doing this: >> * Depending on another configuration (PMU_24M_EN_CFG) these counts can >> be either in 24M or 32k cycles. Thus, though ATF isn't really so >> involved in bringing up the GPU, ATF should probably manage the counts >> for everything so it can also manage the 24M / 32k choice. >> * It turns out that (right now) 24M mode is broken on rk3399 and not >> being used. That means that the count the kernel was programming >> in (24) was not 1 us (which it seems was intended) but was actually >> .75 ms >> * On rk3399 there are actually 2 separate registers for setting CPU >> up/down time plus 1 register for GPU up/down time. The curent kernel >> code actually was putting the register for the "little" cores in the >> "CPU" slot and the register for the "big" cores in the "GPU" slot. It >> was never initting the GPU counts. >> >> Note: this change assumes that ATF will actually set these values at >> boot, as I'm proposing in <http://crosreview.com/372381>. > > I'd hope to see a link to an ATF github pull request here :-) > But I guess that simply needs some more discussion on your side. Caesar is going to get confirmation that the patch is OK then I think he'll work on the ATF pull request. Once done we can update the link here? >> Signed-off-by: Douglas Anderson <dianders at chromium.org> > > change itself looks good to me. > > So I guess we'll just need to wait for the counterpart to land in the ATF or > do you know if the poweron-defaults are somewhat sane? Power on defaults are crappy (750 ms to turn on/off a CPU), so non-ideal. Probably best to wait for ATF to land. -Doug
