linux-kernel - Re: [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 04 Dec 2018 16:53:01 -0800
From:   Kevin Hilman <khilman@...libre.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-amlogic@...ts.infradead.org, carlo@...one.org
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b

Martin Blumenstingl <martin.blumenstingl@...glemail.com> writes:

> This series enables CPU frequency scaling on Meson8 and Meson8b. On
> these SoCs all CPU cores are using the same clock, so all cores will
> always run at the same frequency.
>
> On Meson8b this is pretty straight-forward by taking the frequency and
> voltage table from Amlogic's 3.10 vendor kernel and converting it to
> "operating-points-v2".
>
> Meson8 (which is inherited by Meson8m2) is not so straight forward:
> The 3.10 vendor kernel contains two frequency and voltage tables with
> different voltages for the same frequency. It turns out that this is
> due to the design of a specific reference board where the output
> voltage of the regulator is limited. This has nothing to do with the
> recommended voltages of the chip so this adds the "operating-points-v2"
> which are used by all boards in the vendor kernel except the special
> case.
> The two fastest (clock rates: 1.8GHz and 1.992GHz) operating points are
> causing my Meson8m2 "M8S" (not upstream yet) board to lock up hard with
> instruction errors. I'm not sure if this is due to the poor design of
> the PCB (the LED is getting darker when I switch to 1.8GHz and soon
> after that it will crash). Thus I decided to play safe and disabled
> these two frequencies for now.
>
> Special thanks to Jianxin from Amlogic who patiently replied to all of
> my questions about the CPU clocks (without his hints I would still be
> looking at why I'm seeing random lockups when running the CPU off
> cpu_in_div3 or why the udelay is not working properly)!
>
> This is successfully tested on:
> - Meson8b: Odroid-C1 and EC-100
> - Meson8m2: MXIII-Plus and my "M8S" board (the latter is not upstream
>   yet) with frequencies up to 1.608GHz
>
> Dependencies of this series:
> - these patches are based on my other series: [0] "32-bit Meson: add
>   the ARM TWD and Global Timers"
> - when not running linux-next this requires the the clock driver
>   patches which are queued for v4.21: [1] "[GIT PULL] clk: meson:
>   updates for v4.21"
> - when not running linux-next there is a runtime dependency on the
>   meson6_timer from [2] "clocksource/meson6_timer: implement ARM
>   delay timer" because changing the CPU clock requires a small udelay
>   which only works properly when using a timer as clocksource (instead
>   of running a jiffies based delay loop where the timing changes with
>   the CPU frequency)

Thanks for the detailed description of dependencies.

Applied to v4.21/dt,

Kevin