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 Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
