diff options
author | Noe Rubinstein <nrubinstein@proformatique.com> | 2010-11-19 10:38:18 +0100 |
---|---|---|
committer | Noe Rubinstein <nrubinstein@proformatique.com> | 2010-11-19 10:38:18 +0100 |
commit | b96bc6ff8387acff617d6efc419472d78dd9b2c1 (patch) | |
tree | 2aeb3a61f5ff78e8c6300d0606534953d5d1adcd /xhfc | |
parent | 0db1de3492ed6c868165960adca7593b5f0e47fc (diff) |
update notes
Diffstat (limited to 'xhfc')
-rw-r--r-- | xhfc/xhfc_st_state.c | 22 |
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. */ |