An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hwmod framework throws a WARN() about
the device being already in enabled state.
Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT'
to identify such devices/hwmods. When the device/hwmod
is requested to be enabled (the first time) by its driver/user,
nothing except the mux-enable and a state change to '_HWMOD_STATE_ENABLED'
is needed. The mux data is board specific and is unavailable during
initial enable() of the device, done by the framework as part of
setup().
A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.
Acked-by: Kevin Hilman <khilman(a)ti.com>
Acked-by: Benoit Cousson <b-cousson(a)ti.com>
Signed-off-by: Rajendra Nayak <rnayak(a)ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 23 ++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 6 ++++++
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6b3088d..166a42d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1441,6 +1441,25 @@ static int _enable(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
+ /*
+ * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left
+ * in enabled state at init.
+ * Now that someone is really trying to enable them,
+ * just update the state.
+ */
+ if (oh->_state == _HWMOD_STATE_ENABLED_AT_INIT) {
+ /*
+ * If the caller has mux data populated, do the mux'ing
+ * which wouldn't have been done as part of the _enable()
+ * done during setup.
+ */
+ if (oh->mux)
+ omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+
+ oh->_state = _HWMOD_STATE_ENABLED;
+ return 0;
+ }
+
if (oh->_state != _HWMOD_STATE_INITIALIZED &&
oh->_state != _HWMOD_STATE_IDLE &&
oh->_state != _HWMOD_STATE_DISABLED) {
@@ -1744,8 +1763,10 @@ static int _setup(struct omap_hwmod *oh, void *data)
* it should be set by the core code as a runtime flag during startup
*/
if ((oh->flags & HWMOD_INIT_NO_IDLE) &&
- (postsetup_state == _HWMOD_STATE_IDLE))
+ (postsetup_state == _HWMOD_STATE_IDLE)) {
+ oh->_state = _HWMOD_STATE_ENABLED_AT_INIT;
postsetup_state = _HWMOD_STATE_ENABLED;
+ }
if (postsetup_state == _HWMOD_STATE_IDLE)
_idle(oh);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..2bd3929 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -436,6 +436,12 @@ struct omap_hwmod_omap4_prcm {
#define _HWMOD_STATE_ENABLED 4
#define _HWMOD_STATE_IDLE 5
#define _HWMOD_STATE_DISABLED 6
+/*
+ * This state signifies the hwmod was left enabled
+ * after init, by the framework, because of the
+ * 'HWMOD_INIT_NO_IDLE' flag.
+ */
+#define _HWMOD_STATE_ENABLED_AT_INIT 7
/**
* struct omap_hwmod_class - the type of an IP block
--
1.7.1
Hi,
Just to let you all know, due to the ongoing multiarch work, it is not
possible to cross-compile
relatively complex packages in ubuntu. For example, following the
instructions[1], Firefox. While
building on oneiric, patched packages from the linaro-maintainers
overlay are needed, many of
those patches are on precise, and rest should get there during the next cycle.
Cheers,
Riku
[1] https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompi…
Hi all,
A quick refresher: the clock framework APIs in include/linux/clk.h have
allowed platforms to develop their own platform-specific implementations
to manage clocks; this meant that everyone had their own definition of
struct clk, duplicated much code and contributed negatively to the
on-going quest for The One Image to Rule Them All.
The common clk framework is an attempt to define a generic struct clk
which most platforms can use to build a clk tree and perform a
well-defined set of operations against.
These five patches are the next iteration of the common clk framework.
Since the V2 submission back in late September I ported the OMAP4
portion of OMAP's platform-specific clk framework and actively developed
the generic code on a Panda board which revealed many bugs in V2.
The patches are based on Linus' v3.2-rc1 tag and can be pulled from:
git://git.linaro.org/people/mturquette/linux.githttp://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=ref…
A great deal of this work was first done by Jeremy Kerr, who in turn
based his patches off of work by Ben Herrenschmidt
(https://lkml.org/lkml/2011/5/20/81). Many others contributed to those
patches and promptly had their work stolen by me. Thanks to all for
their past contributions.
What to expect in this version:
.the most notable change is the removal of struct clk_hw. This extra
layer of abstraction is only necessary if we want hide the definition of
struct clk from platform code. Many developers expressed the need to
know some details of the generic struct clk in the platform layer, and
rightly so. Now struct clk is defined in include/linux/clk.h, protected
by #ifdef CONFIG_GENERIC_CLK.
.flags have been introduced to struct clk, with several of them
defined and used in the common code. These flags protect against
changing clk rates or switching the clk parent while that clk is
enabled; another flag is used to signal to clk_set_rate that it should
ask the parent to change it's rate too.
.speaking of which, clk_set_rate has been overhauled and is now
recursive. *collective groan*. clk_set_rate is still simple for the
common case of simply setting a single clk's rate. But if your clk has
the CLK_PARENT_SET_RATE flag and the .round_rate callback recommends
changing the parent rate, then clk_set_rate will recurse upwards to the
parent and try it all over again. In the event of a failure everything
unwinds and all the clks go out for drinks.
.clk_register has been replaced by clk_init, which does NOT allocate
memory for you. Platforms should allocate their own clk_hw_whatever
structure which contains struct clk. clk_init is still necessary to
initialize struct clk internals. clk_init also accepts struct device
*dev as an argument, but does nothing with it. This is in anticipation
of device tree support.
.Documentation! I'm sure somebody reads it.
.sysfs support. Visualize your clk tree at /sys/clk! Where would be
a better place to put the clk tree besides the root of /sys/? When a
consensus on this is reached I'll submit the proper changes to
Documentation/ABI/testing/.
What's missing?
.per tree locking. I implemented this at the Linaro Connect
conference but the implementation was unpopular, so it didn't make the
cut. There needs to be better understanding of everyone's needs for
this to work.
.rate change notifications. I simply didn't want to delay getting
these patches to the list any longer, so the notifiers didn't make it
in. I'll submit them to the list soon, or roll them into the V4
patchset. There are comments in the clk API definitions for where
PRECHANGE, POSTCHANGE and ABORT propagation will go.
.basic mux clk, divider and dummy clk implementations. I think others
have some code lying around to implement these, so I left them out.
.device tree support. I haven't looked much at the on-going
discussions on the dt clk bindings. How compatible (or not) are the
device tree clk bindings and the way these patches want to initialize
clks?
.what is the overlap between common clk and clkdev? We're essentially
tracking the clks in two places (common clk's tree and clkdevs's list),
which feels a bit wasteful.
What else?
.OMAP4 support will be posted to LOML and LAKML in a separate
patchset, since others might be interested in seeing a full port. It is
a total hack, and is not ready for a formal submission.
Mike Turquette (5):
clk: Kconfig: add entry for HAVE_CLK_PREPARE
Documentation: common clk API
clk: introduce the common clock framework
clk: basic gateable and fixed-rate clks
clk: export tree topology and clk data via sysfs
Documentation/clk.txt | 312 +++++++++++++++++++++++++++
drivers/clk/Kconfig | 24 ++
drivers/clk/Makefile | 5 +-
drivers/clk/clk-basic.c | 208 ++++++++++++++++++
drivers/clk/clk-sysfs.c | 199 +++++++++++++++++
drivers/clk/clk.c | 541 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/clk.h | 199 +++++++++++++++++-
7 files changed, 1484 insertions(+), 4 deletions(-)
create mode 100644 Documentation/clk.txt
create mode 100644 drivers/clk/clk-basic.c
create mode 100644 drivers/clk/clk-sysfs.c
create mode 100644 drivers/clk/clk.c
--
1.7.4.1
Hi Amit,
Is there anyone working on a SoC bus framework?
The bus framework can manage the bus fabric, ddr, OCRAM clocks. When a
device driver become working, it tells bus framework, cpu may access
me (ip bus and related bus fabric on), I'm also a bus master, may
access ddr (ddr dma access +1 ). For bus framework, if ddr dma access
request is zero, ddr clk can be disabled in WFI/wait mode. The bus
framework manage the SoC bus topology. If a bus switch use count is
zero, it can be disabled. It may even adjust the bus freq dynamically
according to bus request.
Thanks
Richard
Greetings,
This is a mail sent to remind you the coming release dates:
* Linaro 11.11 components release is November 17th, 2011.
* Linaro 11.10 RC images is November 21st, 2011.
* Linaro 11.10 Release images is November 21st, 2011 (due to holiday
on Nov 24).
* Linaro 11.10 release is UTC 16:00, November 24th, 2011.
Components release will be announced this week.
The release dates and deliveries information is available from the release
dashboard: http://wiki.linaro.org/Cycles/1111/Release/Dashboard
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
Hi Angus & Grant,
Because the Linaro Android 11.11 release has been done successfully, I have
some time to continue to work on device tree topic, here is my blue print
for it:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-origen…
Therefore, I would like to know what I can do for this in the 11.12 cycle -
from now to the 18th December 2011. For Samsung Origen Android build, the
latest kernel version I got is still 3.0.4+, so I think there is no any
device tree stuff in it.
@Angus, Would you give me a brief about the device tree support status on
our current 3.0.4+ kernel? Will you upgrade it to the 3.1 in 11.12 cycle?
@Thomas, In this blue print:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.…,
Tony mentioned that you has upstreamed the initial support for device tree.
However, it depends on the 3.1 kernel upgrade. I would like to know that is
there any possible that I can do something without the kernel upgrade?
I currently feel that this work highly depends on the outcome of landing
team and kernel group, so before I get something from them, I'm afraid that
I can't do any "real" work on this.
Thank you all for your help!
BR
Botao Sun
Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details.
I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.
We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.
The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.
Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.
Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches!
A git tree is available here:
git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm
the gitweb url is the following:
http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a…
And here is the full diff:
http://xenbits.xen.org/people/sstabellini/diff
We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.
I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.
Cheers,
Stefano
Amit/Mounir,
What's your guys plan with cpu_idle for each board? Are you going to
try and upstream a solution that will work across all boards? Would
you or Mounir be open to filing a BP per board so we can track when
cpu_idle will hit each board? Does it make sense to prototype
something across each board that we could land in Ubuntu and Android?
Adding other people, leads, etc...
--
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