linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Felipe Balbi <balbi@ti.com>
Cc: Roger Quadros <rogerq@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: Wed, 3 Jul 2013 10:30:30 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1307031023060.1241-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <20130703131513.GH15056@arwen.pp.htv.fi>

On Wed, 3 Jul 2013, Felipe Balbi wrote:

> On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
> > On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> > >> 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.
> > > 
> > > This, kinda, matches what OMAP tries to do with pad wakeup. Just that
> > > pad wakeup sits outside of the device itself. Perhaps we could look into
> > > how PCI handles the aux well and take some inspiration from there.
> > > 
> > > Any pointers under drivers/pci/ would be great :-)
> > > 
> > From what I understood, auxiliary well is just a power source, and it keeps
> > the EHCI controller powered even during suspend.
> > 
> > If that is true then it is different from our situation as we power down the
> > EHCI controller completely.
> 
> right but our "auxiliary well" keeps PRCM powered which can wake EHCI up
> ;-)
> 
> What I'm saying is that from ehci-omap's perspective, there's very
> little difference, specially since we route the wakeup through the same
> IRQ line anyway. Perhaps we could take some inspiration from the PCI
> land to make our hwmod/omap_device a little easier from driver
> perspective.
> 
> Or maybe it doesn't make sense ;-)

This idea probably won't lead anywhere.  To the best of my knowledge 
(and I'm not an expert on PCI), these different power wells are simply 
part of the PCI bus.  The bus controller knows to turn off one of them 
when the device (or maybe when all the devices on a bus segment) goes 
into D3.

One big difference with respect to OMAP is the way PCI handles wakeup
messages.  There's a separate bus signal, PME# (which stands for Power
Management Event), that a device asserts when it wants to send a wakeup
request.  When the ACPI driver sees the PME# signal, it searches
through the entire PCI tree to find the device or devices which need to
be resumed.  Or maybe when ACPI sees the signal, it tells the PCI core 
to do this -- I'm not sure of the details.

Alan Stern


  reply	other threads:[~2013-07-03 14:30 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
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 [this message]
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.1307031023060.1241-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).