From: George Cherian <george.cherian@ti.com>
To: balbi@ti.com
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
rogerq@ti.com, kishon@ti.com
Subject: Re: [PATCH 5/5] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume
Date: Wed, 14 May 2014 11:29:43 +0530 [thread overview]
Message-ID: <5373064F.4000204@ti.com> (raw)
In-Reply-To: <20140513155019.GN1151@saruman.home>
On 5/13/2014 9:20 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, May 08, 2014 at 03:03:07PM +0530, George Cherian wrote:
>> Enabling the core interrupts in complete is too late for XHCI, and stops
>> xhci from proper operation. So remove prepare and complete and disable/enable
> isn't this a bug in xhci ? I mean the driver should make no assumption
> as to when IRQs are enabled, why do we need to enable IRQs earlier when
> the device is only considered "ready for use" after ->complete()
> finishes executing ?
I dont think its a bug in xhci. In case of xhci-pci driver it actually
does an
hcd->driver->pci_suspend (xhci_suspend) followed by synchronize_irq()
and the does a pci_disable_device(). In resume path it calls
pci_enable_device()
followed by hcd->driver->pci_resume(xhci_resume).
In case of dwc3-omap we do have a wrapper register which can still
disable the XHCI IRQs
even though the xhci driver enables the interrupts internally.
Now dwc3-omap wrapper driver should not actually fiddle with the core
Interrupt
enable/disable except in probe/remove.
> From documentation we have:
>
> 107 * @complete: Undo the changes made by @prepare(). This method is executed for
> 108 * all kinds of resume transitions, following one of the resume callbacks:
> 109 * @resume(), @thaw(), @restore(). Also called if the state transition
> 110 * fails before the driver's suspend callback: @suspend(), @freeze() or
> 111 * @poweroff(), can be executed (e.g. if the suspend callback fails for one
> 112 * of the other devices that the PM core has unsuccessfully attempted to
> 113 * suspend earlier).
> 114 * The PM core executes subsystem-level @complete() after it has executed
> 115 * the appropriate resume callbacks for all devices.
>
> which tells me that using ->complete() to reenable IRQs is ok here.
> Specially when you consider that the role of ->prepare() is to prevent
> new children from being created and, for a USB host, that means we
> should prevent hub port changes.
Probably the patch should have been to still keep the complete/prepare
in place
but not disable the core interrupts, rather enable/disable only the
wrapper interrupt.
> cheers
>
--
-George
WARNING: multiple messages have this Message-ID (diff)
From: George Cherian <george.cherian@ti.com>
To: <balbi@ti.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<linux-usb@vger.kernel.org>, <gregkh@linuxfoundation.org>,
<rogerq@ti.com>, <kishon@ti.com>
Subject: Re: [PATCH 5/5] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume
Date: Wed, 14 May 2014 11:29:43 +0530 [thread overview]
Message-ID: <5373064F.4000204@ti.com> (raw)
In-Reply-To: <20140513155019.GN1151@saruman.home>
On 5/13/2014 9:20 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, May 08, 2014 at 03:03:07PM +0530, George Cherian wrote:
>> Enabling the core interrupts in complete is too late for XHCI, and stops
>> xhci from proper operation. So remove prepare and complete and disable/enable
> isn't this a bug in xhci ? I mean the driver should make no assumption
> as to when IRQs are enabled, why do we need to enable IRQs earlier when
> the device is only considered "ready for use" after ->complete()
> finishes executing ?
I dont think its a bug in xhci. In case of xhci-pci driver it actually
does an
hcd->driver->pci_suspend (xhci_suspend) followed by synchronize_irq()
and the does a pci_disable_device(). In resume path it calls
pci_enable_device()
followed by hcd->driver->pci_resume(xhci_resume).
In case of dwc3-omap we do have a wrapper register which can still
disable the XHCI IRQs
even though the xhci driver enables the interrupts internally.
Now dwc3-omap wrapper driver should not actually fiddle with the core
Interrupt
enable/disable except in probe/remove.
> From documentation we have:
>
> 107 * @complete: Undo the changes made by @prepare(). This method is executed for
> 108 * all kinds of resume transitions, following one of the resume callbacks:
> 109 * @resume(), @thaw(), @restore(). Also called if the state transition
> 110 * fails before the driver's suspend callback: @suspend(), @freeze() or
> 111 * @poweroff(), can be executed (e.g. if the suspend callback fails for one
> 112 * of the other devices that the PM core has unsuccessfully attempted to
> 113 * suspend earlier).
> 114 * The PM core executes subsystem-level @complete() after it has executed
> 115 * the appropriate resume callbacks for all devices.
>
> which tells me that using ->complete() to reenable IRQs is ok here.
> Specially when you consider that the role of ->prepare() is to prevent
> new children from being created and, for a USB host, that means we
> should prevent hub port changes.
Probably the patch should have been to still keep the complete/prepare
in place
but not disable the core interrupts, rather enable/disable only the
wrapper interrupt.
> cheers
>
--
-George
next prev parent reply other threads:[~2014-05-14 5:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 9:33 [PATCH 0/5] Cleanup and fixes for dwc3-omap George Cherian
2014-05-08 9:33 ` George Cherian
2014-05-08 9:33 ` [PATCH 1/5] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function George Cherian
2014-05-08 9:33 ` George Cherian
[not found] ` <1399541587-14067-2-git-send-email-george.cherian-l0cyMroinI0@public.gmane.org>
2014-05-13 16:02 ` Felipe Balbi
2014-05-13 16:02 ` Felipe Balbi
2014-05-14 5:41 ` George Cherian
2014-05-14 5:41 ` George Cherian
2014-05-08 9:33 ` [PATCH 2/5] usb: dwc3: dwc3-omap: Add dwc3_omap_set_utmi_mode() function George Cherian
2014-05-08 9:33 ` George Cherian
2014-05-08 9:33 ` [PATCH 3/5] usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function George Cherian
2014-05-08 9:33 ` George Cherian
2014-05-08 9:33 ` [PATCH 4/5] usb: dwc3: dwc3-omap: Fix the crash on module removal George Cherian
2014-05-08 9:33 ` George Cherian
2014-05-08 9:33 ` [PATCH 5/5] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume George Cherian
2014-05-08 9:33 ` George Cherian
[not found] ` <1399541587-14067-6-git-send-email-george.cherian-l0cyMroinI0@public.gmane.org>
2014-05-13 15:50 ` Felipe Balbi
2014-05-13 15:50 ` Felipe Balbi
2014-05-14 5:59 ` George Cherian [this message]
2014-05-14 5:59 ` George Cherian
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=5373064F.4000204@ti.com \
--to=george.cherian@ti.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rogerq@ti.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.