From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Date: Thu, 20 Oct 2016 10:17:42 +0530 Message-ID: <20161020044742.GK11766@vireshk-i7> References: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org> <20161020042012.GI11766@vireshk-i7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pf0-f180.google.com ([209.85.192.180]:34531 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933266AbcJTErp (ORCPT ); Thu, 20 Oct 2016 00:47:45 -0400 Received: by mail-pf0-f180.google.com with SMTP id r16so28586759pfg.1 for ; Wed, 19 Oct 2016 21:47:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20161020042012.GI11766@vireshk-i7> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Linus Walleij Cc: "Rafael J . Wysocki" , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Arnd Bergmann , Russell King On 20-10-16, 09:50, Viresh Kumar wrote: > On 19-10-16, 11:59, Linus Walleij wrote: > > This switches the ARM Integrator/AP and Integrator/CP to use the > > Device Tree cpufreq policy with its definition of operating points > > using the generic OPP library. > > > > The Integrators does not need to control a regulator to switch > > frequency, only a clock. This clock and its device tree bindings > > have been defined in the device tree and merged upstream for v4.9. > > > > This approach provides a little better granularity on the > > Integrator/AP where I defined a few operating points: before > > this change the Integrator would just switch between min speed > > (12 MHz) and max speed (71 MHz). Now it can switch between a > > few arbitrarily chosen OPPs as in the examples below: > > > > The following tests were made on the Integrator/AP: > > > > /sys/devices/system/cpu/cpufreq/policy0 echo ondemand > scaling_governor > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 24000000 Hz > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 24000000 Hz > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz > > > > The switch from 12 to 24 MHz is triggered by as little as using the > > command line with the ondemand governor. If we do this: > > > > yes > /dev/null & > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 36000000 Hz > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 36000000 Hz --> 71000000 Hz > > pkill yes > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz > > > > So the algorithm is indeed using all the OPPs. > > > > Also as a confirmation test to make sure performance is affected by the > > speed changes, we set the performance governor and: > > > > echo 12000 > scaling_max_freq > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz > > time find /sys|sort|uniq > /dev/null > > real 0m 45.51s > > user 0m 11.15s > > sys 0m 26.74s > > > > echo 71000 > scaling_max_freq > > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 71000000 Hz > > time find /sys|sort|uniq > > > /dev/null > > real 0m 9.13s > > user 0m 2.35s > > sys 0m 5.50s > > > > So it is working. > > > > If people are happy with this approach and approve of the patches > > I'd like an ACK from the cpufreq people and then merge the whole set > > through ARM SoC. > > Acked-by: Viresh Kumar Integrator is an UP, right? Otherwise you may want to use operating-points-v2 bindings instead. -- viresh