요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
=====================================
2
Linux I2C slave interface description
3
=====================================
5
by Wolfram Sang <[email protected]> in 2014-15
7
Linux can also be an I2C slave if the I2C controller in use has slave
8
functionality. For that to work, one needs slave support in the bus driver plus
9
a hardware independent software backend providing the actual functionality. An
10
example for the latter is the slave-eeprom driver, which acts as a dual memory
11
driver. While another I2C master on the bus can access it like a regular
12
EEPROM, the Linux I2C slave can access the content via sysfs and handle data as
13
needed. The backend driver and the I2C bus driver communicate via events. Here
14
is a small graph visualizing the data flow and the means by which data is
15
transported. The dotted line marks only one example. The backend could also
16
use a character device, be in-kernel only, or something completely different::
19
e.g. sysfs I2C slave events I/O registers
20
+-----------+ v +---------+ v +--------+ v +------------+
21
| Userspace +........+ Backend +-----------+ Driver +-----+ Controller |
22
+-----------+ +---------+ +--------+ +------------+
23
| |
24
----------------------------------------------------------------+-- I2C
25
--------------------------------------------------------------+---- Bus
27
Note: Technically, there is also the I2C core between the backend and the
28
driver. However, at this time of writing, the layer is transparent.
31
User manual
32
===========
34
I2C slave backends behave like standard I2C clients. So, you can instantiate
35
them as described in the document instantiating-devices.rst. The only
36
difference is that i2c slave backends have their own address space. So, you
37
have to add 0x1000 to the address you would originally request. An example for
38
instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
39
on bus 1::
41
# echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
43
Each backend should come with separate documentation to describe its specific
44
behaviour and setup.
47
Developer manual
48
================
50
First, the events which are used by the bus driver and the backend will be
51
described in detail. After that, some implementation hints for extending bus
52
drivers and writing backends will be given.
55
I2C slave events
56
----------------
58
The bus driver sends an event to the backend using the following function::
60
ret = i2c_slave_event(client, event, &val)
62
'client' describes the I2C slave device. 'event' is one of the special event
63
types described hereafter. 'val' holds an u8 value for the data byte to be
64
read/written and is thus bidirectional. The pointer to val must always be
65
provided even if val is not used for an event, i.e. don't use NULL here. 'ret'
66
is the return value from the backend. Mandatory events must be provided by the
67
bus drivers and must be checked for by backend drivers.
69
Event types:
71
* I2C_SLAVE_WRITE_REQUESTED (mandatory)
73
'val': unused
75
'ret': 0 if the backend is ready, otherwise some errno
77
Another I2C master wants to write data to us. This event should be sent once
78
our own address and the write bit was detected. The data did not arrive yet, so
79
there is nothing to process or return. After returning, the bus driver must
80
always ack the address phase. If 'ret' is zero, backend initialization or
81
wakeup is done and further data may be received. If 'ret' is an errno, the bus
82
driver should nack all incoming bytes until the next stop condition to enforce
83
a retry of the transmission.
85
* I2C_SLAVE_READ_REQUESTED (mandatory)
87
'val': backend returns first byte to be sent
89
'ret': always 0
91
Another I2C master wants to read data from us. This event should be sent once
92
our own address and the read bit was detected. After returning, the bus driver
93
should transmit the first byte.
95
* I2C_SLAVE_WRITE_RECEIVED (mandatory)
97
'val': bus driver delivers received byte
99
'ret': 0 if the byte should be acked, some errno if the byte should be nacked
101
Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
102
is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte
103
should be nacked.
105
* I2C_SLAVE_READ_PROCESSED (mandatory)
107
'val': backend returns next byte to be sent
109
'ret': always 0
111
The bus driver requests the next byte to be sent to another I2C master in
112
'val'. Important: This does not mean that the previous byte has been acked, it
113
only means that the previous byte is shifted out to the bus! To ensure seamless
114
transmission, most hardware requests the next byte when the previous one is
115
still shifted out. If the master sends NACK and stops reading after the byte
116
currently shifted out, this byte requested here is never used. It very likely
117
needs to be sent again on the next I2C_SLAVE_READ_REQUEST, depending a bit on
118
your backend, though.
120
* I2C_SLAVE_STOP (mandatory)
122
'val': unused
124
'ret': always 0
126
A stop condition was received. This can happen anytime and the backend should
127
reset its state machine for I2C transfers to be able to receive new requests.
130
Software backends
131
-----------------
133
If you want to write a software backend:
135
* use a standard i2c_driver and its matching mechanisms
136
* write the slave_callback which handles the above slave events
137
(best using a state machine)
138
* register this callback via i2c_slave_register()
140
Check the i2c-slave-eeprom driver as an example.
143
Bus driver support
144
------------------
146
If you want to add slave support to the bus driver:
148
* implement calls to register/unregister the slave and add those to the
149
struct i2c_algorithm. When registering, you probably need to set the I2C
150
slave address and enable slave specific interrupts. If you use runtime pm, you
151
should use pm_runtime_get_sync() because your device usually needs to be
152
powered on always to be able to detect its slave address. When unregistering,
153
do the inverse of the above.
155
* Catch the slave interrupts and send appropriate i2c_slave_events to the backend.
157
Note that most hardware supports being master _and_ slave on the same bus. So,
158
if you extend a bus driver, please make sure that the driver supports that as
159
well. In almost all cases, slave support does not need to disable the master
160
functionality.
162
Check the i2c-rcar driver as an example.
165
About ACK/NACK
166
--------------
168
It is good behaviour to always ACK the address phase, so the master knows if a
169
device is basically present or if it mysteriously disappeared. Using NACK to
170
state being busy is troublesome. SMBus demands to always ACK the address phase,
171
while the I2C specification is more loose on that. Most I2C controllers also
172
automatically ACK when detecting their slave addresses, so there is no option
173
to NACK them. For those reasons, this API does not support NACK in the address
174
phase.
176
Currently, there is no slave event to report if the master did ACK or NACK a
177
byte when it reads from us. We could make this an optional event if the need
178
arises. However, cases should be extremely rare because the master is expected
179
to send STOP after that and we have an event for that. Also, keep in mind not
180
all I2C controllers have the possibility to report that event.
183
About buffers
184
-------------
186
During development of this API, the question of using buffers instead of just
187
bytes came up. Such an extension might be possible, usefulness is unclear at
188
this time of writing. Some points to keep in mind when using buffers:
190
* Buffers should be opt-in and backend drivers will always have to support
191
byte-based transactions as the ultimate fallback anyhow because this is how
192
the majority of HW works.
194
* For backends simulating hardware registers, buffers are largely not helpful
195
because after each byte written an action should be immediately triggered.
196
For reads, the data kept in the buffer might get stale if the backend just
197
updated a register because of internal processing.
199
* A master can send STOP at any time. For partially transferred buffers, this
200
means additional code to handle this exception. Such code tends to be
201
error-prone.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux I2C 슬레이브 인터페이스의 구성
1-29이 문서는 Wolfram Sang이 2014~2015년에 작성했습니다. 사용하는 I2C 컨트롤러가 슬레이브 기능을 제공한다면 Linux도 I2C 슬레이브로 동작할 수 있습니다.
이를 위해서는 버스 드라이버의 슬레이브 지원과 실제 기능을 제공하는 하드웨어 독립 소프트웨어 백엔드가 모두 필요합니다. 예를 들어 `slave-eeprom` 드라이버는 이중 메모리 드라이버처럼 동작합니다. 버스의 다른 I2C 마스터는 일반 EEPROM처럼 접근하고, Linux I2C 슬레이브 쪽은 sysfs를 통해 같은 내용을 읽고 필요한 방식으로 데이터를 처리합니다.
백엔드 드라이버와 I2C 버스 드라이버는 이벤트로 통신합니다. 원문의 점선은 사용자 공간과 백엔드를 sysfs로 연결하는 한 가지 예일 뿐입니다. 백엔드는 문자 장치를 제공하거나, 커널 내부에서만 동작하거나, 완전히 다른 인터페이스를 사용할 수도 있습니다.
계층다음 계층과의 전달 수단역할
Userspace예: sysfs백엔드 메모리나 상태에 접근
BackendI2C slave events슬레이브 장치의 실제 동작 구현
DriverI/O registers컨트롤러 이벤트와 데이터 전달
ControllerSCL/SDA외부 I2C Bus에 전기적으로 연결
원문의 ASCII 그림을 같은 계층과 전달 수단으로 구조화했습니다.
외부 I2C 마스터가 버스에서 슬레이브 주소 선택→컨트롤러가 주소·데이터 상태 감지→버스 드라이버가 I2C slave event 생성→백엔드가 읽기·쓰기 의미 처리→선택적으로 사용자 공간이 sysfs 등으로 같은 상태 접근
외부 마스터 요청과 사용자 공간 접근이 백엔드에서 만나는 흐름입니다.
기술적으로 백엔드와 버스 드라이버 사이에는 I2C core도 있습니다. 다만 이 문서 작성 시점의 슬레이브 이벤트 경로에서는 해당 계층이 투명하므로 그림에서 생략했습니다.
=====================================
Linux I2C slave interface description
=====================================
by Wolfram Sang <[email protected]> in 2014-15
Linux can also be an I2C slave if the I2C controller in use has slave
functionality. For that to work, one needs slave support in the bus driver plus
a hardware independent software backend providing the actual functionality. An
example for the latter is the slave-eeprom driver, which acts as a dual memory
driver. While another I2C master on the bus can access it like a regular
EEPROM, the Linux I2C slave can access the content via sysfs and handle data as
needed. The backend driver and the I2C bus driver communicate via events. Here
is a small graph visualizing the data flow and the means by which data is
transported. The dotted line marks only one example. The backend could also
use a character device, be in-kernel only, or something completely different::
e.g. sysfs I2C slave events I/O registers
+-----------+ v +---------+ v +--------+ v +------------+
| Userspace +........+ Backend +-----------+ Driver +-----+ Controller |
+-----------+ +---------+ +--------+ +------------+
| |
----------------------------------------------------------------+-- I2C
--------------------------------------------------------------+---- Bus
Note: Technically, there is also the I2C core between the backend and the
driver. However, at this time of writing, the layer is transparent.
사용자 설정과 개발자 인터페이스의 출발점
30-52I2C 슬레이브 백엔드는 표준 I2C 클라이언트처럼 동작하므로 `instantiating-devices.rst`에 설명된 방식으로 생성할 수 있습니다. 차이는 슬레이브 백엔드가 별도의 주소 공간을 사용한다는 점입니다.
요청하려는 원래 7비트 주소에 `0x1000`을 더해야 합니다. 예를 들어 버스 1의 7비트 주소 `0x64`에 `slave-eeprom`을 만들 때는 `0x1064`를 `new_device`에 기록합니다.
# echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device항목값
실제 7비트 슬레이브 주소`0x64`
슬레이브 주소 공간 표시`0x1000`
`new_device`에 전달할 값`0x1064`
버스`i2c-1`
일반 I2C 주소와 생성 인터페이스의 값을 구분합니다.
각 백엔드는 고유한 동작과 설정을 설명하는 별도 문서를 제공해야 합니다.
개발자 설명은 먼저 버스 드라이버와 백엔드가 공유하는 이벤트를 정의하고, 이어서 기존 버스 드라이버에 슬레이브 기능을 추가하는 방법과 새 백엔드를 작성하는 방법을 안내합니다.
User manual
===========
I2C slave backends behave like standard I2C clients. So, you can instantiate
them as described in the document instantiating-devices.rst. The only
difference is that i2c slave backends have their own address space. So, you
have to add 0x1000 to the address you would originally request. An example for
instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
on bus 1::
# echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
Each backend should come with separate documentation to describe its specific
behaviour and setup.
Developer manual
================
First, the events which are used by the bus driver and the backend will be
described in detail. After that, some implementation hints for extending bus
drivers and writing backends will be given.필수 I2C 슬레이브 이벤트
53-128버스 드라이버는 `ret = i2c_slave_event(client, event, &val)`을 호출해 백엔드에 이벤트를 보냅니다. `client`는 I2C 슬레이브 장치, `event`는 아래의 특수 이벤트 유형, `val`은 읽거나 쓸 데이터 바이트를 담는 양방향 `u8` 값입니다.
이벤트가 `val`을 사용하지 않더라도 `&val` 포인터는 항상 제공해야 하며 `NULL`을 전달하면 안 됩니다. `ret`은 백엔드의 반환값입니다. 버스 드라이버는 필수 이벤트를 모두 제공해야 하고, 백엔드는 그 이벤트를 검사해야 합니다.
이벤트`val``ret`버스 드라이버 동작
`I2C_SLAVE_WRITE_REQUESTED`사용하지 않음준비 완료면 0, 아니면 errno주소 단계는 항상 ACK, 오류면 STOP까지 이후 바이트 NACK
`I2C_SLAVE_READ_REQUESTED`백엔드가 첫 바이트 반환항상 0반환 뒤 첫 바이트 전송
`I2C_SLAVE_WRITE_RECEIVED`수신 바이트 전달ACK이면 0, NACK이면 errno반환값에 따라 해당 바이트 ACK/NACK
`I2C_SLAVE_READ_PROCESSED`백엔드가 다음 바이트 반환항상 0연속 전송을 위해 다음 바이트 준비
`I2C_SLAVE_STOP`사용하지 않음항상 0백엔드 전송 상태 머신 초기화
각 이벤트에서 `val`과 `ret`이 의미하는 바를 정리합니다.
`I2C_SLAVE_WRITE_REQUESTED`는 다른 마스터가 우리 주소와 write 비트를 보냈을 때 한 번 전달합니다. 아직 데이터 바이트는 도착하지 않았으므로 처리하거나 반환할 데이터가 없습니다. 버스 드라이버는 이 콜백이 끝난 뒤 주소 단계를 항상 ACK해야 합니다.
반환값이 0이면 백엔드의 초기화 또는 깨우기가 끝나 이후 데이터를 받을 수 있습니다. errno이면 전송을 다시 시도하게 만들기 위해 다음 STOP 조건까지 들어오는 모든 데이터 바이트를 NACK하는 것이 권장됩니다.
`I2C_SLAVE_READ_REQUESTED`는 다른 마스터가 우리 주소와 read 비트를 보냈을 때 한 번 전달합니다. 백엔드는 `val`에 첫 바이트를 넣고, 버스 드라이버는 콜백이 끝난 뒤 그 바이트를 전송합니다.
`I2C_SLAVE_WRITE_RECEIVED`에서는 다른 마스터가 보낸 바이트를 버스 드라이버가 `val`에 넣습니다. 백엔드가 0을 반환하면 해당 바이트를 ACK하고, errno를 반환하면 NACK합니다.
`I2C_SLAVE_READ_PROCESSED`는 다른 마스터에게 보낼 다음 바이트를 요청합니다. 이 이벤트는 이전 바이트가 마스터에게 ACK되었다는 뜻이 아니라, 이전 바이트가 버스로 시프트 아웃되고 있다는 뜻입니다. 대부분의 하드웨어는 끊김 없는 전송을 위해 이전 바이트가 나가는 동안 다음 바이트를 미리 요청합니다.
마스터가 현재 전송 중인 바이트 뒤에 NACK를 보내 읽기를 중단하면 이번 이벤트로 준비한 다음 바이트는 사용되지 않습니다. 백엔드의 의미에 따라 다음 `I2C_SLAVE_READ_REQUESTED` 때 이 바이트를 다시 보내야 할 가능성이 큽니다.
`I2C_SLAVE_STOP`은 STOP 조건을 수신했음을 알립니다. STOP은 언제든 발생할 수 있으므로 백엔드는 새 요청을 받을 수 있도록 I2C 전송 상태 머신을 초기화해야 합니다.
주소 + write 감지→`I2C_SLAVE_WRITE_REQUESTED`→주소 단계 ACK→각 바이트마다 `I2C_SLAVE_WRITE_RECEIVED`→반환값에 따라 바이트 ACK 또는 NACK→`I2C_SLAVE_STOP`으로 상태 초기화
주소 선택부터 STOP까지 이벤트와 응답을 연결합니다.
주소 + read 감지→`I2C_SLAVE_READ_REQUESTED`에서 첫 바이트 획득→첫 바이트 전송→`I2C_SLAVE_READ_PROCESSED`에서 다음 바이트 선행 준비→마스터가 ACK하면 계속, NACK하면 준비 바이트 미사용 가능→`I2C_SLAVE_STOP`으로 상태 초기화
첫 바이트와 선행 준비되는 다음 바이트를 구분합니다.
I2C slave events
----------------
The bus driver sends an event to the backend using the following function::
ret = i2c_slave_event(client, event, &val)
'client' describes the I2C slave device. 'event' is one of the special event
types described hereafter. 'val' holds an u8 value for the data byte to be
read/written and is thus bidirectional. The pointer to val must always be
provided even if val is not used for an event, i.e. don't use NULL here. 'ret'
is the return value from the backend. Mandatory events must be provided by the
bus drivers and must be checked for by backend drivers.
Event types:
* I2C_SLAVE_WRITE_REQUESTED (mandatory)
'val': unused
'ret': 0 if the backend is ready, otherwise some errno
Another I2C master wants to write data to us. This event should be sent once
our own address and the write bit was detected. The data did not arrive yet, so
there is nothing to process or return. After returning, the bus driver must
always ack the address phase. If 'ret' is zero, backend initialization or
wakeup is done and further data may be received. If 'ret' is an errno, the bus
driver should nack all incoming bytes until the next stop condition to enforce
a retry of the transmission.
* I2C_SLAVE_READ_REQUESTED (mandatory)
'val': backend returns first byte to be sent
'ret': always 0
Another I2C master wants to read data from us. This event should be sent once
our own address and the read bit was detected. After returning, the bus driver
should transmit the first byte.
* I2C_SLAVE_WRITE_RECEIVED (mandatory)
'val': bus driver delivers received byte
'ret': 0 if the byte should be acked, some errno if the byte should be nacked
Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte
should be nacked.
* I2C_SLAVE_READ_PROCESSED (mandatory)
'val': backend returns next byte to be sent
'ret': always 0
The bus driver requests the next byte to be sent to another I2C master in
'val'. Important: This does not mean that the previous byte has been acked, it
only means that the previous byte is shifted out to the bus! To ensure seamless
transmission, most hardware requests the next byte when the previous one is
still shifted out. If the master sends NACK and stops reading after the byte
currently shifted out, this byte requested here is never used. It very likely
needs to be sent again on the next I2C_SLAVE_READ_REQUEST, depending a bit on
your backend, though.
* I2C_SLAVE_STOP (mandatory)
'val': unused
'ret': always 0
A stop condition was received. This can happen anytime and the backend should
reset its state machine for I2C transfers to be able to receive new requests.
소프트웨어 백엔드와 버스 드라이버 구현
129-163소프트웨어 백엔드를 작성할 때는 표준 `i2c_driver`와 그 매칭 메커니즘을 사용합니다. 위 슬레이브 이벤트를 처리하는 `slave_callback`을 상태 머신 형태로 작성하고 `i2c_slave_register()`로 등록합니다. 실제 구현 예는 `i2c-slave-eeprom` 드라이버입니다.
단계요구사항
드라이버 선언표준 `i2c_driver`와 매칭 사용
이벤트 처리가능하면 상태 머신인 `slave_callback` 작성
등록`i2c_slave_register()` 호출
참고 구현`i2c-slave-eeprom`
표준 I2C 드라이버에서 슬레이브 콜백을 연결하는 순서입니다.
버스 드라이버에 슬레이브 지원을 추가할 때는 슬레이브 등록과 등록 해제 호출을 구현하고 `struct i2c_algorithm`에 연결합니다. 등록할 때 보통 슬레이브 주소를 설정하고 슬레이브 전용 인터럽트를 활성화해야 합니다.
런타임 전원 관리를 사용한다면 장치가 자기 슬레이브 주소를 항상 감지할 수 있도록 대개 계속 전원이 켜져 있어야 하므로 `pm_runtime_get_sync()`를 사용해야 합니다. 등록 해제 시에는 주소, 인터럽트, 전원 참조 설정을 반대로 되돌립니다.
컨트롤러의 슬레이브 인터럽트를 처리해 상태에 맞는 `i2c_slave_event`를 백엔드에 보내야 합니다.
대부분의 하드웨어는 같은 버스에서 마스터와 슬레이브 역할을 동시에 지원합니다. 버스 드라이버를 확장할 때도 두 역할을 함께 지원해야 하며, 거의 모든 경우 슬레이브 지원 때문에 마스터 기능을 끌 필요는 없습니다. 참고 구현은 `i2c-rcar` 드라이버입니다.
`struct i2c_algorithm`에 register/unregister 추가→슬레이브 주소와 전용 인터럽트 설정→필요하면 `pm_runtime_get_sync()`로 상시 감지 보장→인터럽트를 적절한 `i2c_slave_event`로 변환→마스터 기능과 슬레이브 기능을 함께 유지→해제 시 설정과 전원 참조를 역순으로 복원
등록부터 이벤트 전달과 해제까지의 책임입니다.
Software backends
-----------------
If you want to write a software backend:
* use a standard i2c_driver and its matching mechanisms
* write the slave_callback which handles the above slave events
(best using a state machine)
* register this callback via i2c_slave_register()
Check the i2c-slave-eeprom driver as an example.
Bus driver support
------------------
If you want to add slave support to the bus driver:
* implement calls to register/unregister the slave and add those to the
struct i2c_algorithm. When registering, you probably need to set the I2C
slave address and enable slave specific interrupts. If you use runtime pm, you
should use pm_runtime_get_sync() because your device usually needs to be
powered on always to be able to detect its slave address. When unregistering,
do the inverse of the above.
* Catch the slave interrupts and send appropriate i2c_slave_events to the backend.
Note that most hardware supports being master _and_ slave on the same bus. So,
if you extend a bus driver, please make sure that the driver supports that as
well. In almost all cases, slave support does not need to disable the master
functionality.
Check the i2c-rcar driver as an example.
주소 ACK 정책과 바이트 단위 API
164-201주소 단계는 항상 ACK하는 것이 바람직합니다. 그래야 마스터가 장치가 기본적으로 존재하는지, 갑자기 사라졌는지를 구분할 수 있습니다. 바쁨을 알리기 위해 주소를 NACK하는 방식은 문제가 많습니다.
SMBus는 주소 단계를 항상 ACK할 것을 요구하지만 I2C 규격은 더 느슨합니다. 또한 많은 I2C 컨트롤러가 자기 슬레이브 주소를 감지하면 자동으로 ACK해 소프트웨어가 NACK할 선택지가 없습니다. 이런 이유로 이 API는 주소 단계 NACK를 지원하지 않습니다.
현재 마스터가 우리에게서 바이트를 읽을 때 그 바이트를 ACK했는지 NACK했는지를 보고하는 슬레이브 이벤트는 없습니다. 필요해지면 선택적 이벤트로 추가할 수 있지만, 마스터는 보통 직후 STOP을 보내고 이미 STOP 이벤트가 있으므로 실제 필요 사례는 매우 드뭅니다. 모든 I2C 컨트롤러가 바이트 ACK/NACK 보고 기능을 제공하는 것도 아닙니다.
단계정책이유
주소항상 ACKSMBus 요구, 하드웨어 자동 ACK, 장치 존재 확인
마스터가 쓰는 데이터 바이트백엔드 반환값으로 ACK/NACK`I2C_SLAVE_WRITE_RECEIVED`가 결정
마스터가 읽은 데이터 바이트ACK/NACK 결과 이벤트 없음STOP으로 종료를 관찰하며 HW 지원도 일정하지 않음
주소 단계와 데이터 단계의 지원 범위를 구분합니다.
API 개발 중 바이트 대신 버퍼를 사용하는 방안도 논의됐습니다. 확장은 가능할 수 있지만 이 문서 작성 시점에는 유용성이 명확하지 않습니다.
버퍼 지원은 선택 기능이어야 하고, 백엔드는 최종 대체 경로로 바이트 단위 전송을 항상 지원해야 합니다. 대다수 하드웨어가 바이트 단위로 동작하기 때문입니다.
하드웨어 레지스터를 모사하는 백엔드에서는 각 쓰기 바이트 직후 동작을 일으켜야 하므로 버퍼가 대체로 도움이 되지 않습니다. 읽기에서도 내부 처리로 레지스터가 갱신되면 버퍼에 미리 담긴 데이터가 오래된 값이 될 수 있습니다.
마스터는 언제든 STOP을 보낼 수 있습니다. 부분 전송된 버퍼를 처리하는 예외 코드가 추가로 필요하고, 이런 코드는 오류가 생기기 쉽습니다.
관점제약
하드웨어 호환성대다수 컨트롤러가 바이트 단위이므로 byte fallback 필수
레지스터 모사 쓰기각 바이트 뒤 즉시 부작용 발생
레지스터 모사 읽기미리 채운 버퍼가 내부 갱신으로 stale해질 수 있음
전송 종료언제든 STOP이 와 부분 버퍼 예외 처리가 필요
바이트 API를 기본으로 유지해야 하는 이유입니다.
About ACK/NACK
--------------
It is good behaviour to always ACK the address phase, so the master knows if a
device is basically present or if it mysteriously disappeared. Using NACK to
state being busy is troublesome. SMBus demands to always ACK the address phase,
while the I2C specification is more loose on that. Most I2C controllers also
automatically ACK when detecting their slave addresses, so there is no option
to NACK them. For those reasons, this API does not support NACK in the address
phase.
Currently, there is no slave event to report if the master did ACK or NACK a
byte when it reads from us. We could make this an optional event if the need
arises. However, cases should be extremely rare because the master is expected
to send STOP after that and we have an event for that. Also, keep in mind not
all I2C controllers have the possibility to report that event.
About buffers
-------------
During development of this API, the question of using buffers instead of just
bytes came up. Such an extension might be possible, usefulness is unclear at
this time of writing. Some points to keep in mind when using buffers:
* Buffers should be opt-in and backend drivers will always have to support
byte-based transactions as the ultimate fallback anyhow because this is how
the majority of HW works.
* For backends simulating hardware registers, buffers are largely not helpful
because after each byte written an action should be immediately triggered.
For reads, the data kept in the buffer might get stale if the backend just
updated a register because of internal processing.
* A master can send STOP at any time. For partially transferred buffers, this
means additional code to handle this exception. Such code tends to be
error-prone.
요약·해설
slave-interface.rst:1-201I2C 슬레이브 프레임워크는 컨트롤러 버스 드라이버와 하드웨어 독립 백엔드를 필수 이벤트로 연결합니다. 주소 단계는 항상 ACK하고, 데이터 바이트 처리와 STOP 기반 상태 초기화는 백엔드 상태 머신이 담당합니다.
원문 분량과 핵심 검토 대상을 요약합니다.
문서의 주요 동작을 압축합니다.