From: Paul Walmsley <paul@pwsan.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"Aaro Koskinen" <aaro.koskinen@nokia.com>,
"Rajendra Nayak" <rnayak@ti.com>,
"Benoît Cousson" <b-cousson@ti.com>,
"Michael Buesch" <mb@bu3sch.de>
Subject: Re: [PATCH] OMAP: hwmod: add kernel cmdline flag to avoid resetting IP blocks during init
Date: Wed, 6 Jul 2011 15:01:49 -0600 (MDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1107061458460.4217@utopia.booyaka.com> (raw)
In-Reply-To: <20110706064326.GI5783@atomide.com>
On Tue, 5 Jul 2011, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [110705 18:55]:
> > On Tue, 5 Jul 2011, Paul Walmsley wrote:
> >
> > > For this case, we probably need some board file function to tell the
> > > hwmod code to disregard a device completely, to tell the kernel to
> > > pretend that the device does not exist.
> >
> > ... and the other problem here is that we currently probe devices via an
> > arch_initcall(), and the board file init_machine is also an arch_initcall.
> > Either we'll need to be very careful about Makefile ordering, or we should
> > just call omap2_init_devices() from the board file init_machine directly.
> > The latter makes the most sense to me.
>
> And that can then be passed the list of devices with the special flags
> for noreset, disabled and reserved. Then the late_initcall can optionally
> reset the rest of the devices.
'disabled' can probably be the default for a device that doesn't have a
driver associated with it, once the runtime PM conversion is complete.
That's what the late_initcall would do. Then if a driver is dynamically
loaded for one of those devices, the hwmod code would just re-enable it.
- Paul
next prev parent reply other threads:[~2011-07-06 21:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110703010204.19046.85186.stgit@dusk>
2011-07-03 1:02 ` [PATCH] OMAP: hwmod: add kernel cmdline flag to avoid resetting IP blocks during init Paul Walmsley
2011-07-04 8:55 ` Tony Lindgren
2011-07-06 1:42 ` Paul Walmsley
2011-07-06 2:00 ` Paul Walmsley
2011-07-06 6:43 ` Tony Lindgren
2011-07-06 21:01 ` Paul Walmsley [this message]
2011-07-06 6:41 ` Tony Lindgren
2011-07-06 20:57 ` Paul Walmsley
2011-07-07 5:27 ` Tony Lindgren
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=alpine.DEB.2.00.1107061458460.4217@utopia.booyaka.com \
--to=paul@pwsan.com \
--cc=aaro.koskinen@nokia.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mb@bu3sch.de \
--cc=rnayak@ti.com \
--cc=tony@atomide.com \
/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).