summaryrefslogtreecommitdiff
path: root/xhfc
diff options
context:
space:
mode:
authorNoe Rubinstein <nrubinstein@proformatique.com>2010-11-19 10:38:18 +0100
committerNoe Rubinstein <nrubinstein@proformatique.com>2010-11-19 10:38:18 +0100
commitb96bc6ff8387acff617d6efc419472d78dd9b2c1 (patch)
tree2aeb3a61f5ff78e8c6300d0606534953d5d1adcd /xhfc
parent0db1de3492ed6c868165960adca7593b5f0e47fc (diff)
update notes
Diffstat (limited to 'xhfc')
-rw-r--r--xhfc/xhfc_st_state.c22
1 files changed, 11 insertions, 11 deletions
diff --git a/xhfc/xhfc_st_state.c b/xhfc/xhfc_st_state.c
index 537b8d9..538fe30 100644
--- a/xhfc/xhfc_st_state.c
+++ b/xhfc/xhfc_st_state.c
@@ -70,30 +70,30 @@ void deactivate_request(struct xhfc_span* s) /* XXX not called */
}
/* This function is meant to be ran each time an interface changes state;
- * however, if the state change is polled instead of generating an interrupt
- * (what is done currently during the timer interrupt; see enable_interrupts
- * and xhfc_interrupt). In this case, it is possible that two or more state
- * changes happen on the same interface between two interruptions.
- * Additionally, even when using the ST state change interruptions, an
- * interruption can still be overlooked and lead to one of these conditions.
+ * however, the state change is polled (during the timer interrupt; see
+ * enable_interrupts and xhfc_interrupt). Therefore case, it is possible that
+ * two or more state changes happen on the same interface between two
+ * interruptions and that this functions gets only called once.
+ * Additionally, even when using the ST state change interrupt, an interruption
+ * can still be overlooked and lead to one of these conditions.
*
* However, there is no notable consequence because the actions are either:
*
* - Starting timers:
- * there is a problem iff a timer that should be started is not started and
- * cannot expire when it should
* - T3 is only started after an activation request, therefore we always now
* when T3 has to start
* - T1 is only started when going to state G2, which can only yield G3
- * automatically. This can be disallowed with V_G2_G3_EN so that the timer
+ * automatically. This can be disallowed in V_G2_G3_EN so that the timer
* can be started before allowing the transition with V_SU_SET_G2_G3.
* - Stopping timers:
* - T1 is only stopped on G2->G3.
* From G3:
* - G3->G2: if the timer is already running, stop it
* - on deactivate requests stop the timer
- * - T3 is stopped on going to state F7. I don't see how it is possible to
- * guarantee this.
+ * - T3 is stopped on going to state F7. I don't think it's possible to
+ * guarantee this; however except F2->F7 which can not happen when T3 is
+ * running, every transition to F7 stops the timer, so there is no incoherent
+ * behaviour;
* - Changing alarms in DAHDI, which will be done anyway. No point notifying
* something that lasts less that 1ms.
*/