TISCI

Starting in v4.3, Processor SDK documentation is no longer hosted on processors wiki.

For latest information on Texas Instruments' System Control Interface (TISCI) please refer to the following link on ti.com http://downloads.ti.com/tisci/esd/latest/

Texas Instruments' System Control Interface (TISCI)

Introduction

Brief Introduction to SoC System Control entity

Traditional Texas Instruments SoCs implement system control functions such as power management within operating systems on each of the processing units (ARM/DSP etc). However the traditional approach has had tremendous challenges to ensure system stability. Few of the challenges include:

• Complex interactions between operating systems on heterogeneous SoCs for generic features.
• Lack of centralized knowledge of system state.
• Complex implementation challenges when implementing workarounds for SoC errata.
• Equivalent SoC power or device management entitlement on all variations of Operating Systems.

Texas Instruments' Keystone generation System on Chips (SoC) starting with 66AK2G02, now include a dedicated SoC System Control entity called PMMC(Power Management Micro Controller) in line with ARM architecture recommendations. The function of this module is to integrate all system operations in a centralized location. Communication with the SoC System Control entity from various processing units like ARM/DSP occurs over Message Manager hardware block.

For further details on the integration of the hardware on 66AK2G02, please see Technical Reference Manual for the processor.

Now, it is great we have a central entity for system control and we have communication mechanism with it, without a common language, processing entities such as ARM/DSP and the system control entity will be in the Tower of Babel.

Texas Instruments' System Control Interface defines the communication protocol between various processing entities to the System Control Entity on TI SoCs. This is a set of message formats and sequence of operations required to communicate and get system services processed from System Control entity in the SoC.

Similar protocols do exist for other SoCs. Similar SoC definitions are available:

• ARM System Control and Power Interface (SCPI) for the ARM System Control Processor

NOTE: SoC System Control Processor should not be confused with the typical System Control Co-processor (CP15) that helps support the ARM processor functions.

Introduction to the TISCI protocol

Primary goal of TISCI protocol is to be SoC independent. To achieve this, the following rules are followed by TISCI protocol:

• Limited in scope to SoC boundary - Entities outside the SoC boundary are not directly controlled by TISCI protocol.
• Centralized control of SoC system functions including power management (device management, clock abstraction, etc.). This implies that operating systems do not directly access any of the hardware modules that control system functions such as power management, instead TISCI will be used.
• SoC comprises of multiple hardware blocks, hence all abstractions are at the hardware block level. This implies that if I2C2 instance is to be requested, I2C2 device is requested, and clock frequency for example is referenced from I2C2's perspective. Hence, if the OS driver controlling I2C2 needs to know the functional clock frequency, the request is made for I2C2 functional clock frequency.
• Maximum message size is constrained to 64 bytes. This constraint is based on the messaging mechanism that is standardized for TI SoCs (Message Manager).

TISCI protocol description

Main categories of the protocol

The following are the major categories for TISCI protocol messages:

1. Core Messages: These messages control SoC level such as those involved for SoC reset etc.
2. Device Messages: These messages control or query the access to the hardware blocks inside the SoC
3. Clock Messages: These messages control or query the access to the clocks that supply hardware blocks inside the SoC

Message Manager protocol

Message Manager, in a nutshell, is a data buffer consisting of 16 32-bit registers. The protocol requires the data buffer registers are written in 32-bit access and byte0 corresponds to the lowest position data byte for the register and byte3 is the highest position data byte for the register from the lowest buffer register to the highest buffer register.

NOTE: Each register write must have appropriate memory barriers (example: isb/dsb for ARM) to ensure that the data is actually flushed down to the message manager hardware block. If the operating system drivers don't consider potential out of order writes/reads at interconnect level, the result can be undefined.

Following table displays a few examples - Notice that register 15 is the last register to be written/read:

Message Buffer	Message Manager Buffer
Data to be transmitted	Register 0	Register 1	Register 2	Register ..	Register 14	Register 15 (confirmation)
0x01	0x00000001	N/A	N/A	N/A	N/A	0x00000000
0x00,0x01,0x02,0x03 0x04	0x03020100	0x00000004	N/A	N/A	N/A	0x00000000
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b	0x03020100	0x07060504	0x0b0a0908	..	0x3b3a3938	0x00000000
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c	0x03020100	0x07060504	0x0b0a0908	..	0x3b3a3938	0x0000003c
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f	0x03020100	0x07060504	0x0b0a0908	..	0x3b3a3938	0x3f3e3d3c

Generic Messaging Header

All messages are prefixed by a header. This header is always present for transmit or receive messages. The format is as follows

Byte Index	Data Type	Name	Description
[0:1]	U16	message_type	Type of messages: One of TI_SCI_MSG* values
[2]	U8	Host	Host of the message
[3]	U8	sequence_id	Message identifier indicating a transfer sequence
[4:7]	U32	Flags	Flag for the message - Generic Message flags are as following: For messages that are being transmitted: Flag Value Description TI_SCI_FLAG_REQ_GENERIC_NORESPONSE 0x0 No response required TI_SCI_FLAG_REQ_ACK_ON_RECEIVED (1 << 0) Send the transmitter a ACK/NAK message when message is received. TI_SCI_FLAG_REQ_ACK_ON_PROCESSED (1 << 1) Send the transmitter a ACK/NAK message when message processing is complete. For messages that are being received: Flag Value Description TI_SCI_FLAG_RESP_GENERIC_NACK 0x0 The requested operation failed. TI_SCI_FLAG_RESP_GENERIC_ACK (1 << 1) The requested operation succeeded. NOTE: Specific Messages may have additional flags that may be used as well.

Core Messages

This section explains the Core Messages

Get Revision Message

Objective: Request revision information of TISCI

Usage: Used by the processing entity to request for TISCI protocol revision used. Information such as ABI revision can be used to maintain compatibility OR handle new features based on ABI revision availability.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0002 (Request revision)

Message Response Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0002
[8:39]	char[32]	firmware_description	Verbose firmware version - string for human readable format
[40:41]	U16	Firmware_revision	Firmware revision in hexadecimal
[42]	U8	ABI_Major	ABI Major revision - Major revision changes indicate backward compatibility breakage
[43]	U8	ABI_Minor	ABI Minor revision - Minor revision changes indicate backward compatibility is maintained, however, new messages OR extensions to existing messages might have been added

System Reset Message

Objective: Trigger a SoC level reset

Usage: Used to trigger a system level reset. NOTE: Depending on permissions configured for the SoC, not all processing entities may be permitted to request a SoC reset. When permitted, the request once processed will not return back to caller.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0005 (SYS_RESET)

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Device Control Messages

Set Device State Message

Objective: Request for a device state to be set

Usage: This is used to request or release a device. For example: When the device is requested for operation, state is set to MSG_DEVICE_SW_STATE_ON. When the usage of the device is complete and released, the same request with state set as MSG_DEVICE_SW_STATE_AUTO_OFF is invoked. Based on exclusive access request, multiple processing entities can share a specific hardware block, however, this must be carefully used keeping the full system view in mind.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0200 (SET_DEVICE). Flags can also have the following additional states: Flag Value Description MSG_FLAG_DEVICE_WAKE_ENABLED (1 << 8) Device can wakeup the SoC MSG_FLAG_DEVICE_RESET_ISO (1 << 9) Enable Reset Isolation when the device is requested MSG_FLAG_DEVICE_EXCLUSIVE (1 << 10) Request the device exclusively for the processing entity requesting the same.
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12:15]	U32	Reserved	Reserved for future expansion
[16]	U8	state	State of device requested. This can be one of the following: State Value Description MSG_DEVICE_SW_STATE_AUTO_OFF 0 Request the device to be switched OFF MSG_DEVICE_SW_STATE_RETENTION 1 Request the device to be setup to be in retention MSG_DEVICE_SW_STATE_ON 2 Request the device be switched ON

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Set Device Resets Message

Objective: Set the state of device reset state

Usage: This is used to set or release various resets of the hardware block. This is typically used for hardware blocks which require special handling prior to specific resets being released. Typical example is when starting up a processing entity like ICSS/DSP, the device must be requested with resets asserted, required firmware loaded and the required resets released in appropriate order for operation of the device.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0202 (SET_DEVICE_RESETS)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12:15]	U32	resets	Resets corresponding to the hardware block. A value of '0' at the bit position indicates the corresponding reset being released, while a '1' indicates the reset being asserted.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Get Device State Message

Objective: Retrieve the hardware block state

Usage: Determine the current state of the hardware block. This request does not require the processing entity to have control of the device via a set device state request.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0201 (GET_DEVICE_STATE)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8:11]	U32	Context_loss_count	Indicates how many times the hardware block has lost context
[12:15]	U32	resets	Current state of the resets for the hardware block. A '0' in the bit position indicates the corresponding reset is released, and a '1' indicates the reset is asserted.
[16:19]	U32	programmed_state	Current requested state of the device. This can be one of the following: State Value Description MSG_DEVICE_SW_STATE_AUTO_OFF 0 Request the device to be switched OFF MSG_DEVICE_SW_STATE_RETENTION 1 Request the device to be setup to be in retention MSG_DEVICE_SW_STATE_ON 2 Request the device be switched ON
[20:23]	U32	current_hardware_state	Current state of the hardware block. This can be one of the following: State Value Description MSG_DEVICE_HW_STATE_OFF 0 The device is switched OFF MSG_DEVICE_HW_STATE_ON 1 The device is ON MSG_DEVICE_HW_STATE_TRANS 2 The device is in the middle of state transition (OR if the state persists, stuck in transition)

Clock Control Messages

Set Clock State Message

Objective: Setup a hardware device's clock state

Usage: This requests for finer control of hardware device's clocks. This allows for configuration for hardware blocks that require customization of the specific input clocks. NOTE: each of the clock IDs are relative to the hardware block.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0100 (SET_CLOCK_STATE), The following additional flags can also be used for the request: Flag Value Description MSG_FLAG_CLOCK_ALLOW_SSC (1 << 8) Allow this clock to be modified via Spread Spectrum Clocking. MSG_FLAG_CLOCK_ALLOW_FREQ_CHANGE (1 << 9) Allow this clock's frequency to be changed while it is running so long as it is within the min/max limits. MSG_FLAG_CLOCK_INPUT_TERM (1 << 10) Enable input termination, this is only applicable to clock inputs on the SoC pseudo-device.
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.
[13]	U8	request_state	Request the state for the clock to be set to. This can be one of the following: State Value Description MSG_CLOCK_SW_STATE_UNREQ 0 The IP does not require this clock, it can be disabled, regardless of the state of the device. MSG_CLOCK_SW_STATE_AUTO 1 Allow the System Controller to automatically manage the state of this clock. If the device is enabled, then the clock is enabled. If the device is set to off or retention, then the clock is internally set as not being required by the device.(default) MSG_CLOCK_SW_STATE_REQ 2 Configure the clock to be enabled, regardless of the state of the device.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Get Clock State Message

Objective: Get the state of a clock to or from a hardware block

Usage:

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0101 (GET_CLOCK_STATE)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8]	U8	programmed_state	This indicates the current programmed state of the clock. This can be one of: State Value Description MSG_CLOCK_SW_STATE_UNREQ 0 The IP does not require this clock, it can be disabled, regardless of the state of the device. MSG_CLOCK_SW_STATE_AUTO 1 Allow the System Controller to automatically manage the state of this clock. If the device is enabled, then the clock is enabled. If the device is set to off or retention, then the clock is internally set as not being required by the device.(default) MSG_CLOCK_SW_STATE_REQ 2 Configure the clock to be enabled, regardless of the state of the device.
[9]	U8	current_state	This indicates the current programmed state of the clock. This can be one of: State Value Description MSG_CLOCK_HW_STATE_NOT_READY 0 Clock is not ready MSG_CLOCK_HW_STATE_READY 1 Clock is ready

Set Clock Parent Message

Objective: SoC specific customization for setting up a specific clock parent ID for the various clock input options for a hardware block's clock.

Usage: This is rarely used customization that may be required based on the usecase of the system where the reset input clock option may not suffice for the usecase attempted.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0102 (SET_CLOCK_PARENT)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.
[13]	U8	parent_id	New parent ID requested for the clock.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Get Clock Parent Message

Objective: Query the clock parent currently configured for a specific clock source of a hardware block

Usage: This is typically used to confirm the current clock parent to ensure that the requisite usecase for the hardware block can be satisfied.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0103 (GET_CLOCK_PARENT)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8]	U8	parent_id	Currently configured Clock parent ID

Get Number of Clock Parents Message

Objective: Query for the number of parent clock paths available for a specific hardware block's clock.

Usage: This is typically used to get the max number of clock parent options available for a specific hardware block's clock.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x0104 (GET_NUM_CLOCK_PARENTS)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8]	U8	num_parents	Number of clock parents available for the requested clock

Set Clock Frequency Message

Objective: Setup a clock frequency for a hardware block's clock.

Usage: This is typically desired when the default frequency of the hardware block's clock is not appropriate for the usecase desired.

NOTE: Normally clock frequency management is automatically done by TISCI entity. In case of specific requests, TISCI evaluates capability to achieve requested range and responds with success/failure message.

This sets the desired frequency for a clock within an allowable range. This message will fail on an enabled clock unless MSG_FLAG_CLOCK_ALLOW_FREQ_CHANGE is set for the clock. Additionally, if other clocks have their frequency modified due to this message, they also must have the MSG_FLAG_CLOCK_ALLOW_FREQ_CHANGE or be disabled.

Calling set frequency on a clock input to the SoC pseudo-device will inform the PMMC of that clock's frequency. Setting a frequency of zero will indicate the clock is disabled.

Calling set frequency on clock outputs from the SoC pseudo-device will function similarly to setting the clock frequency on a device.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x010c (SET_CLOCK_FREQ)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12:19]	U64	min_freq_hz	Minimum allowed frequency in Hz. This is the minimum allowable programmed frequency and does not account for clock tolerances and jitter.
[20:27]	U64	target_freq_hz	Target frequency in Hz. The clock will be programmed at a rate as close to this target frequency as possible.
[28:35]	U64	max_freq_hz	Maximum allowed frequency in Hz. This is the maximum allowable programmed frequency and does not account for clock tolerances and jitter.
[36]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.

Query Clock Frequency Message

Objective: Query to find closest match possible for a target frequency

Usage: This message does no real operation, instead, it requests the system control entity to respond with the best frequency that can match a frequency range provided. NOTE: This is a snapshot view. In a multi processing system, it is very well possible that another processing entity might change the configuration after one entity has queried for best match capability. Only a SET_CLOCK_FREQ will guarantee the frequency is configured.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x010d (QUERY_CLOCK_FREQ)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12:19]	U64	min_freq_hz	Minimum allowed frequency in Hz. This is the minimum allowable programmed frequency and does not account for clock tolerances and jitter.
[20:27]	U64	target_freq_hz	Target frequency in Hz. A frequency will be found that is at a rate as close to this target frequency as possible.
[28:35]	U64	max_freq_hz	Maximum allowed frequency in Hz. This is the maximum allowable programmed frequency and does not account for clock tolerances and jitter.
[36]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8:15]	U64	freq_Hz	Frequency that is the best match for the request in Hz

Get Clock Frequency Message

Objective: Get the clock frequency of a specific clock which belongs to a hardware block.

Usage: This is most used functionality and is meant for usage when the driver controlling the hardware block requires to know the input clock frequency for configuring internal dividers / multipliers as required.

Message Request Format:

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where Type is 0x010e (GET_CLOCK_FREQ)
[8:11]	U32	DeviceID	SoC specific Device Identifier uniquely identifying the hardware block instance
[12]	U8	ClockID	Device specific clock Identifier uniquely identifying the specific input or output clock for the hardware block.

Message Response Format (if requested):

Byte Index	Data Type	Name	Description
[0:7]	Header	Header	Where ACK/NACK is set in the flags indicating status of request.
[8:15]	U64	freq_Hz	Current frequency of the clock in Hz

SoC specific Data

66AK2G02 Data

Device IDs

Hardware Block Name	Device ID
PMMC0	0x0000
MLB0	0x0001
DSS0	0x0002
MCBSP0	0x0003
MCASP0	0x0004
MCASP1	0x0005
MCASP2	0x0006
DCAN0	0x0008
DCAN1	0x0009
EMIF0	0x000a
MMCHS0	0x000b
MMCHS1	0x000c
GPMC0	0x000d
ELM0	0x000e
SPI0	0x0010
SPI1	0x0011
SPI2	0x0012
SPI3	0x0013
ICSS0	0x0014
ICSS1	0x0015
USB0	0x0016
USB1	0x0017
NSS0	0x0018
PCIE0	0x0019
GPIO0	0x001b
GPIO1	0x001c
TIMER64	0x001d
TIMER64	0x001e
TIMER64	0x001f
TIMER64	0x0020
TIMER64	0x0021
TIMER64	0x0022
TIMER64	0x0023
MSGMGR0	0x0025
BOOTCFG0	0x0026
ARM	0x0027
DSP	0x0029
DEBUGSS0	0x002b
UART0	0x002c
UART1	0x002d
UART2	0x002e
EHRPWM0	0x002f
EHRPWM1	0x0030
EHRPWM2	0x0031
EHRPWM3	0x0032
EHRPWM4	0x0033
EHRPWM5	0x0034
EQEP0	0x0035
EQEP1	0x0036
EQEP2	0x0037
ECAP0	0x0038
ECAP1	0x0039
I2C0	0x003a
I2C1	0x003b
I2C2	0x003c
EDMA0	0x003f
SEMAPHORE0	0x0040
INTC0	0x0041
GIC0	0x0042
QSPI0	0x0043
ARM	0x0044
TETRIS0	0x0045
CGEM0	0x0046
MSMC0	0x0047
CBASS0	0x0049
BOARD0	0x004c
EDMA1	0x004f

Clock IDs

Hardware Block Name	Hardware Block's Clock Name	Clock ID
PMMC	MPM_VBUS_CLK	0
PMMC	MPM_FUNC_32K_CLK	1
PMMC	MPM_FUNC_OSC_CLK	2
PMMC	MPM_DAP_CLK	3
MLB	MLB_SYS_CLK	0
MLB	MLB_SHB_OCP_CLK	1
MLB	MLB_SPB_OCP_CLK	2
MLB	MLB_IO_CLK	3
MLB	MLBP_IO_CLK	4
DSS	PI_DSS_OCP_CLK	0
DSS	PI_DSS_VP_CLK	1
MCBSP	VBUS_CLK	0
MCBSP	CLKS	1
MCBSP	CLKS_PARENT_AUDIO_OSC	2
MCBSP	CLKS_PARENT_MLB_IO_CLK	3
MCBSP	CLKS_PARENT_MLBP_IO_CLK	4
MCBSP	CLKS_PARENT_SYS_OSCCLK	5
MCBSP	CLKS_PARENT_XREFCLK	6
MCBSP	CLKS_PARENT_UART_PLL	7
MCASP	VBUS_CLK	0
MCASP	AUX_CLK	1
MCASP	AUX_CLK_PARENT_AUDIO_OSC	2
MCASP	AUX_CLK_PARENT_MLB_IO_CLK	3
MCASP	AUX_CLK_PARENT_MLBP_IO_CLK	4
MCASP	AUX_CLK_PARENT_SYS_OSCCLK	5
MCASP	AUX_CLK_PARENT_XREFCLK	6
MCASP	AUX_CLK_PARENT_UART_PLL	7
DCAN	VBUS_CLK	0
DCAN	CAN_CLK	1
EMIF	V_CLK	0
EMIF	M_CLK	1
EMIF	DFT_LOCAL_CLK	2
EMIF	PUB_CTL_CLK	3
EMIF	PHY_CTL_CLK	4
EMIF	VBUSP_CLK	5
MMCHS	VBUS_CLK	0
MMCHS	CLK_ADPI	1
MMCHS	CLK32K	2
GPMC	GPMC_FCLK	0
ELM	CLK	0
SPI	VBUSP_CLK	0
ICSS	VCLK_CLK	0
ICSS	CORE_CLK	1
ICSS	CORE_CLK_PARENT_ICSS_PLL	2
ICSS	CORE_CLK_PARENT_NSS_PLL	3
ICSS	UCLK_CLK	4
ICSS	IEPCLK_CLK	5
USB	BUS_CLK	0
USB	PHYMMR_CLK	1
USB	SUSP_CLK	2
USB	REF_CLK	3
USB	DFT_ULPI_CLK	4
USB	DFT_UTMI_CLK	5
USB	CLKCORE	6
NSS	VCLK	0
NSS	SA_UL_CLK	1
NSS	SA_UL_X1_CLK	2
NSS	ESW_CLK	3
NSS	CPTS_CHIP_CLK1_2	4
NSS	CPTS_CHIP_CLK1_3	5
NSS	CPTS_TIMI0	6
NSS	CPTS_TIMI1	7
NSS	CPTS_NSS_PLL	8
NSS	GMII_RFTCLK	9
NSS	RGMII_MHZ_5_CLK	10
NSS	RGMII_MHZ_50_CLK	11
NSS	RGMII_MHZ_250_CLK	12
NSS	RMII_MHZ_50_CLK	13
PCIE	VBUS_CLK	0
OTP	VBUS_CLK	0
GPIO	VBUS_CLK	0
TIMER64	VBUS_CLK	0
TIMER64	TINL	1
TIMER64	TINL_PARENT_TIMI0	2
TIMER64	TINL_PARENT_TIMI1	3
TIMER64	TINH	4
TIMER64	TINH_PARENT_TIMI0	5
TIMER64	TINH_PARENT_TIMI1	6
TIMER64	TOUTL	7
TIMER64	TOUTH	8
SEC	MGR_SEC_CLK_PI	0
MSGMGR	VBUS_CLK	0
BOOTCFG	VBUS_CLK	0
ARM	BOOTROM_VBUS_CLK	0
DSP	BOOTROM_VBUS_CLK	0
DEBUGSS	VBUSP_CTTBRCLK_CLK	0
DEBUGSS	VBUSP_STMD0_CLK	1
DEBUGSS	VBUSP_SLAVE_CLK	2
DEBUGSS	VBUSP_MASTER_CLK	3
DEBUGSS	TCK	4
DEBUGSS	CS_TRCEXPT_CLK	5
DEBUGSS	DSP_TRACECLK	6
DEBUGSS	STMXPT_CLK	7
UART	CBA_CLK_PI	0
EHRPWM	VBUS_CLK	0
EQEP	VBUS_CLK	0
ECAP	VBUS_CLK	0
I2C	VBUS_CLK	0
CP	TRACER_CP_TRACER_CLK	0
EDMA	TPTC_CLK	0
EDMA	TPCC_CLK	1
SEMAPHORE	VBUS_CLK	0
INTC	VBUS_CLK	0
GIC	VBUS_CLK	0
QSPI	QSPI_CLK	0
QSPI	DATA_BUS_CLK	1
QSPI	CFG_BUS_CLK	2
QSPI	QSPI_CLK_O	3
QSPI	QSPI_CLK_I	4
ARM	64B_COUNTER_CLK_INPUT	0
ARM	64B_COUNTER_VBUSP_CLK	1
TETRIS	CORE_CLK	0
TETRIS	SUBSYS_CLK	1
CGEM	CORE_CLK	0
CGEM	TRACE_CLK	1
MSMC	VBUS_CLK	0
DFT	SS_VBUS_CLK	0
DFT	SS_TCK	1
CBASS	VBUS_CLK	0
SMARTREFLEX	SCLK_CLK	0
SMARTREFLEX	REFCLK1_CLK	1
SMARTREFLEX	TEMPMCLK_CLK	2
EFUSE	VBUS_CLK	0
BOARD	SYS_OSCIN	0
BOARD	SYS_CLK	1
BOARD	AUDIO_OSCIN	2
BOARD	DDR	3
BOARD	MLBCLK	4
BOARD	MLBPCLK	5
BOARD	XREFCLK	6
BOARD	TIMI0	7
BOARD	TIMI1	8
BOARD	SYSCLKOUT	10
BOARD	OBSCLK	11
BOARD	OBSCLK_PARENT_MAIN_PLL	12
BOARD	OBSCLK_PARENT_DSS_PLL	13
BOARD	OBSCLK_PARENT_ARM_PLL	14
BOARD	OBSCLK_PARENT_UART_PLL	15
BOARD	OBSCLK_PARENT_ICSS_PLL	16
BOARD	OBSCLK_PARENT_DDR_PLL	17
BOARD	OBSCLK_PARENT_PLL_CTRL	18
BOARD	OBSCLK_PARENT_NSS_PLL	19
BOARD	OBSCLK_PARENT_SYSOSC	20
BOARD	MII_CLKOUT	21
BOARD	TIMO0	22
BOARD	TIMO1	23
BOARD	TIMO_PARENT_TIMER64_0L	24
BOARD	TIMO_PARENT_TIMER64_0H	25
BOARD	TIMO_PARENT_TIMER64_1L	26
BOARD	TIMO_PARENT_TIMER64_1H	27
BOARD	TIMO_PARENT_TIMER64_2L	28
BOARD	TIMO_PARENT_TIMER64_2H	29
BOARD	TIMO_PARENT_TIMER64_3L	30
BOARD	TIMO_PARENT_TIMER64_3H	31
BOARD	TIMO_PARENT_TIMER64_4L	32
BOARD	TIMO_PARENT_TIMER64_4H	33
BOARD	TIMO_PARENT_TIMER64_5L	34
BOARD	TIMO_PARENT_TIMER64_5H	35

Device Reset IDs

Hardware Block Name	Reset Name	Reset ID
CGEM0	DSP0_RESET	0x1