This patch series is an RFC for converting OMAP to the common struct
clk. These patches are based on v4 of the common struct clk series:
https://lkml.org/lkml/2011/12/13/451
OMAP's old struct clk has been renamed to struct clk_hw_omap, but left
essentially the same. This series only targets OMAP4 and was only
tested on a 4430 Panda.
The next step is to figure out:
* what are the various clk types we want to support in separate
structures
* where does the "clk driver" code live (still in mach-omap2?)
* kill off plat-omap/clock.* completely? I vote yes.
These patches can also be found at,
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=ref…
The same series merged with Kevin's PM branch (to get CPUfreq working)
can be found at,
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=ref…
This series will be followed up shortly with another set of patches for
"testing" the clk rate change notifiers, parent propagation of rate
changes and debugfs re-parenting.
Mike Turquette (7):
OMAP: Kconfig: select GENERIC_CLK
HACK: omap4: clk: convert to common struct clk
HACK: omap: convert 44xx data to common struct clk
omap: hwmod: convert to use common struct clk
omap: panda: use clk_prepare in ehci init
omap: dss: use clk_prepare in dss reset
HACK: comment WARN_ON in _clkdm_clk_hwmod_disable
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/clkt_clksel.c | 195 +-
arch/arm/mach-omap2/clkt_dpll.c | 54 +-
arch/arm/mach-omap2/clock.c | 363 +--
arch/arm/mach-omap2/clock.h | 59 +-
arch/arm/mach-omap2/clock44xx_data.c | 4615 ++++++++++++++++++-------------
arch/arm/mach-omap2/clockdomain.c | 2 +-
arch/arm/mach-omap2/display.c | 4 +-
arch/arm/mach-omap2/dpll3xxx.c | 228 +-
arch/arm/mach-omap2/dpll44xx.c | 62 +-
arch/arm/mach-omap2/omap_hwmod.c | 54 +-
arch/arm/plat-omap/clock.c | 315 +--
arch/arm/plat-omap/include/plat/clock.h | 96 +-
14 files changed, 3415 insertions(+), 2634 deletions(-)
--
1.7.5.4
Hi Tony/Amit,
anybody has tried to use powertop from linaro on a single core ARM
SoC? What i am using is
git://android.git.linaro.org/platform/external/powertop.git.
I got two questions:
1. powertop will crash in handle_one_cpu() due to it gets wrong cpu
number(-1), then i made the following change to make it work:
powertop: fix segment fault for single cpu env
Signed-off-by: Barry Song <baohua.song(a)csr.com>
diff --git a/cpu/cpu.cpp b/cpu/cpu.cpp
index 29fc72c..c56c746 100644
--- a/cpu/cpu.cpp
+++ b/cpu/cpu.cpp
@@ -302,6 +302,9 @@ void enumerate_cpus(void)
model = strtoull(c, NULL, 10);
}
}
+
+ if (number == -1)
+ number = 0;
if (strncasecmp(line, "bogomips\t", 9) == 0) {
handle_one_cpu(number, vendor, family, model);
set_max_cpu(number);
2. after fixing problem1, powertop can run on PrimaII, but i always
get 0.0% for every p states as you can see from attached pic.
but if we check cpufreq stats in
/sys/devices/system/cpu/cpu0/cpufreq/stats, my system does change freq
based on ondemand.
# cat time_in_state
800000 2064
600000 181
400000 341
200000 60381
# cat trans_table
From : To
: 800000 600000 400000 200000
800000: 0 13 13 14
600000: 5 0 3 5
400000: 5 0 0 11
200000: 29 0 0 0
# cat total_trans
98
does anyone have experiences about it?
Thanks
barry
With the latest 3.1.5 merge linux-linaro-3.1 fails to build on Jenkins:
https://ci.linaro.org/jenkins/view/All%20CI/job/linux-linaro-3.1_panda-omap…
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
`oprofile_arch_exit' referenced in section `.init.text' of
arch/arm/oprofile/built-in.o: defined in discarded section
`.exit.text' of arch/arm/oprofile/built-in.o
`oprofile_arch_exit' referenced in section `.init.text' of
arch/arm/oprofile/built-in.o: defined in discarded section
`.exit.text' of arch/arm/oprofile/built-in.o
I originally saw this with my packaged kernel builds so checked the
unpackaged version to see if it was a config/sauce issue from
packaging.
Great work getting this up and running Dave, and thanks to Sangwook for his
support in helping us sort out issues with usb ethernet dongles. I'm doing
some smoke testing on the boards right now in preparation for having
regular, daily runs going.
Thanks,
Paul Larson
On Thu, Dec 8, 2011 at 3:12 AM, Dave Pigott <dave.pigott(a)linaro.org> wrote:
>
> Hi all,
>
> A slightly higher resolution version. The lower shelf contains 9 of our 10
> Origens - this is rack 2, Origen 1 is in rack 1.
>
> Thanks
>
> Dave
>
> Dave Pigott
> Validation Engineer
> T: +44 1223 45 00 24 | M +44 7940 45 93 44
> Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM
> SoCs****
> Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter<http://twitter.com/#%21/linaroorg>
> | Blog <http://www.linaro.org/linaro-blog/>
>
> On 8 Dec 2011, at 09:09, Sangwook Lee wrote:
>
> <Lava7Dec11.jpg>
>
>
>
Hi,
In case you haven't seen this yes, Ubuntu has a new (updated) site for
ODMs. Might be useful if you work on the Linaro Ubuntu LEB and
components.
http://odm.ubuntu.com/
Joey
Enclosed please find the link to the Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2011-12-09
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-12-08
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-12-07
== Summary ==
(For details, see the Weekly Status Report and Meeting Minutes )
* Linaro Connect http://connect.linaro.org/events/event/lcq1-12/
initial session blueprints are set:
https://blueprints.launchpad.net/sprints/lcq1-12?searchtext=power-management
* Common Clock
* Implemented notification will push the patches next.
* Discussion on going about where the common struct code will reside,
looks like it may stay in the kernel source while the binding code will be
in the DT.
* Cpuidle
* Submitted a patch for common ARM cpuidle patch
* Submitted v4 patches for exynos4210 cpuidle support with Russell
fixes.
* Sched_mc
* Preparing a new version of sched_mc for ARM
* Working on submitting a patch on scheduler and cpu_power, which has
been accepted into Nico Linaro-kernel tree
* Thermal Management
* Tested that temperature is reduced in production using the current
solution-done on Origen board.
* Added and posted the patch for a new trip type needed for cooling
devices like cpufreq.
* Working on adding a generic processor cooling devices(non ACPI based,
for ACPI already exists).
* Continue to work on i.MX6 cpufreq and thermal solution.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Hi Mike
+int clk_register_gate(struct device *dev, const char *name, unsigned long flags,
+ struct clk *fixed_parent, void __iomem *reg, u8 bit_idx,
+ int set_to_enable)
+
How do you suggest handling gated clocks which are already running
when calling the register function?
On my kirkwood bases system, the bootloader has already turned on a
number of clocks. It does not seem right to start messing with
clk->enable_count and clk->prepare_count. Could clk_register_gate()
have one more parameter, a bool indicating running?
The kirkwood mach code keeps a bitmap of which platform_data init
functions are called from the board file. In a late_initcall function
it then enables and disables clocks as needed. What i was thinking is
i can ask the hardware what clocks are already running before i
register them and register them as running/not running. Then let the
driver probe functions use the API to enable clocks which are really
needed. In a late_initcall function, i would then call clk_disable(),
clk_unprepare() on clocks which the boot loader started, thus turning
them off if no driver has claimed them.
Is this how you envisage it working?
Thanks
Andrew
Hi,
The next RC of the Android toolchain 11.12 (this is more than likely
identical to the final) is ready.
https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-2011.…
It updates to the 11.12 release from the toolchain WG and makes sure
gold is built with gcc 4.5 so we don't get dependencies on a current
libstdc++.
I'm updating all official builds.
ttyl
bero
Hi John,
Attached is a somewhat cleaned up version of the USB patch that seems
to work on my pandaboard. I figured you could include it in your new
u-boot-linaro-stable repository in lieu of the other one.
I'm not quite sure how you want patches to work; do you want me to
submit patches to you, or should I just try to send them to upstream
u-boot as I have them?
Thanks,
--
Chris Lalancette