Documentation/driver-api/i3c/protocol.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/i3c/protocol.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/i3c/protocol.rst
Extension
.rst
Size
8170 bytes
Lines
204
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. 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

Annotation

Implementation Notes