linux-kernel - [PATCH v1 0/6] ACPI: thermal: Migrate cpufreq cooling to generic cpu

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1401351334-11210-1-git-send-email-amit.daniel@samsung.com>
Date:	Thu, 29 May 2014 13:45:28 +0530
From:	Amit Daniel Kachhap <amit.daniel@...sung.com>
To:	linux-pm@...r.kernel.org, linux-acpi@...r.kernel.org
Cc:	Zhang Rui <rui.zhang@...el.com>, linux-kernel@...r.kernel.org,
	amit.kachhap@...il.com, edubezval@...il.com, rjw@...ysocki.net,
	linux-arm-kernel@...ts.infradead.org, lenb@...nel.org
Subject: [PATCH v1 0/6] ACPI: thermal: Migrate cpufreq cooling to generic cpu_cooling layer

Changes since RFC:
* Moved the cooling state notification support to thermal core from cpu cooling
  as suggested by Eduardo.
* Used per cpu notifier structure in the cpufreq cooling implementation. This
  is a fix for race condition.
* One more comment from Eduardo was to take care when multiple listeners try to
  modify the cooling state. This is however not implemented in this patch series.
  One idea is to allow only 1 set type of clients and multiple get type of clients.
  The point to consider in these case is that cooling state management logic is now
  in control of client driver and thermal governor cooling state decisions can be
  overriden.
* Fixed other minor review comments and updated documentation section.

This patch adds notification support for those clients of cpu_cooling
APIs which may want to do something extra after receiving these
cpu_cooling events shown below. The notifier structure passed is of both Set/Get type.
The notfications events can be of the following type,

1. COOLING_SET_STATE_PRE
2. COOLING_SET_STATE_POST
3. COOLING_GET_CUR_STATE
4. COOLING_GET_MAX_STATE

The advantages of these notfications is to differentiate between different
P states in the cpufreq table and the cooling states. The clients of these
events may group few P states into 1 cooling states as done by ACPI .
Also some more cooling states can be enabled when the maximum of P state is
reached. In case of ACPI processor throttling are enabled when minimum
P-state is reached. Post notification events can be used for those cases.

All these changes are tested in samsung arndale(exynos5250) with Linaro ACPI
kernel along with few tweaks. However only cpu frequency scaling down is tested
for thermal cooling and throttling is untested as this feature is not supported
in H/W. But since the functionality is not modified so expecting the changes to
work in ACPI based platform also.  

Amit Daniel Kachhap (6):
  thermal: cpu_cooling: Fix the notification mechanism by using per cpu
    structure
  thermal: cpu_cooling: Support passing driver private data.
  thermal: thermal-core: Add notifications support for the cooling
    states
  thermal: cpu_cooling: Add support to find up/low frequency levels.
  thermal: thermal_core: Remove the max cooling limit check in
    registration
  ACPI: thermal: processor: Use the generic cpufreq infrastructure

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/