apply other transforms
This commit is contained in:
eZio Pan
parent
ebceb6d15c
commit
448ed12b13
@ -1,11 +1,11 @@
|
||||
block/DataRegs:
|
||||
items:
|
||||
- name: DR
|
||||
description: I3C transmit data byte register.
|
||||
description: I3C receive data byte register.
|
||||
byte_offset: 0
|
||||
fieldset: DR
|
||||
- name: DWR
|
||||
description: I3C transmit data word register.
|
||||
description: I3C receive data word register.
|
||||
byte_offset: 4
|
||||
fieldset: DWR
|
||||
block/I3C:
|
||||
@ -65,22 +65,13 @@ block/I3C:
|
||||
description: I3C own device characteristics register.
|
||||
byte_offset: 96
|
||||
fieldset: DEVR0
|
||||
- name: DEVR1
|
||||
- name: DEVR
|
||||
description: I3C device 1 characteristics register.
|
||||
array:
|
||||
len: 4
|
||||
stride: 4
|
||||
byte_offset: 100
|
||||
fieldset: DEVR1
|
||||
- name: DEVR2
|
||||
description: I3C device 2 characteristics register.
|
||||
byte_offset: 104
|
||||
fieldset: DEVR2
|
||||
- name: DEVR3
|
||||
description: I3C device 3 characteristics register.
|
||||
byte_offset: 108
|
||||
fieldset: DEVR3
|
||||
- name: DEVR4
|
||||
description: I3C device 4 characteristics register.
|
||||
byte_offset: 112
|
||||
fieldset: DEVR4
|
||||
fieldset: DEVR
|
||||
- name: MAXRLR
|
||||
description: I3C maximum read length register.
|
||||
byte_offset: 144
|
||||
@ -362,6 +353,33 @@ fieldset/DCR:
|
||||
description: 'device characteristics ID others: ID to describe the type of the I3C sensor/device Note: The latest MIPI DCR ID assignments are available at: https://www.mipi.org/MIPI_I3C_device_characteristics_register.'
|
||||
bit_offset: 0
|
||||
bit_size: 8
|
||||
fieldset/DEVR:
|
||||
description: I3C device 4 characteristics register.
|
||||
fields:
|
||||
- name: DA
|
||||
description: assigned I3C dynamic address to target x (when the I3C is acting as controller) When the I3C is acting as controller, this field should be written by software to store the 7-bit dynamic address that the controller sends via a broadcast ENTDAA or a direct SETNEWDA CCC which has been acknowledged by the target x. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 1
|
||||
bit_size: 7
|
||||
- name: IBIACK
|
||||
description: 'IBI request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a IBI request from target x: - After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another IBI request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the controller logs the IBI payload data, if any, depending on I3C_DEVRx.IBIDEN. - The software is notified by the IBI flag (i.e. I3C_EVR.IBIF=1) and/or the corresponding interrupt if enabled; - Independently from IBIACK configuration for this or other devices, further IBI request(s) are NACKed until IBI request flag (i.e. I3C_EVR.IBIF) and controller-role request flag (i.e. I3C_EVR.CRF) are both cleared.'
|
||||
bit_offset: 16
|
||||
bit_size: 1
|
||||
- name: CRACK
|
||||
description: 'controller-role request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a controller-role request from target x: After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another controller-role request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the message continues as initially programmed. The software is notified by the controller-role request flag (i.e. I3C_EVR.CRF=1) and/or the corresponding interrupt if enabled; For effectively granting the controller-role to the requesting secondary controller, software should issue a GETACCCR (formerly known as GETACCMST), followed by a STOP. - Independently of CRACK configuration for this or other devices, further controller-role request(s) are NACKed until controller-role request flag (i.e. I3C_EVR.CRF) and IBI flag (i.e. I3C_EVR.IBIF) are both cleared.'
|
||||
bit_offset: 17
|
||||
bit_size: 1
|
||||
- name: IBIDEN
|
||||
description: IBI data enable (when the I3C is acting as controller) When the I3C is acting as controller, this bit should be written by software to store the BCR[2] bit as received from the target x during broadcast ENTDAA or direct GETBCR CCC via the received I3C_RDR. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 18
|
||||
bit_size: 1
|
||||
- name: SUSP
|
||||
description: suspend/stop I3C transfer on received IBI (when the I3C is acting as controller) When the I3C is acting as controller, this bit is used to receive an IBI from target x with pending read notification feature (i.e. with received MDB[7:5]=3’b101). If this bit is set, when an IBI is received (i.e. I3C_EVR.IBIF=1), a Stop is emitted on the I3C bus and the C-FIFO is automatically flushed by hardware; to avoid a next private read communication issue if a previous private read message to the target x was stored in the C-FIFO.
|
||||
bit_offset: 19
|
||||
bit_size: 1
|
||||
- name: DIS
|
||||
description: DA[6:0] write disabled (when the I3C is acting as controller) When the I3C is acting as controller, once that software set IBIACK=1 or CRACK=1, this read bit is set by hardware (i.e. DIS=1) to lock the configured DA[6:0] and IBIDEN values. Then, to be able to next modify DA[6:0] or IBIDEN, the software must wait for this field DIS to be de-asserted by hardware (i.e. polling on DIS=0) before modifying these two assigned values to the target x. Indeed, the target may be requesting an IBI or a controller-role meanwhile the controller intends to modify DA[6:0] or IBIDEN.
|
||||
bit_offset: 31
|
||||
bit_size: 1
|
||||
fieldset/DEVR0:
|
||||
description: I3C own device characteristics register.
|
||||
fields:
|
||||
@ -397,119 +415,11 @@ fieldset/DEVR0:
|
||||
description: 'reset action is valid (when the I3C is acting as target) This read bit is asserted by hardware to indicate that the RTSACT[1:0] field has been updated on the reception of a broadcast or direct write RSTACT CCC (target reset action) and is valid. This field is cleared by hardware when the target receives a frame start. If RSTVAL=1: when the RSTF is asserted (and/or the corresponding interrupt if enabled), I3C_DEVR0.RSTACT[1:0] dictates the reset action to be performed by the software if any. If RSTVAL=0: when the RSTF is asserted (and/or the corresponding interrupt if enabled), the software should issue an I3C reset after a first detected reset pattern, and a system reset on the second one.'
|
||||
bit_offset: 24
|
||||
bit_size: 1
|
||||
fieldset/DEVR1:
|
||||
description: I3C device 1 characteristics register.
|
||||
fields:
|
||||
- name: DA
|
||||
description: assigned I3C dynamic address to target x (when the I3C is acting as controller) When the I3C is acting as controller, this field should be written by software to store the 7-bit dynamic address that the controller sends via a broadcast ENTDAA or a direct SETNEWDA CCC which has been acknowledged by the target x. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 1
|
||||
bit_size: 7
|
||||
- name: IBIACK
|
||||
description: 'IBI request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a IBI request from target x: - After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another IBI request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the controller logs the IBI payload data, if any, depending on I3C_DEVRx.IBIDEN. - The software is notified by the IBI flag (i.e. I3C_EVR.IBIF=1) and/or the corresponding interrupt if enabled; - Independently from IBIACK configuration for this or other devices, further IBI request(s) are NACKed until IBI request flag (i.e. I3C_EVR.IBIF) and controller-role request flag (i.e. I3C_EVR.CRF) are both cleared.'
|
||||
bit_offset: 16
|
||||
bit_size: 1
|
||||
- name: CRACK
|
||||
description: 'controller-role request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a controller-role request from target x: After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another controller-role request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the message continues as initially programmed. The software is notified by the controller-role request flag (i.e. I3C_EVR.CRF=1) and/or the corresponding interrupt if enabled; For effectively granting the controller-role to the requesting secondary controller, software should issue a GETACCCR (formerly known as GETACCMST), followed by a STOP. - Independently of CRACK configuration for this or other devices, further controller-role request(s) are NACKed until controller-role request flag (i.e. I3C_EVR.CRF) and IBI flag (i.e. I3C_EVR.IBIF) are both cleared.'
|
||||
bit_offset: 17
|
||||
bit_size: 1
|
||||
- name: IBIDEN
|
||||
description: IBI data enable (when the I3C is acting as controller) When the I3C is acting as controller, this bit should be written by software to store the BCR[2] bit as received from the target x during broadcast ENTDAA or direct GETBCR CCC via the received I3C_RDR. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 18
|
||||
bit_size: 1
|
||||
- name: SUSP
|
||||
description: suspend/stop I3C transfer on received IBI (when the I3C is acting as controller) When the I3C is acting as controller, this bit is used to receive an IBI from target x with pending read notification feature (i.e. with received MDB[7:5]=3’b101). If this bit is set, when an IBI is received (i.e. I3C_EVR.IBIF=1), a Stop is emitted on the I3C bus and the C-FIFO is automatically flushed by hardware; to avoid a next private read communication issue if a previous private read message to the target x was stored in the C-FIFO.
|
||||
bit_offset: 19
|
||||
bit_size: 1
|
||||
- name: DIS
|
||||
description: DA[6:0] write disabled (when the I3C is acting as controller) When the I3C is acting as controller, once that software set IBIACK=1 or CRACK=1, this read bit is set by hardware (i.e. DIS=1) to lock the configured DA[6:0] and IBIDEN values. Then, to be able to next modify DA[6:0] or IBIDEN, the software must wait for this field DIS to be de-asserted by hardware (i.e. polling on DIS=0) before modifying these two assigned values to the target x. Indeed, the target may be requesting an IBI or a controller-role meanwhile the controller intends to modify DA[6:0] or IBIDEN.
|
||||
bit_offset: 31
|
||||
bit_size: 1
|
||||
fieldset/DEVR2:
|
||||
description: I3C device 2 characteristics register.
|
||||
fields:
|
||||
- name: DA
|
||||
description: assigned I3C dynamic address to target x (when the I3C is acting as controller) When the I3C is acting as controller, this field should be written by software to store the 7-bit dynamic address that the controller sends via a broadcast ENTDAA or a direct SETNEWDA CCC which has been acknowledged by the target x. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 1
|
||||
bit_size: 7
|
||||
- name: IBIACK
|
||||
description: 'IBI request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a IBI request from target x: - After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another IBI request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the controller logs the IBI payload data, if any, depending on I3C_DEVRx.IBIDEN. - The software is notified by the IBI flag (i.e. I3C_EVR.IBIF=1) and/or the corresponding interrupt if enabled; - Independently from IBIACK configuration for this or other devices, further IBI request(s) are NACKed until IBI request flag (i.e. I3C_EVR.IBIF) and controller-role request flag (i.e. I3C_EVR.CRF) are both cleared.'
|
||||
bit_offset: 16
|
||||
bit_size: 1
|
||||
- name: CRACK
|
||||
description: 'controller-role request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a controller-role request from target x: After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another controller-role request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the message continues as initially programmed. The software is notified by the controller-role request flag (i.e. I3C_EVR.CRF=1) and/or the corresponding interrupt if enabled; For effectively granting the controller-role to the requesting secondary controller, software should issue a GETACCCR (formerly known as GETACCMST), followed by a STOP. - Independently of CRACK configuration for this or other devices, further controller-role request(s) are NACKed until controller-role request flag (i.e. I3C_EVR.CRF) and IBI flag (i.e. I3C_EVR.IBIF) are both cleared.'
|
||||
bit_offset: 17
|
||||
bit_size: 1
|
||||
- name: IBIDEN
|
||||
description: IBI data enable (when the I3C is acting as controller) When the I3C is acting as controller, this bit should be written by software to store the BCR[2] bit as received from the target x during broadcast ENTDAA or direct GETBCR CCC via the received I3C_RDR. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 18
|
||||
bit_size: 1
|
||||
- name: SUSP
|
||||
description: suspend/stop I3C transfer on received IBI (when the I3C is acting as controller) When the I3C is acting as controller, this bit is used to receive an IBI from target x with pending read notification feature (i.e. with received MDB[7:5]=3’b101). If this bit is set, when an IBI is received (i.e. I3C_EVR.IBIF=1), a Stop is emitted on the I3C bus and the C-FIFO is automatically flushed by hardware; to avoid a next private read communication issue if a previous private read message to the target x was stored in the C-FIFO.
|
||||
bit_offset: 19
|
||||
bit_size: 1
|
||||
- name: DIS
|
||||
description: DA[6:0] write disabled (when the I3C is acting as controller) When the I3C is acting as controller, once that software set IBIACK=1 or CRACK=1, this read bit is set by hardware (i.e. DIS=1) to lock the configured DA[6:0] and IBIDEN values. Then, to be able to next modify DA[6:0] or IBIDEN, the software must wait for this field DIS to be de-asserted by hardware (i.e. polling on DIS=0) before modifying these two assigned values to the target x. Indeed, the target may be requesting an IBI or a controller-role meanwhile the controller intends to modify DA[6:0] or IBIDEN.
|
||||
bit_offset: 31
|
||||
bit_size: 1
|
||||
fieldset/DEVR3:
|
||||
description: I3C device 3 characteristics register.
|
||||
fields:
|
||||
- name: DA
|
||||
description: assigned I3C dynamic address to target x (when the I3C is acting as controller) When the I3C is acting as controller, this field should be written by software to store the 7-bit dynamic address that the controller sends via a broadcast ENTDAA or a direct SETNEWDA CCC which has been acknowledged by the target x. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 1
|
||||
bit_size: 7
|
||||
- name: IBIACK
|
||||
description: 'IBI request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a IBI request from target x: - After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another IBI request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the controller logs the IBI payload data, if any, depending on I3C_DEVRx.IBIDEN. - The software is notified by the IBI flag (i.e. I3C_EVR.IBIF=1) and/or the corresponding interrupt if enabled; - Independently from IBIACK configuration for this or other devices, further IBI request(s) are NACKed until IBI request flag (i.e. I3C_EVR.IBIF) and controller-role request flag (i.e. I3C_EVR.CRF) are both cleared.'
|
||||
bit_offset: 16
|
||||
bit_size: 1
|
||||
- name: CRACK
|
||||
description: 'controller-role request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a controller-role request from target x: After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another controller-role request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the message continues as initially programmed. The software is notified by the controller-role request flag (i.e. I3C_EVR.CRF=1) and/or the corresponding interrupt if enabled; For effectively granting the controller-role to the requesting secondary controller, software should issue a GETACCCR (formerly known as GETACCMST), followed by a STOP. - Independently of CRACK configuration for this or other devices, further controller-role request(s) are NACKed until controller-role request flag (i.e. I3C_EVR.CRF) and IBI flag (i.e. I3C_EVR.IBIF) are both cleared.'
|
||||
bit_offset: 17
|
||||
bit_size: 1
|
||||
- name: IBIDEN
|
||||
description: IBI data enable (when the I3C is acting as controller) When the I3C is acting as controller, this bit should be written by software to store the BCR[2] bit as received from the target x during broadcast ENTDAA or direct GETBCR CCC via the received I3C_RDR. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 18
|
||||
bit_size: 1
|
||||
- name: SUSP
|
||||
description: suspend/stop I3C transfer on received IBI (when the I3C is acting as controller) When the I3C is acting as controller, this bit is used to receive an IBI from target x with pending read notification feature (i.e. with received MDB[7:5]=3’b101). If this bit is set, when an IBI is received (i.e. I3C_EVR.IBIF=1), a Stop is emitted on the I3C bus and the C-FIFO is automatically flushed by hardware; to avoid a next private read communication issue if a previous private read message to the target x was stored in the C-FIFO.
|
||||
bit_offset: 19
|
||||
bit_size: 1
|
||||
- name: DIS
|
||||
description: DA[6:0] write disabled (when the I3C is acting as controller) When the I3C is acting as controller, once that software set IBIACK=1 or CRACK=1, this read bit is set by hardware (i.e. DIS=1) to lock the configured DA[6:0] and IBIDEN values. Then, to be able to next modify DA[6:0] or IBIDEN, the software must wait for this field DIS to be de-asserted by hardware (i.e. polling on DIS=0) before modifying these two assigned values to the target x. Indeed, the target may be requesting an IBI or a controller-role meanwhile the controller intends to modify DA[6:0] or IBIDEN.
|
||||
bit_offset: 31
|
||||
bit_size: 1
|
||||
fieldset/DEVR4:
|
||||
description: I3C device 4 characteristics register.
|
||||
fields:
|
||||
- name: DA
|
||||
description: assigned I3C dynamic address to target x (when the I3C is acting as controller) When the I3C is acting as controller, this field should be written by software to store the 7-bit dynamic address that the controller sends via a broadcast ENTDAA or a direct SETNEWDA CCC which has been acknowledged by the target x. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 1
|
||||
bit_size: 7
|
||||
- name: IBIACK
|
||||
description: 'IBI request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a IBI request from target x: - After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another IBI request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the controller logs the IBI payload data, if any, depending on I3C_DEVRx.IBIDEN. - The software is notified by the IBI flag (i.e. I3C_EVR.IBIF=1) and/or the corresponding interrupt if enabled; - Independently from IBIACK configuration for this or other devices, further IBI request(s) are NACKed until IBI request flag (i.e. I3C_EVR.IBIF) and controller-role request flag (i.e. I3C_EVR.CRF) are both cleared.'
|
||||
bit_offset: 16
|
||||
bit_size: 1
|
||||
- name: CRACK
|
||||
description: 'controller-role request acknowledge (when the I3C is acting as controller) When the I3C is acting as controller, this bit is written by software to define the acknowledge policy to be applied on the I3C bus on the reception of a controller-role request from target x: After the NACK, the message continues as initially programmed (the target is aware of the NACK and can emit another controller-role request later on) - The field DIS is asserted by hardware to protect DA[6:0] from being modified by software meanwhile the hardware can store internally the current DA[6:0] into the kernel clock domain. - After the ACK, the message continues as initially programmed. The software is notified by the controller-role request flag (i.e. I3C_EVR.CRF=1) and/or the corresponding interrupt if enabled; For effectively granting the controller-role to the requesting secondary controller, software should issue a GETACCCR (formerly known as GETACCMST), followed by a STOP. - Independently of CRACK configuration for this or other devices, further controller-role request(s) are NACKed until controller-role request flag (i.e. I3C_EVR.CRF) and IBI flag (i.e. I3C_EVR.IBIF) are both cleared.'
|
||||
bit_offset: 17
|
||||
bit_size: 1
|
||||
- name: IBIDEN
|
||||
description: IBI data enable (when the I3C is acting as controller) When the I3C is acting as controller, this bit should be written by software to store the BCR[2] bit as received from the target x during broadcast ENTDAA or direct GETBCR CCC via the received I3C_RDR. Writing to this field has no impact when the read field I3C_DEVRx.DIS=1.
|
||||
bit_offset: 18
|
||||
bit_size: 1
|
||||
- name: SUSP
|
||||
description: suspend/stop I3C transfer on received IBI (when the I3C is acting as controller) When the I3C is acting as controller, this bit is used to receive an IBI from target x with pending read notification feature (i.e. with received MDB[7:5]=3’b101). If this bit is set, when an IBI is received (i.e. I3C_EVR.IBIF=1), a Stop is emitted on the I3C bus and the C-FIFO is automatically flushed by hardware; to avoid a next private read communication issue if a previous private read message to the target x was stored in the C-FIFO.
|
||||
bit_offset: 19
|
||||
bit_size: 1
|
||||
- name: DIS
|
||||
description: DA[6:0] write disabled (when the I3C is acting as controller) When the I3C is acting as controller, once that software set IBIACK=1 or CRACK=1, this read bit is set by hardware (i.e. DIS=1) to lock the configured DA[6:0] and IBIDEN values. Then, to be able to next modify DA[6:0] or IBIDEN, the software must wait for this field DIS to be de-asserted by hardware (i.e. polling on DIS=0) before modifying these two assigned values to the target x. Indeed, the target may be requesting an IBI or a controller-role meanwhile the controller intends to modify DA[6:0] or IBIDEN.
|
||||
bit_offset: 31
|
||||
bit_size: 1
|
||||
fieldset/DR:
|
||||
description: I3C transmit data byte register.
|
||||
description: I3C receive data byte register.
|
||||
fields:
|
||||
- name: DB
|
||||
description: 8-bit data to transmit on I3C bus.
|
||||
description: 8-bit received data on I3C bus.
|
||||
bit_offset: 0
|
||||
bit_size: 8
|
||||
fieldset/DWR:
|
||||
@ -677,22 +587,13 @@ fieldset/GETMXDSR:
|
||||
fieldset/IBIDR:
|
||||
description: I3C IBI payload data register.
|
||||
fields:
|
||||
- name: IBIDB0
|
||||
- name: IBIDB
|
||||
description: 8-bit IBI payload data (earliest byte on I3C bus, i.e. MDB[7:0] mandatory data byte).
|
||||
bit_offset: 0
|
||||
bit_size: 8
|
||||
- name: IBIDB1
|
||||
description: 8-bit IBI payload data (next byte on I3C bus after IBIDB0[7:0]).
|
||||
bit_offset: 8
|
||||
bit_size: 8
|
||||
- name: IBIDB2
|
||||
description: 8-bit IBI payload data (next byte on I3C bus after IBIDB1[7:0]).
|
||||
bit_offset: 16
|
||||
bit_size: 8
|
||||
- name: IBIDB3
|
||||
description: 8-bit IBI payload data (latest byte on I3C bus).
|
||||
bit_offset: 24
|
||||
bit_size: 8
|
||||
array:
|
||||
len: 4
|
||||
stride: 8
|
||||
fieldset/IER:
|
||||
description: I3C interrupt enable register.
|
||||
fields:
|
||||
@ -791,7 +692,7 @@ fieldset/IER:
|
||||
fieldset/MAXRLR:
|
||||
description: I3C maximum read length register.
|
||||
fields:
|
||||
- name: MRL
|
||||
- name: ML
|
||||
description: maximum data read length (when I3C is acting as target) This field is initially written by software when I3C_CFGR.EN=0 and updated by hardware on the reception of SETMRL command (with potentially also updated IBIP[2:0]). Software is notified of a MRL update by the I3C_EVR.MRLUPF and the corresponding interrupt if enabled. This field is used by hardware to return the value on the I3C bus when the target receives a GETMRL CCC.
|
||||
bit_offset: 0
|
||||
bit_size: 16
|
||||
@ -802,7 +703,7 @@ fieldset/MAXRLR:
|
||||
fieldset/MAXWLR:
|
||||
description: I3C maximum write length register.
|
||||
fields:
|
||||
- name: MWL
|
||||
- name: ML
|
||||
description: maximum data write length (when I3C is acting as target) This field is initially written by software when I3C_CFGR.EN=0 and updated by hardware on the reception of SETMWL command. Software is notified of a MWL update by the I3C_EVR.MWLUPF and the corresponding interrupt if enabled. This field is used by hardware to return the value on the I3C bus when the target receives a GETMWL CCC.
|
||||
bit_offset: 0
|
||||
bit_size: 16
|
||||
|
||||
@ -35,3 +35,22 @@ transforms:
|
||||
to: ${1}x${2}
|
||||
|
||||
### End of making DataRegs block ###
|
||||
|
||||
- !MakeFieldArray
|
||||
fieldsets: IBIDR
|
||||
from: ^(IBIDB)\d$
|
||||
to: $1
|
||||
|
||||
- !MergeFieldsets
|
||||
from: ^(DEVR)[1-4]$
|
||||
to: $1
|
||||
|
||||
- !MakeRegisterArray
|
||||
blocks: I3C
|
||||
from: ^(DEVR)[1-4]$
|
||||
to: $1
|
||||
|
||||
- !RenameFields
|
||||
fieldset: ^MAX[RW]LR$
|
||||
from: ^M[RW]L$
|
||||
to: ML
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user