linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Kevin Hilman <khilman@linaro.org>,
	Hebbar Gururaja <gururaja.hebbar@ti.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
Date: Wed, 26 Jun 2013 16:20:16 +0300	[thread overview]
Message-ID: <51CAEA90.90200@ti.com> (raw)
In-Reply-To: <20130625065811.GZ5523@atomide.com>

Hi All,

On 06/25/2013 09:58 AM, Tony Lindgren wrote:
> * Linus Walleij <linus.walleij@linaro.org> [130624 05:13]:
>> On Fri, Jun 21, 2013 at 5:03 PM, Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>
>>> Hence, add pinctrl handling in omap_device core:
>>> 1) on PM runtime resume
>>> - switch pinctrl state to "default" (todo: "active")
>>> 2) on PM runtime suspend
>>> - switch pinctrl state to "idle"
>>> 3) during system wide suspend
>>> - switch pinctrl state to "sleep" or "idle" if omap_device core disables device
>>> - switch pinctrl state to "sleep" if device is disabled already
> Do you need a separate setting for "idle" and "sleep", or are
> they the same?
>
>>> 4) during system wide resume
>>> - switch pinctrl state to "default" (todo: "active") if omap_device core has
>>>    disabled  device during suspend
>>> - switch pinctrl state to "idle" if device was already disabled before suspend
>> I don't understand step 4.
>>
>> I get the creeps about whether the system is runtime suspended
>> or runtime resumed when we come to resume proper, so I need
>> Kevin to have a look at this.
>>
>> Apart from that it looks good.
>>
>> Stephen and Tony are trying to figure out the details of whether "active"
>> is necessary or not in a related thread I think.
Thanks for your comments.

I've prepared diagram to illustrate how does this work:
                                                  +
                                                  |
                                                  |  .probe()
                                                  |
                                            +-----v--------+
                                            |              |
                                            |  default     |
                                            |              |
                                            +----+--+------+
                                                 |  |
                               pm_runtime_get()  |  | pm_runtime_put()
                              +------------------+ +------------------+
|                                        |
                       +------v--------+ pm_runtime_put() +-------v-------+
                       | +----------------------->               |
           +----------->  Active       |      pm_runtime_get() | 
Idle        <--------------+
           |           | <-----------------------+               
|              |
           |           +-------+-------+ +-------+-------+              |
           | |.suspend_noirq()                       
|.suspend_noirq()      |
           | |                                       
|                      |
           | |                                       
|                      |
           | |                                       
|                      |
           | |                                       
|                      |
           |           +-------v-------+ +-------v--------+             |
           |           |               | |                |             |
           +-----------+  Sleep        ------+                 | 
Sleep         +-------------+
       .resume_noirq() |               |     | |                
|.resume_noirq()
                       +-------|-------+     | +----------------+
                               |   Idle      |
                               +-------------+

The "Sleep" pinctrl state is optional - if "sleep" state isn't defined
then "Idle" pinctrl state will be used during suspend.

As per above pinctrl state transition diagram - I think, that:
- if "idle" or "sleep" states are defined then "active" state have to be 
defined too.
So, pinctrl core should detect such situation and generate a warning.

 From my point of view, we should have "active" state - it would allow 
to avoid additional
runtime overhead and handle properly the case when drivers are used as 
loadable modules.
In this case, after boot, device's pinctrl registers can have HW default 
values (after reset) or
can be configured to some safe (off) state from board file (board's 
"default" configuration).
Driver module will activate its PINs when loaded and need to restore 
safe (off) PINs state when
unloaded.
As result, it seems, we should have "off" state which can be used when 
driver's module is removed.

So, final list of default pnctrl states may be defined as "default", 
"active", "idle", "sleep", "off":
- "active", "idle", "sleep": will be handled by omap_device core
- "default", "off": will be handled by driver itself (or Device core).



> Yes we should have that sorted out over next few weeks, so let's
> just wait a little while on all these dynamic remuxing patches
> to avoid churn.
>
> Regards,
>
> Tony

Regards,
- grygorii

  reply	other threads:[~2013-06-26 13:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 15:03 [RFC] ARM: OMAP2+: omap_device: add pinctrl handling Grygorii Strashko
2013-06-24 12:06 ` Linus Walleij
2013-06-25  6:58   ` Tony Lindgren
2013-06-26 13:20     ` Grygorii Strashko [this message]
2013-06-26 14:36       ` Grygorii Strashko
2013-06-26 19:31       ` Linus Walleij
2013-06-27  7:30         ` Tony Lindgren
2013-06-27 14:01         ` Grygorii Strashko
2013-06-27 14:45           ` Tony Lindgren
2013-06-27 16:04             ` Grygorii Strashko
2013-07-10 20:42             ` Linus Walleij
2013-07-10 20:36           ` Linus Walleij
2013-07-11  6:17             ` Tony Lindgren
2013-07-12 15:36             ` Grygorii Strashko
2013-07-22 21:00               ` Linus Walleij
2013-06-24 17:55 ` Kevin Hilman

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=51CAEA90.90200@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=gururaja.hebbar@ti.com \
    --cc=khilman@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --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).