Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751814Ab3HTIMF (ORCPT ); Tue, 20 Aug 2013 04:12:05 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:65288 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181Ab3HTIL7 (ORCPT ); Tue, 20 Aug 2013 04:11:59 -0400 X-AuditID: cbfee61a-b7f196d000007dfa-d2-521324cc2540 Date: Tue, 20 Aug 2013 10:11:47 +0200 From: Lukasz Majewski To: "Rafael J. Wysocki" Cc: Viresh Kumar , Zhang Rui , Eduardo Valentin , "cpufreq@vger.kernel.org" , Linux PM list , Jonghwa Lee , Lukasz Majewski , linux-kernel , Bartlomiej Zolnierkiewicz , Daniel Lezcano , Kukjin Kim , Myungjoo Ham , "R, Durgadoss" Subject: Re: [PATCH v7 0/7] cpufreq:boost: CPU Boost mode support Message-id: <20130820101147.5a7c2efa@amdc308.digital.local> In-reply-to: <2325996.izOUC9kIz1@vostro.rjw.lan> References: <1370502472-7249-1-git-send-email-l.majewski@samsung.com> <20130819085037.11e95c06@amdc308.digital.local> <2325996.izOUC9kIz1@vostro.rjw.lan> Organization: SPRC Poland X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsVy+t9jQd0zKsJBBv1NOhYbZ6xntXja9IPd Yt5nWYu+n1eYLdbs/8lk0Xn2CbNF74KrbBZvHnFbXN41h83ic+8RRovbjSvYLPoX9jJZPHnY x2ax8auHA5/H4j0vmTzuXNvD5rFu2ltmj74tqxg9Hi1uYfQ4fmM7k8fnTXIB7FFcNimpOZll qUX6dglcGTtmzWMp+KldMeN3F3sDY5NSFyMnh4SAicTRmd0sELaYxIV769m6GLk4hASmM0qs +NrECOG0M0mcu7uYCaSKRUBVYuqnG+wgNpuAnsTnu0/B4iJA8S1P/oPFmQX2sUicOq8DYgsL OEp039/PDGLzClhL3JvUD1bDKWAgMfHpUXaIBU8YJQ59vcwIkuAXkJRo//eDGeIkO4lznzaw QzQLSvyYfI8FYoGWxOZtTawQtrzE5jVvmScwCs5CUjYLSdksJGULGJlXMYqmFiQXFCel5xrq FSfmFpfmpesl5+duYgRH1TOpHYwrGywOMQpwMCrx8HYqCQUJsSaWFVfmHmKU4GBWEuF9oSwc JMSbklhZlVqUH19UmpNafIhRmoNFSZz3QKt1oJBAemJJanZqakFqEUyWiYNTqoHRw+VzU90z jbmbLUITDU/OlG/463jhe/2thw/yq6qdX9guKPz/28leRNpQMuLm2jJhc72V2fsvdB1bJ9/K njuLqzVYN3l14jRd+b65DelxXNWFV49ezPNN2bLt9u0ivQk8Ks3+B46my/Evin4UavR4zj// 3YLLVeXl/ypIVP98t+HUN9czx/cosRRnJBpqMRcVJwIAX7uyNaYCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5723 Lines: 152 On Tue, 20 Aug 2013 01:29:20 +0200 Rafael J. Wysocki rjw@sisk.pl wrote, > On Monday, August 19, 2013 08:50:37 AM Lukasz Majewski wrote: > > On Mon, 19 Aug 2013 12:08:26 +0530 Viresh Kumar > > viresh.kumar@linaro.org wrote, > > > On 13 August 2013 15:38, Lukasz Majewski > > > wrote: > > > > This patch series introduces support for CPU overclocking > > > > technique called Boost. > > > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > > component: > > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > > software oriented one (like the one done at Exynos). > > > > For this reason cpufreq/freq_table code has been reorganized to > > > > include common code. > > > > > > > > Important design decisions: > > > > - Boost related code is compiled-in unconditionally to cpufreq > > > > core and disabled by default. The cpufreq_driver is > > > > responsibile for setting boost_supported flag and providing > > > > set_boost callback(if HW support is needed). For software > > > > managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW > > > > has been defined. It will be selected only when a target > > > > platform has thermal framework properly configured. > > > > > > > > - struct cpufreq_driver has been extended with boost related > > > > fields: -- boost_supported - when driver supports boosting > > > > -- boost_enabled - boost state > > > > -- set_boost - callback to function, which is necessary > > > > to enable/disable boost > > > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) > > > > is visible _only_ when cpufreq driver supports Boost. > > > > > > > > - No special spin_lock for Boost was created. The one from > > > > cpufreq core was reused. > > > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > > changed, then the policy list is iterated and proper > > > > adjustements are done. > > > > > > > > - To improve safety level, the thermal framework is also > > > > extended to disable software boosting, when thermal trip point > > > > is reached. Then it starts monitoring target temperature to > > > > evaluate if boost can be enabled again. This emulates behaviour > > > > similar to HW managed boost (like x86) > > > > > > > > Tested at HW: > > > > Exynos 4412 3.11-rc4 Linux > > > > Intel Core i7-3770 3.11-rc4 Linux > > > > > > > > Above patches were posted on top of linux_pm/linux-next with > > > > following patches applied: > > > > > > > > cpufreq: exynos5440: Fix to skip when new frequency same as > > > > current cpufreq: fix EXYNOS drivers selection > > > > > > > > Lukasz Majewski (7): > > > > cpufreq: Add boost frequency support in core > > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > > > > common boost solution > > > > thermal:boost: Automatic enable/disable of BOOST feature > > > > cpufreq:boost:Kconfig: Provide support for software managed > > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support > > > > boost framework > > > > Documentation:cpufreq:boost: Update BOOST documentation > > > > cpufreq:exynos4x12: Change L0 driver data to > > > > CPUFREQ_BOOST_FREQ > > > > > > Hi Lukasz, > > > > > > > Hi Viresh, > > > > > I haven't found time yet to go through this series.. > > > > I've just started wondering if I had send those patches > > correctly :-). > > > > > I want to do a > > > deep/careful review this time as these are almost the final > > > patches. > > > > Ok. > > > > > > > > Will try to get over them by the end of this week.. > > > > Ok, I understand. > > Do I assume correctly that this stuff has been tested on > ACPI-compatible x86 with acpi-cpufreq and everything has worked > correctly there? > > Rafael > Hi Rafael, Following test configuration/test case (x86): - DELL OptiPlex 9010 Intel Core i7-3770 - Linux repo: [kernel_pm_http/bleeding-edge] [kernel_pm_http/linux-next] SHA1: a238ea5e20be7bea2b1fc951a024ecce770306b5 with v7 applied on top - Linux version: 3.11-rc4 (patches v7) and 3.11-rc1 (v6) - Ubuntu 11.10 (make bzImage + make all when module was needed) - config_ubuntu_3_11 (the default one for ubuntu) - KConfig: 1. Disabled intel_pstate driver 2. Enabled ACPI-Prosessor P state driver 3. Legacy cpb sysfs knob support for AMD CPUs ON/OFF (which is a part of acpi-cpufreq.c driver). - acpi-cpufreq driver was build as a module or was embedded in kernel (tested with modprobe -i / -r => no dmesg error|warning output) - I was able to read/write (echo 0/1 > /sys/devices/system/cpu/cpufreq/boost) => no output at dmesg - system was working stable. Toolchain: gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) Since I'm mostly working with ARM (exynos4412) and major work was done with cpufreq core (and x86 related work was to move common code to cpufreq core) tests mostly have been performed on ARM. Tests on ARM: - Stress tests with up to 4 scripts running to enable/disable boost sysfs attribute with random time interval (gzip < /dev/urandom > /dev/null). - Test to overheat the ARM target and look if boost+thermal cools down the device and enables boost again. - LAB governor (which was already posted to ML) to boost when power envelope allows it. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/