요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
============
I3C protocol
============
Disclaimer
==========
This chapter will focus on aspects that matter to software developers. For
everything hardware related (like how things are transmitted on the bus, how
collisions are prevented, ...) please have a look at the I3C specification.
This document is just a brief introduction to the I3C protocol and the concepts
it brings to the table. If you need more information, please refer to the MIPI
I3C specification (can be downloaded here
https://resources.mipi.org/mipi-i3c-v1-download).
Introduction
============
The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
to overcome I2C limitations (limited speed, external signals needed for
interrupts, no automatic detection of the devices connected to the bus, ...)
while remaining power-efficient.
I3C Bus
=======
An I3C bus is made of several I3C devices and possibly some I2C devices as
well, but let's focus on I3C devices for now.
An I3C device on the I3C bus can have one of the following roles:
* Master: the device is driving the bus. It's the one in charge of initiating
transactions or deciding who is allowed to talk on the bus (slave generated
events are possible in I3C, see below).
* Slave: the device acts as a slave, and is not able to send frames to another
slave on the bus. The device can still send events to the master on
its own initiative if the master allowed it.
I3C is a multi-master protocol, so there might be several masters on a bus,
though only one device can act as a master at a given time. In order to gain
bus ownership, a master has to follow a specific procedure.
Each device on the I3C bus has to be assigned a dynamic address to be able to
communicate. Until this is done, the device should only respond to a limited
set of commands. If it has a static address (also called legacy I2C address),
the device can reply to I2C transfers.
In addition to these per-device addresses, the protocol defines a broadcast
address in order to address all devices on the bus.
Once a dynamic address has been assigned to a device, this address will be used
for any direct communication with the device. Note that even after being
assigned a dynamic address, the device should still process broadcast messages.
I3C Device discovery
====================
The I3C protocol defines a mechanism to automatically discover devices present
on the bus, their capabilities and the functionalities they provide. In this
regard I3C is closer to a discoverable bus like USB than it is to I2C or SPI.
The discovery mechanism is called DAA (Dynamic Address Assignment), because it
not only discovers devices but also assigns them a dynamic address.
During DAA, each I3C device reports 3 important things:
* BCR: Bus Characteristic Register. This 8-bit register describes the device bus
related capabilities
* DCR: Device Characteristic Register. This 8-bit register describes the
functionalities provided by the device
* Provisioned ID: A 48-bit unique identifier. On a given bus there should be no
Provisioned ID collision, otherwise the discovery mechanism may fail.
I3C slave events
================
The I3C protocol allows slaves to generate events on their own, and thus allows
them to take temporary control of the bus.
This mechanism is called IBI for In Band Interrupts, and as stated in the name,
it allows devices to generate interrupts without requiring an external signal.
During DAA, each device on the bus has been assigned an address, and this
address will serve as a priority identifier to determine who wins if 2 different
devices are generating an interrupt at the same moment on the bus (the lower the
dynamic address the higher the priority).
Masters are allowed to inhibit interrupts if they want to. This inhibition
request can be broadcast (applies to all devices) or sent to a specific
device.
I3C Hot-Join
============
The Hot-Join mechanism is similar to USB hotplug. This mechanism allows
slaves to join the bus after it has been initialized by the master.
This covers the following use cases:
* the device is not powered when the bus is probed
* the device is hotplugged on the bus through an extension board
This mechanism is relying on slave events to inform the master that a new
device joined the bus and is waiting for a dynamic address.
The master is then free to address the request as it wishes: ignore it or
assign a dynamic address to the slave.
I3C transfer types
==================
If you omit SMBus (which is just a standardization on how to access registers
exposed by I2C devices), I2C has only one transfer type.
I3C defines 3 different classes of transfer in addition to I2C transfers which
are here for backward compatibility with I2C devices.
I3C CCC commands
----------------
CCC (Common Command Code) commands are meant to be used for anything that is
related to bus management and all features that are common to a set of devices.
CCC commands contain an 8-bit CCC ID describing the command that is executed.
The MSB of this ID specifies whether this is a broadcast command (bit7 = 0) or a
unicast one (bit7 = 1).
The command ID can be followed by a payload. Depending on the command, this
payload is either sent by the master sending the command (write CCC command),
or sent by the slave receiving the command (read CCC command). Of course, read
accesses only apply to unicast commands.
Note that, when sending a CCC command to a specific device, the device address
is passed in the first byte of the payload.
The payload length is not explicitly passed on the bus, and should be extracted
from the CCC ID.
Note that vendors can use a dedicated range of CCC IDs for their own commands
(0x61-0x7f and 0xe0-0xef).
I3C Private SDR transfers
-------------------------
Private SDR (Single Data Rate) transfers should be used for anything that is
device specific and does not require high transfer speed.
It is the equivalent of I2C transfers but in the I3C world. Each transfer is
passed the device address (dynamic address assigned during DAA), a payload
and a direction.
The only difference with I2C is that the transfer is much faster (typical clock
frequency is 12.5MHz).
I3C HDR commands
----------------
HDR commands should be used for anything that is device specific and requires
high transfer speed.
The first thing attached to an HDR command is the HDR mode. There are currently
3 different modes defined by the I3C specification (refer to the specification
for more details):
* HDR-DDR: Double Data Rate mode
* HDR-TSP: Ternary Symbol Pure. Only usable on buses with no I2C devices
* HDR-TSL: Ternary Symbol Legacy. Usable on buses with I2C devices
When sending an HDR command, the whole bus has to enter HDR mode, which is done
using a broadcast CCC command.
Once the bus has entered a specific HDR mode, the master sends the HDR command.
An HDR command is made of:
* one 16-bits command word in big endian
* N 16-bits data words in big endian
Those words may be wrapped with specific preambles/post-ambles which depend on
the chosen HDR mode and are detailed here (see the specification for more
details).
The 16-bits command word is made of:
* bit[15]: direction bit, read is 1, write is 0
* bit[14:8]: command code. Identifies the command being executed, the amount of
data words and their meaning
* bit[7:1]: I3C address of the device this command is addressed to
* bit[0]: reserved/parity-bit
Backward compatibility with I2C devices
=======================================
The I3C protocol has been designed to be backward compatible with I2C devices.
This backward compatibility allows one to connect a mix of I2C and I3C devices
on the same bus, though, in order to be really efficient, I2C devices should
be equipped with 50 ns spike filters.
I2C devices can't be discovered like I3C ones and have to be statically
declared. In order to let the master know what these devices are capable of
(both in terms of bus related limitations and functionalities), the software
has to provide some information, which is done through the LVR (Legacy I2C
Virtual Register).
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
I3C protocol 문서 범위
1-18문서 제목은 `I3C protocol`입니다. 이 장은 software developer에게 중요한 측면에 초점을 맞춥니다. Bus에서 bit가 전송되는 방식이나 collision 방지처럼 hardware와 관련된 모든 사항은 I3C specification을 확인해야 합니다.
이 문서는 I3C protocol과 새로 도입되는 concept를 짧게 소개합니다. 더 자세한 내용은 MIPI I3C specification을 참조해야 하며 `https://resources.mipi.org/mipi-i3c-v1-download`에서 내려받을 수 있습니다.
Software 관점과 hardware 상세의 참조 위치를 구분합니다.
I3C가 해결하는 I2C 한계
19-26I3C는 'eye-three-see'로 발음하며 MIPI가 표준화한 protocol입니다. I2C의 제한된 speed, interrupt를 위한 external signal 필요, bus에 연결된 device를 자동 감지하지 못하는 문제 등을 해결하면서도 power-efficient하도록 설계했습니다.
I3C가 개선하려는 핵심 항목입니다.
I3C bus 역할과 address
27-57I3C bus는 여러 I3C device로 구성되며 I2C device도 함께 있을 수 있습니다. 여기서는 먼저 I3C device에 초점을 맞춥니다.
I3C bus의 device 역할은 Master 또는 Slave입니다. Master는 bus를 drive하고 transaction을 시작하거나 bus에서 누가 말할 수 있는지 결정합니다. I3C에서는 아래에서 설명하는 slave-generated event도 가능합니다.
Slave는 slave로 동작하며 bus의 다른 slave로 frame을 보낼 수 없습니다. 다만 master가 허용했다면 자신의 판단으로 master에 event를 보낼 수 있습니다.
I3C는 multi-master protocol이므로 bus에 master가 여러 개 있을 수 있지만 어느 한 순간에는 device 하나만 master로 동작할 수 있습니다. Master가 bus ownership을 얻으려면 정해진 procedure를 따라야 합니다.
I3C bus의 각 device는 통신하기 전에 dynamic address를 할당받아야 합니다. 할당 전에는 제한된 command 집합에만 응답해야 합니다. Static address, 즉 legacy I2C address가 있다면 I2C transfer에는 응답할 수 있습니다.
Protocol은 device별 address 외에 bus의 모든 device를 지정하는 broadcast address도 정의합니다. Dynamic address를 할당한 뒤에는 device와 직접 통신할 때 그 address를 사용하지만, device는 할당 후에도 broadcast message를 계속 처리해야 합니다.
Master와 Slave의 bus 권한을 비교합니다.
초기 상태에서 direct·broadcast communication까지의 흐름입니다.
Device discovery와 DAA
58-76I3C protocol은 bus에 있는 device, device capability, 제공 functionality를 자동으로 발견하는 mechanism을 정의합니다. 이 점에서 I3C는 I2C나 SPI보다 USB 같은 discoverable bus에 가깝습니다.
Discovery mechanism은 DAA(Dynamic Address Assignment)라고 부릅니다. Device를 발견할 뿐 아니라 dynamic address도 할당하기 때문입니다.
DAA 중 각 I3C device는 세 가지 핵심 정보를 보고합니다. BCR(Bus Characteristic Register)은 bus 관련 capability를 설명하는 8-bit register이고, DCR(Device Characteristic Register)은 device가 제공하는 functionality를 설명하는 8-bit register입니다. Provisioned ID는 48-bit unique identifier입니다.
같은 bus 안에서는 Provisioned ID collision이 없어야 합니다. 충돌하면 discovery mechanism이 실패할 수 있습니다.
Device 발견과 dynamic address 할당을 함께 수행합니다.
DAA에서 각 device가 보고하는 세 field입니다.
In-Band Interrupt
77-94I3C protocol은 slave가 스스로 event를 생성해 bus를 일시적으로 제어할 수 있게 합니다.
이 mechanism은 IBI(In Band Interrupts)라고 하며 이름 그대로 external signal 없이 device가 interrupt를 생성할 수 있게 합니다.
DAA에서 각 bus device에 할당된 dynamic address는 서로 다른 두 device가 같은 순간 interrupt를 생성할 때 승자를 정하는 priority identifier로 쓰입니다. Dynamic address가 낮을수록 priority가 높습니다.
Master는 원한다면 interrupt를 inhibit할 수 있습니다. Inhibition request는 broadcast하여 모든 device에 적용하거나 특정 device에만 보낼 수 있습니다.
동시 slave event에서 dynamic address로 우선순위를 정합니다.
Interrupt 허용·억제와 대상 범위입니다.
Hot-Join
95-111Hot-Join mechanism은 USB hotplug와 비슷하며 master가 bus를 initialize한 뒤에도 slave가 bus에 참여할 수 있게 합니다.
Bus probe 시점에 device 전원이 꺼져 있거나 extension board를 통해 device가 bus에 hotplug되는 use case를 다룹니다.
새 device는 slave event로 자신이 bus에 참여했고 dynamic address를 기다린다고 master에 알립니다. Master는 이 request를 무시하거나 slave에 dynamic address를 할당하는 등 원하는 방식으로 처리할 수 있습니다.
초기화 뒤 참여한 slave의 address 요청 흐름입니다.
I3C transfer class
112-120I2C device가 노출한 register에 접근하는 방식을 표준화한 SMBus를 제외하면 I2C에는 transfer type이 하나뿐입니다.
I3C는 서로 다른 transfer class 세 가지를 정의하고, I2C device와의 backward compatibility를 위해 I2C transfer도 추가로 허용합니다.
세 I3C class와 compatibility transfer를 구분합니다.
CCC command
121-143CCC(Common Command Code) command는 bus management와 여러 device에 공통인 모든 feature에 사용합니다.
CCC command에는 실행할 command를 설명하는 8-bit CCC ID가 있습니다. ID의 MSB인 bit7은 broadcast command인지 unicast command인지 나타냅니다. `bit7 = 0`이면 broadcast이고 `bit7 = 1`이면 unicast입니다.
Command ID 뒤에는 payload가 올 수 있습니다. Command에 따라 command를 보내는 master가 payload를 전송하는 write CCC command이거나 command를 받은 slave가 payload를 전송하는 read CCC command입니다. Read access는 당연히 unicast command에만 적용됩니다.
특정 device에 CCC command를 보낼 때 device address는 payload의 첫 byte로 전달합니다. Payload length는 bus에서 명시적으로 전달하지 않으며 CCC ID에서 추출해야 합니다.
Vendor는 자체 command에 전용 CCC ID 범위 `0x61-0x7f`와 `0xe0-0xef`를 사용할 수 있습니다.
8-bit CCC ID의 최상위 bit가 addressing mode를 정합니다.
ID 해석과 payload 방향·길이 결정 순서입니다.
Vendor-specific command에 예약된 두 범위입니다.
Private SDR transfer
144-156Private SDR(Single Data Rate) transfer는 device-specific이고 높은 transfer speed가 필요하지 않은 작업에 사용해야 합니다.
I3C 세계에서 I2C transfer에 해당합니다. 각 transfer에는 DAA 중 할당된 device dynamic address, payload, direction을 전달합니다.
I2C와의 유일한 차이는 transfer가 훨씬 빠르다는 점이며 typical clock frequency는 12.5 MHz입니다.
일반 device-specific transfer의 입력과 속도입니다.
HDR command
157-190HDR command는 device-specific이고 높은 transfer speed가 필요한 작업에 사용해야 합니다.
HDR command에는 먼저 HDR mode가 붙습니다. I3C specification은 현재 세 mode를 정의합니다. HDR-DDR은 Double Data Rate mode입니다. HDR-TSP는 Ternary Symbol Pure로 I2C device가 없는 bus에서만 쓸 수 있습니다. HDR-TSL은 Ternary Symbol Legacy로 I2C device가 있는 bus에서도 쓸 수 있습니다. 자세한 내용은 specification을 참조해야 합니다.
HDR command를 보낼 때는 먼저 broadcast CCC command로 전체 bus를 HDR mode에 진입시켜야 합니다. Bus가 특정 HDR mode에 들어가면 master가 HDR command를 보냅니다.
HDR command는 big endian의 16-bits command word 하나와 big endian의 16-bits data word N개로 이루어집니다. 선택한 HDR mode에 따라 특정 preamble과 post-amble로 word를 감쌀 수 있으며 세부 형식은 specification에 있습니다.
16-bits command word에서 `bit[15]`는 direction bit로 read는 1, write는 0입니다. `bit[14:8]`은 실행할 command, data word 수와 의미를 식별하는 command code입니다. `bit[7:1]`은 command 대상 I3C device address이고 `bit[0]`은 reserved/parity-bit입니다.
세 high data rate mode와 I2C device 공존 조건입니다.
Bus mode 전환에서 data word 전송까지의 순서입니다.
Command word의 bit field를 보존해 구조화했습니다.
I2C backward compatibility와 LVR
191-203I3C protocol은 I2C device와 backward compatible하도록 설계했습니다. 따라서 같은 bus에 I2C와 I3C device를 섞어 연결할 수 있습니다. 다만 실제로 효율적으로 동작하려면 I2C device에 50 ns spike filter가 있어야 합니다.
I2C device는 I3C device처럼 discovery할 수 없으므로 statically declared해야 합니다. Master가 bus-related limitation과 functionality 양쪽에서 이 device의 capability를 알 수 있도록 software가 정보를 제공해야 하며, 이 정보는 LVR(Legacy I2C Virtual Register)을 통해 전달합니다.
혼합 bus에서 I2C device에 필요한 처리입니다.
자동 발견이 없는 I2C device 정보를 master에 제공하는 흐름입니다.
요약과 해설
protocol.rst:1-203I3C는 I2C 호환성을 유지하면서 자동 discovery와 dynamic address, external IRQ 선 없는 slave event, 더 빠른 transfer class를 제공합니다. Software는 DAA identity, IBI priority, CCC addressing, HDR mode와 legacy I2C LVR를 함께 다뤄야 합니다.