 |
dp
Xilinx SDK Drivers API Documentation
|
|
dp
Xilinx SDK Drivers API Documentation
|
The Xilinx DisplayPort transmitter (DP) driver. This driver supports the Xilinx DisplayPort soft IP core in both transmit/source (TX) and receive/sink (RX) modes of operation.
The Xilinx DisplayPort soft IP supports the following features:
The Xilinx DisplayPort soft IP does not support the following features:
DisplayPort overview
A DisplayPort link consists of:
Device configuration
The device can be configured in various ways during the FPGA implementation process. Configuration parameters are stored in the xdp_g.c file which is generated when compiling the board support package (BSP). A table is defined where each entry contains configuration information for the DisplayPort instances present in the system. This information includes parameters that are defined in the driver's data/dp.tcl file such as the base address of the memory-mapped device and the maximum number of lanes, maximum link rate, and video interface that the DisplayPort instance supports, among others.
The DisplayPort core may be configured in both transmitter (TX) or receiver (RX) modes of operation. Depending on which mode of operation the hardware is configured for, the set of registers associated with the core will be different.
Driver description
The DisplayPort (DP) driver consists of functions, structures, and definitions: 1) Specific to the DisplayPort TX mode of operation.
Driver description: TX mode of operation
The device driver enables higher-level software (e.g., an application) to configure and control a DisplayPort TX soft IP, communicate and control an RX device/sink monitor over the AUX channel, and to initialize and transmit data streams over the main link. This driver follows the DisplayPort 1.2a specification.
This driver implements link layer functionality: a Link Policy Maker (LPM) and a Stream Policy Maker (SPM) as per the DisplayPort 1.2a specification.
Using AUX transactions to read/write from/to the sink's DisplayPort Configuration Data (DPCD) address space, the LPM obtains the link capabilities, obtains link configuration and link and sink status, and configures and controls the link and sink. The main link is trained this way.
I2C-over-AUX transactions are used to obtain the sink's Extended Display Identification Data (EDID) which give information on the display capabilities of the monitor. The SPM may use this information to determine what available screen resolutions and video timing are possible.
Driver description: RX mode of operation
The device driver enables higher-level software (e.g., an application) to configure and control a DisplayPort RX soft IP.
This driver gives applications the ability to configure the RX using various settings, handle and issue interrupts, and modify a subset of its DisplayPort Configuration Data (DPCD) fields.
Link training is done automatically by the hardware.
Interrupt processing
For the driver to process interrupts, the application must set up the system's interrupt controller and connect the XDp_InterruptHandler function to service interrupts. When an interrupt occurs, XDp_InterruptHandler will check which mode of operation the DisplayPort core is running in, and will call the appropriate interrupt handler for that core (XDp_TxInterruptHandler or XDp_RxInterruptHandler - local to xdp_intr.c).
Interrupt processing: TX mode of operation
DisplayPort interrupts occur on the HPD signal line when the DisplayPort cable is connected/disconnected or when the RX device sends a pulse. The user hardware design must contain an interrupt controller which the DisplayPort TX instance's interrupt signal is connected to. The user application must enable interrupts in the system and set up the interrupt controller such that the XDp_TxHpdInterruptHandler handler will service DisplayPort interrupts. When the XDp_TxHpdInterruptHandler function is invoked, the handler will identify what type of DisplayPort interrupt has occurred, and will call either the HPD event handler function or the HPD pulse handler function, depending on whether a an HPD event on an HPD pulse event occurred.
The DisplayPort TX's XDP_TX_INTERRUPT_STATUS register indicates the type of interrupt that has occurred, and the XDp_TxInterruptHandler will use this information to decide which handler to call. An HPD event is identified if bit XDP_TX_INTERRUPT_STATUS_HPD_EVENT_MASK is set, and an HPD pulse is identified from the XDP_TX_INTERRUPT_STATUS_HPD_PULSE_DETECTED_MASK bit.
The HPD event handler may be set up by using the XDp_TxSetHpdEventHandler function and, for the HPD pulse handler, the XDp_TxSetHpdPulseHandler function.
Interrupt processing: RX mode of operation
The DisplayPort RX driver may generate a pulse on the hot-plug-detect (HPD) signal line using the XDp_RxGenerateHpdInterrupt function. This allows the RX to send an interrupt to the upstream TX device, useful for signaling the TX that it needs to do some checks for changes in downstream devices or a loss of link training.
For RX interrupt handling of HPD events or events that happen internal to the RX, the user hardware design must contain an interrupt controller which the DisplayPort RX instance's interrupt signal is connected to. The user application must enable interrupts in the system and set up the interrupt controller such that the XDp_RxInterruptHandler handler will service interrupts. When the XDp_RxInterruptHandler function is invoked, the handler will identify what type of interrupt has occurred, and will call the appropriate interrupt handler.
The DisplayPort RX's XDP_RX_INTERRUPT_CAUSE register indicates the type of interrupt that has occured, and the XDp_RxInterruptHandler will use this information to decide which handler to call.
The handlers are set up using the XDp_RxSetIntr* functions.
Specific interrupts may be enabled or disabled using the XDp_RxInterruptEnable and XDp_RxInterruptDisable functions.
Multi-stream transport (MST) mode: TX mode of operation
The driver handles MST mode functionality in TX mode of operation, including sideband messaging, topology discovery, virtual channel payload ID table management, and directing streams to different sinks.
MST testing has been done at all possible link rate/lane count/topology/ resolution/color depth combinations with each setting using following values:
Multi-stream transport (MST) mode: RX mode of operation
The driver handles MST mode functionality in RX mode of operation. The API function, XDp_RxHandleDownReq, will read a sideband message from the down request registers in the DisplayPort RX core, parse it, arbitrate control for the sideband message type that was requested, format a reply, and send the reply.
The current version of the driver only supports a software representation of a shallow topology - meaning virtual sinks are defined in the user application and assigned to port numbers. The RX acts as a branch connected to multiple sinks, but is not connected to another branch. Sideband messages will then be handled for the targeted downstream sink.
The user application creates the topology using the driver's API functions:
The driver will keep track of the topology in the structures:
Note that the driver uses the topology's XDp_RxPort[] array such that the indices match the port number that attaches the virtual sink to the RX branch.
The following sideband messages are supported:
Audio
The driver in RX mode of operation may received audio info and extension packets. When this happens, if interrupts are enabled, the appropriate handlers will be invoked. Control functions are available for enabling, disabling, and resetting audio in the DisplayPort RX core.
The TX driver does not handle audio. For an example as to how to configure and transmit audio, examples/xdptx_audio_example.c illustrates the required sequence in the TX mode of operation. The user will need to configure the audio source connected to the Displayport TX instance and set up the audio info frame as per user requirements.
Asserts
Asserts are used within all Xilinx drivers to enforce constraints on argument values. Asserts can be turned off on a system-wide basis by defining, at compile time, the NDEBUG identifier. By default, asserts are turned on and it is recommended that application developers leave asserts on during development.
Limitations: TX mode of operation
Limitations: RX mode of operation
MODIFICATION HISTORY:
Ver Who Date Changes
----- ---- -------- -----------------------------------------------
1.0 als 01/20/15 Initial release. TX code merged from the dptx driver.
2.0 als 06/08/15 Added MST functionality to RX. New APIs:
XDp_RxHandleDownReq, XDp_RxGetIicMapEntry,
XDp_RxSetIicMapEntry, XDp_RxSetDpcdMap,
XDp_RxMstExposePort, XDp_RxMstSetPort,
XDp_RxMstSetInputPort, XDp_RxMstSetPbn,
XDp_RxSetIntrDownReqHandler,
XDp_RxSetIntrDownReplyHandler,
XDp_RxSetIntrAudioOverHandler,
XDp_RxSetIntrPayloadAllocHandler,
XDp_RxSetIntrActRxHandler,
XDp_RxSetIntrCrcTestHandler
Added Intr*Handler and Intr*CallbackRef interrupt-related
members to XDp_Rx structure for:
DownReq, DownReply, AudioOver, PayloadAlloc, ActRx,
CrcTest
Added new data structures related to RX MST topology:
XDp_RxIicMapEntry, XDp_RxDpcdMap, XDp_RxPort,
XDp_RxTopology
Renamed XDp_Tx* to XDp_* to reflect commonality with RX
for:
XDp_TxSbMsgLinkAddressReplyPortDetail
XDp_TxSbMsgLinkAddressReplyDeviceInfo
GUID type change for ease of use:
'u32 Guid[4]' changed to 'u8 Guid[16]'
Added handlers and setter functions for HDCP and unplug
events.
Added callbacks for lane count changes, link rate changes
and pre-emphasis + voltage swing adjust requests.
3.0 als 10/07/15 Added MSA callback.