Alan
On 10/18/2012 09:02 AM, Alan Stern wrote:
On Wed, 17 Oct 2012, vikram pandita wrote:
Alan
I was looking at your implementation [1] on Periodic schedule
enable/disable using hrtimer.
Looks really neat.
Thank you.
Current implementation is:
On Periodic Enable, Sate is: PSE =1 , PSS dont care - will be set
automatically after > 7 microframes time
On Periodic Disable, Sate is: PSE =0 , PSS dont care - will be cleared
automatically after > 7 microframes time
Could you shed some light why we don't make sure that:
On Periodic Enable, Sate is: PSE =1 and PSS=1
On Periodic Disable, State is: PSE =0 and PSS=0
Why on enable/disable would we not want to ensure PSS state is same as PSE?
Because it would be a waste of time. Eventually the controller will
set PSS equal to PSE; why should the driver wait for it? The driver
can go on to do other useful work in the meantime.
Thanks for your comments.
In a general working case of USB auto-suspend followed by
auto-resume/remote-wake, this looks fine and makes sense on PC/intel
controllers.
Lets consider EHCI controller on an ARM soc in a phone say attached to
modem with multiple IN interrupt EPs, and system wide suspend happens
(aka echo mem > /sys/power/state), as we do want to save power.
Scenario:
---
Active USB traffic - SOFs going on
USB auto-suspend: usb_runtime_suspend()
Device is first resumed to send int-urb: usb_runtime_resume()
|-> calls: enable_periodic()
Checks PSS==1, Sets PSE=1, [No check for PSS==1]
Trigger System Wide Suspend : echo mem > /sys/power/state
Device suspend started: usb_dev_suspend()
|-> calls: disable_periodic()
Checks PSS==1, Sets PSE=0, [No check for PSS==0]
Chip goes to low power mode like OFF.
*(Now at this stage we cannot guarantee PSS state: 0 or 1)
Wakeup the devcie, restore state of EHCI, etc....
---
We have seen in the past that time to disable Periodic schedule can be
variable on different hw.
Given we have left a window open by not checking PSS, its not guaranteed
in different EHCI implementations, what state would be restored: PSS 1
or PSS 0 - When we know we always wanted to restore in state PSS=0.
I have done this analysis on 3.0 kernel which does not have yet the 10ms
delay implementation in disable path. I am not sure how this 10ms
timeout will play with system wide suspend and could there be a race??
The EHCI spec states that PSE shouldn't be changed unless PSS is equal
to PSE, so we have to wait _before_ changing PSE. But we don't have to
wait _after_ changing it.
On 3.0 kernel with older implementation, this leads to HC died issues,
hence this query.
The older implementation was a over-cautious; after waiting 1125 us it
would die. The current implementation may be a little under-cautious,
because it gives up waiting for PSS after about 20 ms (and it doesn't
die). Some controllers may take even longer to adjust PSS, although I
can't imagine why.
Alan Stern
--
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
