20 Apr, 2017

1 commit

  • …t/sunxi/linux into clk-next

    Pull Allwinner clock patches for 4.12 from Maxime Ripard:

    Support for the new H5 SoC and the PRCM block found in a number of SoCs as
    well, plus the usual chunk of fixes and minor enhancements.

    * tag 'sunxi-clk-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
    clk: sunxi-ng: Display index when clock registration fails
    clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor
    clk: sunxi-ng: a80: Remodel CPU cluster PLLs as N-type multiplier clocks
    clk: sunxi-ng: mult: Support PLL lock detection
    clk: sunxi-ng: add support for PRCM CCUs
    dt-bindings: update device tree binding for Allwinner PRCM CCUs
    clk: sunxi-ng: sun5i: Fix mux width for csi clock
    clk: sunxi-ng: tighten SoC deps on explicit AllWinner SoCs
    clk: sunxi-ng: add Allwinner H5 CCU support for H3 CCU driver
    clk: sunxi-ng: gate: Support common pre-dividers

    Stephen Boyd
     

13 Apr, 2017

1 commit

  • In common PLL designs, changes to the dividers take effect almost
    immediately, while changes to the multipliers (implemented as
    dividers in the feedback loop) take a few cycles to work into
    the feedback loop for the PLL to stablize.

    Sometimes when the PLL clock rate is changed, the decrease in the
    divider is too much for the decrease in the multiplier to catch up.
    The PLL clock rate will spike, and in some cases, might lock up
    completely. This is especially the case if the divider changed is
    the pre-divider, which affects the reference frequency.

    This patch introduces a clk notifier callback that will gate and
    then ungate a clk after a rate change, effectively resetting it,
    so it continues to work, despite any possible lockups. Care must
    be taken to reparent any consumers to other temporary clocks during
    the rate change, and that this notifier callback must be the first
    to be registered.

    This is intended to fix occasional lockups with cpufreq on newer
    Allwinner SoCs, such as the A33 and the H3. Previously it was
    thought that reparenting the cpu clock away from the PLL while
    it stabilized was enough, as this worked quite well on the A31.

    On the A33, hangs have been observed after cpufreq was recently
    introduced. With the H3, a more thorough test [1] showed that
    reparenting alone isn't enough. The system still locks up unless
    the dividers are limited to 1.

    A hunch was if the PLL was stuck in some unknown state, perhaps
    gating then ungating it would bring it back to normal. Tests
    done by Icenowy Zheng using Ondrej's test firmware shows this
    to be a valid solution.

    [1] http://www.spinics.net/lists/arm-kernel/msg552501.html

    Reported-by: Ondrej Jirman
    Signed-off-by: Chen-Yu Tsai
    Tested-by: Icenowy Zheng
    Tested-by: Quentin Schulz
    Signed-off-by: Maxime Ripard

    Chen-Yu Tsai
     

06 Apr, 2017

1 commit


07 Feb, 2017

1 commit


30 Jan, 2017

1 commit


11 Aug, 2016

1 commit

  • The condition passed to read*_poll_timeout() is the break condition,
    i.e. wait for this condition to happen and return success.

    The original code assumed the opposite, resulting in a warning when
    the PLL clock rate was changed but never lost it's lock as far as
    the readout indicated. This was verified by checking the read out
    register value.

    Fixes: 1d80c14248d6 ("clk: sunxi-ng: Add common infrastructure")
    Signed-off-by: Chen-Yu Tsai
    Acked-by: Maxime Ripard
    Signed-off-by: Stephen Boyd

    Chen-Yu Tsai
     

09 Jul, 2016

1 commit