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 03:45:53 -0700 [thread overview]
Message-ID: <20110705104553.GF5783@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1107050136120.4217@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [110705 00:35]:
> Hi Tony
>
> On Mon, 4 Jul 2011, Tony Lindgren wrote:
>
> > * Paul Walmsley <paul@pwsan.com> [110702 21:09]:
> >
> > > Here are some options that come to mind:
> > >
> > > 1. Wait until the driver runtime PM conversion is finished before doing
> > > anything. In the meantime, boards with IP blocks that can't be reset
> > > - N810, TI 4460 boards - will have problems.
> > >
> > > 2. Merge the lazy/unused hwmod reset code, but prevent IP blocks
> > > controlled by non-runtime PM drivers from being reset. We'd have to
> > > maintain a list of these somewhere, perhaps in some common code called
> > > by board file init_machine code. Then we'd need to redact that list as
> > > new driver runtime PM conversions complete.
> > >
> > > 3. Merge the lazy/unused hwmod reset code, but disable the unused hwmod
> > > reset code until the driver runtime PM conversion is finished. This
> > > could cause problems with driverless devices that are left configured
> > > by bootloaders or ROM code, and that problem would reoccur for each new
> > > OMAP chip.
> > >
> > > Do you have a preference as to which approach to take?
> >
> > I think #3 above is the safest option. How about make it only happen with
> > hwmod_reset=1 cmdline with 0 being the default value?
>
> With the patch that was posted, that would disable all reset. Probably we
> want to reset devices that have drivers with PM runtime support?
Can't we always reset the registered hwmods automatically one at a time when
omap_device_build is called?
> 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?
TOny
next prev parent reply other threads:[~2011-07-05 10:45 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 [this message]
2011-07-05 21:47 ` Paul Walmsley
2011-07-06 6:47 ` Tony Lindgren
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=20110705104553.GF5783@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