All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.