Hi Alan,
When I try to optimize system resume time, I find bus resume routine
cost much time (> 20ms), even there is no device at any ports.
Let's take ehci bus resume as an example.
1. At ehci_bus_resume
/* Some controller/firmware combinations need a delay during which
* they
On Tue, 9 Oct 2012, Peter Chen wrote:
> Hi Alan,
>
> When I try to optimize system resume time, I find bus resume routine
> cost much time (> 20ms), even there is no device at any ports.
> Let's take ehci bus resume as an example.
>
> 1. At ehci_bus_resume
>
> /* Some controller/firmware
On Tue, Oct 09, 2012 at 11:03:47AM -0400, Alan Stern wrote:
> On Tue, 9 Oct 2012, Peter Chen wrote:
>
> > Hi Alan,
> >
> > When I try to optimize system resume time, I find bus resume routine
> > cost much time (> 20ms), even there is no device at any ports.
> > Let's take ehci bus resume as an e
On Wed, 10 Oct 2012, Peter Chen wrote:
> On Tue, Oct 09, 2012 at 11:03:47AM -0400, Alan Stern wrote:
> > On Tue, 9 Oct 2012, Peter Chen wrote:
> >
> > > Hi Alan,
> > >
> > > When I try to optimize system resume time, I find bus resume routine
> > > cost much time (> 20ms), even there is no devic
On Wed, Oct 10, 2012 at 10:48:39AM -0400, Alan Stern wrote:
> On Wed, 10 Oct 2012, Peter Chen wrote:
>
> > On Tue, Oct 09, 2012 at 11:03:47AM -0400, Alan Stern wrote:
> > > On Tue, 9 Oct 2012, Peter Chen wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > When I try to optimize system resume time, I f
On Thu, 11 Oct 2012, Peter Chen wrote:
> > You could test all the port status registers. If any of them have the
> > PORT_PE bit set and the PORT_SUSPEND bit clear then the delay is
> > needed; otherwise it can be skipped.
>
> I think the condition should like below, as we need to consider remot
On Thu, Oct 11, 2012 at 03:20:51PM -0400, Alan Stern wrote:
> On Thu, 11 Oct 2012, Peter Chen wrote:
>
>
> > > There is a port on the root hub with suspend status clear
> > > and enabled status set (which implies there must be a device
> > > attached to the port, because disconnected ports
On Fri, 12 Oct 2012, Peter Chen wrote:
> Taking EHCI controller as an example, it just needs to change ehci_bus_resume,
> if there is any enabled, unsuspended port, set hcd->unsuspended_device_on_port
We don't need to do that. See below.
> > usb_bus_resume() can poll the port statuses to see if
On Fri, Oct 12, 2012 at 11:04:25AM -0400, Alan Stern wrote:
> On Fri, 12 Oct 2012, Peter Chen wrote:
>
> > Taking EHCI controller as an example, it just needs to change
> > ehci_bus_resume,
> > if there is any enabled, unsuspended port, set
> > hcd->unsuspended_device_on_port
>
> We don't need
On Tue, 16 Oct 2012, Peter Chen wrote:
> > --- usb-3.6.orig/drivers/usb/core/hcd.c
> > +++ usb-3.6/drivers/usb/core/hcd.c
> > @@ -2023,6 +2023,7 @@ int hcd_bus_resume(struct usb_device *rh
> > struct usb_hcd *hcd = container_of(rhdev->bus, struct usb_hcd, self);
> > int status
On Tue, 16 Oct 2012, Peter Chen wrote:
> I have tested it at Freescale i.mx6Q sabrelite board, your patch is ok.
> Will you post a patch or I do it for you?
I decided to use a different approach. The core should know which
ports are suspended without asking the HCD. Can you test this patch in
On Wed, Oct 17, 2012 at 05:28:22PM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2012, Peter Chen wrote:
>
> > I have tested it at Freescale i.mx6Q sabrelite board, your patch is ok.
> > Will you post a patch or I do it for you?
>
> I decided to use a different approach. The core should know which
On Thu, 18 Oct 2012, Peter Chen wrote:
> > I decided to use a different approach. The core should know which
> > ports are suspended without asking the HCD. Can you test this patch in
> > place of the other one?
> It shows below oops, you may not consider there is no device at port
> condition
On Thu, Oct 18, 2012 at 03:16:04PM -0400, Alan Stern wrote:
> On Thu, 18 Oct 2012, Peter Chen wrote:
>
> > > I decided to use a different approach. The core should know which
> > > ports are suspended without asking the HCD. Can you test this patch in
> > > place of the other one?
> > It shows
14 matches
Mail list logo