요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _cec_pin_error_inj:
CEC Pin Framework Error Injection
=================================
The CEC Pin Framework is a core CEC framework for CEC hardware that only
has low-level support for the CEC bus. Most hardware today will have
high-level CEC support where the hardware deals with driving the CEC bus,
but some older devices aren't that fancy. However, this framework also
allows you to connect the CEC pin to a GPIO on e.g. a Raspberry Pi and
you have now made a CEC adapter.
What makes doing this so interesting is that since we have full control
over the bus it is easy to support error injection. This is ideal to
test how well CEC adapters can handle error conditions.
Currently only the cec-gpio driver (when the CEC line is directly
connected to a pull-up GPIO line) and the AllWinner A10/A20 drm driver
support this framework.
If ``CONFIG_CEC_PIN_ERROR_INJ`` is enabled, then error injection is available
through debugfs. Specifically, in ``/sys/kernel/debug/cec/cecX/`` there is
now an ``error-inj`` file.
.. note::
The error injection commands are not a stable ABI and may change in the
future.
With ``cat error-inj`` you can see both the possible commands and the current
error injection status::
$ cat /sys/kernel/debug/cec/cec0/error-inj
# Clear error injections:
# clear clear all rx and tx error injections
# rx-clear clear all rx error injections
# tx-clear clear all tx error injections
# <op> clear clear all rx and tx error injections for <op>
# <op> rx-clear clear all rx error injections for <op>
# <op> tx-clear clear all tx error injections for <op>
#
# RX error injection settings:
# rx-no-low-drive do not generate low-drive pulses
#
# RX error injection:
# <op>[,<mode>] rx-nack NACK the message instead of sending an ACK
# <op>[,<mode>] rx-low-drive <bit> force a low-drive condition at this bit position
# <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message
# <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message
# any[,<mode>] rx-arb-lost [<poll>] generate a POLL message to trigger an arbitration lost
#
# TX error injection settings:
# tx-ignore-nack-until-eom ignore early NACKs until EOM
# tx-custom-low-usecs <usecs> define the 'low' time for the custom pulse
# tx-custom-high-usecs <usecs> define the 'high' time for the custom pulse
# tx-custom-pulse transmit the custom pulse once the bus is idle
# tx-glitch-low-usecs <usecs> define the 'low' time for the glitch pulse
# tx-glitch-high-usecs <usecs> define the 'high' time for the glitch pulse
# tx-glitch-falling-edge send the glitch pulse after every falling edge
# tx-glitch-rising-edge send the glitch pulse after every rising edge
#
# TX error injection:
# <op>[,<mode>] tx-no-eom don't set the EOM bit
# <op>[,<mode>] tx-early-eom set the EOM bit one byte too soon
# <op>[,<mode>] tx-add-bytes <num> append <num> (1-255) spurious bytes to the message
# <op>[,<mode>] tx-remove-byte drop the last byte from the message
# <op>[,<mode>] tx-short-bit <bit> make this bit shorter than allowed
# <op>[,<mode>] tx-long-bit <bit> make this bit longer than allowed
# <op>[,<mode>] tx-custom-bit <bit> send the custom pulse instead of this bit
# <op>[,<mode>] tx-short-start send a start pulse that's too short
# <op>[,<mode>] tx-long-start send a start pulse that's too long
# <op>[,<mode>] tx-custom-start send the custom pulse instead of the start pulse
# <op>[,<mode>] tx-last-bit <bit> stop sending after this bit
# <op>[,<mode>] tx-low-drive <bit> force a low-drive condition at this bit position
#
# <op> CEC message opcode (0-255) or 'any'
# <mode> 'once' (default), 'always', 'toggle' or 'off'
# <bit> CEC message bit (0-159)
# 10 bits per 'byte': bits 0-7: data, bit 8: EOM, bit 9: ACK
# <poll> CEC poll message used to test arbitration lost (0x00-0xff, default 0x0f)
# <usecs> microseconds (0-10000000, default 1000)
clear
You can write error injection commands to ``error-inj`` using
``echo 'cmd' >error-inj`` or ``cat cmd.txt >error-inj``. The ``cat error-inj``
output contains the current error commands. You can save the output to a file
and use it as an input to ``error-inj`` later.
Basic Syntax
------------
Leading spaces/tabs are ignored. If the next character is a ``#`` or the end
of the line was reached, then the whole line is ignored. Otherwise a command
is expected.
The error injection commands fall in two main groups: those relating to
receiving CEC messages and those relating to transmitting CEC messages. In
addition, there are commands to clear existing error injection commands and
to create custom pulses on the CEC bus.
Most error injection commands can be executed for specific CEC opcodes or for
all opcodes (``any``). Each command also has a 'mode' which can be ``off``
(can be used to turn off an existing error injection command), ``once``
(the default) which will trigger the error injection only once for the next
received or transmitted message, ``always`` to always trigger the error
injection and ``toggle`` to toggle the error injection on or off for every
transmit or receive.
So '``any rx-nack``' will NACK the next received CEC message,
'``any,always rx-nack``' will NACK all received CEC messages and
'``0x82,toggle rx-nack``' will only NACK if an Active Source message was
received and do that only for every other received message.
After an error was injected with mode ``once`` the error injection command
is cleared automatically, so ``once`` is a one-time deal.
All combinations of ``<op>`` and error injection commands can co-exist. So
this is fine::
0x9e tx-add-bytes 1
0x9e tx-early-eom
0x9f tx-add-bytes 2
any rx-nack
All four error injection commands will be active simultaneously.
However, if the same ``<op>`` and command combination is specified,
but with different arguments::
0x9e tx-add-bytes 1
0x9e tx-add-bytes 2
Then the second will overwrite the first.
Clear Error Injections
----------------------
``clear``
Clear all error injections.
``rx-clear``
Clear all receive error injections
``tx-clear``
Clear all transmit error injections
``<op> clear``
Clear all error injections for the given opcode.
``<op> rx-clear``
Clear all receive error injections for the given opcode.
``<op> tx-clear``
Clear all transmit error injections for the given opcode.
Receive Messages
----------------
``<op>[,<mode>] rx-nack``
NACK broadcast messages and messages directed to this CEC adapter.
Every byte of the message will be NACKed in case the transmitter
keeps transmitting after the first byte was NACKed.
``<op>[,<mode>] rx-low-drive <bit>``
Force a Low Drive condition at this bit position. If <op> specifies
a specific CEC opcode then the bit position must be at least 18,
otherwise the opcode hasn't been received yet. This tests if the
transmitter can handle the Low Drive condition correctly and reports
the error correctly. Note that a Low Drive in the first 4 bits can also
be interpreted as an Arbitration Lost condition by the transmitter.
This is implementation dependent.
``<op>[,<mode>] rx-add-byte``
Add a spurious 0x55 byte to the received CEC message, provided
the message was 15 bytes long or less. This is useful to test
the high-level protocol since spurious bytes should be ignored.
``<op>[,<mode>] rx-remove-byte``
Remove the last byte from the received CEC message, provided it
was at least 2 bytes long. This is useful to test the high-level
protocol since messages that are too short should be ignored.
``<op>[,<mode>] rx-arb-lost <poll>``
Generate a POLL message to trigger an Arbitration Lost condition.
This command is only allowed for ``<op>`` values of ``next`` or ``all``.
As soon as a start bit has been received the CEC adapter will switch
to transmit mode and it will transmit a POLL message. By default this is
0x0f, but it can also be specified explicitly via the ``<poll>`` argument.
This command can be used to test the Arbitration Lost condition in
the remote CEC transmitter. Arbitration happens when two CEC adapters
start sending a message at the same time. In that case the initiator
with the most leading zeroes wins and the other transmitter has to
stop transmitting ('Arbitration Lost'). This is very hard to test,
except by using this error injection command.
This does not work if the remote CEC transmitter has logical address
0 ('TV') since that will always win.
``rx-no-low-drive``
The receiver will ignore situations that would normally generate a
Low Drive pulse (3.6 ms). This is typically done if a spurious pulse is
detected when receiving a message, and it indicates to the transmitter that
the message has to be retransmitted since the receiver got confused.
Disabling this is useful to test how other CEC devices handle glitches
by ensuring we will not be the one that generates a Low Drive.
Transmit Messages
-----------------
``tx-ignore-nack-until-eom``
This setting changes the behavior of transmitting CEC messages. Normally
as soon as the receiver NACKs a byte the transmit will stop, but the
specification also allows that the full message is transmitted and only
at the end will the transmitter look at the ACK bit. This is not
recommended behavior since there is no point in keeping the CEC bus busy
for longer than is strictly needed. Especially given how slow the bus is.
This setting can be used to test how well a receiver deals with
transmitters that ignore NACKs until the very end of the message.
``<op>[,<mode>] tx-no-eom``
Don't set the EOM bit. Normally the last byte of the message has the EOM
(End-Of-Message) bit set. With this command the transmit will just stop
without ever sending an EOM. This can be used to test how a receiver
handles this case. Normally receivers have a time-out after which
they will go back to the Idle state.
``<op>[,<mode>] tx-early-eom``
Set the EOM bit one byte too soon. This obviously only works for messages
of two bytes or more. The EOM bit will be set for the second-to-last byte
and not for the final byte. The receiver should ignore the last byte in
this case. Since the resulting message is likely to be too short for this
same reason the whole message is typically ignored. The receiver should be
in Idle state after the last byte was transmitted.
``<op>[,<mode>] tx-add-bytes <num>``
Append ``<num>`` (1-255) spurious bytes to the message. The extra bytes
have the value of the byte position in the message. So if you transmit a
two byte message (e.g. a Get CEC Version message) and add 2 bytes, then
the full message received by the remote CEC adapter is
``0x40 0x9f 0x02 0x03``.
This command can be used to test buffer overflows in the receiver. E.g.
what does it do when it receives more than the maximum message size of 16
bytes.
``<op>[,<mode>] tx-remove-byte``
Drop the last byte from the message, provided the message is at least
two bytes long. The receiver should ignore messages that are too short.
``<op>[,<mode>] tx-short-bit <bit>``
Make this bit period shorter than allowed. The bit position cannot be
an Ack bit. If <op> specifies a specific CEC opcode then the bit position
must be at least 18, otherwise the opcode hasn't been received yet.
Normally the period of a data bit is between 2.05 and 2.75 milliseconds.
With this command the period of this bit is 1.8 milliseconds, this is
done by reducing the time the CEC bus is high. This bit period is less
than is allowed and the receiver should respond with a Low Drive
condition.
This command is ignored for 0 bits in bit positions 0 to 3. This is
because the receiver also looks for an Arbitration Lost condition in
those first four bits and it is undefined what will happen if it
sees a too-short 0 bit.
``<op>[,<mode>] tx-long-bit <bit>``
Make this bit period longer than is valid. The bit position cannot be
an Ack bit. If <op> specifies a specific CEC opcode then the bit position
must be at least 18, otherwise the opcode hasn't been received yet.
Normally the period of a data bit is between 2.05 and 2.75 milliseconds.
With this command the period of this bit is 2.9 milliseconds, this is
done by increasing the time the CEC bus is high.
Even though this bit period is longer than is valid it is undefined what
a receiver will do. It might just accept it, or it might time out and
return to Idle state. Unfortunately the CEC specification is silent about
this.
This command is ignored for 0 bits in bit positions 0 to 3. This is
because the receiver also looks for an Arbitration Lost condition in
those first four bits and it is undefined what will happen if it
sees a too-long 0 bit.
``<op>[,<mode>] tx-short-start``
Make this start bit period shorter than allowed. Normally the period of
a start bit is between 4.3 and 4.7 milliseconds. With this command the
period of the start bit is 4.1 milliseconds, this is done by reducing
the time the CEC bus is high. This start bit period is less than is
allowed and the receiver should return to Idle state when this is detected.
``<op>[,<mode>] tx-long-start``
Make this start bit period longer than is valid. Normally the period of
a start bit is between 4.3 and 4.7 milliseconds. With this command the
period of the start bit is 5 milliseconds, this is done by increasing
the time the CEC bus is high. This start bit period is more than is
valid and the receiver should return to Idle state when this is detected.
Even though this start bit period is longer than is valid it is undefined
what a receiver will do. It might just accept it, or it might time out and
return to Idle state. Unfortunately the CEC specification is silent about
this.
``<op>[,<mode>] tx-last-bit <bit>``
Just stop transmitting after this bit. If <op> specifies a specific CEC
opcode then the bit position must be at least 18, otherwise the opcode
hasn't been received yet. This command can be used to test how the receiver
reacts when a message just suddenly stops. It should time out and go back
to Idle state.
``<op>[,<mode>] tx-low-drive <bit>``
Force a Low Drive condition at this bit position. If <op> specifies a
specific CEC opcode then the bit position must be at least 18, otherwise
the opcode hasn't been received yet. This can be used to test how the
receiver handles Low Drive conditions. Note that if this happens at bit
positions 0-3 the receiver can interpret this as an Arbitration Lost
condition. This is implementation dependent.
Custom Pulses
-------------
``tx-custom-low-usecs <usecs>``
This defines the duration in microseconds that the custom pulse pulls
the CEC line low. The default is 1000 microseconds.
``tx-custom-high-usecs <usecs>``
This defines the duration in microseconds that the custom pulse keeps the
CEC line high (unless another CEC adapter pulls it low in that time).
The default is 1000 microseconds. The total period of the custom pulse is
``tx-custom-low-usecs + tx-custom-high-usecs``.
``<op>[,<mode>] tx-custom-bit <bit>``
Send the custom bit instead of a regular data bit. The bit position cannot
be an Ack bit. If <op> specifies a specific CEC opcode then the bit
position must be at least 18, otherwise the opcode hasn't been received yet.
``<op>[,<mode>] tx-custom-start``
Send the custom bit instead of a regular start bit.
``tx-custom-pulse``
Transmit a single custom pulse as soon as the CEC bus is idle.
Glitch Pulses
-------------
This emulates what happens if the signal on the CEC line is seeing spurious
pulses. Typically this happens after the falling or rising edge where there
is a short voltage fluctuation that, if the CEC hardware doesn't do
deglitching, can be seen as a spurious pulse and can cause a Low Drive
condition or corrupt data.
``tx-glitch-low-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse pulls
the CEC line low. The default is 1 microsecond. The range is 0-100
microseconds. If 0, then no glitch pulse will be generated.
``tx-glitch-high-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse keeps the
CEC line high (unless another CEC adapter pulls it low in that time).
The default is 1 microseconds. The range is 0-100 microseconds. If 0, then
no glitch pulse will be generated.The total period of the glitch pulse is
``tx-custom-low-usecs + tx-custom-high-usecs``.
``tx-glitch-falling-edge``
Send the glitch pulse right after the falling edge.
``tx-glitch-rising-edge``
Send the glitch pulse right after the rising edge.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Framework, 지원 driver와 debugfs ABI
1-31CEC Pin Framework는 CEC bus에 대한 low-level 기능만 제공하는 hardware를 위한 core CEC framework입니다. 오늘날 대부분의 hardware는 bus 구동까지 처리하는 high-level CEC 기능을 갖지만 일부 구형 device는 그렇지 않습니다.
이 framework를 사용하면 Raspberry Pi 같은 장치의 GPIO에 CEC pin을 연결해 CEC adapter를 만들 수도 있습니다.
bus를 완전히 제어할 수 있으므로 error injection을 쉽게 지원하며, CEC adapter가 여러 오류 조건을 얼마나 잘 처리하는지 시험하기에 적합합니다.
현재는 CEC line이 pull-up GPIO에 직접 연결된 `cec-gpio` driver와 AllWinner A10/A20 DRM driver만 이 framework를 지원합니다.
`CONFIG_CEC_PIN_ERROR_INJ`가 켜지면 `/sys/kernel/debug/cec/cecX/error-inj` debugfs file로 error injection을 사용할 수 있습니다.
error injection command는 stable ABI가 아니며 앞으로 변경될 수 있습니다. 자동화 script는 kernel version과 현재 도움말을 함께 확인해야 합니다.
build option, 지원 driver와 debugfs 경로가 모두 필요합니다.
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _cec_pin_error_inj:
CEC Pin Framework Error Injection
=================================
The CEC Pin Framework is a core CEC framework for CEC hardware that only
has low-level support for the CEC bus. Most hardware today will have
high-level CEC support where the hardware deals with driving the CEC bus,
but some older devices aren't that fancy. However, this framework also
allows you to connect the CEC pin to a GPIO on e.g. a Raspberry Pi and
you have now made a CEC adapter.
What makes doing this so interesting is that since we have full control
over the bus it is easy to support error injection. This is ideal to
test how well CEC adapters can handle error conditions.
Currently only the cec-gpio driver (when the CEC line is directly
connected to a pull-up GPIO line) and the AllWinner A10/A20 drm driver
support this framework.
If ``CONFIG_CEC_PIN_ERROR_INJ`` is enabled, then error injection is available
through debugfs. Specifically, in ``/sys/kernel/debug/cec/cecX/`` there is
now an ``error-inj`` file.
.. note::
The error injection commands are not a stable ABI and may change in the
future.
error-inj command 목록과 상태 저장
32-91`cat error-inj`는 사용 가능한 command와 현재 설정 상태를 함께 출력합니다. 출력 끝의 `clear`는 현재 injection이 없는 초기 상태를 나타냅니다.
전체, RX/TX 방향 또는 opcode별 설정을 지웁니다.
수신 ACK, bit 전기 조건과 payload 길이를 변형합니다.
NACK 처리와 custom·glitch pulse timing을 정합니다.
EOM, 길이, bit timing과 송신 중단을 변형합니다.
bit 번호는 CEC의 10-bit byte 표현을 따릅니다.
`echo 'cmd' >error-inj` 또는 `cat cmd.txt >error-inj`로 command를 씁니다. `cat error-inj` 출력은 현재 command를 포함하므로 file에 저장했다가 나중에 그대로 입력해 설정을 복원할 수 있습니다.
debugfs 출력이 실행 가능한 command 목록 역할도 합니다.
With ``cat error-inj`` you can see both the possible commands and the current
error injection status::
$ cat /sys/kernel/debug/cec/cec0/error-inj
# Clear error injections:
# clear clear all rx and tx error injections
# rx-clear clear all rx error injections
# tx-clear clear all tx error injections
# <op> clear clear all rx and tx error injections for <op>
# <op> rx-clear clear all rx error injections for <op>
# <op> tx-clear clear all tx error injections for <op>
#
# RX error injection settings:
# rx-no-low-drive do not generate low-drive pulses
#
# RX error injection:
# <op>[,<mode>] rx-nack NACK the message instead of sending an ACK
# <op>[,<mode>] rx-low-drive <bit> force a low-drive condition at this bit position
# <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message
# <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message
# any[,<mode>] rx-arb-lost [<poll>] generate a POLL message to trigger an arbitration lost
#
# TX error injection settings:
# tx-ignore-nack-until-eom ignore early NACKs until EOM
# tx-custom-low-usecs <usecs> define the 'low' time for the custom pulse
# tx-custom-high-usecs <usecs> define the 'high' time for the custom pulse
# tx-custom-pulse transmit the custom pulse once the bus is idle
# tx-glitch-low-usecs <usecs> define the 'low' time for the glitch pulse
# tx-glitch-high-usecs <usecs> define the 'high' time for the glitch pulse
# tx-glitch-falling-edge send the glitch pulse after every falling edge
# tx-glitch-rising-edge send the glitch pulse after every rising edge
#
# TX error injection:
# <op>[,<mode>] tx-no-eom don't set the EOM bit
# <op>[,<mode>] tx-early-eom set the EOM bit one byte too soon
# <op>[,<mode>] tx-add-bytes <num> append <num> (1-255) spurious bytes to the message
# <op>[,<mode>] tx-remove-byte drop the last byte from the message
# <op>[,<mode>] tx-short-bit <bit> make this bit shorter than allowed
# <op>[,<mode>] tx-long-bit <bit> make this bit longer than allowed
# <op>[,<mode>] tx-custom-bit <bit> send the custom pulse instead of this bit
# <op>[,<mode>] tx-short-start send a start pulse that's too short
# <op>[,<mode>] tx-long-start send a start pulse that's too long
# <op>[,<mode>] tx-custom-start send the custom pulse instead of the start pulse
# <op>[,<mode>] tx-last-bit <bit> stop sending after this bit
# <op>[,<mode>] tx-low-drive <bit> force a low-drive condition at this bit position
#
# <op> CEC message opcode (0-255) or 'any'
# <mode> 'once' (default), 'always', 'toggle' or 'off'
# <bit> CEC message bit (0-159)
# 10 bits per 'byte': bits 0-7: data, bit 8: EOM, bit 9: ACK
# <poll> CEC poll message used to test arbitration lost (0x00-0xff, default 0x0f)
# <usecs> microseconds (0-10000000, default 1000)
clear
You can write error injection commands to ``error-inj`` using
``echo 'cmd' >error-inj`` or ``cat cmd.txt >error-inj``. The ``cat error-inj``
output contains the current error commands. You can save the output to a file
and use it as an input to ``error-inj`` later.
기본 문법, mode와 중복 규칙
92-137행 앞의 space와 tab은 무시합니다. 다음 문자가 `#`이거나 줄 끝이면 전체 행을 무시하고, 그 밖에는 command가 와야 합니다.
command는 수신 CEC message, 송신 CEC message의 두 주요 그룹과 기존 설정 제거 및 custom bus pulse command로 나뉩니다.
대부분은 특정 opcode 또는 `any`에 적용할 수 있습니다. mode `off`는 기존 설정을 끄고, 기본값 `once`는 다음 해당 message 한 번에만 injection하며, `always`는 매번, `toggle`은 해당 송수신마다 on/off를 교대로 전환합니다.
`any rx-nack`은 다음 수신 message를 NACK하고, `any,always rx-nack`은 모든 수신 message를 NACK합니다. `0x82,toggle rx-nack`은 Active Source message를 받을 때마다 교대로 NACK합니다.
`once`가 실제로 주입된 뒤 해당 command는 자동으로 지워지므로 일회성입니다.
서로 다른 `<op>`와 command 조합은 동시에 존재할 수 있습니다. 예제의 0x9e add-byte·early-eom, 0x9f add-byte와 any rx-nack 네 설정은 모두 함께 활성화됩니다.
같은 `<op>`와 같은 command를 다른 인자로 다시 지정하면 두 번째 설정이 첫 번째를 덮어씁니다. 예를 들어 `0x9e tx-add-bytes 2`가 앞선 값 1을 대체합니다.
opcode가 일치하는 message가 올 때 설정의 수명을 정합니다.
설정 identity는 opcode와 command 조합입니다.
Basic Syntax
------------
Leading spaces/tabs are ignored. If the next character is a ``#`` or the end
of the line was reached, then the whole line is ignored. Otherwise a command
is expected.
The error injection commands fall in two main groups: those relating to
receiving CEC messages and those relating to transmitting CEC messages. In
addition, there are commands to clear existing error injection commands and
to create custom pulses on the CEC bus.
Most error injection commands can be executed for specific CEC opcodes or for
all opcodes (``any``). Each command also has a 'mode' which can be ``off``
(can be used to turn off an existing error injection command), ``once``
(the default) which will trigger the error injection only once for the next
received or transmitted message, ``always`` to always trigger the error
injection and ``toggle`` to toggle the error injection on or off for every
transmit or receive.
So '``any rx-nack``' will NACK the next received CEC message,
'``any,always rx-nack``' will NACK all received CEC messages and
'``0x82,toggle rx-nack``' will only NACK if an Active Source message was
received and do that only for every other received message.
After an error was injected with mode ``once`` the error injection command
is cleared automatically, so ``once`` is a one-time deal.
All combinations of ``<op>`` and error injection commands can co-exist. So
this is fine::
0x9e tx-add-bytes 1
0x9e tx-early-eom
0x9f tx-add-bytes 2
any rx-nack
All four error injection commands will be active simultaneously.
However, if the same ``<op>`` and command combination is specified,
but with different arguments::
0x9e tx-add-bytes 1
0x9e tx-add-bytes 2
Then the second will overwrite the first.
Error injection 제거
138-158`clear`, `rx-clear`, `tx-clear`는 각각 전체 injection, 모든 receive injection, 모든 transmit injection을 제거합니다.
`<op> clear`, `<op> rx-clear`, `<op> tx-clear`는 범위를 특정 opcode로 제한합니다.
방향과 opcode 두 축으로 제거 범위를 고릅니다.
Clear Error Injections
----------------------
``clear``
Clear all error injections.
``rx-clear``
Clear all receive error injections
``tx-clear``
Clear all transmit error injections
``<op> clear``
Clear all error injections for the given opcode.
``<op> rx-clear``
Clear all receive error injections for the given opcode.
``<op> tx-clear``
Clear all transmit error injections for the given opcode.
Receive message error injection
159-210`rx-nack`은 broadcast와 현재 CEC adapter 대상 message를 NACK합니다. transmitter가 첫 byte의 NACK 뒤에도 계속 보낼 수 있으므로 모든 byte를 NACK합니다.
`rx-low-drive <bit>`는 지정 bit에서 Low Drive를 강제합니다. 특정 opcode를 지정했다면 opcode를 아직 수신하지 못한 앞부분을 대상으로 할 수 없으므로 bit가 최소 18이어야 합니다.
이 command는 transmitter의 Low Drive 처리와 오류 보고를 시험합니다. 첫 4 bit의 Low Drive는 transmitter가 Arbitration Lost로 해석할 수도 있으며 구현에 따라 달라집니다.
`rx-add-byte`는 원 message가 15 byte 이하일 때 가짜 `0x55` byte를 추가합니다. high-level protocol이 가짜 byte를 무시하는지 시험합니다.
`rx-remove-byte`는 message가 최소 2 byte일 때 마지막 byte를 지웁니다. 너무 짧은 message를 high-level protocol이 무시하는지 시험합니다.
`rx-arb-lost <poll>`은 start bit를 받자마자 adapter를 transmit mode로 바꾸고 POLL을 보내 Arbitration Lost를 유도합니다. 기본 POLL은 0x0f이며 인자로 직접 지정할 수 있습니다.
상세 설명은 이 command의 `<op>`를 `next` 또는 `all`에만 허용한다고 적지만 앞선 도움말은 `any`로 표시합니다. 원문 두 표현을 모두 보존하며 자동으로 하나를 선택하지 않습니다.
두 adapter가 동시에 송신하면 leading zero가 더 많은 initiator가 arbitration에서 이기고 다른 transmitter는 멈춰야 합니다. remote transmitter의 logical address가 0(`TV`)이면 항상 이겨 이 시험은 동작하지 않습니다.
`rx-no-low-drive`는 원래 3.6 ms Low Drive pulse를 만들 상황을 receiver가 무시하게 합니다. 이 pulse는 대개 수신 중 spurious pulse를 감지했을 때 retransmit을 요구하는 신호입니다. 이를 끄면 시험 장치가 Low Drive를 만들지 않은 상태에서 다른 device의 glitch 처리를 볼 수 있습니다.
ACK, message 길이, arbitration과 glitch 대응을 시험합니다.
remote transmitter와 동시에 POLL을 시작해 우선순위를 겨룹니다.
Receive Messages
----------------
``<op>[,<mode>] rx-nack``
NACK broadcast messages and messages directed to this CEC adapter.
Every byte of the message will be NACKed in case the transmitter
keeps transmitting after the first byte was NACKed.
``<op>[,<mode>] rx-low-drive <bit>``
Force a Low Drive condition at this bit position. If <op> specifies
a specific CEC opcode then the bit position must be at least 18,
otherwise the opcode hasn't been received yet. This tests if the
transmitter can handle the Low Drive condition correctly and reports
the error correctly. Note that a Low Drive in the first 4 bits can also
be interpreted as an Arbitration Lost condition by the transmitter.
This is implementation dependent.
``<op>[,<mode>] rx-add-byte``
Add a spurious 0x55 byte to the received CEC message, provided
the message was 15 bytes long or less. This is useful to test
the high-level protocol since spurious bytes should be ignored.
``<op>[,<mode>] rx-remove-byte``
Remove the last byte from the received CEC message, provided it
was at least 2 bytes long. This is useful to test the high-level
protocol since messages that are too short should be ignored.
``<op>[,<mode>] rx-arb-lost <poll>``
Generate a POLL message to trigger an Arbitration Lost condition.
This command is only allowed for ``<op>`` values of ``next`` or ``all``.
As soon as a start bit has been received the CEC adapter will switch
to transmit mode and it will transmit a POLL message. By default this is
0x0f, but it can also be specified explicitly via the ``<poll>`` argument.
This command can be used to test the Arbitration Lost condition in
the remote CEC transmitter. Arbitration happens when two CEC adapters
start sending a message at the same time. In that case the initiator
with the most leading zeroes wins and the other transmitter has to
stop transmitting ('Arbitration Lost'). This is very hard to test,
except by using this error injection command.
This does not work if the remote CEC transmitter has logical address
0 ('TV') since that will always win.
``rx-no-low-drive``
The receiver will ignore situations that would normally generate a
Low Drive pulse (3.6 ms). This is typically done if a spurious pulse is
detected when receiving a message, and it indicates to the transmitter that
the message has to be retransmitted since the receiver got confused.
Disabling this is useful to test how other CEC devices handle glitches
by ensuring we will not be the one that generates a Low Drive.
Transmit message 길이와 EOM 변형
211-254`tx-ignore-nack-until-eom`은 receiver가 byte를 NACK해도 즉시 멈추지 않고 message 전체를 보낸 뒤 끝에서 ACK bit를 봅니다. specification이 허용하지만 느린 CEC bus를 불필요하게 점유하므로 권장되지 않습니다. receiver가 이런 transmitter를 처리하는지 시험할 수 있습니다.
`tx-no-eom`은 마지막 byte에도 EOM을 보내지 않고 송신을 끝냅니다. receiver는 보통 timeout 뒤 Idle state로 돌아가야 합니다.
`tx-early-eom`은 2 byte 이상 message의 끝에서 두 번째 byte에 EOM을 설정하고 마지막 byte에는 설정하지 않습니다. receiver는 마지막 byte를 무시해야 하며 결과가 너무 짧아 전체 message도 보통 무시됩니다. 마지막 byte 뒤에는 Idle state여야 합니다.
`tx-add-bytes <num>`은 1–255개의 가짜 byte를 붙입니다. 값은 message 안의 byte position입니다. 2-byte `0x40 0x9f` message에 2개를 더하면 remote adapter는 `0x40 0x9f 0x02 0x03`을 받습니다.
추가 byte command는 최대 CEC message 크기 16 byte보다 큰 입력에 대한 receiver buffer overflow 방어를 시험할 수 있습니다.
`tx-remove-byte`는 2 byte 이상 message의 마지막 byte를 제거하며 receiver는 너무 짧은 message를 무시해야 합니다.
message 종료와 길이를 비정상으로 만들어 receiver 상태 복구를 시험합니다.
EOM 또는 길이가 틀려도 receiver는 결국 Idle로 복구해야 합니다.
Transmit Messages
-----------------
``tx-ignore-nack-until-eom``
This setting changes the behavior of transmitting CEC messages. Normally
as soon as the receiver NACKs a byte the transmit will stop, but the
specification also allows that the full message is transmitted and only
at the end will the transmitter look at the ACK bit. This is not
recommended behavior since there is no point in keeping the CEC bus busy
for longer than is strictly needed. Especially given how slow the bus is.
This setting can be used to test how well a receiver deals with
transmitters that ignore NACKs until the very end of the message.
``<op>[,<mode>] tx-no-eom``
Don't set the EOM bit. Normally the last byte of the message has the EOM
(End-Of-Message) bit set. With this command the transmit will just stop
without ever sending an EOM. This can be used to test how a receiver
handles this case. Normally receivers have a time-out after which
they will go back to the Idle state.
``<op>[,<mode>] tx-early-eom``
Set the EOM bit one byte too soon. This obviously only works for messages
of two bytes or more. The EOM bit will be set for the second-to-last byte
and not for the final byte. The receiver should ignore the last byte in
this case. Since the resulting message is likely to be too short for this
same reason the whole message is typically ignored. The receiver should be
in Idle state after the last byte was transmitted.
``<op>[,<mode>] tx-add-bytes <num>``
Append ``<num>`` (1-255) spurious bytes to the message. The extra bytes
have the value of the byte position in the message. So if you transmit a
two byte message (e.g. a Get CEC Version message) and add 2 bytes, then
the full message received by the remote CEC adapter is
``0x40 0x9f 0x02 0x03``.
This command can be used to test buffer overflows in the receiver. E.g.
what does it do when it receives more than the maximum message size of 16
bytes.
``<op>[,<mode>] tx-remove-byte``
Drop the last byte from the message, provided the message is at least
two bytes long. The receiver should ignore messages that are too short.
Bit·start timing, 중단과 Low Drive
255-320`tx-short-bit <bit>`은 ACK bit가 아닌 지정 bit의 period를 정상 2.05–2.75 ms보다 짧은 1.8 ms로 만듭니다. CEC bus high 시간을 줄이며 receiver는 Low Drive로 응답해야 합니다.
특정 opcode를 지정하면 bit가 최소 18이어야 합니다. bit position 0–3의 0 bit에는 적용하지 않는데, receiver가 이 구간에서 Arbitration Lost도 검사하므로 너무 짧은 0 bit의 결과가 정의되지 않았기 때문입니다.
`tx-long-bit <bit>`은 high 시간을 늘려 period를 2.9 ms로 만듭니다. receiver가 그대로 받을 수도, timeout 후 Idle로 갈 수도 있으며 CEC specification은 동작을 규정하지 않습니다. 첫 4 bit의 0에는 short-bit와 같은 이유로 적용하지 않습니다.
`tx-short-start`는 정상 4.3–4.7 ms start period를 4.1 ms로 줄입니다. receiver는 이를 감지하면 Idle state로 돌아가야 합니다.
`tx-long-start`는 start period를 5 ms로 늘립니다. 원문은 먼저 receiver가 Idle로 돌아가야 한다고 설명한 뒤, 실제 동작은 수용 또는 timeout일 수 있고 specification이 침묵한다고 덧붙입니다. 두 문장을 모두 보존합니다.
`tx-last-bit <bit>`은 지정 bit 직후 갑자기 송신을 멈춥니다. opcode를 지정하면 bit가 최소 18이어야 하며 receiver는 timeout 뒤 Idle state로 돌아가야 합니다.
`tx-low-drive <bit>`은 지정 bit에 Low Drive를 강제합니다. 특정 opcode에서는 bit가 최소 18이어야 하며 position 0–3이면 receiver가 Arbitration Lost로 해석할 수도 있습니다.
정상 구간과 주입 값을 비교합니다.
ACK와 opcode 판정 시점 때문에 bit 위치 제약이 있습니다.
receiver 구현과 오류 종류에 따라 Low Drive 또는 Idle 복귀를 확인합니다.
``<op>[,<mode>] tx-short-bit <bit>``
Make this bit period shorter than allowed. The bit position cannot be
an Ack bit. If <op> specifies a specific CEC opcode then the bit position
must be at least 18, otherwise the opcode hasn't been received yet.
Normally the period of a data bit is between 2.05 and 2.75 milliseconds.
With this command the period of this bit is 1.8 milliseconds, this is
done by reducing the time the CEC bus is high. This bit period is less
than is allowed and the receiver should respond with a Low Drive
condition.
This command is ignored for 0 bits in bit positions 0 to 3. This is
because the receiver also looks for an Arbitration Lost condition in
those first four bits and it is undefined what will happen if it
sees a too-short 0 bit.
``<op>[,<mode>] tx-long-bit <bit>``
Make this bit period longer than is valid. The bit position cannot be
an Ack bit. If <op> specifies a specific CEC opcode then the bit position
must be at least 18, otherwise the opcode hasn't been received yet.
Normally the period of a data bit is between 2.05 and 2.75 milliseconds.
With this command the period of this bit is 2.9 milliseconds, this is
done by increasing the time the CEC bus is high.
Even though this bit period is longer than is valid it is undefined what
a receiver will do. It might just accept it, or it might time out and
return to Idle state. Unfortunately the CEC specification is silent about
this.
This command is ignored for 0 bits in bit positions 0 to 3. This is
because the receiver also looks for an Arbitration Lost condition in
those first four bits and it is undefined what will happen if it
sees a too-long 0 bit.
``<op>[,<mode>] tx-short-start``
Make this start bit period shorter than allowed. Normally the period of
a start bit is between 4.3 and 4.7 milliseconds. With this command the
period of the start bit is 4.1 milliseconds, this is done by reducing
the time the CEC bus is high. This start bit period is less than is
allowed and the receiver should return to Idle state when this is detected.
``<op>[,<mode>] tx-long-start``
Make this start bit period longer than is valid. Normally the period of
a start bit is between 4.3 and 4.7 milliseconds. With this command the
period of the start bit is 5 milliseconds, this is done by increasing
the time the CEC bus is high. This start bit period is more than is
valid and the receiver should return to Idle state when this is detected.
Even though this start bit period is longer than is valid it is undefined
what a receiver will do. It might just accept it, or it might time out and
return to Idle state. Unfortunately the CEC specification is silent about
this.
``<op>[,<mode>] tx-last-bit <bit>``
Just stop transmitting after this bit. If <op> specifies a specific CEC
opcode then the bit position must be at least 18, otherwise the opcode
hasn't been received yet. This command can be used to test how the receiver
reacts when a message just suddenly stops. It should time out and go back
to Idle state.
``<op>[,<mode>] tx-low-drive <bit>``
Force a Low Drive condition at this bit position. If <op> specifies a
specific CEC opcode then the bit position must be at least 18, otherwise
the opcode hasn't been received yet. This can be used to test how the
receiver handles Low Drive conditions. Note that if this happens at bit
positions 0-3 the receiver can interpret this as an Arbitration Lost
condition. This is implementation dependent.
Custom pulse
321-345`tx-custom-low-usecs <usecs>`는 custom pulse가 CEC line을 low로 당기는 시간을 microsecond로 정하며 기본값은 1000입니다.
`tx-custom-high-usecs <usecs>`는 다른 adapter가 line을 low로 당기지 않는 동안 high로 두는 시간을 정하며 기본값은 1000입니다. 전체 period는 두 low·high 값의 합입니다.
`tx-custom-bit <bit>`은 일반 data bit 대신 custom bit를 보냅니다. ACK bit에는 사용할 수 없고 특정 opcode를 지정하면 bit가 최소 18이어야 합니다.
`tx-custom-start`는 일반 start bit 대신 custom bit를 보내며, `tx-custom-pulse`는 CEC bus가 idle이 되는 즉시 custom pulse 하나를 송신합니다.
low/high duration을 조합해 data, start 또는 독립 pulse로 보냅니다.
두 duration의 합이 한 pulse period가 됩니다.
Custom Pulses
-------------
``tx-custom-low-usecs <usecs>``
This defines the duration in microseconds that the custom pulse pulls
the CEC line low. The default is 1000 microseconds.
``tx-custom-high-usecs <usecs>``
This defines the duration in microseconds that the custom pulse keeps the
CEC line high (unless another CEC adapter pulls it low in that time).
The default is 1000 microseconds. The total period of the custom pulse is
``tx-custom-low-usecs + tx-custom-high-usecs``.
``<op>[,<mode>] tx-custom-bit <bit>``
Send the custom bit instead of a regular data bit. The bit position cannot
be an Ack bit. If <op> specifies a specific CEC opcode then the bit
position must be at least 18, otherwise the opcode hasn't been received yet.
``<op>[,<mode>] tx-custom-start``
Send the custom bit instead of a regular start bit.
``tx-custom-pulse``
Transmit a single custom pulse as soon as the CEC bus is idle.
Glitch pulse
346-371glitch pulse는 CEC line의 falling 또는 rising edge 직후 생기는 짧은 voltage fluctuation을 흉내 냅니다. hardware가 deglitching하지 않으면 가짜 pulse로 인식해 Low Drive나 data corruption을 일으킬 수 있습니다.
`tx-glitch-low-usecs <usecs>`는 line을 low로 당기는 시간을 정합니다. 기본값은 1 μs, 범위는 0–100 μs이며 0이면 glitch를 만들지 않습니다.
`tx-glitch-high-usecs <usecs>`는 다른 adapter가 low로 당기지 않는 동안 high로 두는 시간을 정합니다. 기본값 1 μs, 범위 0–100 μs이고 0이면 glitch를 만들지 않습니다.
원문은 glitch 전체 period를 `tx-custom-low-usecs + tx-custom-high-usecs`라고 적고 있으며 `generated.The` 사이 공백도 빠져 있습니다. 원문은 그대로 보존하고, 실제 command 이름과 공식의 불일치는 자동 수정하지 않습니다.
`tx-glitch-falling-edge`는 모든 falling edge 직후, `tx-glitch-rising-edge`는 모든 rising edge 직후 glitch pulse를 보냅니다.
edge와 low/high duration을 조합합니다.
짧은 fluctuation이 deglitching과 오류 복구를 시험합니다.
Glitch Pulses
-------------
This emulates what happens if the signal on the CEC line is seeing spurious
pulses. Typically this happens after the falling or rising edge where there
is a short voltage fluctuation that, if the CEC hardware doesn't do
deglitching, can be seen as a spurious pulse and can cause a Low Drive
condition or corrupt data.
``tx-glitch-low-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse pulls
the CEC line low. The default is 1 microsecond. The range is 0-100
microseconds. If 0, then no glitch pulse will be generated.
``tx-glitch-high-usecs <usecs>``
This defines the duration in microseconds that the glitch pulse keeps the
CEC line high (unless another CEC adapter pulls it low in that time).
The default is 1 microseconds. The range is 0-100 microseconds. If 0, then
no glitch pulse will be generated.The total period of the glitch pulse is
``tx-custom-low-usecs + tx-custom-high-usecs``.
``tx-glitch-falling-edge``
Send the glitch pulse right after the falling edge.
``tx-glitch-rising-edge``
Send the glitch pulse right after the rising edge.
요약·해설
cec-pin-error-inj.rst:1-371이 debugfs interface는 CEC Pin Framework가 bus waveform을 직접 제어한다는 특성을 이용해 ACK, EOM, payload 길이, bit·start timing, Low Drive, arbitration과 edge glitch를 재현합니다. command ABI는 안정적이지 않으므로 현재 kernel의 `cat error-inj` 출력을 기준으로 사용해야 합니다. 원문의 `rx-arb-lost` opcode 표현과 glitch period 공식에는 내부 불일치가 있어 원문을 보존하고 해당 구간에 검토 메모를 남겼습니다.