[PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support

Geert Uytterhoeven geert at linux-m68k.org
Mon Jan 29 07:01:49 PST 2018


Hi Simon,

On Mon, Jan 29, 2018 at 3:24 PM, Simon Horman <horms at verge.net.au> wrote:
> On Fri, Jan 05, 2018 at 03:35:13PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 5, 2018 at 3:04 PM, Simon Horman <horms at verge.net.au> wrote:
>> > On Wed, Jan 03, 2018 at 01:47:08PM +0100, Geert Uytterhoeven wrote:
>> >> On Wed, Jan 3, 2018 at 1:18 PM, Simon Horman <horms+renesas at verge.net.au> wrote:
>> >> > From: Takeshi Kihara <takeshi.kihara.df at renesas.com>
>> >> > This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>> >> >
>> >> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df at renesas.com>
>> >> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>>
>> >> As the CPG/MSSR driver now has suspend/resume support, do we need
>> >> a notifier to restore the Z or Z2 registers? Or is that handled automatically
>> >> by cpufreq during system resume, for both the primary and the secondary
>> >> CPU cores?
>> >
>> > I am a bit unsure.
>> >
>> > When using the A57 cores, which is the default case, the Z clk is queried
>> > by CPUFreq on resume. It appears that on my system its already set to the
>> > correct value but I assume if it was not then it would be reset. However,
>> > this does not cover Z2 clk. So perhaps to be safe we need to register
>> > notifiers and make sure they they play nicely with CPUFreq?
>>
>> Of course the CPU is special: unlike many other devices, it must be running
>> when the kernel is reentered upon system resume.
>> It may be running using a different frequency setting, though.
>> However, following "opp-suspend", the system will always suspend with the
>> Z clock running at 1.5GHz, which is the default?
>> So Z is probably OK.
>>
>> It's more interesting to check what happens when the little cores are
>> enabled as well (unfortunately that requires different firmware).
>> 1. Does cpufreq handle them correctly when they are onlined again during
>>    system resume?
>
> I tested this by updating the firmware on an H3 ES2.0 / Salvator-XS
> using the instructions at
> https://elinux.org/R-Car/Virtualization#Enabling_HYP_Support

> # grep -E -w "pll[01]|z|z2" /sys/kernel/debug/clk/clk_summary
>           z2                              0            0  1198080000          0 0
>        .pll1                              1            1  3194880000          0 0
>        .pll0                              0            0  2995200000          0 0
>           z                               0            0  1497600000          0 0

You know it's PLL2, not PLL1, you want to look at? ;-)

Thanks for checking, looks all good!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



More information about the linux-arm-kernel mailing list