Version 0.82.

01 30-Oct-2008 MIPI Alliance Specification for DDB

MIPI Alliance Specification for

Device Descriptor Block (DDB)

Version 0.82.01 – 30 October 2008

MIPI Board Approved 29-Oct-2008

Further technical changes to this document are expected as work continues in the DDB Working Group

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

1 NOTICE OF DISCLAIMER

2 The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled
3 by any of the authors or developers of this material or MIPI. The material contained herein is provided on
4 an “AS IS” basis and to the maximum extent permitted by applicable law, this material is provided AS IS
5 AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all
6 other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if
7 any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of
8 accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of
9 negligence.

10 All materials contained herein are protected by copyright laws, and may not be reproduced, republished,
11 distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express
12 prior written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related
13 trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and
14 cannot be used without its express prior written permission.

15 ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET

16 POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
17 TO THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT. IN NO EVENT WILL ANY
18 AUTHOR OR DEVELOPER OF THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT OR
19 MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE
20 GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
21 CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
22 CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR
23 ANY OTHER AGREEMENT, SPECIFICATION OR DOCUMENT RELATING TO THIS MATERIAL,
24 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
25 DAMAGES.

26 Without limiting the generality of this Disclaimer stated above, the user of the contents of this Document is
27 further notified that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the
28 contents of this Document; (b) does not monitor or enforce compliance with the contents of this Document;
29 and (c) does not certify, test, or in any manner investigate products or services or any claims of compliance
30 with the contents of this Document. The use or implementation of the contents of this Document may
31 involve or require the use of intellectual property rights ("IPR") including (but not limited to) patents,
32 patent applications, or copyrights owned by one or more parties, whether or not Members of MIPI. MIPI
33 does not make any search or investigation for IPR, nor does MIPI require or request the disclosure of any
34 IPR or claims of IPR as respects the contents of this Document or otherwise.

35 Questions pertaining to this document, or the terms or conditions of its provision, should be addressed to:

36 MIPI Alliance, Inc.

37 c/o IEEE-ISTO
38 445 Hoes Lane
39 Piscataway, NJ 08854
40 Attn: Board Secretary
41

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
ii
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

42 Contents
43 Version 0.82.01 – 30 October 2008 ..................................................................................................................i

44 1 Introduction ............................................................................................................................................. 7

45 1.1 Scope ............................................................................................................................................... 7

46 1.2 Purpose ............................................................................................................................................ 7

47 2 Terminology (informative) ...................................................................................................................... 8

48 2.1 Definitions ....................................................................................................................................... 8

49 2.2 Service Primitive Naming ............................................................................................................... 9

50 2.3 Acronyms ........................................................................................................................................ 9

51 3 References ............................................................................................................................................. 11

52 4 Architecture Overview (informative) .................................................................................................... 12

53 5 DDB Services ........................................................................................................................................ 14

54 5.1 Generic Service Elements .............................................................................................................. 14

55 5.1.1 General Service Parameters ................................................................................................... 14

56 5.1.2 Error Reporting ...................................................................................................................... 16

57 5.2 DDB Level 1 Service ..................................................................................................................... 16

58 5.2.1 DDB Level 1 Specific Service Parameter .............................................................................. 16

59 5.2.2 GET-DDB-LEVEL1 SAP ..................................................................................................... 17

60 5.3 DDB Level 2 Services ................................................................................................................... 20

61 5.3.1 DDB Level 2 Data Model ...................................................................................................... 20

62 5.3.2 DDB Level 2 Specific Service Parameters ............................................................................ 22

63 5.3.3 GET-DDB-LEVEL2 SAP ..................................................................................................... 23

64 5.3.4 SET-DDB-LEVEL2 SAP ...................................................................................................... 27

65 6 DDB Protocol ........................................................................................................................................ 31

66 6.1 Generic Protocol Elements ............................................................................................................ 31

67 6.1.1 Requestor and Provider Protocol Model ................................................................................ 31

68 6.1.2 Underlying Interconnect Requirements ................................................................................. 32

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
iii
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

69 6.1.3 DDB-PDU Format ................................................................................................................. 32

70 6.1.4 Error Handling ....................................................................................................................... 33

71 6.2 DDB Protocol Support for Level 1 Service ................................................................................... 34

72 6.2.1 Relation to Service Primitives ............................................................................................... 34

73 6.2.2 GET-DDB-LEVEL1 Payloads .............................................................................................. 34

74 6.3 DDB Protocol support for Level 2 Services .................................................................................. 35

75 6.3.1 Relation to Service Primitives ............................................................................................... 35

76 6.3.2 GET-DDB-LEVEL2 Payloads .............................................................................................. 35

77 6.3.3 SET-DDB-LEVEL2 Payloads ............................................................................................... 36

78 Annex A DDB Error Flow (informative) ...................................................................................................... 38

79
80

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
iv
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

81 Figures
82 Figure 1 Devices on an Interconnect ............................................................................................................ 12

83 Figure 2 Mapping DDB to MIPI Interfaces .................................................................................................. 12

84 Figure 3 DDB Layer Overview .................................................................................................................... 13

85 Figure 4 Service Primitives and Roles.......................................................................................................... 13

86 Figure 5 ResultCode Format......................................................................................................................... 15

87 Figure 6 Level 2 Data Model and Mapping Example .................................................................................. 22

88 Figure 7 Service Primitive to Protocol Relationship .................................................................................... 31

89 Figure 8 DDB-PDU Format ......................................................................................................................... 32

90 Figure 9 GET-DDB-LEVEL1 Response Message Payload Format ............................................................. 35

91 Figure 10 GET-DDB-LEVEL2 Request Message Payload Format ............................................................. 36

92 Figure 11 GET-DDB-LEVEL2 Response Message Payload Format ........................................................... 36

93 Figure 12 SET-DDB-LEVEL2 Request Message Payload Format .............................................................. 37

94 Figure 13 SET-DDB-LEVEL2 Response Message Payload Format............................................................ 37

95 Figure 14 DDB Error Flow........................................................................................................................... 39

96
97

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
v
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

98 Tables
99 Table 1 RequestorID Format ........................................................................................................................ 14

100 Table 2 ProviderID Format .......................................................................................................................... 14

101 Table 3 TransactionID Format ..................................................................................................................... 15

102 Table 4 ResultCode Flags ............................................................................................................................. 15

103 Table 5 ResultCode Status Values................................................................................................................ 15

104 Table 6 DdbL1Data Fields ........................................................................................................................... 17

105 Table 7 DDB-L1-SAP Primitives ................................................................................................................. 17

106 Table 8 GET-DDB-LEVEL1.response ResultCode Status Values .............................................................. 19

107 Table 9 GET-DDB-LEVEL1.confirm ResultCode Status Values ................................................................ 20

108 Table 10 DDB Level 2 Data Type Encoding................................................................................................ 21

109 Table 11 DDB Level 2 Offset Format .......................................................................................................... 22

110 Table 12 DDB Level 2 RequestLength Format ............................................................................................ 22

111 Table 13 DDB Level 2 ResponseLength Format.......................................................................................... 23

112 Table 14 GET-DDB-LEVEL2 Primitives .................................................................................................... 23

113 Table 15 GET-DDB-LEVEL2.response ResultCode Status Values ............................................................ 25

114 Table 16 GET-DDB-LEVEL2.confirm ResultCode Status Values .............................................................. 26

115 Table 17 SET-DDB-LEVEL2 Primitives ..................................................................................................... 27

116 Table 18 SET-DDB-LEVEL2.response ResultCode Status Values ............................................................. 29

117 Table 19 SET-DDB-LEVEL2.confirm ResultCode Status Values .............................................................. 30

118 Table 20 MessageType Values ..................................................................................................................... 32

119 Table 21 ServiceID Values ........................................................................................................................... 33

120

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
vi
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

121 MIPI Alliance Specification for

122 Device Descriptor Block (DDB)

123 1 Introduction
124 This MIPI Device Descriptor Block specification defines Services to transfer descriptor and configuration
125 data between Devices on a MIPI Interconnect. This document is used with other MIPI Alliance
126 specifications as part of a complete system design.

127 The descriptor and configuration data, hereafter referred to as DDB Data, is comprised of several fields
128 with each field representing a single data item.

129 The DDB specification allows for three levels of conformity, called Level 1, Level 2, and Level 3. Level 1
130 provides access to basic Device descriptor data fields as defined in this document. Level 2 provides getting
131 and setting of DDB Data fields, using a sequence of bytes as access model for the Device’s fields. Level 3
132 provides the same functionality as Level 2, but uses a field ID-based access model. Level 2 and Level 3
133 include the Level 1 functionality. Level 2 and Level 3 are functional alternatives that may be supported
134 individually or in combination.

135 For a given Device, a manufacturer may choose whether or not to support DDB. In addition, the
136 manufacturer may choose to support only DDB Level 1, to support Level 2, to support Level 3 or to
137 support both Level 2 and Level 3. For example, a simple Device such as a MEMS microphone may only
138 need to convey limited information such as its manufacturer ID and device class to other Devices; in this
139 case providing Level 1 suffices. A more complex Device such as a display module may need to provide
140 additional descriptor data such as the display resolution and configuration information such as color depth
141 to other Devices; this additional information can be provided by DDB Level 2 or by DDB Level 3.

142 1.1 Scope

143 This document defines DDB Level 1 and Level 2 Services, Service Access Points (SAPs), Level 1
144 descriptor data fields, and the Level 2 data model framework for DDB Data. The DDB Data fields may be
145 defined in a MIPI Interface specification, in a separate Device class specification, or in a manufacturer’s
146 Device specification and are outside the scope of this document.

147 This document also defines a reference protocol that may be used in the definition of the mapping of DDB
148 Services onto the various MIPI Interfaces. The actual mapping is defined in separate, Interface specific,
149 specifications and is outside the scope of this document.

150 1.2 Purpose

151 The DDB specification provides a common set of Services to dynamically read (get) descriptor and
152 configuration data from Devices and to write (set) configuration data to Devices regardless of the Device
153 type or the underlying Interconnect.

154 Descriptor data can be used in the Device discovery process to identify the available Devices and their
155 class, e.g. microphone, display module, modem. Descriptor data can also be used to dynamically detect
156 variability between Devices of the same class, e.g. the actual resolution of a display, allowing the user of a
157 Device to adjust its use of the Device to be in accordance with its capabilities or properties. This is useful
158 when dealing with second sourcing, dealing with evolution of Devices and for building product families.
159

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
7
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

160 2 Terminology (informative)

161 The MIPI Alliance has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the
162 words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:

163 The word shall is used to indicate mandatory requirements strictly to be followed in order
164 to conform to the standard and from which no deviation is permitted (shall equals is
165 required to).

166 The use of the word must is deprecated and shall not be used when stating mandatory
167 requirements; must is used only to describe unavoidable situations.

168 The use of the word will is deprecated and shall not be used when stating mandatory
169 requirements; will is only used in statements of fact.

170 The word should is used to indicate that among several possibilities one is recommended
171 as particularly suitable, without mentioning or excluding others; or that a certain course
172 of action is preferred but not necessarily required; or that (in the negative form) a certain
173 course of action is deprecated but not prohibited (should equals is recommended that).

174 The word may is used to indicate a course of action permissible within the limits of the
175 standard (may equals is permitted).

176 The word can is used for statements of possibility and capability, whether material,
177 physical, or causal (can equals is able to).

178 All sections are normative, unless they are explicitly indicated to be informative.

179 Numbers are decimal unless otherwise indicated. A prefix of 0x indicates a hexadecimal number, while a
180 prefix of 0b indicates a binary number. Unless stated otherwise, all values are unsigned integers.

181 Throughout the document, in all bytes and octets, the most significant bit is bit 7.

182 2.1 Definitions

183 DDB Data: Device description or configuration data fields that are accessible through a DDB Service.

184 DDB Level 1 Data: The basic Device descriptor data as defined in this document. See section 5.2.1.1.

185 DDB Level 2 Data: DDB Data that is accessible through the GET-DDB-LEVEL2 or SET-DDB--LEVEL2
186 Service. DDB Level 2 Data field definitions are outside the scope of this document.

187 DDB Protocol Data Unit (DDB-PDU): A unit of data exchanged between DDB Service Providers
188 consisting of DDB layer Protocol Control Information and any payload.

189 Device: An addressable entity on an Interconnect.

190 Interaction: A communication between a Requestor and a Provider.

191 Interconnect: A data transport layer Interface.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
8
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

192 Interface: The protocols, signaling characteristics, commands, clocking signals, register models,
193 application program interfaces and data structures to the extent they enable interoperation, interconnection
194 or communication between integrated circuits (even if located on the same die).

195 Primitive: see Service Primitive.

196 Protocol Control Information (PCI): Information exchanged between DDB layers in different devices to
197 coordinate their joint-operation.

198 Provider: A Device that provides DDB data access to Devices on the Interconnect.

199 Request Message: A DDB-PDU with a MessageType of REQ_MESSAGE. See section 6.1.3.

200 Requestor: A Device that requests DDB data access from Devices on the Interconnect.

201 Response Message: A DDB-PDU with a MessageType of RESP_MESSAGE. See section 6.1.3.

202 Service: A capability of the DDB layer and the layers beneath it.

203 Service Access Point (SAP): The point at which a DDB Service is provided by the DDB layer to Service
204 Users.

205 Service Primitive: An abstract, and implementation independent, representation of an interaction between
206 a DDB Service User and a DDB Service Provider.

207 Service Provider: An abstract representation of the DDB layer and any underlying Interconnect that
208 provides the DDB Service.

209 Service User: An abstract representation of an entity in a system that uses the DDB Service.

210 Slice: Contiguous portion of mapped DDB Level 2 Data.

211 2.2 Service Primitive Naming

212 This document uses an OSI-like naming convention in the definition of Service Primitives:

213 <service-primitive> ::= <primitive-name> ( [<parameter-list>] )

214 <primitive-name> ::= <service-name> . <primitive-type>

215 <service-name> ::= GET-DDB-LEVEL1 | GET-DDB-LEVEL2 | SET-DDB-LEVEL2

216 <primitive-type> ::= request | indication | response | confirm

217 <parameter-list> ::= <parameter> { , <parameter> }*

218 <parameter> ::= <Service control information> | <Service User data>

219 2.3 Acronyms

220 DDB Device Descriptor Block

221 IC Integrated Circuit

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
9
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

222 MIPI Mobile Industry Processor Interface

223 OSI Open Systems Interconnection

224 PCI Protocol Control Information

225 PDU Protocol Data Unit

226 SAP Service Access Point

227

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
10
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

228 3 References
229 [IEEE01] 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, ISBN
230 978-1-5593-7653-2, Institute of Electrical and Electronics Engineers, 1 January 2003

231 [IETF01] RFC3629, UTF-8, a transformation format of ISO 10646,

232 <http://www.ietf.org/rfc/rfc3629.txt>, The Internet Society, November 2003

233 [IETF02] RFC2781, UTF-16, an encoding of ISO 10646, <http://www.ietf.org/rfc/rfc2781.txt>,

234 The Internet Society, February 2000

235 [ITUT01] ITU-T Recommendation X.200 (7/94), Information technology - Open Systems
236 Interconnection - Basic Reference Model: The basic model, <http://www.itu.int/rec/T-
237 REC-X/en>, International Telecommunication Union, 7 November 1997

238 [ITUT02] ITU-T Recommendation X.210 (11/93), Information technology - Open systems
239 interconnection - Basic Reference Model: Conventions for the definition of OSI services,
240 <http://www.itu.int/rec/T-REC-X/en>, International Telecommunication Union, 30
241 November 1994

242 [MIPI01] MIPI Alliance, Current Members – List of all MIPI Manufacturer IDs, “List of MIPI
243 Manufacturer IDs”, <http://www.mipi.org/view_mid.asp>, 10 December 2007
244

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
11
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

245 4 Architecture Overview (informative)

246 The DDB specification defines Services that allow a Device on a MIPI Interconnect (Figure 1) to transfer
247 DDB Data with any Device on the Interconnect that supports DDB. Typical DDB-capable Devices include
248 processor ICs and peripheral ICs.

249 DDB Data can be classified as descriptor data or configuration data. Descriptor data includes identifying
250 information such as the manufacturer, capability information such as the supported display formats for a
251 display device, and calibration information such as the gain of a particular microphone. Configuration data
252 provides a means to configure the device in a standard way. Typically, descriptor data is read-only (i.e. get)
253 while configuration data is read-write (i.e. get and set).

254
255
256 Figure 1 Devices on an Interconnect

257 DDB is built on an OSI-style layered model [ITUT01], similar to many network systems. The DDB
258 Services are contained within a layer so that DDB is independent of the Service User and can provide the
259 same Services no matter the specific underlying Interconnect(s), as shown in Figure 2.

260
261 Figure 2 Mapping DDB to MIPI Interfaces

262 The Service User accesses DDB Services through DDB Service Access Points (SAPs). The DDB layer
263 accesses the underlying Interconnect through the Interconnect’s SAPs. The DDB layered model with SAPs
264 is shown in Figure 3.

265 The Interaction between the DDB Service User and the DDB layer is defined using four types of Service
266 Primitives: request, indication, response, and confirm [ITUT02].

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
12
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

267
268 Figure 3 DDB Layer Overview

269 A Device initiating a DDB Data exchange is called the Requestor and a Device providing or acting on the
270 DDB Data is called the Provider. Requestor and Provider are roles played by a Device. Any Device may
271 act as a Requestor, a Provider, or both.

272 Figure 4 shows a typical Interaction and the relationship between the SAP, the Service Primitives and the
273 Requestor and Provider roles. Service User R in Device A (the Requestor) accesses a DDB Service by
274 generating a request Primitive, passing the ID of Device B (the Provider) and any DDB Data (in case of a
275 set Primitive) as parameters. The DDB layer in the Requestor communicates the Service request to the
276 DDB layer in the Provider through the underlying Interconnect. The DDB layer in the Provider signals
277 Service User P by generating an indication Primitive that Device A requested the specific Service, passing
278 any relevant data as parameters. Service User P consumes (in case of a set Primitive) or produces (in case
279 of a get Primitive) the data and generates a response Primitive with any DDB Data (in case of a get
280 Primitive) to the Provider’s DDB layer. This layer in turn forwards the response through the underlying
281 Interconnect to the DDB layer in the Requestor. Finally, the DDB layer in the Requestor signals Service
282 User R by generating a confirm Primitive passing any data and the status as parameters.

283
284 Figure 4 Service Primitives and Roles
285

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
13
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

286 5 DDB Services

287 The DDB Services describe the capability of the DDB layer and any underlying Interconnect to exchange
288 DDB Data between Devices on that Interconnect. Separate Services are defined for DDB Level 1 get and
289 for DDB Level 2 get and set.

290 Each DDB Service is defined in terms of parameterized Service Primitives that are available at a Service
291 Access Point. There are four types of Service Primitives: request, indication, response, and confirm. For
292 each Primitive the parameters, when it is generated, the effect on receipt, and any additional requirements
293 are defined.

294 5.1 Generic Service Elements

295 This section contains elements that are common to DDB Services on multiple levels.

296 5.1.1 General Service Parameters

297 Some parameters are common to Services on multiple levels; these are defined in the following sections.

298 5.1.1.1 RequestorID

299 The RequestorID shall uniquely identify an Interconnect endpoint reachable in the scope of the Provider’s
300 Service User.
301 Table 1 RequestorID Format

Name Size, bits Description

RequestorID 32 ID to identify an Interconnect endpoint reachable in the scope of the
Service User.

302 5.1.1.2 ProviderID

303 The ProviderID shall uniquely identify an Interconnect endpoint reachable in the scope of the Requestor’s
304 Service User. A valid ProviderID is obtained through a mechanism that is outside the scope of this
305 document.
306 Table 2 ProviderID Format

Name Size, bits Description

ProviderID 32 ID to identify an Interconnect endpoint reachable in the scope of the
Service User.

307 5.1.1.3 TransactionID

308 The TransactionID shall be used to link a confirm Primitive to a specific request Primitive and to link a
309 response Primitive to a specific indication Primitive. The Service Provider and the Provider's Service User
310 shall treat the TransactionID as an opaque value.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
14
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

311 Table 3 TransactionID Format

Name Size, bits Description

TransactionID 8 The TransactionID is used to link a confirm Primitive to a request
Primitive and to link a response Primitive to an indication Primitive.

312 5.1.1.4 ResultCode

313 The ResultCode is a 16-bit value with flags indicating the source of the result and a status value indicating
314 the result status. Figure 5 defines the ResultCode format.

315
316 Figure 5 ResultCode Format

317 The ResultCode flag descriptions and their values are defined in Table 4.
318 Table 4 ResultCode Flags

Bits Description
15 Reserved (R). Must be zero.
14 Component (C)
0b0: Provider
0b1: Requestor
[13:12] Source
0b00: Not Applicable
0b01: Transport Layer
0b10: DDB Layer
0b11: Service User
[11:8] Reserved. Must be zero.

319 Table 5 defines the values for the ResultCode status; values not listed are reserved and shall not be used.
320 Table 5 ResultCode Status Values

ResultCode Status Value Description

RESULT_OK 0x00 No error occurred.
ERROR_NOT_SUPPORTED 0x01 The Device does not support this Service.
ERROR_INVALID_ID 0x02 The ProviderID is not valid.
ERROR_NO_RESPONSE 0x03 A transmission error occurred or no response was
received from the Device within a time-out interval.
The time-out value depends on the underlying
Interconnect and shall be defined in a separate document.
ERROR_UNKNOWN 0x04 An unspecified error occurred.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
15
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

ResultCode Status Value Description

ERROR_BUSY 0x05 An element of the implementation is busy and cannot
process the request. The number of outstanding requests
may be limited by any element of the implementation.
ERROR_INVALID_SLICE 0x06 The Slice of the DDB Level 2 Data defined by Offset
and RequestLength (in case of a GET-DDB-LEVEL2
Service) or the length of DdbL2Data (in case of a
SET-DDB-LEVEL2 Service) is not valid for the Device.
ERROR_UNSUPPORTED_LENGTH 0x07 The RequestLength (in case of a GET-DDB-LEVEL2
Service) or the length of DdbL2Data (in case of a
SET-DDB-LEVEL2 Service) exceeds the capabilities of
the Device.
ERROR_INVALID_VALUE 0x08 A field is being set with an invalid value.

321 5.1.2 Error Reporting

322 The Service Provider reports errors to the Requestor's Service User through a confirm Primitive.

323 The Provider's Service User reports errors to the Service Provider through a response Primitive.

324 The Requestor's Service Provider shall report the ERROR_NO_RESPONSE and ERROR_INVALID_ID
325 conditions and any result codes reported by the Provider. The Requestor's Service Provider may report the
326 ERROR_BUSY and ERROR_UNKNOWN conditions.

327 The Provider's Service Provider may report the ERROR_NOT_SUPPORTED, ERROR_BUSY,
328 ERROR_UNKNOWN and ERROR_UNSUPPORTED_LENGTH conditions.

329 The Provider's Service User may report the ERROR_BUSY, ERROR_UNKNOWN,
330 ERROR_INVALID_SLICE, ERROR_UNSUPPORTED_LENGTH, and ERROR_INVALID_VALUE
331 conditions.

332 5.2 DDB Level 1 Service

333 The DDB Level 1 functionality consists of a single Service, GET-DDB-LEVEL1. The
334 GET-DDB-LEVEL1 Service provides a mechanism for Requestor Devices to obtain the basic Device
335 descriptor data as defined by the DdbL1Data fields from Provider Devices.

336 This section defines the DDB Level 1 Data and the Service Primitives used to provide the DDB Level 1
337 Service.

338 5.2.1 DDB Level 1 Specific Service Parameter

339 There is one DDB Level 1 specific Service parameter, DdbL1Data.

340 5.2.1.1 DdbL1Data

341 The DdbL1Data is a structured parameter containing the basic Device descriptor data fields. The fields of
342 this parameter are defined in Table 6.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
16
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

343 Table 6 DdbL1Data Fields

Item Size, bits Description

Revision 8 The revision of the DDB specification supported by this Device encoded
as major-version * 0x10 + minor-version. For this version (v1.0) the value
shall be 0x10.
Level 8 Eight bit field indicating the DDB support:
b0: DDB Level 1 support. Shall be 0b1.
b1: DDB Level 2 get support. Shall be 0b1 if and only if the
GET-DDB-LEVEL2 Service is supported.
If b1 is set, then b0 shall also be set.
b2: DDB Level 2 set support. Shall be 0b1 if and only if the
SET-DDB-LEVEL2 Service is supported.
If b2 is set, both b0 and b1 shall also be set.
b[7:3]: Reserved. Shall be 0b00000.
DeviceClass 16 The device class ID of the Device as specified by the MIPI Alliance. If the
Device does not conform to a specified device class, the value shall be 0.
ManufacturerID 16 The manufacturer ID of the Device's manufacturer as specified by the
MIPI Alliance [MIPI01].
ProductID 16 The product ID as specified by the Device manufacturer.
Length 16 The length of any DDB Level 2 data.
For Devices supporting only DDB Level 1, the value shall be 0.
For Devices supporting DDB Level 2, the value shall be the size of the
available DDB Level 2 data in bytes.

344 5.2.2 GET-DDB-LEVEL1 SAP

345 The parameters used by the Service Primitives are described in sections 5.1.1 and 5.2.1.

346 The GET-DDB-LEVEL1 Primitives are covered in this section and are listed in Table 7.
347 Table 7 DDB-L1-SAP Primitives

Service Primitive request indication response confirm

GET-DDB-LEVEL1 5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4

348 5.2.2.1 GET-DDB-LEVEL1.request

349 The specification of this Primitive is:

350 GET-DDB-LEVEL1.request (ProviderID, TransactionID)

351 When Generated

352 The Requestor's DDB Service User shall generate this Service Primitive to obtain the DdbL1Data of the
353 Device given in ProviderID.

354 The Service User shall provide TransactionID to associate the corresponding confirm Primitive with this
355 request.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
17
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

356 Effect on Receipt

357 Receipt of this Service Primitive shall cause the generation of a single corresponding confirm Primitive.

358 Additional Requirements

359 If the ProviderID is not valid in the context of the Requestor’s Service User, the Requestor’s Service
360 Provider shall generate a corresponding confirm Primitive with ResultCode status value
361 ERROR_INVALID_ID and ResultCode flags set to Requestor DDB Layer (Component = Requestor,
362 Source = DDB Layer) or to Requestor Transport Layer (Component = Requestor, Source = Transport
363 Layer) according to the component that detected the error.

364 If the Requestor’s Service Provider detects a transmission error on the Interconnect, it may generate a
365 corresponding confirm Primitive with ResultCode status value ERROR_NO_RESPONSE and ResultCode
366 flags set to Requestor Transport Layer (Component = Requestor, Source = Transport Layer).

367 If, after a time-out value as specified by the underlying Interconnect’s DDB Service to protocol mapping,
368 the Requestor’s Service Provider has not obtained the necessary data to generate a corresponding confirm
369 Primitive, it shall generate a corresponding confirm Primitive with ResultCode status value
370 ERROR_NO_RESPONSE and ResultCode flags set to Requestor DDB Layer (Component = Requestor,
371 Source = DDB Layer).

372 5.2.2.2 GET-DDB-LEVEL1.indication

373 The specification of this Primitive is:

374 GET-DDB-LEVEL1.indication (RequestorID, TransactionID)

375 When Generated

376 The DDB Service Provider may generate this Primitive as a result of a GET-DDB-LEVEL1.request
377 Primitive generated on the Device identified by RequestorID.

378 The Service Provider shall provide TransactionID to associate the corresponding response Primitive with
379 this indication.

380 Effect on Receipt

381 The Provider's DDB Service User shall generate a single corresponding response Primitive using the given
382 RequestorID and TransactionID.

383 Additional Requirements

384 None.

385 5.2.2.3 GET-DDB-LEVEL1.response

386 The specification of this Primitive is:

387 GET-DDB-LEVEL1.response (RequestorID, TransactionID, DdbL1Data, ResultCode)

388 When Generated

389 The Provider's DDB Service User shall generate this Service Primitive as a result of a
390 GET-DDB-LEVEL1.indication Primitive.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
18
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

391 RequestorID shall be identical to RequestorID of the corresponding indication Primitive.

392 TransactionID shall be identical to TransactionID of the corresponding indication Primitive.

393 ResultCode shall contain one of the ResultCode status values listed in Table 8. If the ResultCode status is
394 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
395 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall be set
396 to Provider Service User (Component = Provider, Source = Service User).

397 If the ResultCode status is RESULT_OK, DdbL1Data shall contain the basic descriptor data of this Device.
398 Table 8 GET-DDB-LEVEL1.response ResultCode Status Values

ResultCode Status Comment

RESULT_OK DdbL1Data contains the basic descriptor data of this Device
ERROR_BUSY
DdbL1Data is undefined
ERROR_UNKNOWN

399 Effect on Receipt

400 Receipt of this Service Primitive shall cause the generation of a single corresponding confirm Primitive on
401 the Device identified by RequestorID, except when such a Service Primitive has already been generated;
402 for example, due to a time-out.

403 Additional Requirements

404 None.

405 5.2.2.4 GET-DDB-LEVEL1.confirm

406 The specification of this Primitive is:

407 GET-DDB-LEVEL1.confirm (ProviderID, TransactionID, DdbL1Data, ResultCode)

408 When Generated

409 The DDB Service Provider shall generate this Service Primitive as a result of a
410 GET-DDB-LEVEL1.request Primitive.

411 ProviderID shall be identical to ProviderID of the corresponding request Primitive.

412 TransactionID shall be identical to TransactionID of the corresponding request Primitive.

413 ResultCode shall contain one of the ResultCode status values listed in Table 9. If the ResultCode status is
414 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
415 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall indicate
416 the source of the error.

417 If the ResultCode status is RESULT_OK, DdbL1Data shall contain the basic descriptor data of the Device
418 identified by ProviderID; this data shall originate from the Device identified by ProviderID.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
19
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

419 Table 9 GET-DDB-LEVEL1.confirm ResultCode Status Values

ResultCode Status Comment

RESULT_OK DdbL1Data contains the basic descriptor data of the Device identified
by ProviderID
ERROR_BUSY
ERROR_INVALID_ID
ERROR_NO_RESPONSE DdbL1Data is undefined
ERROR_NOT_SUPPORTED
ERROR_UNKNOWN

420 Effect on Receipt

421 The Requestor's Service User is provided with DdbL1Data.

422 Additional Requirements

423 None.

424 5.3 DDB Level 2 Services

425 The DDB Level 2 functionality consists of two Services, GET-DDB-LEVEL2 and SET-DDB-LEVEL2.
426 The GET-DDB-LEVEL2 Service provides a mechanism for Service Users to get DDB data from Provider
427 Devices. The SET-DDB-LEVEL2 Service provides a mechanism for Service Users to set DDB data on
428 Provider Devices. GET-DDB-LEVEL2 may be supported without supporting SET-DDB-LEVEL2.
429 However, GET-DDB-LEVEL2 shall be supported if SET-DDB-LEVEL2 is supported.

430 This section defines the DDB Level 2 Data Model and Service Primitives used to provide the DDB Level 2
431 Services.

432 5.3.1 DDB Level 2 Data Model

433 The DDB Level 2 Services present the Provider’s DDB Data fields as a sequence of bytes. The first byte of
434 the DDB Level 2 data shall have index zero as indicated in Figure 6.

435 Fields may be separated by filler bytes in the byte sequence, e.g. to provide field alignment to a word or
436 some other boundary or to allow for future extension. A get or set operation on a filler byte shall not cause
437 an error. The filler byte shall be transferred between Provider and Requestor and shall be included in the
438 RequestLength or ResponseLength value. The value of a filler byte is not defined.

439 The sequence of bytes can be accessed at any offset and with any length of data transfer. Field mapping
440 specifications may limit the supported offsets and data lengths in order to allow for future extensions,
441 preserve data integrity, align to address boundaries, or any other specification or implementation reason.

442 The mapping of DDB data fields onto a DDB Level 2 byte sequence is outside the scope of this document.

443 5.3.1.1 Data Types

444 The DDB Level 2 Data should be encoded according to the types listed in Table 10.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
20
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

445 Table 10 DDB Level 2 Data Type Encoding

Type Size, bits Description

INT8 8 Signed 8-bit integer
UINT8 8 Unsigned 8-bit integer
INT16 16 Signed 16-bit integer
UINT16 16 Unsigned 16-bit integer
INT32 32 Signed 32-bit integer
UINT32 32 Unsigned 32-bit integer
INT64 64 Signed 64-bit integer
UINT64 64 Unsigned 64-bit integer
FLOAT 32 Single precision floating-point number encoding according to [IEEE01].
DOUBLE 64 Double precision floating-point number encoding according to [IEEE01].
STRING fixed Strings are encoded with a fixed reserved length in bytes as indicated in the
device data sheet. Character encoding should use zero terminated UTF-8
[IETF01] or UTF-16 [IETF02]. A single character is encoded as a STRING
with length equal to the character length in bytes.

446 5.3.1.2 Field Mapping

447 A single multi-byte field should be mapped to consecutive bytes in big-endian format with the most
448 significant byte having the lowest index. The device data sheet should identify the byte arrangement for
449 multi-byte values in the DDB Level 2 Data. See Figure 6 for an example mapping.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
21
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

DdbL2Data Mapping DDB Level 2 Data

0 Field 1

Field N
Field N Offset
Filler Filler
Field N+1 MSB RequestLength /
Field N+1 LSB ResponseLength Field N+1 MSB
Field N+2 MSB Field N+1 LSB
Field N+2 LSB
Field N+2 MSB
Field N+2 LSB

DdbL1Data.Length-1
450
451
452 Figure 6 Level 2 Data Model and Mapping Example

453 5.3.2 DDB Level 2 Specific Service Parameters

454 The DDB Level 2 specific Service parameters are Offset, RequestLength, ResponseLength, and
455 DdbL2Data.

456 5.3.2.1 Offset

457 Offset specifies the index of the first byte of the mapped DDB Level 2 data to be processed.
458 Table 11 DDB Level 2 Offset Format

Name Size, bits Description

Offset 16 The index of the first byte of the mapped DDB Level 2 data to be
processed.

459 5.3.2.2 RequestLength

460 RequestLength specifies the number of bytes to be processed in the GET-DDB-LEVEL2 Service.
461 Table 12 DDB Level 2 RequestLength Format

Name Size, bits Description

RequestLength 16 The number of DDB Level 2 data bytes to be processed in the
GET-DDB-LEVEL2 Service.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
22
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

462 5.3.2.3 ResponseLength

463 ResponseLength specifies the number of bytes that have been processed by the Service User in the
464 SET-DDB-LEVEL2 Service. ResponseLength may be smaller than the DdbL2Data length, in which case
465 only the first ResponseLength bytes have been processed starting from the Offset position.
466 Table 13 DDB Level 2 ResponseLength Format

Name Size, bits Description

ResponseLength 16 The number of bytes that have been processed in the
SET-DDB-LEVEL2 Service.

467 5.3.2.4 DdbL2Data

468 DdbL2Data represents a slice of the Provider’s mapped DDB Level 2 data.

469 5.3.3 GET-DDB-LEVEL2 SAP

470 The parameters used by the GET-DDB-LEVEL2 Service Primitives are defined in sections 5.1.1 and 5.3.2.

471 The GET-DDB-LEVEL2 Service Primitives are defined in this section and are listed in Table 14.
472 Table 14 GET-DDB-LEVEL2 Primitives

Service Primitive request indication response confirm

GET-DDB-LEVEL2 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4

473 5.3.3.1 GET-DDB-LEVEL2.request

474 The specification of this Primitive is:

475 GET-DDB-LEVEL2.request (ProviderID, TransactionID, Offset, RequestLength)

476 When Generated

477 The Requestor’s DDB Service User shall generate this Service Primitive to obtain DDB Level 2 data of the
478 Device given in ProviderID.

479 The Service User shall provide TransactionID to associate the corresponding confirm Primitive with this
480 request.

481 Effect on Receipt

482 Receipt of this Service Primitive shall cause the generation of a single corresponding
483 GET-DDB-LEVEL2.indication Primitive on the Device given in ProviderID.

484 Additional Requirements

485 If the ProviderID is not valid in the context of the Requestor’s Service User, the Requestor’s Service
486 Provider shall generate a corresponding confirm Primitive with ResultCode status value
487 ERROR_INVALID_ID and ResultCode flags set to Requestor DDB Layer (Component = Requestor,
488 Source = DDB Layer) or to Requestor Transport Layer (Component = Requestor, Source = Transport
489 Layer) according to the component that detected the error.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
23
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

490 If the Requestor’s Service Provider detects a transmission error on the Interconnect, it may generate a
491 corresponding confirm Primitive with ResultCode status value ERROR_NO_RESPONSE and ResultCode
492 flags set to Requestor Transport Layer (Component = Requestor, Source = Transport Layer).

493 If the Service Provider detects that the Device identified by ProviderID does not support the
494 GET-DDB-LEVEL2 Service, it shall generate a corresponding confirm Primitive with ResultCode status
495 value ERROR_NOT_SUPPORTED. The ResultCode flags shall be set to Provider DDB Layer
496 (Component = Provider, Source = DDB Layer) or Requestor DDB Layer (Component = Requestor, Source
497 = DDB Layer) according to the component that detected the error.

498 If, after a time-out value as specified by the underlying Interconnect’s Service to protocol mapping, the
499 Requestor’s Service Provider has not obtained the necessary data to generate a corresponding confirm
500 Primitive, it shall generate a corresponding confirm Primitive with ResultCode status value
501 ERROR_NO_RESPONSE and ResultCode flags set to Requestor DDB Layer (Component = Requestor,
502 Source = DDB Layer).

503 5.3.3.2 GET-DDB-LEVEL2.indication

504 The specification of this Primitive is:

505 GET-DDB-LEVEL2.indication (RequestorID, TransactionID, Offset, RequestLength)

506 When Generated

507 The DDB Service Provider shall generate this Service Primitive as a result of a
508 GET-DDB-LEVEL2.request Primitive generated on the Device identified by RequestorID.

509 The Service Provider shall provide TransactionID to associate the corresponding response Primitive with
510 this indication.

511 Offset shall be equal to Offset of the corresponding request Primitive.

512 RequestLength shall be equal to RequestLength of the corresponding request Primitive.

513 Effect on Receipt

514 The Provider’s DDB Service User shall process, i.e. get, its DDB Level 2 data starting at Offset for
515 RequestLength bytes and shall subsequently generate a single corresponding GET-DDB-LEVEL2.response
516 Primitive using the given RequestorID and TransactionID.

517 Additional Requirements

518 The mapped DDB Data shall be processed in order of increasing index. Each byte shall be processed
519 exactly once. If the Service User is aware of the field boundaries, then the Service User should access the
520 field atomically so that when the field is processed all bytes of the field are consistent and correct.

521 The Provider’s Service User shall stop processing at the first error condition encountered and indicate the
522 error condition in the ResultCode status of the corresponding response Primitive.

523 If Offset exceeds the Provider’s DDB Data Length as given in the DdbL1Data Length field, the Provider’s
524 Service User shall not process any data and indicate the ResultCode status ERROR_INVALID_SLICE in
525 the corresponding response Primitive.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
24
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

526 If Offset is the index of a byte other then the first byte in a field or the sum of Offset and RequestLength
527 minus one is not the last byte in a field, the Provider’s Service User may process no data at all and indicate
528 the ResultCode status ERROR_INVALID_SLICE in the corresponding response Primitive.

529 If the sum of Offset and RequestLength exceeds the DDB Level 2 data length as given in the DdbL1Data
530 Length field, the Provider’s DDB Service User shall either process no data at all and return a zero length
531 DdbL2Data parameter in the corresponding response Primitive or process as many bytes of data as are
532 available and return only the processed bytes as the DdbL2Data parameter in the corresponding response
533 Primitive. In both cases the Service User shall indicate the ResultCode status ERROR_INVALID_SLICE
534 in the corresponding response Primitive.

535 If RequestLength exceeds the Device's capabilities, the Service User shall process as many bytes of data as
536 the Device can transfer and indicate the ResultCode status ERROR_UNSUPPORTED_LENGTH in the
537 corresponding response Primitive.

538 5.3.3.3 GET-DDB-LEVEL2.response

539 The specification of this Primitive is:

540 GET-DDB-LEVEL2.response (RequestorID, TransactionID, DdbL2Data, ResultCode)

541 When Generated

542 The Provider’s DDB Service User shall generate this Service Primitive as a result of a corresponding
543 GET-DDB-LEVEL2.indication Primitive.

544 RequestorID shall be identical to RequestorID of the corresponding indication Primitive.

545 TransactionID shall be identical to TransactionID of the corresponding indication Primitive.

546 DdbL2Data shall be set to a Slice of the Provider’s mapped DDB Data starting at Offset as given in the
547 corresponding indication Primitive and with a length equal to the number of bytes processed. If no bytes
548 were processed then DdbL2Data shall have a length of zero.

549 ResultCode shall contain one of the ResultCode status values listed in Table 15. If the ResultCode status is
550 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
551 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall be set
552 to Provider Service User (Component = Provider, Source = Service User).
553 Table 15 GET-DDB-LEVEL2.response ResultCode Status Values

ResultCode Comment
RESULT_OK DdbL2Data contains valid data.
ERROR_BUSY
ERROR_UNKNOWN
DdbL2Data contains either valid data or has a length of zero.
ERROR_INVALID_SLICE
ERROR_UNSUPPORTED_LENGTH

554 Effect on Receipt

555 Receipt of this Service Primitive shall cause the generation of a single corresponding
556 GET-DDB-LEVEL2.confirm Primitive on the Device identified by RequestorID, except when such a
557 Service Primitive has already been generated; for example due to a time-out.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
25
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

558 Additional Requirements

559 None.

560 5.3.3.4 GET-DDB-LEVEL2.confirm

561 The specification of this Primitive is:

562 GET-DDB-LEVEL2.confirm (ProviderID, TransactionID, DdbL2Data, ResultCode)

563 When Generated

564 The DDB Service Provider shall generate this Service Primitive as the result of a corresponding
565 GET-DDB-LEVEL2.response Primitive generated on the Device identified by ProviderID.

566 TransactionID shall be identical to TransactionID of the corresponding request Primitive.

567 DdbL2Data shall be equal to DdbL2Data of the corresponding response Primitive.

568 ResultCode shall contain one of the ResultCode status values in Table 16. If the ResultCode status is
569 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
570 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall indicate
571 the source of the error.
572 Table 16 GET-DDB-LEVEL2.confirm ResultCode Status Values

ResultCode Comment
RESULT_OK DdbL2Data contains valid data.
ERROR_BUSY
ERROR_INVALID_ID
ERROR_NO_RESPONSE
ERROR_NOT_SUPPORTED DdbL2Data will either contain valid data or have a length of zero.
ERROR_UNKNOWN
ERROR_INVALID_SLICE
ERROR_UNSUPPORTED_LENGTH

573 Effect on Receipt

574 The Requestor's Service User is provided with DdbL2Data.

575 If the ResultCode status is ERROR_NO_RESPONSE, ERROR_BUSY or ERROR_UNKNOWN, no

576 assumptions shall be made on whether DDB Level 2 data has been processed at the Device identified by
577 ProviderID or not.

578 Additional Requirements

579 When generation of this Primitive is not caused by a corresponding response Primitive, DdbL2Data shall
580 have a length of zero.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
26
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

581 5.3.4 SET-DDB-LEVEL2 SAP

582 The parameters used by the Service Primitives are described in sections 5.1.1 and 5.3.1.

583 The SET-DDB-LEVEL2 Primitives are covered in this section and are listed in Table 17.
584 Table 17 SET-DDB-LEVEL2 Primitives

Service Primitive request indication response confirm

SET-DDB-LEVEL2 5.3.4.1 5.3.4.2 5.3.4.3 5.3.4.4

585 5.3.4.1 SET-DDB-LEVEL2.request

586 The specification of this Primitive is:

587 SET-DDB-LEVEL2.request (ProviderID, TransactionID, Offset, DdbL2Data)

588 When Generated

589 The Requestor’s DDB Service User shall generate this Service Primitive to set DDB Level 2 Data on the
590 Device given in ProviderID to DdbL2Data.

591 The Service User shall provide TransactionID to associate the corresponding confirm Primitive with this
592 request.

593 Effect on Receipt

594 Receipt of this Service Primitive shall cause the generation of a single corresponding
595 SET-DDB-LEVEL2.indication Primitive on the Device given in ProviderID.

596 Additional Requirements

597 If the ProviderID is not valid in the context of the Requestor’s Service User, the Requestor’s Service
598 Provider shall generate a corresponding confirm Primitive with ResultCode status value
599 ERROR_INVALID_ID and ResultCode flags set to Requestor DDB Layer (Component = Requestor,
600 Source = DDB Layer) or to Requestor Transport Layer (Component = Requestor, Source = Transport
601 Layer) according to the component that detected the error.

602 If the Requestor’s Service Provider detects a transmission error on the Interconnect, it may generate a
603 corresponding confirm Primitive with ResultCode status value ERROR_NO_RESPONSE and ResultCode
604 flags set to Requestor Transport Layer (Component = Requestor, Source = Transport Layer).

605 If the Service Provider detects that the Device identified by ProviderID does not support the
606 SET-DDB-LEVEL2 Service, it shall generate a corresponding confirm Primitive with ResultCode status
607 value ERROR_NOT_SUPPORTED. The ResultCode flags shall be set to Provider DDB Layer
608 (Component = Provider, Source = DDB Layer) or Requestor DDB Layer (Component = Requestor, Source
609 = DDB Layer) according to the component that detected the error.

610 If, after a time-out value specified by the underlying Interconnect’s DDB Service to protocol mapping, the
611 Requestor’s Service Provider has not obtained the necessary information required to generate a
612 corresponding confirm Primitive, it shall generate a corresponding confirm Primitive with ResultCode
613 status value ERROR_NO_RESPONSE and ResultCode flags set to Requestor DDB Layer (Component =
614 Requestor, Source = DDB Layer).

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
27
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

615 5.3.4.2 SET-DDB-LEVEL2.indication

616 The specification of this Primitive is:

617 SET-DDB-LEVEL2.indication (RequestorID, TransactionID, Offset, DdbL2Data)

618 When Generated

619 The DDB Service Provider shall generate this Service Primitive as a result of a corresponding
620 SET-DDB-LEVEL2.request Primitive generated on the Device identified by RequestorID.

621 The Service Provider shall provide TransactionID to associate the corresponding response Primitive with
622 this indication.

623 Offset shall be equal to Offset of the corresponding request Primitive.

624 DdbL2Data shall be equal to DdbL2Data of the corresponding request Primitive.

625 Effect on Receipt

626 The Provider’s DDB Service User shall process DdbL2Data, i.e. set the Slice of mapped DDB Data starting
627 at Offset for as many bytes as contained in DdbL2Data to the values given in DdbL2Data, and shall
628 subsequently generate a corresponding SET-DDB-LEVEL2.response Primitive using the given
629 RequestorID and TransactionID.

630 Additional Requirements

631 The DdbL2Data shall be processed in order of increasing index. Each byte shall be processed exactly once.
632 If the Service User is aware of the field boundaries, then the Service User should access the field atomically
633 so that when the field is processed all bytes of the field are consistent and correct.

634 The Provider’s Service User shall stop processing at the first error condition encountered and indicate the
635 error condition in the ResultCode status of the corresponding response Primitive.

636 If the value set to a field is not valid for that field, the Provider’s Service User may stop processing, in
637 which case it shall indicate the ResultCode status ERROR_INVALID_VALUE in the corresponding
638 response Primitive.

639 If Offset exceeds the Provider’s DDB Data Length as given in the DdbL1Data Length field, the Provider’s
640 Service User shall not process any data and indicate the ResultCode status ERROR_INVALID_SLICE in
641 the corresponding response Primitive.

642 If Offset is the index of a byte other then the first byte in a field or the sum of Offset and the length of
643 DdbL2data minus one is not the last byte in a field, the Provider’s Service User may process no data at all
644 and indicate the ResultCode status ERROR_INVALID_SLICE in the corresponding response Primitive.

645 If the sum of Offset and the length of DdbL2data exceeds the DDB Level 2 data Length as given in the
646 DdbL1Data Length field, the Provider’s DDB Service User shall either process no data at all and set
647 ResponseLength to zero in the corresponding response Primitive or process as many bytes of data as are
648 available and report the number of processed bytes in ResponseLength of the corresponding response
649 Primitive. In both cases the Service User shall indicate the ResultCode status ERROR_INVALID_SLICE
650 in the corresponding response Primitive.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
28
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

651 5.3.4.3 SET-DDB-LEVEL2.response

652 The specification of this Primitive is:

653 SET-DDB-LEVEL2.response (RequestorID, TransactionID, ResponseLength, ResultCode)

654 When Generated

655 The Provider’s DDB Service User shall generate this Service Primitive as a result of a corresponding
656 SET-DDB-LEVEL2.indication.

657 RequestorID shall be identical to RequestorID of the corresponding indication Primitive.

658 TransactionID shall be identical to TransactionID of the corresponding indication Primitive.

659 ResponseLength shall indicate the number of bytes processed.

660 ResultCode shall contain one of the ResultCode status values listed in Table 18. If the ResultCode status is
661 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
662 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall be set
663 to Provider Service User (Component = Provider, Source = Service User).
664 Table 18 SET-DDB-LEVEL2.response ResultCode Status Values

ResultCode status Comment

RESULT_OK DDB Level 2 data has been set
ERROR_BUSY
ERROR_UNKNOWN
DDB Level 2 data has been set as indicated by ResponseLength
ERROR_INVALID_SLICE
ERROR_INVALID_VALUE

665 Effect on Receipt

666 Receipt of this Service Primitive shall cause the generation of a single corresponding
667 SET-DDB-LEVEL2.confirm Primitive on the Device identified by RequestorID, except when such a
668 Service Primitive has already been generated; for example due to a time-out.

669 Additional Requirements

670 None.

671 5.3.4.4 SET-DDB-LEVEL2.confirm

672 The specification of this Primitive is:

673 SET-DDB-LEVEL2.confirm (ProviderID, TransactionID, ResponseLength, ResultCode)

674 When Generated

675 The DDB Service Provider shall generate this Service Primitive as the result of a corresponding
676 SET-DDB-LEVEL2.response Primitive generated on the Device identified by ProviderID.

677 TransactionID shall be identical to TransactionID of the corresponding request Primitive.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
29
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

678 ResponseLength shall be identical to ResponseLength of the corresponding response Primitive.

679 ResultCode shall contain one of the ResultCode status values listed in Table 19. If the ResultCode status is
680 RESULT_OK, the ResultCode flags shall be set to Provider Not Applicable (Component = Provider,
681 Source = Not Applicable). If the ResultCode status is not RESULT_OK, the ResultCode flags shall indicate
682 the source of the error.
683 Table 19 SET-DDB-LEVEL2.confirm ResultCode Status Values

ResultCode Comment
RESULT_OK No error occurred
ERROR_BUSY
ERROR_INVALID_ID
ERROR_NO_RESPONSE
ERROR_NOT_SUPPORTED
An error occurred
ERROR_UNKNOWN
ERROR_INVALID_SLICE
ERROR_INVALID_VALUE
ERROR_UNSUPPORTED_LENGTH

684 Effect on Receipt

685 The Requestor’s Service User is notified of how many bytes have been set.

686 If the ResultCode status is ERROR_NO_RESPONSE, ERROR_BUSY or ERROR_UNKNOWN, no

687 assumptions shall be made on whether DDB Level 2 data has been processed at the Device identified by
688 ProviderID or not.

689 Additional Requirements

690 When generation of this Primitive is not caused by a corresponding response Primitive, ResponseLength
691 shall be zero.
692

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
30
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

693 6 DDB Protocol

694 The DDB protocol defines how the Requestor and Provider parts of the DDB layer interact to realize the
695 DDB Services. The DDB Layer uses an asymmetric, connectionless protocol to transfer control information
696 and DDB data between a Provider and a Requestor on an Interconnect. The protocol follows the model
697 shown in Figure 7.

REQUESTOR PROVIDER

request(…)
REQ_MESSAGE

indication(…)

response(…)
RESP_MESSAGE

confirm(…)

698
699 Figure 7 Service Primitive to Protocol Relationship

700 This document defines the DDB high-level protocol that may be mapped to MIPI Interfaces. Such
701 mappings define how DDB protocol messages (PDUs) are transported using the MIPI Interface specific
702 Services.

703 The DDB protocol is optional. Therefore, a MIPI Interface may specify any other mechanism to realize the
704 DDB Services for that specific MIPI Interface. However, if the DDB protocol is used it shall be
705 implemented as defined in this section.

706 6.1 Generic Protocol Elements

707 The DDB Protocol is a collection of related Service specific protocols. This section describes the elements
708 that are common to all DDB Service protocols: the protocol model, the underlying Interconnect
709 requirements, the DDB-PDU format, and the error handling.

710 6.1.1 Requestor and Provider Protocol Model

711 In the DDB Requestor and Provider protocol model, a Requestor shall initiate an Interaction with a
712 Provider by sending a single DDB-PDU (section 6.1.3) with a MessageType of REQ_MESSAGE (Request
713 Message) to that Provider. The Request Message contains all the data needed by the Provider to perform
714 the request.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
31
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

715 The Provider shall process the Request Message and shall finalize the Interaction by sending a single
716 DDB-PDU with a MessageType of RESP_MESSAGE (Response Message) to the Requestor. The
717 Response Message contains all the data needed by the Requestor.

718 A Requestor may have up to 256 simultaneous Interactions with a single Provider, and may have
719 simultaneous Interactions with multiple Providers. A Provider shall be capable of processing at least one
720 Request Message at a time.

721 6.1.2 Underlying Interconnect Requirements

722 The underlying Interconnect shall be capable of indicating the source of a DDB-PDU to the recipient.

723 The underlying Interconnect shall be capable of transferring a DDB-PDU to a given endpoint on that
724 Interconnect.

725 The underlying Interconnect shall guarantee error-free transfer or shall detect and indicate transfer errors.

726 6.1.3 DDB-PDU Format

727 The DDB-PDU is composed of two parts, the Protocol Control Information (PCI) and the payload, and
728 shall have the format defined in Figure 8.

729
730 Figure 8 DDB-PDU Format

731 The PCI contains four fields: MessageType, ServiceID, MessageID and MessageSize. The PCI fields are
732 described in sections 6.1.3.1, 6.1.3.2, 6.1.3.3 and 6.1.3.4. The payload depends on the MessageType and
733 ServiceID values and is specified in the protocol sections.

734 6.1.3.1 MessageType Values

735 The MessageType shall be one of the values listed in Table 20. Values not listed in the table are reserved.
736 A Device shall not send a DDB-PDU with a reserved value.
737 Table 20 MessageType Values

Value MessageType Description

0x00 REQ_MESSAGE Request Message
0x01 RESP_MESSAGE Response Message

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
32
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

738 6.1.3.2 ServiceID Values

739 The ServiceID shall be one of the values listed in Table 21. Values not listed in the table are reserved. A
740 Device shall not send a DDB-PDU with a reserved value.
741 Table 21 ServiceID Values

Value Service Name Description

0x01 GET-DDB-LEVEL1 See section 5.2.2
0x02 GET-DDB-LEVEL2 See section 5.3.3
0x03 SET-DDB-LEVEL2 See section 5.3.4

742 6.1.3.3 MessageID

743 The MessageID links a Response Message to a particular Request Message. The Requestor shall provide
744 the MessageID within the Request Message. The Provider shall set the MessageID in a Response Message
745 to the MessageID contained in the corresponding Request Message.

746 The Requestor’s DDB Service Provider may use the TransactionID of the request Primitive for the
747 MessageID in the DDB-PDU. The Provider’s DDB Service Provider may use the MessageID of the
748 DDB-PDU as TransactionID for the indication Primitive.

749 6.1.3.4 MessageSize

750 The MessageSize gives the size of the DDB-PDU in octets as an unsigned integer number. The number of
751 message octets shall be the same as the value of the MessageSize field.

752 6.1.4 Error Handling

753 The DDB protocol only supports error detection; error recovery is the responsibility of the Service User.

754 If the DDB Layer receives a DDB-PDU with an unknown MessageType, it shall ignore the DDB-PDU.

755 If the DDB Layer receives a DDB-PDU with MessageType REQ_MESSAGE and an unknown ServiceID,
756 the DDB Layer should report the error to the Requestor using a corresponding Response Message with
757 ResultCode status value ERROR_NOT_SUPPORTED and ResultCode flags set to Provider DDB Layer
758 (Component = Provider, Source = DDB Layer).

759 On receipt of a DDB-PDU with MessageType REQ_MESSAGE, the DDB Layer may internally detect the
760 ERROR_ BUSY and/or ERROR_UNKNOWN conditions. If either of these error conditions is detected, it
761 should report the error to the Requestor using a corresponding Response Message with the detected
762 ResultCode status value and ResultCode flags set to Provider DDB Layer (Component = Provider, Source
763 = DDB Layer).

764 If the DDB Layer receives a DDB-PDU with MessageType RESP_MESSAGE and a combination of
765 ServiceID and MessageID that do not belong to an ongoing Transaction, it shall ignore the DDB-PDU.

766 If the Requestor’s DDB Layer does not receive a Response Message within the time-out value specified in
767 the Interconnect Mapping for that Interconnect, it shall report ERROR_NO_RESPONSE to the Service
768 User. The ResultCode flags shall be set to Requestor DDB Layer (Component = Requestor, Source = DDB
769 Layer).

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
33
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

770 6.1.4.1 Interaction with the Interconnect

771 If the Requestor's DDB Layer detects an invalid ProviderID value when receiving a request primitive, or
772 receives an indication from the Transport layer of an invalid ProviderID condition when sending a
773 REQ_MESSAGE, it shall abort the Transaction and shall report Result Status ERROR_INVALID_ID with
774 ResultCode flags set to Requestor DDB Layer (Component = Requestor, Source = DDB Layer) or
775 Requestor Transport Layer (Component = Requestor, Source = Transport Layer) according to the
776 component that detected the error to the Service User in the corresponding confirm primitive.

777 The Provider’s DDB Layer may detect an invalid RequestorID value when receiving a response primitive.
778 In this case it should not generate a RESP_MESSAGE.

779 The Provider’s DDB Layer shall ignore ERROR_INVALID_ID and transport error conditions indicated by
780 the Interconnect.

781 6.2 DDB Protocol Support for Level 1 Service

782 The DDB protocol shall be used to realize the DDB-LEVEL-1 Service.

783 6.2.1 Relation to Service Primitives

784 The receipt of a GET-DDB-LEVEL1.request Primitive may cause the sending of a GET-DDB-LEVEL1
785 Request Message.

786 The receipt of a GET-DDB-LEVEL1 Request Message may cause the generation of a
787 GET-DDB-LEVEL1.indication Primitive.

788 The receipt of a GET-DDB-LEVEL1.response Primitive shall cause the sending of a GET-DDB-LEVEL1
789 Response Message.

790 The receipt of a Response Message shall generate a GET-DDB-LEVEL1.confirm Primitive, except when
791 such a Service Primitive has already been generated; for example due to a time-out. See section 5.2.1.1.

792 6.2.2 GET-DDB-LEVEL1 Payloads

793 This section describes the Request Message and Response Message DDB-PDU payloads for the
794 GET-DDB-LEVEL1 service.

795 6.2.2.1 GET-DDB-LEVEL1 Request Message Payload

796 There shall be no payload in the Request Message for GET-DDB-LEVEL1 service.

797 6.2.2.2 GET-DDB-LEVEL1 Response Message Payload

798 The payload of the Response Message shall contain the ResultCode (section 5.1.1.4) and, if the ResultCode
799 Status is RESULT_OK, the DdbL1Data (section 5.2.1) and shall be transferred in the order specified in
800 Figure 9.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
34
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

Octet 7 6 5 4 3 2 1 0
0 ResultCode Flags
1 ResultCode Status
2 Revision
3 Level
4 DeviceClass [15:8]
5 DeviceClass [7:0]
6 ManufacturerID [15:8]
7 ManufacturerID [7:0]
8 ProductID [15:8]
9 ProductID [7:0]
10 Length [15:8]
11 Length [7:0]
801
802 Figure 9 GET-DDB-LEVEL1 Response Message Payload Format

803 6.3 DDB Protocol support for Level 2 Services

804 The DDB protocol shall be used to realize the DDB-LEVEL-2 Services.

805 6.3.1 Relation to Service Primitives

806 The receipt of a valid DDB Level 2 request Primitive shall cause the sending of a corresponding DDB
807 Level 2 Request Message.

808 The receipt of a DDB Level 2 Request Message shall cause the generation of a corresponding DDB Level 2
809 indication Primitive.

810 The receipt of a DDB Level 2 response Primitive shall cause the sending of a corresponding DDB Level 2
811 Response Message.

812 The receipt of a DDB Level 2 Response Message shall generate a corresponding DDB Level 2 confirm
813 Primitive, except when such a Service Primitive has already been generated; for example, due to a time-out.
814 See sections 5.3.3.1 and 5.3.4.1 for more information.

815 6.3.2 GET-DDB-LEVEL2 Payloads

816 This section defines the Request Message and Response Message DDB-PDU payloads for the
817 GET-DDB-LEVEL2 service.

818 6.3.2.1 GET-DDB-LEVEL2 Request Message Payload

819 The payload of the Request Message shall contain the Offset (section 5.3.2.1) and the RequestLength
820 (section 5.3.2.2) and shall be transferred in the order as specified in Figure 10.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
35
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

Octet 7 6 5 4 3 2 1 0
0 Offset [15:8]
1 Offset [7:0]
2 RequestLength [15:8]
3 RequestLength [7:0]
821
822 Figure 10 GET-DDB-LEVEL2 Request Message Payload Format

823 6.3.2.2 GET-DDB-LEVEL2 Response Message Payload

824 The payload of the Response Message shall contain the ResultCode (section 5.1.1.4), the DataLength of the
825 DdbL2Data and the DdbL2Data values (section 5.3.2.4) and shall be transferred in the order as defined in
826 Figure 11.

827 DdbL2Data shall be transferred in the order of increasing index values.

828
829 Figure 11 GET-DDB-LEVEL2 Response Message Payload Format

830 6.3.3 SET-DDB-LEVEL2 Payloads

831 6.3.3.1 SET-DDB-LEVEL2 Request Message Payload

832 The payload of the Request Message shall contain the Offset (section 5.3.2.1), the DataLength of the
833 DdbL2Data and the DdbL2Data values (section 5.3.2.4) and shall be transferred in the order as defined in
834 Figure 12.

835 DdbL2Data shall be transferred in the order of increasing index values.

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
36
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

836
837 Figure 12 SET-DDB-LEVEL2 Request Message Payload Format

838 6.3.3.2 SET-DDB-LEVEL2 Response Message Payload

839 The payload of the Response Message shall contain the ResultCode (section 5.1.1.4) and the
840 ResponseLength (section 5.3.2.3) and shall be transferred in the order as defined in Figure 13.

Octet 7 6 5 4 3 2 1 0
0 ResultCode Flags
1 ResultCode Status
2 ResponseLength [15:8]
3 ResponseLength [7:0]
841
842 Figure 13 SET-DDB-LEVEL2 Response Message Payload Format

843

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
37
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

844 Annex A DDB Error Flow (informative)

845 Figure 14 shows the simplified communication flow from the request Primitive initiated by the Requestor’s
846 Service User through the Service Providers and the Transport to the Provider’s Service User. Note, not all
847 error conditions are shown in the diagram.

848 In cases where there is a ResultCode denoting an error, the ResultCode flags are set to indicate the source
849 of that error. This information is intended as a system debugging aid – the Requester Service User may
850 ignore the flag bits. The ResultCode flags set depend on the activity lane in Figure 14 where the error is
851 detected, and use the values listed in Table 4.

852

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
38
 Version 0.82.01 30-Oct-2008 MIPI Alliance Specification for DDB

853
854 Figure 14 DDB Error Flow

Copyright © 2007-2008 MIPI Alliance, Inc. All rights reserved.

MIPI Alliance Member Confidential.
39