66 lines · plain
1========================2SoundWire Error Handling3========================4 5The SoundWire PHY was designed with care and errors on the bus are going to6be very unlikely, and if they happen it should be limited to single bit7errors. Examples of this design can be found in the synchronization8mechanism (sync loss after two errors) and short CRCs used for the Bulk9Register Access.10 11The errors can be detected with multiple mechanisms:12 131. Bus clash or parity errors: This mechanism relies on low-level detectors14 that are independent of the payload and usages, and they cover both control15 and audio data. The current implementation only logs such errors.16 Improvements could be invalidating an entire programming sequence and17 restarting from a known position. In the case of such errors outside of a18 control/command sequence, there is no concealment or recovery for audio19 data enabled by the SoundWire protocol, the location of the error will also20 impact its audibility (most-significant bits will be more impacted in PCM),21 and after a number of such errors are detected the bus might be reset. Note22 that bus clashes due to programming errors (two streams using the same bit23 slots) or electrical issues during the transmit/receive transition cannot24 be distinguished, although a recurring bus clash when audio is enabled is a25 indication of a bus allocation issue. The interrupt mechanism can also help26 identify Slaves which detected a Bus Clash or a Parity Error, but they may27 not be responsible for the errors so resetting them individually is not a28 viable recovery strategy.29 302. Command status: Each command is associated with a status, which only31 covers transmission of the data between devices. The ACK status indicates32 that the command was received and will be executed by the end of the33 current frame. A NAK indicates that the command was in error and will not34 be applied. In case of a bad programming (command sent to non-existent35 Slave or to a non-implemented register) or electrical issue, no response36 signals the command was ignored. Some Master implementations allow for a37 command to be retransmitted several times. If the retransmission fails,38 backtracking and restarting the entire programming sequence might be a39 solution. Alternatively some implementations might directly issue a bus40 reset and re-enumerate all devices.41 423. Timeouts: In a number of cases such as ChannelPrepare or43 ClockStopPrepare, the bus driver is supposed to poll a register field until44 it transitions to a NotFinished value of zero. The MIPI SoundWire spec 1.145 does not define timeouts but the MIPI SoundWire DisCo document adds46 recommendation on timeouts. If such configurations do not complete, the47 driver will return a -ETIMEOUT. Such timeouts are symptoms of a faulty48 Slave device and are likely impossible to recover from.49 50Errors during global reconfiguration sequences are extremely difficult to51handle:52 531. BankSwitch: An error during the last command issuing a BankSwitch is54 difficult to backtrack from. Retransmitting the Bank Switch command may be55 possible in a single segment setup, but this can lead to synchronization56 problems when enabling multiple bus segments (a command with side effects57 such as frame reconfiguration would be handled at different times). A global58 hard-reset might be the best solution.59 60Note that SoundWire does not provide a mechanism to detect illegal values61written in valid registers. In a number of cases the standard even mentions62that the Slave might behave in implementation-defined ways. The bus63implementation does not provide a recovery mechanism for such errors, Slave64or Master driver implementers are responsible for writing valid values in65valid registers and implement additional range checking if needed.66