This issue surrounds the GO_IRQ_STATE command. This command typically follows a request from the device to perform some action, and then waits for the device to respond to the command once the action is complete. However, it is possible for the controller to also interrupt the device if/when it decides it no longer wishes to wait for the IRQ.
This leads to the very real possibility that both device and host might attempt to exit the IRQ state at the same time.
Mitigating this requires that the host leave the push-pull IO model, and also that it slow down the clock significantly.
Logic exists within the front end to detect collisions like this and to stop attempting to drive the bus if any are detected. This logic is known to have issues. Specifically, the synchronization between outgoing and incoming data doesn't (yet) match simulations with actually known hardware delays. As a result, collisions are likely to be detected if the host ever tries to exit the IRQ state even if no collision has actually taken place.
One potential solution is to leave collision detection off, and simply risk a malformed reply (CRC failure) in this case. Either way, the device will leave the IRQ state--it's just that an error might be detected when none actually existed.
This issue surrounds the
GO_IRQ_STATEcommand. This command typically follows a request from the device to perform some action, and then waits for the device to respond to the command once the action is complete. However, it is possible for the controller to also interrupt the device if/when it decides it no longer wishes to wait for the IRQ.This leads to the very real possibility that both device and host might attempt to exit the IRQ state at the same time.
Mitigating this requires that the host leave the push-pull IO model, and also that it slow down the clock significantly.
Logic exists within the front end to detect collisions like this and to stop attempting to drive the bus if any are detected. This logic is known to have issues. Specifically, the synchronization between outgoing and incoming data doesn't (yet) match simulations with actually known hardware delays. As a result, collisions are likely to be detected if the host ever tries to exit the IRQ state even if no collision has actually taken place.
One potential solution is to leave collision detection off, and simply risk a malformed reply (CRC failure) in this case. Either way, the device will leave the IRQ state--it's just that an error might be detected when none actually existed.
A longer term solution needs to be determined.