Hi Rafael, > On 04-12-2013 02:59, Lukasz Majewski wrote: > > Hi Rafael, > > > >> 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. > >> After cooling down the boost can be enabled again. This emulates > >> behaviour similar to HW managed boost (like x86) > >> > >> Tested at HW: > >> Exynos 4412 3.13-rc2 Linux > >> Intel Core i7-3770 3.13-rc2 Linux > >> > >> Above patches were posted on top of kernel_pm/bleeding-edge > >> (SHA1: 9483a9f69d5c8f83f1723361bf8340ddfb6475b4) > >> > > > > Rafael, could you pull patches from 1 to 6 of this series? Those are > > related to cpufreq core and has already been accepted by Viresh at a > > late August this year. > > This would facilitate my further cpufreq work. > > > > And about the last patch - related to thermal. It seems that more > > discussion NOT related to cpufreq will be ongoing. > > > > I would prefer to add it as a separate patch to thermal subtree. > > I agree with Lukasz here. The part that touches the thermal driver is > minimal and the discussion is a simple matter of concept and > optimization of data structures.
Rafael, what is your opinion here? Shall I prepare another resend (without thermal patch) or would you accept the cpufreq part of this patch set (1 to 6) as is? > > > > > > > > >> > >> 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 > >> 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 > >> thermal:exynos:boost: Automatic enable/disable of BOOST feature > >> (at Exynos4412) > >> > >> Documentation/cpu-freq/boost.txt | 26 +++---- > >> drivers/cpufreq/Kconfig | 4 + > >> drivers/cpufreq/Kconfig.arm | 15 ++++ > >> drivers/cpufreq/acpi-cpufreq.c | 86 > >> +++++++-------------- drivers/cpufreq/cpufreq.c | > >> 118 ++++++++++++++++++++++++++++- > >> drivers/cpufreq/exynos-cpufreq.c | 3 + > >> drivers/cpufreq/exynos4x12-cpufreq.c | 2 +- > >> drivers/cpufreq/freq_table.c | 56 ++++++++++++-- > >> drivers/thermal/samsung/exynos_tmu_data.c | 47 ++++++++++++ > >> include/linux/cpufreq.h | 24 ++++++ 10 files > >> changed, 302 insertions(+), 79 deletions(-) > >> > > > > > > > > -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/