icenowy@aosc.io píše v Po 10. 04. 2017 v 18:15 +0800:
在 2017-04-10 18:06，Ondřej Jirman 写道：
Hi Maxime,
Maxime Ripard píše v Po 10. 04. 2017 v 08:59 +0200:
On Mon, Apr 10, 2017 at 12:19:41AM +0800, Icenowy Zheng wrote:
According to the researching result of Ondrej Jirman, the factor M of PLL1 shouldn't be used and the factor P should be used only if the intended frequency is lower than 288MHz. This is proven by the clk-sun8iw7_tbl.c in the BSP source code -- in there the M value is always 0 and the maximum frequency that P is not 0 is 224MHz.
As P is ignored on sun6i, it's not currently used. This patch removed the usage of M.
This patch is an original work by Ondrej Jirman, however, he didn't add a Signed-off-by tag here to his commit. So I take this code and added my Signed-off-by.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
This is a critical patch, and should be added to 2017.05.
It has been verified by the Armbian.
This doesn't mean anything. How has this been verified?
We already discussed this here: https://patchwork.kernel.org/patch/9446 365/
P.S. as Chen-Yu dig out, it's not the correct work to restrict factors, but we need to gate the PLL_CPUX when adjusting. (Of course the mux should also be switched to osc24M when PLL_CPUX is gated)
I tried this on your h3-firmware code, and it succeeded with even P overused (for any frequency) (and M is also free in this situation).
Interesting, I was only switching the source of the CPUX clock, and not gating the CPUX_PLL for the test. I guess the kernel still doesn't gate CPUX_PLL, so this whole situation should be fixed by adding the gating of PLL during the chnage and that would be it?
Sounds like the cleanest solution so far.
regards, o.j.
regards, o.j.
Maxime
-- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com