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 5/6] USB: Support wakeup IRQ for suspended controllers
Date: Thu, 11 Jul 2013 10:30:35 +0300 [thread overview]
Message-ID: <51DE5F1B.8080201@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>
On 07/10/2013 10:08 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
>
>> Some platforms e.g. ehci-omap can generate an interrupt
>> (i.e. remote wakeup) even when the controller is suspended i.e.
>> HW_ACCESSIBLE is cleared.
>>
>> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
>> such cases.
>>
>> We tackle this case by disabling the IRQ, scheduling a
>> hub resume and enabling back the IRQ after the controller has
>> resumed. This ensures that the IRQ handler runs only after the
>> controller is accessible.
>
> Oh yes, one more thing...
>
>> @@ -132,6 +134,7 @@ struct usb_hcd {
>> unsigned wireless:1; /* Wireless USB HCD */
>> unsigned authorized_default:1;
>> unsigned has_tt:1; /* Integrated TT in root hub */
>> + unsigned has_wakeup_irq:1; /* Can IRQ when suspended */
>
> Please add a highly visible comment here, warning that has_wakeup_irq
> should never be set on systems with shared IRQs. Having both would ...
> well, it would indicate a really bad system design.
>
OK, will do.
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
From: rogerq@ti.com (Roger Quadros)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
Date: Thu, 11 Jul 2013 10:30:35 +0300 [thread overview]
Message-ID: <51DE5F1B.8080201@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>
On 07/10/2013 10:08 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
>
>> Some platforms e.g. ehci-omap can generate an interrupt
>> (i.e. remote wakeup) even when the controller is suspended i.e.
>> HW_ACCESSIBLE is cleared.
>>
>> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
>> such cases.
>>
>> We tackle this case by disabling the IRQ, scheduling a
>> hub resume and enabling back the IRQ after the controller has
>> resumed. This ensures that the IRQ handler runs only after the
>> controller is accessible.
>
> Oh yes, one more thing...
>
>> @@ -132,6 +134,7 @@ struct usb_hcd {
>> unsigned wireless:1; /* Wireless USB HCD */
>> unsigned authorized_default:1;
>> unsigned has_tt:1; /* Integrated TT in root hub */
>> + unsigned has_wakeup_irq:1; /* Can IRQ when suspended */
>
> Please add a highly visible comment here, warning that has_wakeup_irq
> should never be set on systems with shared IRQs. Having both would ...
> well, it would indicate a really bad system design.
>
OK, will do.
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
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 5/6] USB: Support wakeup IRQ for suspended controllers
Date: Thu, 11 Jul 2013 10:30:35 +0300 [thread overview]
Message-ID: <51DE5F1B.8080201@ti.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>
On 07/10/2013 10:08 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
>
>> Some platforms e.g. ehci-omap can generate an interrupt
>> (i.e. remote wakeup) even when the controller is suspended i.e.
>> HW_ACCESSIBLE is cleared.
>>
>> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
>> such cases.
>>
>> We tackle this case by disabling the IRQ, scheduling a
>> hub resume and enabling back the IRQ after the controller has
>> resumed. This ensures that the IRQ handler runs only after the
>> controller is accessible.
>
> Oh yes, one more thing...
>
>> @@ -132,6 +134,7 @@ struct usb_hcd {
>> unsigned wireless:1; /* Wireless USB HCD */
>> unsigned authorized_default:1;
>> unsigned has_tt:1; /* Integrated TT in root hub */
>> + unsigned has_wakeup_irq:1; /* Can IRQ when suspended */
>
> Please add a highly visible comment here, warning that has_wakeup_irq
> should never be set on systems with shared IRQs. Having both would ...
> well, it would indicate a really bad system design.
>
OK, will do.
cheers,
-roger
next prev parent reply other threads:[~2013-07-11 7:30 UTC|newest]
Thread overview: 59+ 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 ` Roger Quadros
2013-07-10 16:17 ` 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:17 ` Roger Quadros
2013-07-10 16:17 ` 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 ` Roger Quadros
2013-07-10 16:22 ` 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:22 ` Roger Quadros
2013-07-10 16:22 ` 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-10 16:23 ` Roger Quadros
2013-07-10 16:23 ` Roger Quadros
2013-07-14 13:22 ` Kevin Hilman
2013-07-14 13:22 ` Kevin Hilman
2013-07-15 8:23 ` Roger Quadros
2013-07-15 8:23 ` Roger Quadros
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 16:23 ` Roger Quadros
2013-07-10 16:23 ` Roger Quadros
2013-07-10 18:45 ` Alan Stern
2013-07-10 18:45 ` Alan Stern
2013-07-10 18:45 ` Alan Stern
2013-07-11 7:30 ` Roger Quadros
2013-07-11 7:30 ` Roger Quadros
2013-07-11 7:30 ` Roger Quadros
2013-07-10 19:08 ` Alan Stern
2013-07-10 19:08 ` Alan Stern
2013-07-10 19:08 ` Alan Stern
2013-07-11 7:30 ` Roger Quadros [this message]
2013-07-11 7:30 ` Roger Quadros
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 16:23 ` Roger Quadros
2013-07-10 16:23 ` Roger Quadros
2013-07-10 19:04 ` Alan Stern
2013-07-10 19:04 ` Alan Stern
2013-07-10 19:04 ` Alan Stern
2013-07-11 8:50 ` Roger Quadros
2013-07-11 8:50 ` Roger Quadros
2013-07-11 8:50 ` Roger Quadros
[not found] ` <51DE71F3.1040101-l0cyMroinI0@public.gmane.org>
2013-07-11 15:14 ` Alan Stern
2013-07-11 15:14 ` Alan Stern
2013-07-11 15:14 ` Alan Stern
2013-07-22 13:16 ` Roger Quadros
2013-07-22 13:16 ` Roger Quadros
2013-07-22 13:16 ` Roger Quadros
2013-07-22 15:18 ` Alan Stern
2013-07-22 15:18 ` Alan Stern
2013-07-22 15:18 ` Alan Stern
2013-07-23 9:18 ` Roger Quadros
2013-07-23 9:18 ` Roger Quadros
2013-07-23 9:18 ` Roger Quadros
2013-07-23 14:14 ` Alan Stern
2013-07-23 14:14 ` Alan Stern
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=51DE5F1B.8080201@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.