On 2013/4/1 23:12, Alan Stern wrote:
On Mon, 1 Apr 2013, Lan Tianyu wrote:
On 2013年03月30日 01:23, Alan Stern wrote:
On Fri, 29 Mar 2013, Sarah Sharp wrote:
However, what happens if you echo 0 to pm_qos_no_power_off, the
power/control is set to auto, and there's a suspended USB device
attached to the port with remote wakeup enabled? Will the port be
powered off? I don't think it will with the current patchset, but I
will have to double check.
It shouldn't be, because remote wakeup is enabled. But what about the
case where remote wakeup is disabled? Will writing a 0 to
pm_qos_no_power_off cause the power to be turned off?
Or what about the case where there's no device attached to the port? I
guess both questions amount to the same thing: When the user writes to
a pm_qos_* file, does the code call pm_runtime_idle?
Usb port's initial usage count is 0. For port attached with usb port,
when usb device is connected, the usb port's usage count is increased by
one. During device's suspend, its usage count would be decreased to 0
and powered of only when remote wakeup disable, persist enable and PM
Qos NO_POWER_OFF unsetting.
I already know all this.
During pm_qos_* file changing, pm_runtime_get_sync/put(port_dev) will be
done in the dev_pm_qos_update_flags(). The port's usage count would be
increased and decreased by 1. Whether the port's pm_runtime_idle would
be called depends on port's usage count to be set to 0.
That answers my question.
If the usb port has already been powered off(port usage count is already
set to 0), it would be powered on first and powered off depending the PM
Qos NO_POWER_OFF flag value.
Obviously.
If the usb port wasn't powered off, this mean the usb port didn't meet
power off condition() and its usage count was still greater than 0 So
during changing flag, only usage count was changed and no actual operation.
No, because one of the power off conditions is that the NO_POWER_OFF
flag must be clear. If that flag was set, the port won't be powered
off even though the usage count is equal to 0. If the write to the
pm_qos_* file then clears the flag, the port _will_ get powered off.
Hi Alan:
I think current code can't achieve that power off port(whose
child device was already suspended but it was not powered off due to
NO_POWER_OFF flag setting.) via clearing NO_POWER_OFF flag. Because
at that moment, its usage count can't be 0. At last, it should be
1 or large. port's pm_runtime_idle will not be called.
Further thinking, now we call pm_runtime_put_sync() in the
usb_port_suspend() when persist enable, do_remote_wakeup disable and
PM Qos NO_POWER_OFF flag cleared. But PM Qos NO_POWER_OFF flag will
also will be checked in the usb_port_runtime_suspend(). This seems
redundant.
From my opinion, the PM Qos check in the usb_port_suspend()
should be removed and port usage count will reach 0 when persist enable
and remote_wakeup disable. Whether power off or not totally depends on
the PM Qos flag in the usb_port_runtime_suspend(). For NO_POWER_OFF flag
setting case during usb device being suspend, the port's usage count
will be 0 but its runtime status is still active due to flag being set
and usb_port_runtime_suspend() returns -EAGAIN. At this time, clearing
the flag and the port can be powered off. Does this make sense?
For empty port, Only when PM Qos NO_POWER_OFF flag value is set to 0,
the port will be power off.
Alan Stern
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
