Hi Andrew,
This patchset introduces a new generic cooling device based on cpufreq that
can be used on non-ACPI platforms. As a proof of concept, we have drivers for
the following platforms using this mechanism now:
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal)
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal)
These patches have been reviewed by Rui Zhang (https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting them
merged, perhaps a lack of maintainer bandwidth.
ACPI platforms currently have such a mechanism but it is wrapped in ACPI'isms
that we don't have on ARM platforms. If this is accepted, I'm proposing to
convert over the ACPI thermal driver to use this common code too.
Can you please merge these patches for 3.5?
Thanks,
Amit Daniel
Changes since V2:
*Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5 TMU
driver was internally developed by SangWook Ju <sw.ju(a)samsung.com>.
*Removed cpuhotplug cooling code in this patchset.
*Rebased the patches against 3.4-rc6 kernel.
Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon folder
as suggested by Mark Brown and Guenter Roeck
*Added notifier support to notify the registered drivers of any cpu cooling
action. The driver can modify the default cooling behaviour(eg set different
max clip frequency).
*The percentage based frequency replaced with absolute clipped frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
*Many review comments from R, Durgadoss <durgadoss.r(a)intel.com> and
eduardo.valentin(a)ti.com implemented.
*Removed cooling stats through debugfs patch
*The V1 based can be found here,
https://lkml.org/lkml/2012/2/22/123http://lkml.org/lkml/2012/3/3/32
Changes since RFC:
*Changed the cpu cooling registration/unregistration API's to instance based
*Changed the STATE_ACTIVE trip type to pass correct instance id
*Adding support to restore back the policy->max_freq after doing frequency
clipping.
*Moved the trip cooling stats from sysfs node to debugfs node as suggested
by Greg KH greg(a)kroah.com
*Incorporated several review comments from eduardo.valentin(a)ti.com
*Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
as discussed with Guenter Roeck <guenter.roeck(a)ericsson.com> and
Donggeun Kim <dg77.kim(a)samsung.com> (https://lkml.org/lkml/2012/1/5/7)
*Some changes according to the changes in common cpu cooling APIs
*The RFC based patches can be found here,
https://lkml.org/lkml/2011/12/13/186https://lkml.org/lkml/2011/12/21/169
Brief Description:
1) The generic cooling devices code is placed inside driver/thermal/* as
placing inside acpi folder will need un-necessary enabling of acpi code. This
codes is architecture independent.
2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which passes
cooling device instance number and may be helpful for cpufreq cooling devices
to take the correct cooling action. This trip type avoids the temperature
comparision check again inside the cooling handler.
3) This patchset adds generic cpu cooling low level implementation through
frequency clipping and cpu hotplug. In future, other cpu related cooling
devices may be added here. An ACPI version of this already exists
(drivers/acpi/processor_thermal.c). But this will be useful for platforms
like ARM using the generic thermal interface along with the generic cpu
cooling devices. The cooling device registration API's return cooling device
pointers which can be easily binded with the thermal zone trip points.
The important APIs exposed are,
a)struct thermal_cooling_device *cpufreq_cooling_register(
struct freq_clip_table *tab_ptr, unsigned int tab_size,
const struct cpumask *mask_val)
b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
4) Samsung exynos platform thermal implementation is done using the generic
cpu cooling APIs and the new trip type. The temperature sensor driver present
in the hwmon folder(registered as hwmon driver) is moved to thermal folder
and registered as a thermal driver.
All this patchset is based on Kernel version 3.4-rc6
A simple data/control flow diagrams is shown below,
Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor
| |
\|/ |
Cpufreq cooling device <---------------
TODO:
*Will send the DT enablement patches later after the driver is merged.
Amit Daniel Kachhap (6):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpufreq cooling implementation
hwmon: exynos4: Move thermal sensor driver to driver/thermal
directory
thermal: exynos5: Add exynos5 thermal sensor driver support
thermal: exynos: Register the tmu sensor with the kernel thermal
layer
ARM: exynos: Add thermal sensor driver platform data support
Documentation/hwmon/exynos4_tmu | 81 ---
Documentation/thermal/cpu-cooling-api.txt | 60 ++
Documentation/thermal/exynos_thermal | 52 ++
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/hwmon/Kconfig | 10 -
drivers/hwmon/Makefile | 1 -
drivers/hwmon/exynos4_tmu.c | 514 --------------
drivers/thermal/Kconfig | 20 +
drivers/thermal/Makefile | 4 +-
drivers/thermal/cpu_cooling.c | 359 ++++++++++
drivers/thermal/exynos_thermal.c | 933 ++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 62 ++-
include/linux/cpu_cooling.h | 62 ++
include/linux/platform_data/exynos4_tmu.h | 83 ---
include/linux/platform_data/exynos_thermal.h | 100 +++
include/linux/thermal.h | 1 +
16 files changed, 1651 insertions(+), 695 deletions(-)
delete mode 100644 Documentation/hwmon/exynos4_tmu
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 Documentation/thermal/exynos_thermal
delete mode 100644 drivers/hwmon/exynos4_tmu.c
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/cpu_cooling.h
delete mode 100644 include/linux/platform_data/exynos4_tmu.h
create mode 100644 include/linux/platform_data/exynos_thermal.h
These two patches are coming from the series I previously
sent for the cpuidle OMAP3/4 cleanups.
The first one, move the powerdomain lookup check in the init
function, the second one fix the linkage error, when the
CONFIG_PM is not set while CONFIG_CPU_IDLE is. Omap's Kconfig
has been modified to select CONFIG_PM when CONFIG_CPU_IDLE is
set.
I compiled with different options but I was not able to boot
my board because the kernel panics for another reason.
Daniel Lezcano (2):
ARM: OMAP3: cpuidle - check the powerdomain lookup
ARM: OMAP3/4: consolidate cpuidle Makefile
arch/arm/mach-omap2/Kconfig | 2 ++
arch/arm/mach-omap2/Makefile | 11 +++++++----
arch/arm/mach-omap2/cpuidle34xx.c | 11 +++--------
arch/arm/mach-omap2/cpuidle44xx.c | 8 --------
arch/arm/mach-omap2/pm.h | 17 +++++++++++++++--
5 files changed, 27 insertions(+), 22 deletions(-)
--
1.7.5.4
Greetings,
I've just created linux-linaro-core-tracking branch in
git://git.linaro.org/kernel/linux-linaro-tracking.git.
It is based on mainline tip, and has all the Platform and Working Groups
topics which would appear in the next linux-linaro kernel release. No
topics from the Landing Teams there (this is what "core" implies). This
tree will be the basis for the next (12.05) linux-linaro kernel release.
So if you have a topic to be added to 12.05 you can ask me to add it
(the sooner you ask, the better), and it will appear in
linux-linaro-core-tracking first. The request to add a topic must
include the git tree location for me to pull the topic from, and the
base used by this topic (mainline, or another topic). If no base for the
topic is specified, the mainline is assumed. If needed, this is ok to
rebase the topic; this would be easier for me to handle than e.g.
reconfiguring my scripts to use topic-3.4rc5 branch instead of
topic-3.4rc4 branch used so far etc. Again, starting from now this tree
is open for the next release (12.05) topics.
The linux-linaro-core-tracking tree is first of all to identify the
conflicts early, so it could fail to build sometimes, or the kernel
built from it may not boot etc. The plan is to rebase this tree on the
current mainline tip daily. The topics causing the conflicts would be
excluded from the linux-linaro-core-tracking tree, and would be brought
back into it after the conflicts are resolved by the topic owners.
Thanks,
Andrey
Hi.
I have gotten a lot of help from you guys getting the PowerVR drivers up
and running with the 3.3 kernel on the Pandaboard ES. Problem now is
that all I tested then, was that X was running. After some more work, we
tried out EGL, and found out that this is not working.
The 3.3 kernel I'm using is revision
f8e851d03e884b60b5207f59a342da9cafdb415f from tilt-3.3 from the
ti-landing team. I'm using the PowerVR drivers in
http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/, that
is pvr-omap4_1.7.15.0.1.57 and pvr-omap4-dkms_1.7.15.0.1.54. I'm also
using the libdrm, libdri2 and xorg server from the same place, using the
versions from:
https://launchpad.net/~tiomap-dev/+archive/omap-trunk?field.series_filter=p…
Problem is, when trying to run something using EGL, I get the output from:
http://pastebin.com/e5deVmiD
Running it through gdb on the device, I see that it segfaults in
omap_bo_handle in /usr/lib/libdrm_omap.so.1
This file is compiled, using the patches listed in debian/patches/series
in the latest commit from git://gitorious.org/ubuntu-omap/libdrm.git,
and with configure arguments:
--enable-omap-experimental-api
--enable-udev
--enable-libkms
--disable-radeon
Any ideas on what might be wrong or what I can try? I have tried copying
the libdrm_omap binary from the ppa, as it looks like that might be at
fault, but no luck.
Best Regards
Martin Ertsas
While we're planning for connect, I'd like to suggest that we do away
with team tracks all together and just have topic tracks. This would
align with our topic based approach to things now, and would be a way
to breakdown our silo's. The topic track would be lead by a topic
champion. What do people think?
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
Trying to get back to the proper way of scheduling and publishing what
will be covered by the Developer Platform team during the 12.05 cycle,
follows the blueprint description of what we're planning to work on
during this cycle.
Milestone link: https://launchpad.net/linaro-dev-platform/+milestone/12.05
The list is quite long, but most of the blueprints are basically
covering work that was supposed to get done during 12.04, that
unfortunately got blocked once LAVA got off-line.
Some interesting topics we'll cover this month:
* Common Ubuntu kernel config fragment across all kernel packages
used at the LEB
* Ubuntu sauce produced as a topic branch for Linux Linaro
* Cross toolchain updates based on 4.7 for Quantal
* Enablement test cases to be used with LAVA (usb-host-mode and others)
* Cross buildd and multi-arch fixes planning work that might come
with the ARMv8 effort
Hopefully this cycle we'll also be able to get the images in a better
shape sooner, trying to get the QA and Release team more involved with
our releases (to improve our image/builds quality).
Thanks!
--
Ricardo Salveti de Araujo
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
V3 :
* replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE
* Fixed changelog
* Fixed OMAP4_NUM_STATES going back and forth in the patchset
* Removed erratum check at init time
V2 :
* Fixed a couple of typos in the patch description
V1 : Initial Post
Daniel Lezcano (18):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table
ARM: OMAP3: define cpuidle statically
ARM: OMAP3: cpuidle - remove errata check in the init function
ARM: OMAP3: cpuidle - remove the 'valid' field
ARM: OMAP3: cpuidle - remove cpuidle_params_table
ARM: OMAP3: define statically the omap3_idle_data
ARM: OMAP3: cpuidle - use omap3_idle_data directly
ARM: OMAP3: cpuidle - simplify next_valid_state
ARM: OMAP3: set omap3_idle_data as static
ARM: OMAP3/4: consolidate cpuidle Makefile
ARM: OMAP3: cpuidle - set global variables static
arch/arm/mach-omap2/Makefile | 11 +-
arch/arm/mach-omap2/board-rx51.c | 38 +++---
arch/arm/mach-omap2/cpuidle34xx.c | 306 +++++++++++++++----------------------
arch/arm/mach-omap2/cpuidle44xx.c | 134 +++++++----------
arch/arm/mach-omap2/pm.h | 38 ++---
5 files changed, 212 insertions(+), 315 deletions(-)
--
1.7.5.4