All the patchset based on Kernel version 3.2-rc6 and uses the cpufreq
cooling registration api's implemented in earlier patchset
http://www.spinics.net/lists/linux-pm/msg26500.html
The code added in this patchset adds a thermal interface layer for samsung
exynos platforms. This layer is registered from the hwmon based temperature
sensor and recieves/monitor the temperature from the sensor and informs the
generic thermal layer to take the necessary cooling action. Currently this
layer can be used to create only one thermal zone and hence only one
temperature sensor can register.
Some modifications are done in the temperature sensor driver to export the
information needed for the thermal interface to register with the core linux
thermal framework and with the cpu frequency based cooling devices.
A simple data/control flow diagrams to illustrate this,
Core Linux thermal <-------> Exynos thermal <-------- Temperature Sensor
| |
\|/ |
Cpufreq cooling device <-----
Amit Daniel Kachhap (3):
thermal: exynos: Add thermal interface support for linux thermal
layer
thermal: exynos4: Register the tmu sensor with the thermal interface
layer
ARM: exynos4: Add thermal sensor driver platform device support
arch/arm/mach-exynos/Kconfig | 12 ++
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/clock.c | 4 +
arch/arm/mach-exynos/dev-tmu.c | 64 +++++++
arch/arm/mach-exynos/include/mach/irqs.h | 2 +
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-origen.c | 1 +
arch/arm/plat-samsung/include/plat/devs.h | 1 +
drivers/hwmon/exynos4_tmu.c | 34 ++++-
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 255 +++++++++++++++++++++++++++++
include/linux/exynos_thermal.h | 59 +++++++
include/linux/platform_data/exynos4_tmu.h | 7 +
14 files changed, 447 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-exynos/dev-tmu.c
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
Thanks Arnd, Mark, Jamie, Rob, for your review.
Changes in v4:
- add depends on HAVE_CLK && OF && REGULATOR
- add set_cpu_freq fail check
- regulator_put wehn module exit
- add pr_fmt and convert all printk to pr_xxx
- use voltage range
- comment and doc fix
- add cpu_volts value pre-check in module init
- add helpfull module parameter max_freq
- remove compatible string check on Arnd's comment.
- remove generic-cpufreq to clk-reg-cpufreq
Changes in v3:
- move adjusting smp loops_per_jiffy to arm common code,
and also adjust global loops_per_jiffy.
- remove adjusting loops_per_jiffy in imx and omap cpufreq drivers.
- check compatible "generic-cpufreq" when module_init
- change printk to pr_xxx
- add generic-cpufreq DT binding doc
Changes in v2:
- add volatage change support
- change '_' in property name to '-'
- use initial value to calculate loops_per_jiffy
- fix reading cpu_volts property bug
- let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min
- don't change freq in arm_cpufreq_exit, because every core share the same freq.
- use unsigned long describe frequency as much as possible. Because clk use
unsigned long, but cpufreq use unsigned int.
[PATCH v4 1/7] ARM: add cpufreq transiton notifier to adjust
[PATCH v4 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate
[PATCH v4 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for
[PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
[PATCH v4 5/7] dts/imx6q: add cpufreq property
[PATCH v4 6/7] arm/imx6q: register arm_clk as cpu to clkdev
[PATCH v4 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ
The driver is based on clock and regulator APIs and support single core
and multi core ARM SoCs. For multi core, it assume all cores share the
same clock and voltage.
Thanks Arnd, Mark, Jamie, Rob, for your review.
Changes in V5:
- add more comments
- rename trans-latency to clk-trans-latency, and it only describe clk
latency. Regulator latency is got from regulator_set_voltage_time.
Changes in v4:
- add depends on HAVE_CLK && OF && REGULATOR
- add set_cpu_freq fail check
- regulator_put wehn module exit
- add pr_fmt and convert all printk to pr_xxx
- use voltage range
- comment and doc fix
- add cpu_volts value pre-check in module init
- add helpfull module parameter max_freq
- remove compatible string check on Arnd's comment.
- remove generic-cpufreq to clk-reg-cpufreq
Changes in v3:
- move adjusting smp loops_per_jiffy to arm common code,
and also adjust global loops_per_jiffy.
- remove adjusting loops_per_jiffy in imx and omap cpufreq drivers.
- check compatible "generic-cpufreq" when module_init
- change printk to pr_xxx
- add generic-cpufreq DT binding doc
Changes in v2:
- add volatage change support
- change '_' in property name to '-'
- use initial value to calculate loops_per_jiffy
- fix reading cpu_volts property bug
- let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min
- don't change freq in arm_cpufreq_exit, because every core share the same freq.
- use unsigned long describe frequency as much as possible. Because clk use
unsigned long, but cpufreq use unsigned int.
[PATCH V5 1/7] ARM: add cpufreq transiton notifier to adjust
[PATCH V5 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate
[PATCH V5 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for
[PATCH V5 4/7] cpufreq: add clk-reg cpufreq driver
[PATCH V5 5/7] dts/imx6q: add cpufreq property
[PATCH V5 6/7] arm/imx6q: register arm_clk as cpu to clkdev
[PATCH V5 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ
Thanks
Richard
Hi -
I visited
https://bugs.launchpad.net/linaro-android
to create a couple of bugs for Panda ICS rootfs [1], I was surprised to
see 268 open bugs there including ones about Panda.
When I looked at them, a lot are about Gingerbread, some are about TI LT
kernels but others about Panda are about other kernels. Well, I'm kind
of happy I didn't get bothered about those bugs; we have some open bugs
that are relevant that we're still working on which is fine.
However... what's the plan about Gingerbread? We seem to have moved
lock, stock and barrel to ICS, which although it happened a bit abruptly
I can understand the reasoning for.
Should we not close out the Android bugs about Gingerbread then with
INVALID or WONTFIX? Or is the plan we will continue to make GB builds
too? (That will need us to create another kernel with old SGX 1.7 stuff
in if so, it's no big deal but we would need to know.) It's very
difficult at the moment to see if a bug like
"Panda: Bootup failures observed when HDMI cable is connected"
https://bugs.launchpad.net/linaro-android/+bug/902046
is relevant, I don't think it is since it's about old tracking kernel on
Gingerbread with 1.7 SGX. Then, we should nuke the bug so we can see
the wood from the trees?
Another kind of problem a real, old bug we fixed 6 weeks ago is not
closed out
https://bugs.launchpad.net/linaro-android/+bug/869537
-Andy
[1] I didn't bother listing bugs for all the regressions ICS rootfs
introduced generally since they're well known already, but these ones
are interesting for TI LT
ICS: Panda: 1080p background image memory allocation fails
https://bugs.launchpad.net/linaro-android/+bug/908954
ICS: Panda: 1080p launcher screen positioning uses 720p origin
https://bugs.launchpad.net/linaro-android/+bug/908956
ICS: All arches: No aplay / arecord or equivalent
https://bugs.launchpad.net/linaro-android/+bug/908957
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
Hi there,
Matthias has just landed in the Precise repositories an updated
version of OpenJDK that comes with a newly updated Zero-based ARM
optimized backend. Since many people have inquired about the general
state of Java on ARM, I'd like it if we could get some installation and
testing results using the packages published from the source at:
https://launchpad.net/ubuntu/precise/+source/openjdk-6/6b24~pre2-0ubuntu2
Installable packages are linked to from:
https://launchpad.net/ubuntu/+source/openjdk-6/6b24~pre2-0ubuntu2/+build/30…
Reports of installation issues, and general results trying to run from
simple to complex applications would be appreciated.
Note there is no backport PPA for these packages at the moment. But it's
still time to give them a xmas spin and give me the great news that Java
on ARM is getting back on track -- thanks!
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs