From: Rajendra Nayak <rnayak@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
linux-omap@vger.kernel.org, linux@arm.linux.org.uk,
khilman@deeprootsystems.com, tony@atomide.com,
sourav.poddar@ti.com, vaibhav.bedia@ti.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
Date: Fri, 26 Apr 2013 12:38:31 +0530 [thread overview]
Message-ID: <517A27EF.40408@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1304230804410.30196@utopia.booyaka.com>
On Tuesday 23 April 2013 01:49 PM, Paul Walmsley wrote:
> Hi Rajendra,
>
> On Thu, 18 Apr 2013, Rajendra Nayak wrote:
>
>>>>> _enable_wakeup() and _disable_wakeup() are expected to program the
>>>>> OCP_SYSCONFIG.ENAWAKEUP bit.
>>>>
>>>> These functions were originally intended to take care of everything needed
>>>> for the IP block to wake up the chip, including the PRCM WKEN programming.
>>>> ENAWAKEUP is simply one part of that.
>>>>
>>>>> Get rid of the additional sidle/mstandby programming in them, as its
>>>>> confusing (this is expected to be handled elsewhere as part of
>>>>> _enable_sysc()/__idle_sysc())
>>>>
>>>> Sorry, why does the expectation exist for the code to enable and disable
>>>> device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in
>>>> functions called by _enable_sysc()/_idle_sysc()?
>>>
>>> It all comes down to if SIDLE_SMART_WKUP/MSTANDBY_SMART_WKUP programming
>>> be considered as 'idlemode' programming or 'enwakeup' programming.
>>> If you consider these are being part of 'enwakeup' progrmming, these should
>>> certainly be handled as part of _enable_wakeup() and _disable_wakeup().
>>>
>>> Today, in some cases, these are *also* handled as part of _enable_sysc()
>>> and _idle_sysc(). The way _enable_wakeup() is invoked from _enable_sysc()
>>> is also very inconsistent. For instance, for any IP which supports
>>> SYSC_HAS_MIDLEMODE and SYSC_HAS_ENAWAKEUP, we invoke _enable_wakeup()
>>> regardless of the MIDLEMODE programmmed.
>>> While in case of the IP supporting SYSC_HAS_SIDLEMODE, _enable_wakeup() is
>>> invoked only when the SIDLEMODE programmed is SMART or SMART_WKUP.
>>>
>>> I understand the cleanups you are suggesting below as part of the movement
>>> of some of these things outside of mach-omap2.
>>> I was more looking at fixing the existing piece so its readable and does
>>> things more consistently.
>>
>> Do you have any further thoughts on how we should do about this?
>
> Is it possible to implement a solution that preserves _enable_wakeup() and
> _disable_wakeup() as distinct functions, that can be called by separate
> wakeup control entry points?
>
> If it makes sense to change _enable_sysc() so that it doesn't call
> _enable_wakeup(), but does similar work itself, that's fine with me, as
> long as there's not too much code duplication.
>
> It will be good to have the inconsistencies fixed.
Sure, I'll post something on those lines shortly.
regards,
Rajendra
>
>
> - Paul
>
next prev parent reply other threads:[~2013-04-26 7:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 9:57 [PATCH 0/8] ARM; OMAP2+: hwmod and SERIAL: Remove sysc handling from driver Santosh Shilimkar
2013-02-20 9:57 ` [PATCH 1/8] ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag Santosh Shilimkar
2013-03-31 1:58 ` Paul Walmsley
2013-03-31 2:27 ` Paul Walmsley
2013-02-20 9:57 ` [PATCH 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming Santosh Shilimkar
2013-03-31 1:30 ` Paul Walmsley
2013-04-01 8:39 ` Rajendra Nayak
2013-04-18 10:53 ` Rajendra Nayak
2013-04-23 8:19 ` Paul Walmsley
2013-04-26 7:08 ` Rajendra Nayak [this message]
2013-02-20 9:57 ` [PATCH 3/8] ARM: OMAP2+: hwmod: Always have OCP_SYSCONFIG.ENAWAKEUP enabled Santosh Shilimkar
2013-03-31 1:32 ` Paul Walmsley
2013-02-20 9:57 ` [PATCH 4/8] ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active Santosh Shilimkar
2013-02-20 10:02 ` [PATCH 0/8] ARM; OMAP2+: hwmod and SERIAL: Remove sysc handling from driver Santosh Shilimkar
2013-02-20 10:14 ` Russell King - ARM Linux
2013-02-20 10:23 ` Santosh Shilimkar
2013-02-20 11:51 ` Russell King - ARM Linux
2013-02-20 13:26 ` Santosh Shilimkar
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=517A27EF.40408@ti.com \
--to=rnayak@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=sourav.poddar@ti.com \
--cc=tony@atomide.com \
--cc=vaibhav.bedia@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;
as well as URLs for NNTP newsgroup(s).