On Tuesday, August 20, 2013 10:11:47 AM Lukasz Majewski wrote: > On Tue, 20 Aug 2013 01:29:20 +0200 Rafael J. Wysocki rjw@xxxxxxx 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@xxxxxxxxxx wrote, > > > > On 13 August 2013 15:38, Lukasz Majewski <l.majewski@xxxxxxxxxxx> > > > > 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. Great, thanks a lot for the info! Rafael -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
