One USB mouse problem with runtime power management enabled

One USB mouse problem with runtime power management enabled

[Peter Chen]

Hi Jiri and Alan,

I have run below below at 3.5.7 kernel, but after checking upstream
kernel, it may also be existed.

1. evtest /dev/input/event1 &
2. Let mouse auto suspend, enable mouse as wakeup source, and let
the system enters suspend.
echo auto > /sys/bus/usb/devices/1-1/power/control

echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup

sleep 3
echo mem > /sys/power/state

3. Resume system with USB mouse button.

4. Console output endless with below message
hub 1-0:1.0: port 1 nyet suspended
hub 1-0:1.0: usb_suspend_interface: status -16
usb usb1: usb_suspend_both: status -16

5. The reason for above message
After system goes to suspend, the roothub is RPM_SUSPENDED
At hub_events it will auto resume roothub, then auto suspend
roothub after system resumes. When it tries to auto suspend roothub,
it will print above message. But usbhid interface is resumed 
by system resume, so its can_submit is 1.

Unlike the USB Keyboard, the mouse doesn't have any event after system
resume, so it will not restart OUT/CTRL queues. So the USB mouse will
not do autoresume and autosuspend.

For hid keyboard, it has below message at its usb_hidinput_input_event
after system resume:
hid-generic 0003:413C:2105.0002: type:17, code:0, value:0
hid-generic 0003:413C:2105.0002: type:17, code:1, value:0
hid-generic 0003:413C:2105.0002: type:17, code:2, value:0
hid-generic 0003:413C:2105.0002: type:20, code:1, value:33
hid-generic 0003:413C:2105.0002: type:20, code:0, value:250

6. It will not affect evtest, but the USBHID mouse seems will not do
auto-resume/auto-suspend again even the mouse's button is pressed.
Then the USBHID has always been active (although it is RPM_SUSPENDED)

>From my point, this problem may need to be fixed:
1. At usbhid/input layer:
Since the usbhid device has auto suspended before system suspend, then,
it should still auto suspended after system resume.
2. At USB layer:
It can do auto resume and auto suspend USB device
after system resume to keep the usb device runtime pm status correct.

Thanks.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: One USB mouse problem with runtime power management enabled

[Alan Stern]

On Wed, 3 Jul 2013, Peter Chen wrote:

> Hi Jiri and Alan,
> 
> I have run below below at 3.5.7 kernel, but after checking upstream
> kernel, it may also be existed.
> 
> 1. evtest /dev/input/event1 &
> 2. Let mouse auto suspend, enable mouse as wakeup source, and let
> the system enters suspend.
> echo auto > /sys/bus/usb/devices/1-1/power/control
> 
> echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
> echo enabled > /sys/bus/usb/devices/usb1/power/wakeup

You probably don't need this one.  The root hub ought to respond to the 
mouse's wakeup request, even if it isn't enabled for wakeup itself.

> echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
> echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
> 
> sleep 3
> echo mem > /sys/power/state
> 
> 3. Resume system with USB mouse button.
> 
> 4. Console output endless with below message
> hub 1-0:1.0: port 1 nyet suspended
> hub 1-0:1.0: usb_suspend_interface: status -16
> usb usb1: usb_suspend_both: status -16

This looks like the PM core thinks the mouse is runtime suspended when 
it really isn't.

I tried doing the same thing on a slightly modified 3.10 kernel.  It 
worked okay.  But my mouse was attached to a UHCI controller rather 
than EHCI, which may make a difference.

Have you tried running this test with 3.10?

> 5. The reason for above message
> After system goes to suspend, the roothub is RPM_SUSPENDED
> At hub_events it will auto resume roothub, then auto suspend
> roothub after system resumes. When it tries to auto suspend roothub,
> it will print above message. But usbhid interface is resumed 
> by system resume, so its can_submit is 1.

That's right.  The PM core should realize that the usbhid interface 
is resumed, so it shouldn't try to suspend the root hub.

> Unlike the USB Keyboard, the mouse doesn't have any event after system
> resume, so it will not restart OUT/CTRL queues. So the USB mouse will
> not do autoresume and autosuspend.

These things are handled by the USB core, not by the usbhid driver.

> For hid keyboard, it has below message at its usb_hidinput_input_event
> after system resume:
> hid-generic 0003:413C:2105.0002: type:17, code:0, value:0
> hid-generic 0003:413C:2105.0002: type:17, code:1, value:0
> hid-generic 0003:413C:2105.0002: type:17, code:2, value:0
> hid-generic 0003:413C:2105.0002: type:20, code:1, value:33
> hid-generic 0003:413C:2105.0002: type:20, code:0, value:250
> 
> 6. It will not affect evtest, but the USBHID mouse seems will not do
> auto-resume/auto-suspend again even the mouse's button is pressed.
> Then the USBHID has always been active (although it is RPM_SUSPENDED)

It is supposed to be RPM_ACTIVE.  How did it become RPM_SUSPENDED?

> From my point, this problem may need to be fixed:
> 1. At usbhid/input layer:
> Since the usbhid device has auto suspended before system suspend, then,
> it should still auto suspended after system resume.

No; almost all devices get resumed during system resume, even if they
were runtime-suspended beforehand.  If they want to autosuspend later
on, they can.

You can see this in drivers/usb/core/driver.c:usb_resume():

	status = usb_resume_both(udev, msg);
	if (status == 0) {
		pm_runtime_disable(dev);
		pm_runtime_set_active(dev);
		pm_runtime_enable(dev);
		unbind_no_reset_resume_drivers_interfaces(udev);
	}

The pm_runtime_set_active() call tells the PM core that the device is 
RPM_ACTIVE.

> 2. At USB layer:
> It can do auto resume and auto suspend USB device
> after system resume to keep the usb device runtime pm status correct.

The runtime PM status should be correct -- it should indicate that the 
device is active after a system resume.

Alan Stern

Re: One USB mouse problem with runtime power management enabled

[Peter Chen]

On Wed, Jul 03, 2013 at 12:29:08PM -0400, Alan Stern wrote:
> On Wed, 3 Jul 2013, Peter Chen wrote:
> 
> > Hi Jiri and Alan,
> > 
> > I have run below below at 3.5.7 kernel, but after checking upstream
> > kernel, it may also be existed.
> > 
> > 1. evtest /dev/input/event1 &
> > 2. Let mouse auto suspend, enable mouse as wakeup source, and let
> > the system enters suspend.
> > echo auto > /sys/bus/usb/devices/1-1/power/control
> > 
> > echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
> > echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
> 
> You probably don't need this one.  The root hub ought to respond to the 
> mouse's wakeup request, even if it isn't enabled for wakeup itself.
> 

Yes, it doesn't need for remote wakeup, but it is needed for
WKCN/WKDN(wakeup on connect/disconnect), my script need to take
all usb wakeup into account.

> > echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
> > echo enabled > /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
> > 
> > sleep 3
> > echo mem > /sys/power/state
> > 
> > 3. Resume system with USB mouse button.
> > 
> > 4. Console output endless with below message
> > hub 1-0:1.0: port 1 nyet suspended
> > hub 1-0:1.0: usb_suspend_interface: status -16
> > usb usb1: usb_suspend_both: status -16
> 
> This looks like the PM core thinks the mouse is runtime suspended when 
> it really isn't.
> 
> I tried doing the same thing on a slightly modified 3.10 kernel.  It 
> worked okay.  But my mouse was attached to a UHCI controller rather 
> than EHCI, which may make a difference.
> 
> Have you tried running this test with 3.10?
> 

Have you opened the mouse by apps (like evtest)?, for USB mouse, 
the usbhid->intf->needs_remote_wakeup is only set at .open/.close
API. That means if you have not opened mouse, the runtime pm status
for mouse will changed to RPM_ACTIVE (choose_wakeup -> pm_runtime_resume)
If you have opened the mouse, the runtime pm status is RPM_SUSPENDED.

> > 5. The reason for above message
> > After system goes to suspend, the roothub is RPM_SUSPENDED
> > At hub_events it will auto resume roothub, then auto suspend
> > roothub after system resumes. When it tries to auto suspend roothub,
> > it will print above message. But usbhid interface is resumed 
> > by system resume, so its can_submit is 1.
> 
> That's right.  The PM core should realize that the usbhid interface 
> is resumed, so it shouldn't try to suspend the root hub.

You mean runtime pm core? I find the runtime pm core doesn't know
the device has already resumed by system resume. For this case,
the pm_runtime_set_active(dev) has returned -EBUSY at usb_resume,
(I am still checking why, should be related to parent->power.disable_depth),
so the usbhid is still RPM_SUSPENDED.

> > 
> > 6. It will not affect evtest, but the USBHID mouse seems will not do
> > auto-resume/auto-suspend again even the mouse's button is pressed.
> > Then the USBHID has always been active (although it is RPM_SUSPENDED)
> 
> It is supposed to be RPM_ACTIVE.  How did it become RPM_SUSPENDED?

Yes, the same with above, it needs to check why 
pm_runtime_set_active(dev) has returned -EBUSY.

> 
> > From my point, this problem may need to be fixed:
> > 1. At usbhid/input layer:
> > Since the usbhid device has auto suspended before system suspend, then,
> > it should still auto suspended after system resume.
> 
> No; almost all devices get resumed during system resume, even if they
> were runtime-suspended beforehand.  If they want to autosuspend later
> on, they can.
> 
> You can see this in drivers/usb/core/driver.c:usb_resume():
> 
> 	status = usb_resume_both(udev, msg);
> 	if (status == 0) {
> 		pm_runtime_disable(dev);
> 		pm_runtime_set_active(dev);
> 		pm_runtime_enable(dev);
> 		unbind_no_reset_resume_drivers_interfaces(udev);
> 	}
> 
> The pm_runtime_set_active() call tells the PM core that the device is 
> RPM_ACTIVE.
> 
> > 2. At USB layer:
> > It can do auto resume and auto suspend USB device
> > after system resume to keep the usb device runtime pm status correct.
> 
> The runtime PM status should be correct -- it should indicate that the 
> device is active after a system resume.

Then, who should take the responsibility to put the device to autosuspend
if the device has auto-suspended before the system suspend, we can
see the ../power/control is still "auto".

Thanks.

-- 

Best Regards,
Peter Chen

Re: One USB mouse problem with runtime power management enabled

[Alan Stern]

On Thu, 4 Jul 2013, Peter Chen wrote:

> > I tried doing the same thing on a slightly modified 3.10 kernel.  It 
> > worked okay.  But my mouse was attached to a UHCI controller rather 
> > than EHCI, which may make a difference.
> > 
> > Have you tried running this test with 3.10?
> > 
> 
> Have you opened the mouse by apps (like evtest)?, for USB mouse, 
> the usbhid->intf->needs_remote_wakeup is only set at .open/.close
> API. That means if you have not opened mouse, the runtime pm status
> for mouse will changed to RPM_ACTIVE (choose_wakeup -> pm_runtime_resume)
> If you have opened the mouse, the runtime pm status is RPM_SUSPENDED.

Ah, okay, I will try that.

> > That's right.  The PM core should realize that the usbhid interface 
> > is resumed, so it shouldn't try to suspend the root hub.
> 
> You mean runtime pm core? I find the runtime pm core doesn't know
> the device has already resumed by system resume. For this case,
> the pm_runtime_set_active(dev) has returned -EBUSY at usb_resume,
> (I am still checking why, should be related to parent->power.disable_depth),
> so the usbhid is still RPM_SUSPENDED.

It sounds like this is the real problem.  Under normal conditions, the
runtime PM core won't allow pm_runtime_set_active() to succeed if the
device's parent is suspended.

In your case, the parent was the root hub, right?  So the root hub goes 
back into autosuspend too quickly.

> > The runtime PM status should be correct -- it should indicate that the 
> > device is active after a system resume.
> 
> Then, who should take the responsibility to put the device to autosuspend
> if the device has auto-suspended before the system suspend, we can
> see the ../power/control is still "auto".

This happens automatically, when the PM core calls pm_runtime_put()  
from device_complete() in drivers/base/power/main.c.  This has changed
since 3.5 -- in fact, that's probably the explanation for your problem.  
Back in 3.5, the pm_runtime_put() call was in device_resume() rather
than device_complete().  It was moved in 3.7.

Alan Stern

RE: One USB mouse problem with runtime power management enabled

[Chen Peter-B29397]

 
> >
> > Have you opened the mouse by apps (like evtest)?, for USB mouse,
> > the usbhid->intf->needs_remote_wakeup is only set at .open/.close
> > API. That means if you have not opened mouse, the runtime pm status
> > for mouse will changed to RPM_ACTIVE (choose_wakeup ->
> pm_runtime_resume)
> > If you have opened the mouse, the runtime pm status is RPM_SUSPENDED.
> 
> Ah, okay, I will try that.
> 
> > > That's right.  The PM core should realize that the usbhid interface
> > > is resumed, so it shouldn't try to suspend the root hub.
> >
> > You mean runtime pm core? I find the runtime pm core doesn't know
> > the device has already resumed by system resume. For this case,
> > the pm_runtime_set_active(dev) has returned -EBUSY at usb_resume,
> > (I am still checking why, should be related to parent-
> >power.disable_depth),
> > so the usbhid is still RPM_SUSPENDED.
> 
> It sounds like this is the real problem.  Under normal conditions, the
> runtime PM core won't allow pm_runtime_set_active() to succeed if the
> device's parent is suspended.
> 
> In your case, the parent was the root hub, right?  So the root hub goes
> back into autosuspend too quickly.
> 
> > > The runtime PM status should be correct -- it should indicate that
> the
> > > device is active after a system resume.
> >
> > Then, who should take the responsibility to put the device to
> autosuspend
> > if the device has auto-suspended before the system suspend, we can
> > see the ../power/control is still "auto".
> 
> This happens automatically, when the PM core calls pm_runtime_put()
> from device_complete() in drivers/base/power/main.c.  This has changed
> since 3.5 -- in fact, that's probably the explanation for your problem.
> Back in 3.5, the pm_runtime_put() call was in device_resume() rather
> than device_complete().  It was moved in 3.7.
> 
 
It works after cherry-pick yours [1] and Ulf Hansson's patch [2] (only your patch should
also work), besides, it needs to set controller active after system resume, or the
child (roothub) can't set itself as active.

( [1]PM: Prevent runtime suspend during system resume
[2] PM / Runtime: Asyncronous idle|suspend devices at system resume)


Thanks,
Peter