Documentation/driver-api/soundwire/summary.rst GitHub 원문 ↗

Linux 6.18.37 · Driver API

SoundWire Subsystem Summary

SoundWire physical bus, port 용량, Linux Bus·Slave model, Master ops와 Slave 식별·driver matching을 다루는 전문 번역입니다.

Source pathDocumentation/driver-api/soundwire/summary.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

summary.rst:1-200

SoundWire는 audio payload·control·setup을 data와 clock의 2-pin multi-drop bus로 운반합니다. Linux subsystem은 Master를 Bus instance로, 각 Slave interface를 driver가 관리하는 device로 표현하고, MIPI register와 공통 설정은 Bus가 맡으며 vendor-specific 기능은 Slave driver가 담당합니다. Master ops는 hardware detail을 추상화하고 Slave는 48-bit dev_id와 controller-local link_id, parent/child 관계로 식별됩니다.

문서 구성
원문 줄내용
1-54Physical interface, port 용량과 topology
55-82Bus·Slave·Slave driver terminology
83-137Master registration과 callback ops
138-186Slave enumeration·driver·capability
187-200MIPI specification reference

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ===========================
2 SoundWire Subsystem Summary
3 ===========================
4
5 SoundWire is a new interface ratified in 2015 by the MIPI Alliance.
6 SoundWire is used for transporting data typically related to audio
7 functions. SoundWire interface is optimized to integrate audio devices in
8 mobile or mobile inspired systems.
9
10 SoundWire is a 2-pin multi-drop interface with data and clock line. It
11 facilitates development of low cost, efficient, high performance systems.
12 Broad level key features of SoundWire interface include:
13
14 (1) Transporting all of payload data channels, control information, and setup
15 commands over a single two-pin interface.
16
17 (2) Lower clock frequency, and hence lower power consumption, by use of DDR
18 (Dual Data Rate) data transmission.
19
20 (3) Clock scaling and optional multiple data lanes to give wide flexibility
21 in data rate to match system requirements.
22
23 (4) Device status monitoring, including interrupt-style alerts to the Master.
24
25 The SoundWire protocol supports up to eleven Slave interfaces. All the
26 interfaces share the common Bus containing data and clock line. Each of the
27 Slaves can support up to 14 Data Ports. 13 Data Ports are dedicated to audio
28 transport. Data Port0 is dedicated to transport of Bulk control information,
29 each of the audio Data Ports (1..14) can support up to 8 Channels in
30 transmit or receiving mode (typically fixed direction but configurable
31 direction is enabled by the specification). Bandwidth restrictions to
32 ~19.2..24.576Mbits/s don't however allow for 11*13*8 channels to be
33 transmitted simultaneously.
34
35 Below figure shows an example of connectivity between a SoundWire Master and
36 two Slave devices. ::
37
38 +---------------+ +---------------+
39 | | Clock Signal | |
40 | Master |-------+-------------------------------| Slave |
41 | Interface | | Data Signal | Interface 1 |
42 | |-------|-------+-----------------------| |
43 +---------------+ | | +---------------+
44 | |
45 | |
46 | |
47 +--+-------+--+
48 | |
49 | Slave |
50 | Interface 2 |
51 | |
52 +-------------+
53
54
55 Terminology
56 ===========
57
58 The MIPI SoundWire specification uses the term 'device' to refer to a Master
59 or Slave interface, which of course can be confusing. In this summary and
60 code we use the term interface only to refer to the hardware. We follow the
61 Linux device model by mapping each Slave interface connected on the bus as a
62 device managed by a specific driver. The Linux SoundWire subsystem provides
63 a framework to implement a SoundWire Slave driver with an API allowing
64 3rd-party vendors to enable implementation-defined functionality while
65 common setup/configuration tasks are handled by the bus.
66
67 Bus:
68 Implements SoundWire Linux Bus which handles the SoundWire protocol.
69 Programs all the MIPI-defined Slave registers. Represents a SoundWire
70 Master. Multiple instances of Bus may be present in a system.
71
72 Slave:
73 Registers as SoundWire Slave device (Linux Device). Multiple Slave devices
74 can register to a Bus instance.
75
76 Slave driver:
77 Driver controlling the Slave device. MIPI-specified registers are controlled
78 directly by the Bus (and transmitted through the Master driver/interface).
79 Any implementation-defined Slave register is controlled by Slave driver. In
80 practice, it is expected that the Slave driver relies on regmap and does not
81 request direct register access.
82
83 Programming interfaces (SoundWire Master interface Driver)
84 ==========================================================
85
86 SoundWire Bus supports programming interfaces for the SoundWire Master
87 implementation and SoundWire Slave devices. All the code uses the "sdw"
88 prefix commonly used by SoC designers and 3rd party vendors.
89
90 Each of the SoundWire Master interfaces needs to be registered to the Bus.
91 Bus implements API to read standard Master MIPI properties and also provides
92 callback in Master ops for Master driver to implement its own functions that
93 provides capabilities information. DT support is not implemented at this
94 time but should be trivial to add since capabilities are enabled with the
95 ``device_property_`` API.
96
97 The Master interface along with the Master interface capabilities are
98 registered based on board file, DT or ACPI.
99
100 Following is the Bus API to register the SoundWire Bus:
101
102 .. code-block:: c
103
104 int sdw_bus_master_add(struct sdw_bus *bus,
105 struct device *parent,
106 struct fwnode_handle)
107 {
108 sdw_master_device_add(bus, parent, fwnode);
109
110 mutex_init(&bus->lock);
111 INIT_LIST_HEAD(&bus->slaves);
112
113 /* Check ACPI for Slave devices */
114 sdw_acpi_find_slaves(bus);
115
116 /* Check DT for Slave devices */
117 sdw_of_find_slaves(bus);
118
119 return 0;
120 }
121
122 This will initialize sdw_bus object for Master device. "sdw_master_ops" and
123 "sdw_master_port_ops" callback functions are provided to the Bus.
124
125 "sdw_master_ops" is used by Bus to control the Bus in the hardware specific
126 way. It includes Bus control functions such as sending the SoundWire
127 read/write messages on Bus, setting up clock frequency & Stream
128 Synchronization Point (SSP). The "sdw_master_ops" structure abstracts the
129 hardware details of the Master from the Bus.
130
131 "sdw_master_port_ops" is used by Bus to setup the Port parameters of the
132 Master interface Port. Master interface Port register map is not defined by
133 MIPI specification, so Bus calls the "sdw_master_port_ops" callback
134 function to do Port operations like "Port Prepare", "Port Transport params
135 set", "Port enable and disable". The implementation of the Master driver can
136 then perform hardware-specific configurations.
137
138 Programming interfaces (SoundWire Slave Driver)
139 ===============================================
140
141 The MIPI specification requires each Slave interface to expose a unique
142 48-bit identifier, stored in 6 read-only dev_id registers. This dev_id
143 identifier contains vendor and part information, as well as a field enabling
144 to differentiate between identical components. An additional class field is
145 currently unused. Slave driver is written for a specific vendor and part
146 identifier, Bus enumerates the Slave device based on these two ids.
147 Slave device and driver match is done based on these two ids . Probe
148 of the Slave driver is called by Bus on successful match between device and
149 driver id. A parent/child relationship is enforced between Master and Slave
150 devices (the logical representation is aligned with the physical
151 connectivity).
152
153 The information on Master/Slave dependencies is stored in platform data,
154 board-file, ACPI or DT. The MIPI Software specification defines additional
155 link_id parameters for controllers that have multiple Master interfaces. The
156 dev_id registers are only unique in the scope of a link, and the link_id
157 unique in the scope of a controller. Both dev_id and link_id are not
158 necessarily unique at the system level but the parent/child information is
159 used to avoid ambiguity.
160
161 .. code-block:: c
162
163 static const struct sdw_device_id slave_id[] = {
164 SDW_SLAVE_ENTRY(0x025d, 0x700, 0),
165 {},
166 };
167 MODULE_DEVICE_TABLE(sdw, slave_id);
168
169 static struct sdw_driver slave_sdw_driver = {
170 .driver = {
171 .name = "slave_xxx",
172 .pm = &slave_runtime_pm,
173 },
174 .probe = slave_sdw_probe,
175 .remove = slave_sdw_remove,
176 .ops = &slave_slave_ops,
177 .id_table = slave_id,
178 };
179
180
181 For capabilities, Bus implements API to read standard Slave MIPI properties
182 and also provides callback in Slave ops for Slave driver to implement own
183 function that provides capabilities information. Bus needs to know a set of
184 Slave capabilities to program Slave registers and to control the Bus
185 reconfigurations.
186
187 Links
188 =====
189
190 SoundWire MIPI specification 1.1 is available at:
191 https://members.mipi.org/wg/All-Members/document/70290
192
193 SoundWire MIPI DisCo (Discovery and Configuration) specification is
194 available at:
195 https://www.mipi.org/specifications/mipi-disco-soundwire
196
197 (publicly accessible with registration or directly accessible to MIPI
198 members)
199
200 MIPI Alliance Manufacturer ID Page: mid.mipi.org
201

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

SoundWire interface 개요

1-34

SoundWire는 MIPI Alliance가 2015년에 ratify한 interface입니다. 주로 audio function과 관련된 data를 운반하며 mobile 또는 mobile-inspired system에 audio device를 통합하도록 최적화됐습니다.

SoundWire는 data line과 clock line으로 구성된 2-pin multi-drop interface이며 저비용, 고효율, 고성능 system 개발을 돕습니다.

주요 기능은 payload data channel, control information, setup command를 하나의 2-pin interface로 전송하는 것, DDR(Dual Data Rate) transmission으로 clock frequency와 power consumption을 낮추는 것, clock scaling과 optional multiple data lane으로 요구 data rate에 맞추는 것, interrupt-style alert를 포함한 device status monitoring입니다.

Protocol은 최대 11개의 Slave interface를 지원하며 모두 공통 data·clock Bus를 공유합니다. 각 Slave는 최대 14개 Data Port를 지원할 수 있습니다. 그중 13개는 audio transport 전용이고 Data Port0은 bulk control information 전용입니다.

Audio Data Port 1..14는 transmit 또는 receive mode에서 각각 최대 8 channel을 지원합니다. 방향은 보통 고정되지만 specification은 configurable direction도 허용합니다. 약 19.2..24.576 Mbit/s의 bandwidth 제한 때문에 11*13*8 channel을 동시에 전송할 수는 없습니다.

SoundWire 핵심 용량과 기능
항목범위 / 특성
Physical interface2-pin multi-drop: data + clock
TransmissionDDR, clock scaling, optional multiple lanes
Slave interfaces최대 11
Data Ports per Slave최대 14
Data Port0Bulk control information
Audio Data Ports13개 전용, port당 최대 8 channels
Bus bandwidth약 19.2..24.576 Mbit/s

===========================
SoundWire Subsystem Summary
===========================

SoundWire is a new interface ratified in 2015 by the MIPI Alliance.
SoundWire is used for transporting data typically related to audio
functions. SoundWire interface is optimized to integrate audio devices in
mobile or mobile inspired systems.

SoundWire is a 2-pin multi-drop interface with data and clock line. It
facilitates development of low cost, efficient, high performance systems.
Broad level key features of SoundWire interface include:

 (1) Transporting all of payload data channels, control information, and setup
     commands over a single two-pin interface.

 (2) Lower clock frequency, and hence lower power consumption, by use of DDR
     (Dual Data Rate) data transmission.

 (3) Clock scaling and optional multiple data lanes to give wide flexibility
     in data rate to match system requirements.

 (4) Device status monitoring, including interrupt-style alerts to the Master.

The SoundWire protocol supports up to eleven Slave interfaces. All the
interfaces share the common Bus containing data and clock line. Each of the
Slaves can support up to 14 Data Ports. 13 Data Ports are dedicated to audio
transport. Data Port0 is dedicated to transport of Bulk control information,
each of the audio Data Ports (1..14) can support up to 8 Channels in
transmit or receiving mode (typically fixed direction but configurable
direction is enabled by the specification).  Bandwidth restrictions to
~19.2..24.576Mbits/s don't however allow for 11*13*8 channels to be
transmitted simultaneously.

Master와 두 Slave의 connectivity

35-54

예시 topology는 하나의 SoundWire Master interface와 두 Slave interface를 같은 multi-drop Bus에 연결합니다.

Master에서 나온 Clock Signal과 Data Signal은 Slave Interface 1로 이어지고 중간 branch를 통해 Slave Interface 2에도 공유됩니다.

SoundWire multi-drop topology
Master InterfaceClock SignalSlave Interface 1
Master InterfaceData SignalSlave Interface 1
Shared Clock/Data BusBranchSlave Interface 2

원문의 ASCII 연결 그림을 공통 clock·data bus의 branch 구조로 다시 구성했습니다.

Below figure shows an example of connectivity between a SoundWire Master and
two Slave devices. ::

        +---------------+                                       +---------------+
        |               |                       Clock Signal    |               |
        |    Master     |-------+-------------------------------|    Slave      |
        |   Interface   |       |               Data Signal     |  Interface 1  |
        |               |-------|-------+-----------------------|               |
        +---------------+       |       |                       +---------------+
                                |       |
                                |       |
                                |       |
                             +--+-------+--+
                             |             |
                             |   Slave     |
                             | Interface 2 |
                             |             |
                             +-------------+

Bus, Slave와 Slave driver

55-82

MIPI SoundWire specification은 Master 또는 Slave interface를 가리킬 때 `device`라는 용어를 사용하므로 혼동될 수 있습니다. 이 summary와 code에서는 hardware만 `interface`라고 부릅니다.

Linux device model에 따라 Bus에 연결된 각 Slave interface를 특정 driver가 관리하는 device로 mapping합니다. Linux SoundWire subsystem은 third-party vendor가 implementation-defined 기능을 구현할 수 있는 Slave driver API를 제공하고, 공통 setup과 configuration은 Bus가 처리합니다.

Bus는 SoundWire protocol을 처리하는 Linux Bus를 구현하고 MIPI가 정의한 모든 Slave register를 program하며 SoundWire Master를 나타냅니다. 한 system에 여러 Bus instance가 존재할 수 있습니다.

Slave는 SoundWire Slave device, 즉 Linux Device로 register하며 하나의 Bus instance에 여러 Slave device를 등록할 수 있습니다.

Slave driver는 Slave device를 제어합니다. MIPI-specified register는 Bus가 직접 제어하고 Master driver/interface를 통해 전송합니다. Implementation-defined Slave register는 Slave driver가 제어합니다. 실제 구현에서는 Slave driver가 regmap을 사용하고 direct register access를 요청하지 않을 것으로 예상합니다.

Linux SoundWire 용어와 책임
구성 요소Linux 표현책임
BusMaster를 나타내는 Bus instanceProtocol·MIPI register·공통 설정
SlaveBus에 등록된 Linux DeviceSlave interface 표현
Slave driverVendor/part별 driverImplementation-defined register·기능
Master driver/interfaceBus 전송 경로MIPI register access 전달

Terminology
===========

The MIPI SoundWire specification uses the term 'device' to refer to a Master
or Slave interface, which of course can be confusing. In this summary and
code we use the term interface only to refer to the hardware. We follow the
Linux device model by mapping each Slave interface connected on the bus as a
device managed by a specific driver. The Linux SoundWire subsystem provides
a framework to implement a SoundWire Slave driver with an API allowing
3rd-party vendors to enable implementation-defined functionality while
common setup/configuration tasks are handled by the bus.

Bus:
Implements SoundWire Linux Bus which handles the SoundWire protocol.
Programs all the MIPI-defined Slave registers. Represents a SoundWire
Master. Multiple instances of Bus may be present in a system.

Slave:
Registers as SoundWire Slave device (Linux Device). Multiple Slave devices
can register to a Bus instance.

Slave driver:
Driver controlling the Slave device. MIPI-specified registers are controlled
directly by the Bus (and transmitted through the Master driver/interface).
Any implementation-defined Slave register is controlled by Slave driver. In
practice, it is expected that the Slave driver relies on regmap and does not
request direct register access.

Master interface 등록과 capability

83-100

SoundWire Bus는 Master implementation과 Slave device를 위한 programming interface를 지원합니다. SoC designer와 third-party vendor가 널리 쓰는 `sdw` prefix를 모든 code에 사용합니다.

각 SoundWire Master interface는 Bus에 register해야 합니다. Bus는 standard Master MIPI property를 읽는 API와 Master driver가 자체 capability information function을 구현하는 Master ops callback을 제공합니다.

현재 DT support는 구현되지 않았지만 capability가 `device_property_` API로 enable되므로 추가하기 어렵지 않습니다.

Master interface와 capability는 board file, DT 또는 ACPI를 기반으로 register합니다.

Master 등록 정보
항목제공 경로
Standard MIPI propertiesBus API
Hardware capabilityMaster ops callback
Firmware descriptionBoard file, DT 또는 ACPI
Property abstraction`device_property_` API
Code prefix`sdw`

Programming interfaces (SoundWire Master interface Driver)
==========================================================

SoundWire Bus supports programming interfaces for the SoundWire Master
implementation and SoundWire Slave devices. All the code uses the "sdw"
prefix commonly used by SoC designers and 3rd party vendors.

Each of the SoundWire Master interfaces needs to be registered to the Bus.
Bus implements API to read standard Master MIPI properties and also provides
callback in Master ops for Master driver to implement its own functions that
provides capabilities information. DT support is not implemented at this
time but should be trivial to add since capabilities are enabled with the
``device_property_`` API.

The Master interface along with the Master interface capabilities are
registered based on board file, DT or ACPI.

Following is the Bus API to register the SoundWire Bus:

sdw_bus_master_add와 Master ops

101-137

`sdw_bus_master_add()`는 Master device의 `sdw_bus` object를 initialize합니다. 내부에서 `sdw_master_device_add()`를 호출하고 `bus->lock` mutex와 `bus->slaves` list를 초기화한 다음 ACPI와 DT에서 Slave device를 찾습니다.

Bus에는 `sdw_master_ops`와 `sdw_master_port_ops` callback function이 제공됩니다.

`sdw_master_ops`는 hardware-specific 방식으로 Bus를 제어합니다. SoundWire read/write message 전송, clock frequency 설정, Stream Synchronization Point(SSP) 설정 같은 Bus control function을 포함하며 Master의 hardware detail을 Bus에서 abstract합니다.

`sdw_master_port_ops`는 Master interface port의 parameter를 설정합니다. Master port register map은 MIPI specification에 정의되지 않으므로 Bus가 callback을 호출해 Port Prepare, Port Transport parameter 설정, Port enable·disable을 수행하고 Master driver가 hardware-specific configuration을 적용합니다.

Master callback 역할
Callback대표 operation
`sdw_master_ops`Read/write message, clock frequency, SSP
`sdw_master_port_ops`Port Prepare
`sdw_master_port_ops`Port Transport params set
`sdw_master_port_ops`Port enable / disable


.. code-block:: c

        int sdw_bus_master_add(struct sdw_bus *bus,
                                struct device *parent,
                                struct fwnode_handle)
        {
                sdw_master_device_add(bus, parent, fwnode);

                mutex_init(&bus->lock);
                INIT_LIST_HEAD(&bus->slaves);

                /* Check ACPI for Slave devices */
                sdw_acpi_find_slaves(bus);

                /* Check DT for Slave devices */
                sdw_of_find_slaves(bus);

                return 0;
        }

This will initialize sdw_bus object for Master device. "sdw_master_ops" and
"sdw_master_port_ops" callback functions are provided to the Bus.

"sdw_master_ops" is used by Bus to control the Bus in the hardware specific
way. It includes Bus control functions such as sending the SoundWire
read/write messages on Bus, setting up clock frequency & Stream
Synchronization Point (SSP). The "sdw_master_ops" structure abstracts the
hardware details of the Master from the Bus.

"sdw_master_port_ops" is used by Bus to setup the Port parameters of the
Master interface Port. Master interface Port register map is not defined by
MIPI specification, so Bus calls the "sdw_master_port_ops" callback
function to do Port operations like "Port Prepare", "Port Transport params
set", "Port enable and disable". The implementation of the Master driver can
then perform hardware-specific configurations.

48-bit dev_id와 Slave matching

138-160

MIPI specification은 각 Slave interface가 6개의 read-only `dev_id` register에 저장된 unique 48-bit identifier를 노출하도록 요구합니다.

`dev_id`에는 vendor와 part information, 동일 component를 서로 구별하는 field가 들어갑니다. 추가 class field는 현재 사용하지 않습니다.

Slave driver는 특정 vendor와 part identifier에 맞춰 작성하며 Bus는 이 두 ID로 Slave device를 enumerate합니다. Device와 driver도 두 ID로 match하고 성공하면 Bus가 Slave driver의 probe를 호출합니다.

Master와 Slave device 사이에는 parent/child relationship을 강제해 logical representation을 physical connectivity와 일치시킵니다.

Master/Slave dependency는 platform data, board file, ACPI 또는 DT에 저장합니다. MIPI Software specification은 여러 Master interface를 가진 controller를 위해 `link_id` parameter를 추가로 정의합니다.

`dev_id` register는 link scope에서만 unique하고 `link_id`는 controller scope에서 unique합니다. 둘 다 system level에서 반드시 unique하지는 않지만 parent/child information을 사용해 ambiguity를 피합니다.

Slave 식별 scope
식별 정보구성Unique scope
`dev_id`48 bit, 6 read-only registersLink
Vendor + part IDDriver match keyDriver 대상
Component field동일 component 구분Link 내 device
Class field현재 미사용-
`link_id`Controller의 Master interface 구분Controller
Parent/childMaster-Slave physical relationSystem ambiguity 제거

Programming interfaces (SoundWire Slave Driver)
===============================================

The MIPI specification requires each Slave interface to expose a unique
48-bit identifier, stored in 6 read-only dev_id registers. This dev_id
identifier contains vendor and part information, as well as a field enabling
to differentiate between identical components. An additional class field is
currently unused. Slave driver is written for a specific vendor and part
identifier, Bus enumerates the Slave device based on these two ids.
Slave device and driver match is done based on these two ids . Probe
of the Slave driver is called by Bus on successful match between device and
driver id. A parent/child relationship is enforced between Master and Slave
devices (the logical representation is aligned with the physical
connectivity).

The information on Master/Slave dependencies is stored in platform data,
board-file, ACPI or DT. The MIPI Software specification defines additional
link_id parameters for controllers that have multiple Master interfaces. The
dev_id registers are only unique in the scope of a link, and the link_id
unique in the scope of a controller. Both dev_id and link_id are not
necessarily unique at the system level but the parent/child information is
used to avoid ambiguity.

Slave driver table과 capability

161-186

Slave driver는 `struct sdw_device_id` table에 `SDW_SLAVE_ENTRY(vendor, part, class)`를 등록하고 `MODULE_DEVICE_TABLE(sdw, slave_id)`로 module device table을 제공합니다.

`struct sdw_driver`에는 driver name과 runtime PM, `probe`, `remove`, Slave ops, `id_table`을 설정합니다. 원문 예시는 vendor `0x025d`, part `0x700`, class `0`을 사용합니다.

Capability 처리를 위해 Bus는 standard Slave MIPI property를 읽는 API를 구현하고, Slave driver가 자체 capability information function을 제공할 수 있도록 Slave ops callback을 노출합니다.

Bus는 Slave register를 program하고 Bus reconfiguration을 제어하기 위해 일정한 Slave capability 집합을 알아야 합니다.

Slave driver 구성
구성역할
`sdw_device_id`Vendor·part·class match
`SDW_SLAVE_ENTRY`ID table entry
`sdw_driver.probe/remove`Device lifecycle
`sdw_driver.ops`Slave-specific operation
Slave MIPI propertiesBus의 register programming·reconfiguration 입력

.. code-block:: c

        static const struct sdw_device_id slave_id[] = {
                SDW_SLAVE_ENTRY(0x025d, 0x700, 0),
                {},
        };
        MODULE_DEVICE_TABLE(sdw, slave_id);

        static struct sdw_driver slave_sdw_driver = {
                .driver = {
                           .name = "slave_xxx",
                           .pm = &slave_runtime_pm,
                           },
                .probe = slave_sdw_probe,
                .remove = slave_sdw_remove,
                .ops = &slave_slave_ops,
                .id_table = slave_id,
        };


For capabilities, Bus implements API to read standard Slave MIPI properties
and also provides callback in Slave ops for Slave driver to implement own
function that provides capabilities information. Bus needs to know a set of
Slave capabilities to program Slave registers and to control the Bus
reconfigurations.