From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider API
Date: Wed, 27 Aug 2014 09:58:44 -0600 [thread overview]
Message-ID: <20140827155844.GA911@obsidianresearch.com> (raw)
In-Reply-To: <20140826233008.5251.50447@quantum>
On Tue, Aug 26, 2014 at 04:30:08PM -0700, Mike Turquette wrote:
> 2) for the kexec-kernel-case, the responsibility is on the first kernel
> to set things up in a good state for the second kernel, with the
> exception of using kexec to debug/examime/recover from a kernel crash,
> in which case you likely don't care about this stuff as much
FWIW, we frequently use a kexec flow on Kirkwood for development here
- and I have not been able to get the initial kernel to cleanly shut
down before kexec'ing the second kernel.
The flow we've had to use involved including a pre-kernel stub in the
kexec flow that goes around and cleans up all the registers enough so
that the 2nd kernel will work properly. Critically it does things like
turn off ethernet DMA, because the initial kernel won't even do that
:|
There is some kind of support for doing this, but I ran out of time
unraveling the mess of config options to actually turn it on for
kirkwood.. It is tied to PM support which was/is missing elements on
Kirkwood..
Jason
next prev parent reply other threads:[~2014-08-27 15:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 15:30 [PATCH v7 0/8] Per-user clock constraints Tomeu Vizoso
2014-08-18 15:30 ` [PATCH v7 1/8] clk: Add temporary mapping to the existing API Tomeu Vizoso
2014-08-20 14:50 ` Mike Turquette
2014-08-21 18:04 ` Tony Lindgren
2014-08-21 18:10 ` Jason Cooper
2014-08-22 3:49 ` Simon Horman
2014-08-25 9:18 ` Sebastian Hesselbarth
2014-08-18 15:30 ` [PATCH v7 2/8] clk: provide public clk_is_enabled function Tomeu Vizoso
2014-08-18 15:30 ` [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider API Tomeu Vizoso
[not found] ` <20140820225513.5251.284@quantum>
2014-08-21 7:53 ` Tomeu Vizoso
2014-08-21 13:38 ` Andrew Lunn
2014-08-22 19:29 ` Mike Turquette
2014-08-22 20:11 ` Andrew Lunn
2014-08-22 20:27 ` Andrew Lunn
2014-08-26 21:46 ` Mike Turquette
2014-08-26 22:36 ` Andrew Lunn
2014-08-26 23:30 ` Mike Turquette
2014-08-27 0:35 ` Andrew Lunn
2014-08-27 5:04 ` Mike Turquette
2014-08-27 15:58 ` Jason Gunthorpe [this message]
2014-08-18 15:30 ` [PATCH v7 4/8] ASoC: mxs-saif: fix mixed use of public and provider clk API Tomeu Vizoso
2014-08-18 15:30 ` [PATCH v7 6/8] clk: use struct clk only for external API Tomeu Vizoso
2014-08-18 15:30 ` [PATCH v7 7/8] clk: per-user clock accounting for debug Tomeu Vizoso
2014-08-27 20:54 ` Mike Turquette
2014-08-18 15:30 ` [PATCH v7 8/8] clk: Add floor and ceiling constraints to clock rates Tomeu Vizoso
2014-08-21 2:12 ` [PATCH v7 0/8] Per-user clock constraints Andrew Lunn
2014-08-21 7:10 ` Tomeu Vizoso
2014-08-26 13:20 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140827155844.GA911@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).