요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
========================
SoundWire Error Handling
========================
The SoundWire PHY was designed with care and errors on the bus are going to
be very unlikely, and if they happen it should be limited to single bit
errors. Examples of this design can be found in the synchronization
mechanism (sync loss after two errors) and short CRCs used for the Bulk
Register Access.
The errors can be detected with multiple mechanisms:
1. Bus clash or parity errors: This mechanism relies on low-level detectors
that are independent of the payload and usages, and they cover both control
and audio data. The current implementation only logs such errors.
Improvements could be invalidating an entire programming sequence and
restarting from a known position. In the case of such errors outside of a
control/command sequence, there is no concealment or recovery for audio
data enabled by the SoundWire protocol, the location of the error will also
impact its audibility (most-significant bits will be more impacted in PCM),
and after a number of such errors are detected the bus might be reset. Note
that bus clashes due to programming errors (two streams using the same bit
slots) or electrical issues during the transmit/receive transition cannot
be distinguished, although a recurring bus clash when audio is enabled is a
indication of a bus allocation issue. The interrupt mechanism can also help
identify Slaves which detected a Bus Clash or a Parity Error, but they may
not be responsible for the errors so resetting them individually is not a
viable recovery strategy.
2. Command status: Each command is associated with a status, which only
covers transmission of the data between devices. The ACK status indicates
that the command was received and will be executed by the end of the
current frame. A NAK indicates that the command was in error and will not
be applied. In case of a bad programming (command sent to non-existent
Slave or to a non-implemented register) or electrical issue, no response
signals the command was ignored. Some Master implementations allow for a
command to be retransmitted several times. If the retransmission fails,
backtracking and restarting the entire programming sequence might be a
solution. Alternatively some implementations might directly issue a bus
reset and re-enumerate all devices.
3. Timeouts: In a number of cases such as ChannelPrepare or
ClockStopPrepare, the bus driver is supposed to poll a register field until
it transitions to a NotFinished value of zero. The MIPI SoundWire spec 1.1
does not define timeouts but the MIPI SoundWire DisCo document adds
recommendation on timeouts. If such configurations do not complete, the
driver will return a -ETIMEOUT. Such timeouts are symptoms of a faulty
Slave device and are likely impossible to recover from.
Errors during global reconfiguration sequences are extremely difficult to
handle:
1. BankSwitch: An error during the last command issuing a BankSwitch is
difficult to backtrack from. Retransmitting the Bank Switch command may be
possible in a single segment setup, but this can lead to synchronization
problems when enabling multiple bus segments (a command with side effects
such as frame reconfiguration would be handled at different times). A global
hard-reset might be the best solution.
Note that SoundWire does not provide a mechanism to detect illegal values
written in valid registers. In a number of cases the standard even mentions
that the Slave might behave in implementation-defined ways. The bus
implementation does not provide a recovery mechanism for such errors, Slave
or Master driver implementers are responsible for writing valid values in
valid registers and implement additional range checking if needed.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
PHY 오류 가정과 보호 장치
1-10SoundWire PHY는 bus error가 매우 드물고, 발생하더라도 single-bit error에 그치도록 신중하게 설계되었습니다.
이 설계 원칙은 두 번의 오류 뒤에 sync loss를 선언하는 synchronization mechanism과 Bulk Register Access(BRA)에 사용하는 짧은 CRC에서 확인할 수 있습니다.
========================
SoundWire Error Handling
========================
The SoundWire PHY was designed with care and errors on the bus are going to
be very unlikely, and if they happen it should be limited to single bit
errors. Examples of this design can be found in the synchronization
mechanism (sync loss after two errors) and short CRCs used for the Bulk
Register Access.
Bus clash와 parity error
11-29오류는 여러 mechanism으로 검출할 수 있습니다. 첫 번째는 payload와 usage에 독립적인 low-level detector가 찾는 Bus Clash 또는 Parity Error이며, control data와 audio data를 모두 포괄합니다. 현재 구현은 이런 오류를 log에 남기기만 합니다.
향후 개선안으로는 전체 programming sequence를 무효화하고 알려진 위치에서 다시 시작하는 방법이 있습니다. 그러나 control/command sequence 밖의 audio data 오류에는 SoundWire protocol이 제공하는 concealment나 recovery가 없습니다.
Audio 오류의 가청성은 위치에 따라 달라집니다. PCM에서는 most-significant bit 쪽 오류가 더 큰 영향을 줍니다. 이러한 오류가 일정 횟수 이상 검출되면 bus reset을 고려할 수 있습니다.
동일 bit slot을 두 stream이 사용한 programming error와 transmit/receive transition 중의 electrical issue는 구별할 수 없습니다. 다만 audio enable 때 Bus Clash가 반복되면 bus allocation 문제를 의심할 수 있습니다.
Interrupt mechanism으로 Bus Clash 또는 Parity Error를 검출한 Slave를 찾을 수는 있지만, 그 Slave가 원인이라는 보장은 없습니다. 따라서 개별 Slave reset은 실효성 있는 recovery strategy가 아닙니다.
검출 위치와 반복성은 복구 범위를 정하는 단서일 뿐, 오류 원인을 직접 특정하지는 못합니다.
The errors can be detected with multiple mechanisms:
1. Bus clash or parity errors: This mechanism relies on low-level detectors
that are independent of the payload and usages, and they cover both control
and audio data. The current implementation only logs such errors.
Improvements could be invalidating an entire programming sequence and
restarting from a known position. In the case of such errors outside of a
control/command sequence, there is no concealment or recovery for audio
data enabled by the SoundWire protocol, the location of the error will also
impact its audibility (most-significant bits will be more impacted in PCM),
and after a number of such errors are detected the bus might be reset. Note
that bus clashes due to programming errors (two streams using the same bit
slots) or electrical issues during the transmit/receive transition cannot
be distinguished, although a recurring bus clash when audio is enabled is a
indication of a bus allocation issue. The interrupt mechanism can also help
identify Slaves which detected a Bus Clash or a Parity Error, but they may
not be responsible for the errors so resetting them individually is not a
viable recovery strategy.
Command status와 재전송
30-41각 command에는 device 사이의 data transmission만 나타내는 status가 연결됩니다. 이 status는 register 값의 의미나 적용 결과까지 검증하지 않습니다.
`ACK`는 command를 수신했으며 현재 frame이 끝나기 전에 실행한다는 뜻입니다. `NAK`는 command에 오류가 있어 적용하지 않는다는 뜻입니다.
존재하지 않는 Slave나 구현되지 않은 register로 command를 보내는 잘못된 programming 또는 electrical issue가 있으면 response가 없으며, 이는 command가 무시됐음을 뜻합니다.
일부 Master 구현은 command를 여러 번 retransmit할 수 있습니다. 재전송도 실패하면 programming sequence를 backtrack해 처음부터 다시 시작하거나, 구현에 따라 bus reset 후 모든 device를 re-enumerate할 수 있습니다.
2. Command status: Each command is associated with a status, which only
covers transmission of the data between devices. The ACK status indicates
that the command was received and will be executed by the end of the
current frame. A NAK indicates that the command was in error and will not
be applied. In case of a bad programming (command sent to non-existent
Slave or to a non-implemented register) or electrical issue, no response
signals the command was ignored. Some Master implementations allow for a
command to be retransmitted several times. If the retransmission fails,
backtracking and restarting the entire programming sequence might be a
solution. Alternatively some implementations might directly issue a bus
reset and re-enumerate all devices.
Prepare timeout
42-49`ChannelPrepare`나 `ClockStopPrepare` 같은 절차에서 bus driver는 register field를 poll하여 `NotFinished`가 0으로 전이하기를 기다려야 합니다.
MIPI SoundWire specification 1.1은 timeout을 정의하지 않지만, MIPI SoundWire DisCo 문서는 timeout 권고를 추가합니다.
설정이 완료되지 않으면 driver는 `-ETIMEOUT`을 반환합니다. 이런 timeout은 faulty Slave device의 증상이며 복구가 사실상 불가능할 가능성이 큽니다.
설정 완료 여부를 poll하고 timeout이면 결함이 있는 Slave로 판단합니다.
3. Timeouts: In a number of cases such as ChannelPrepare or
ClockStopPrepare, the bus driver is supposed to poll a register field until
it transitions to a NotFinished value of zero. The MIPI SoundWire spec 1.1
does not define timeouts but the MIPI SoundWire DisCo document adds
recommendation on timeouts. If such configurations do not complete, the
driver will return a -ETIMEOUT. Such timeouts are symptoms of a faulty
Slave device and are likely impossible to recover from.
Global reconfiguration과 BankSwitch
50-59Global reconfiguration sequence 중 발생한 오류는 처리하기가 매우 어렵습니다.
마지막 command가 `BankSwitch`를 실행하는 시점에 오류가 나면 이전 상태로 backtrack하기 어렵습니다. Single-segment 구성에서는 Bank Switch command 재전송을 시도할 수 있습니다.
여러 bus segment를 enable하는 구성에서는 재전송이 synchronization 문제를 만들 수 있습니다. Frame reconfiguration처럼 side effect가 있는 command가 segment마다 서로 다른 시점에 처리될 수 있기 때문입니다.
이 경우에는 global hard-reset이 가장 적절한 해결책일 수 있습니다.
Errors during global reconfiguration sequences are extremely difficult to
handle:
1. BankSwitch: An error during the last command issuing a BankSwitch is
difficult to backtrack from. Retransmitting the Bank Switch command may be
possible in a single segment setup, but this can lead to synchronization
problems when enabling multiple bus segments (a command with side effects
such as frame reconfiguration would be handled at different times). A global
hard-reset might be the best solution.
유효 register의 불법 값
60-65SoundWire에는 valid register에 기록한 illegal value를 검출하는 mechanism이 없습니다. 일부 경우에는 표준 자체가 Slave의 동작을 implementation-defined로 규정합니다.
Bus implementation도 이런 오류를 위한 recovery mechanism을 제공하지 않습니다. Slave 또는 Master driver 구현자는 valid register에 valid value만 기록해야 하며, 필요하면 추가 range checking을 구현할 책임이 있습니다.
Note that SoundWire does not provide a mechanism to detect illegal values
written in valid registers. In a number of cases the standard even mentions
that the Slave might behave in implementation-defined ways. The bus
implementation does not provide a recovery mechanism for such errors, Slave
or Master driver implementers are responsible for writing valid values in
valid registers and implement additional range checking if needed.
요약과 해설
error_handling.rst:1-65SoundWire PHY는 오류를 드물고 국소적으로 만들도록 설계됐지만, protocol이 자동 복구를 제공하는 범위는 제한적입니다. Low-level bus error는 주로 기록하고, command 실패는 재전송·sequence 재시작·re-enumeration으로 대응하며, prepare timeout과 multi-segment BankSwitch 실패는 복구가 어렵습니다. 유효 register에 기록하는 값의 검증은 Slave·Master driver의 책임입니다.