Alan
I was looking at your implementation [1] on Periodic schedule
enable/disable using hrtimer.
Looks really neat.
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?
On 3.0 kernel with older implementation, this leads to HC died issues,
hence this query.
Here is a quick attempt on what i mean:
(excuse the Tab replacement by space - cut/paste issue - this is just
for reference)
diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c
index 20dbdcb..b7a1c94 100644
--- a/drivers/usb/host/ehci-timer.c
+++ b/drivers/usb/host/ehci-timer.c
@@ -154,6 +154,7 @@ static void ehci_poll_PSS(struct ehci_hcd *ehci)
if (ehci->rh_state != EHCI_RH_RUNNING)
return;
+again:
want = (ehci->command & CMD_PSE) ? STS_PSS : 0;
actual = ehci_readl(ehci, &ehci->regs->status) & STS_PSS;
@@ -171,9 +172,11 @@ static void ehci_poll_PSS(struct ehci_hcd *ehci)
/* The status is up-to-date; restart or stop the schedule as
needed */
if (want == 0) { /* Stopped */
- if (ehci->periodic_count > 0)
+ if (ehci->periodic_count > 0) {
ehci_set_command_bit(ehci, CMD_PSE);
-
+ /* On Enable: make sure state is: PSE = 1, PSS =
1 */
+ goto again;
+ }
} else { /* Running */
if (ehci->periodic_count == 0) {
@@ -188,6 +191,8 @@ static void ehci_poll_PSS(struct ehci_hcd *ehci)
static void ehci_disable_PSE(struct ehci_hcd *ehci)
{
ehci_clear_command_bit(ehci, CMD_PSE);
+ /* On Disable: make sure state is: PSE = 0, PSS = 0 */
+ ehci_enable_event(ehci, EHCI_HRTIMER_POLL_PSS, true);
}
regards
vikram
[1] 3ca9aeb USB: EHCI: use hrtimer for the periodic schedule
--
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