On 15.7.2016 16:22, Michal Suchanek wrote: > Hello, > > On 15 July 2016 at 15:48, Ondřej Jirman <megous@xxxxxxxxxx> wrote: >> >> >> On 15.7.2016 15:27, Jean-Francois Moine wrote: >>> On Fri, 15 Jul 2016 12:38:54 +0200 >>> Ondřej Jirman <megous@xxxxxxxxxx> wrote: >>> >>>>> If so, then yes, trying to switch to the 24MHz oscillator before >>>>> applying the factors, and then switching back when the PLL is stable >>>>> would be a nice solution. >>>>> >>>>> I just checked, and all the SoCs we've had so far have that >>>>> possibility, so if it works, for now, I'd like to stick to that. >>>> >>>> It would need to be tested. U-boot does the change only once, while the >>>> kernel would be doing it all the time and between various frequencies >>>> and PLL settings. So the issues may show up with this solution too. >>> >>> I don't think this is a good idea: the CPU clock may be changed at any >>> time with the CPUFreq governor. I don't see the system moving from >>> 1008MHz to 24MHz and then to 1200MHz when some computation is needed! >> >> PLL lock time is around 10-20us, I'd guess based on the number of loops >> in the PLL lock wait loop. So unless you'll be switching frequencies >> many times per second, this should be barely noticeable. >> >> But I'd like a different solution too. > > Do you have a patch to test this? > > For me changing CPU frequency on Orange Pi One always locks up the > system. I keep running it on the u-boot setup 1.08GHz at 1.1V Not anymore. But it's quite simple to hack it into the drivers/clk/sunxi/clk-factors.c:clk_factors_set_rate() You can look at u-boot arch/arm/mach-sunxi/clock_sun6i.c:clock_set_pll1 for how to change the CPU clock source. > Thanks > > Michal >
Attachment:
signature.asc
Description: OpenPGP digital signature
