public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: <gregkh@linuxfoundation.org>, <balbi@ti.com>,
	<sergei.shtylyov@cogentembedded.com>, <khilman@linaro.org>,
	<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: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
Date: Tue, 23 Jul 2013 12:18:52 +0300	[thread overview]
Message-ID: <51EE4A7C.2020709@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1307221111410.1495-100000@iolanthe.rowland.org>

On 07/22/2013 06:18 PM, Alan Stern wrote:
> On Mon, 22 Jul 2013, Roger Quadros wrote:
> 
>> Right, I understand it now. How does the below code look?
>>
>> +static int omap_ehci_suspend(struct device *dev)
>> +{
>> +       struct usb_hcd *hcd = dev_get_drvdata(dev);
>> +       bool do_wakeup = device_may_wakeup(dev);
>> +       int ret;
>> +
>> +       dev_dbg(dev, "%s may_wakeup %d\n", __func__, do_wakeup);
>> +
>> +       if (pm_runtime_status_suspended(dev)) {
> 
> You need to do this only when do_wakeup is false.

Right. Missed that.
> 
>> +               pm_runtime_get_sync(dev);
>> +               ehci_resume(hcd, false);
>> +               ret = ehci_suspend(hcd, do_wakeup);
>> +               pm_runtime_put_sync(dev);
> 
> It would be better to call pm_runtime_resume(dev) at the start instead
> of pm_runtime_get_sync(), and eliminate the last two lines.  Then the
> ehci_suspend() below could be moved outside the "if" statement.

Why do I find pm_runtime_* so confusing ;)

> 
> Alternatively, if you are able to turn off the wakeup setting without
> going through an entire resume/suspend cycle, that would be preferable.
> 

As we don't rely on the EHCI controller's interrupt any more after we
power it down, maybe ehci_resume/suspend cycle is not required at all on OMAP,
even if the wakeup setting is disabled during system suspend.

As the wakeup is controlled entirely by pad wakeup, all we need to do is make sure
the IO pad wakeup is configured correctly based on do_wakeup. How this is done
is still in transition but it might be turn out to be as simple as irq_set_irq_wake()

So IMHO, for ehci-omap this should suffice

static int omap_ehci_suspend(struct device *dev)
{
	struct usb_hcd *hcd = dev_get_drvdata(dev);
	bool do_wakeup = device_may_wakeup(dev);
	int ret = 0;

	if (!pm_runtime_status_suspended(dev))
		ret = ehci_suspend(hcd, do_wakeup);

	/* Not tested yet */
	irq_set_irq_wake(hcd->irq, do_wakeup);

	return ret;
}

What do you think?

As the OMAP IO pad wakeup management code [1] is still in transition, I'll wait till
that gets settled and then resend this series.

cheers,
-roger

[1] - http://thread.gmane.org/gmane.linux.ports.arm.omap/99010

  reply	other threads:[~2013-07-23  9:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-10 16:17 [PATCH 0/6] USB: Implement runtime idling and remote wakeup for OMAP EHCI controller Roger Quadros
2013-07-10 16:17 ` [PATCH 1/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host Roger Quadros
2013-07-10 16:22 ` [PATCH 2/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host Roger Quadros
2013-07-10 16:22 ` [PATCH 3/6] mfd: omap-usb-host: move initialization to module_init() Roger Quadros
2013-07-10 16:23 ` [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend Roger Quadros
2013-07-14 13:22   ` Kevin Hilman
2013-07-15  8:23     ` Roger Quadros
2013-07-10 16:23 ` [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers Roger Quadros
2013-07-10 18:45   ` Alan Stern
2013-07-11  7:30     ` Roger Quadros
2013-07-10 19:08   ` Alan Stern
2013-07-11  7:30     ` Roger Quadros
2013-07-10 16:23 ` [PATCH 6/6] USB: ehci-omap: Implement suspend/resume Roger Quadros
2013-07-10 19:04   ` Alan Stern
2013-07-11  8:50     ` Roger Quadros
2013-07-11 15:14       ` Alan Stern
2013-07-22 13:16         ` Roger Quadros
2013-07-22 15:18           ` Alan Stern
2013-07-23  9:18             ` Roger Quadros [this message]
2013-07-23 14:14               ` 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=51EE4A7C.2020709@ti.com \
    --to=rogerq@ti.com \
    --cc=balbi@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=khilman@linaro.org \
    --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=ruslan.bilovol@ti.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=stern@rowland.harvard.edu \
    --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