From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>,
linux-omap@vger.kernel.org, khilman@ti.com, b-cousson@ti.com,
Nishanth Menon <nm@ti.com>,
s-sintes@ti.com, Moiz Sonasath <m-sonasath@ti.com>
Subject: Re: [PATCH 7/7] 4460sdp/blaze/panda: hwmod: Prevent gpio1 reset during hwmod init
Date: Tue, 5 Jul 2011 23:47:54 -0700 [thread overview]
Message-ID: <20110706064754.GJ5783@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1107051534140.4217@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [110705 14:42]:
> On Tue, 5 Jul 2011, Tony Lindgren wrote:
> >
> > Can't we always reset the registered hwmods automatically one at a time when
> > omap_device_build is called?
>
> The experimental series that I wrote, but haven't posted yet, resets each
> IP block during the first time it's enabled -- which is probably going to
> be when omap_device_build() is called.
OK
> > > That would allow drivers to assume that they are starting from consistent
> > > device state. It also should prevent some power management problems
> > > that are dependent on particular bootloaders. How about if we add a
> > > second parameter, hwmod_reset_unused? The default could be 'no' and then
> > > only devices with PM runtime-enabled drivers would be reset first.
> >
> > Yes I think hwmod_reset_unsed would be a better name, but do we actually
> > need any other reset option in addition to that?
>
> If a driver doesn't reset its device(s) when it starts, then disabling all
> reset might allow the kernel to boot when the board file is missing some
> omap_hwmod_no_setup_reset() calls.
>
> Consider the 4460 GPIO case. If someone hasn't added in the
> omap_hwmod_no_setup_reset(gpioX_hwmod) call into the 4460 board file's
> init_machine(), then these boards would still crash on boot.
>
> This would definitely be considered a bug in the board file, that it's
> missing that omap_hwmod_no_setup_reset() call. But having a general
> 'hwmod_no_reset' might make it easier during initial board bring-up to
> determine whether a problem is caused by reset.
>
> In any case, it doesn't matter too much to me whether a 'hwmod_no_reset'
> option is preserved or not; this is just based on our discussion of the
> issue a few months ago.
Yeah. Sounds like for passing the board specific flags for special case
devices is best done with omap2_init_devices() like you suggested.
Tony
next prev parent reply other threads:[~2011-07-06 6:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 2:07 [PATCH 0/7] OMAP4: Add 4460 base support Rajendra Nayak
2011-07-01 2:07 ` [PATCH 1/7] OMAP: ID: introduce chip detection for OMAP4460 Rajendra Nayak
2011-07-01 2:07 ` [PATCH 2/7] OMAP4: ID: add omap_has_feature for max freq supported Rajendra Nayak
2011-07-01 2:07 ` [PATCH 3/7] OMAP4: PRCM: OMAP4460 specific PRM and CM register bitshifts Rajendra Nayak
2011-07-01 2:07 ` [PATCH 4/7] OMAP4: clocks: Update the clock tree with 4460 clock nodes Rajendra Nayak
2011-07-01 2:07 ` [PATCH 5/7] OMAP4: powerdomain: Reuse on 4460 using CHIP_IS_44XX Rajendra Nayak
2011-07-01 2:08 ` [PATCH 6/7] OMAP4: clockdomain: " Rajendra Nayak
2011-07-01 2:08 ` [PATCH 7/7] 4460sdp/blaze/panda: hwmod: Prevent gpio1 reset during hwmod init Rajendra Nayak
2011-07-01 6:32 ` Tony Lindgren
2011-07-03 4:14 ` Paul Walmsley
2011-07-04 8:53 ` Tony Lindgren
2011-07-05 7:40 ` Paul Walmsley
2011-07-05 10:45 ` Tony Lindgren
2011-07-05 21:47 ` Paul Walmsley
2011-07-06 6:47 ` Tony Lindgren [this message]
2011-07-01 2:41 ` [PATCH 2/7] OMAP4: ID: add omap_has_feature for max freq supported Todd Poynor
2011-07-01 4:48 ` Aneesh V
2011-07-01 6:25 ` [PATCH 1/7] OMAP: ID: introduce chip detection for OMAP4460 Tony Lindgren
2011-07-01 10:15 ` Aneesh V
2011-07-01 16:31 ` [PATCH 0/7] OMAP4: Add 4460 base support Kevin Hilman
2011-07-01 16:36 ` Kevin Hilman
2011-07-01 16:40 ` Kevin Hilman
2011-07-01 17:00 ` Rajendra Nayak
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=20110706064754.GJ5783@atomide.com \
--to=tony@atomide.com \
--cc=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=m-sonasath@ti.com \
--cc=nm@ti.com \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=s-sintes@ti.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