linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Roger Quadros <rogerq@ti.com>
Cc: Felipe Balbi <balbi@ti.com>, <tony@atomide.com>,
	<ruslan.bilovol@ti.com>, <linux-usb@vger.kernel.org>,
	<linux-omap@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Date: Tue, 2 Jul 2013 13:17:58 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <51D28DB9.704@ti.com>

On Tue, 2 Jul 2013, Roger Quadros wrote:

> On 07/02/2013 12:01 AM, Alan Stern wrote:
> > On Mon, 1 Jul 2013, Felipe Balbi wrote:
> > 
> >>> I don't know what Pad wakeup is.  The wakeup signal has to originate 
> >>> from the EHCI controller, doesn't it?  If not, how does the Pad know 
> >>> when a wakeup is needed?
> >>
> >> That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
> >> inside and always on power domain. EHCI sits in another power domain
> >> which be turned off. When it's turned off (power gated and clock gated)
> >> the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
> >> comes into play. It is generated when PRCM sees a change in the actual
> >> pad of the die. To check who should 'own' the wakeup, it checks the
> >> muxing settings to verify whose pad is that.
> > 
> > How does the PRCM know which changes should generate wakeup events?  
> 
> It doesn't know. It will always generate a wakeup on any change in the monitored pins.
> We can only configure which pins we want to monitor.
> So we can't choose which wakeup events we want to monitor. We just can
> enable or disable all events.
> 
> > In the EHCI controller, this is managed by the settings of the WKOC_E,
> > WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers.  But if EHCI is
> > powered off, those bits can't be used.
> 
> Is "powered off" same as ehci_suspend? If yes then how does it work on other systems
> for remote wakeup?

Above, Felipe wrote that on OMAP, EHCI sits in a power domain which is
turned off: power gated and clock gated.  ehci_suspend() doesn't do
those things, but they are what I was referring to.

A PCI-based EHCI controller has two power sources: the core well (which
is turned off during suspend) and the auxiliary well (which remains
powered).  That's how remote wakeup works; it uses the auxiliary well.

> > Also, once the wakeup signal has been turned on, how does it get turned 
> > off again?
> 
> That is taken care of by the OMAP pinctrl driver. It will always turn off the
> wakeup signal once the event is detected and forwarded as an IRQ.
> 
> I know that all this is a bit ugly :(.

I still a little confused.  The wakeup signal turns on.  Then the
pinctrl driver sees it, forwards it as an IRQ, and turns the wakeup
signal off.  But what if the IRQ is disabled (as it would be with your
patch)?  Does the IRQ line remain active until it causes an interrupt?  
What eventually turns off the IRQ line?

Alan Stern


  reply	other threads:[~2013-07-02 17:18 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19 14:05 [RFC PATCH 0/6] Suspend USB Host controller on bus suspend Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init() Roger Quadros
2013-06-20 12:07   ` Felipe Balbi
2013-06-20 12:29     ` Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend Roger Quadros
2013-06-19 17:23   ` Kevin Hilman
2013-06-20  7:21     ` Tony Lindgren
2013-06-20 12:30     ` Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 3/6] USB: ehci: allow controller drivers to override irq & bus_suspend/resume Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend Roger Quadros
2013-06-19 17:39   ` Kevin Hilman
2013-06-20 12:32     ` Roger Quadros
2013-06-20 12:11   ` Felipe Balbi
2013-06-20 12:35     ` Roger Quadros
2013-06-20 17:33       ` Alan Stern
2013-06-24 15:09         ` Roger Quadros
2013-06-24 19:34           ` Alan Stern
2013-06-25 13:59             ` Roger Quadros
2013-06-25 17:38               ` Alan Stern
2013-06-26 13:38                 ` Roger Quadros
2013-06-27 15:40                   ` Alan Stern
2013-06-28 12:20                     ` Roger Quadros
2013-06-28 13:57                       ` Roger Quadros
2013-06-28 19:18                         ` Alan Stern
2013-07-01  8:33                           ` Roger Quadros
2013-06-28 19:06                       ` Alan Stern
2013-07-01  8:16                         ` Roger Quadros
2013-07-01 16:24                           ` Alan Stern
2013-07-01 16:49                             ` Felipe Balbi
2013-07-01 21:01                               ` Alan Stern
2013-07-02  8:22                                 ` Roger Quadros
2013-07-02 17:17                                   ` Alan Stern [this message]
2013-07-03  9:13                                     ` Roger Quadros
2013-07-03 12:57                                     ` Felipe Balbi
2013-07-03 13:06                                       ` Roger Quadros
2013-07-03 13:15                                         ` Felipe Balbi
2013-07-03 14:30                                           ` Alan Stern
2013-07-09 13:58                         ` Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host Roger Quadros
2013-06-19 18:42   ` Kevin Hilman
2013-06-20 11:55     ` Roger Quadros
2013-06-20 12:02       ` Roger Quadros
2013-06-20 13:02         ` Roger Quadros
2013-06-19 14:05 ` [RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host Roger Quadros
2013-06-19 17:30   ` Sergei Shtylyov
2013-06-20 12:42     ` Roger Quadros
2013-06-19 15:23 ` [RFC PATCH 0/6] Suspend USB Host controller on bus suspend Alan Stern
2013-06-20 12:39   ` Roger Quadros
2013-06-20 17:19     ` Alan Stern

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=Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@ti.com \
    --cc=ruslan.bilovol@ti.com \
    --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).