linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 


  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).