84 lines
12 KiB
HTML
Executable file
84 lines
12 KiB
HTML
Executable file
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
|
|
<title>
|
|
dp v1_0
|
|
</title>
|
|
<link href="$DriverApiDocsCssPath" rel="stylesheet" type="text/css">
|
|
</head>
|
|
<h3 class="PageHeader">Xilinx Processor IP Library</h3>
|
|
<hl>Software Drivers</hl>
|
|
<hr class="whs1">
|
|
<!-- Generated by Doxygen 1.4.7 -->
|
|
<div class="tabs">
|
|
<ul>
|
|
<li id="current"><a href="index.html"><span>Main Page</span></a></li>
|
|
<li><a href="annotated.html"><span>Classes</span></a></li>
|
|
<li><a href="files.html"><span>Files</span></a></li>
|
|
</ul></div>
|
|
<h1>dp v1_0</h1>
|
|
<p>
|
|
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.<p>
|
|
The Xilinx DisplayPort soft IP supports the following features:<ul>
|
|
<li>1, 2, or 4 lanes.</li><li>A link rate of 1.62, 2.70, or 5.40Gbps per lane.</li><li>1, 2, or 4 pixel-wide video interfaces.</li><li>RGB and YCbCr color space.</li><li>Up to 16 bits per component.</li><li>Up to 4Kx2K monitor resolution.</li><li>Auto lane rate and width negotiation.</li><li>I2C over a 1Mb/s AUX channel.</li><li>Secondary channel audio support (2 channels).</li><li>4 independent video multi-streams.</li></ul>
|
|
<p>
|
|
The Xilinx DisplayPort soft IP does not support the following features:<ul>
|
|
<li>The automated test feature.</li><li>Audio (3-8 channel).</li><li>FAUX.</li><li>Bridging function.</li><li>MST audio.</li><li>eDP optional features.</li><li>iDP.</li><li>GTC.</li></ul>
|
|
<p>
|
|
<b>DisplayPort overview</b><p>
|
|
A DisplayPort link consists of:<ul>
|
|
<li>A unidirectional main link which is used to transport isochronous data streams such as video and audio. The main link may use 1, 2, or 4 lanes at a link rate of 1.62, 2.70, or 5.40Gbps per lane. The link needs to be trained prior to sending streams.</li><li>An auxiliary (AUX) channel is a 1MBps bidirectional channel used for link training, link management, and device control.</li><li>A hot-plug-detect (HPD) signal line is used to determine whether a DisplayPort connection exists between the DisplayPort TX connector and an RX device. It is serves as an interrupt request by the RX device.</li></ul>
|
|
<p>
|
|
<b>Device configuration</b><p>
|
|
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.<p>
|
|
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.<p>
|
|
<b>Driver description</b><p>
|
|
The DisplayPort (DP) driver consists of functions, structures, and definitions: 1) Specific to the DisplayPort TX mode of operation.<ul>
|
|
<li>Prefix: XDp_Tx* and XDP_TX_* 2) Specific to the DisplayPort RX mode of operation.</li><li>Prefix: XDp_Rx* and XDP_RX_* 3) Common to both DisplayPort modes of operation.</li><li>Prefix: XDp_* and XDP_*</li></ul>
|
|
<p>
|
|
<b>Driver description: TX mode of operation</b><p>
|
|
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.<p>
|
|
This driver implements link layer functionality: a Link Policy Maker (LPM) and a Stream Policy Maker (SPM) as per the DisplayPort 1.2a specification.<ul>
|
|
<li>The LPM manages the main link and is responsible for keeping the link synchronized. It will establish a link with a downstream RX device by undergoing a link training sequence which consists of:<ul>
|
|
<li>Clock recovery: The clock needs to be recovered and PLLs need to be locked for all lanes.</li><li>Channel equalization: All lanes need to achieve channel equalization and and symbol lock, as well as for interlane alignment to take place.</li></ul>
|
|
</li><li>The SPM manages transportation of an isochronous stream. That is, it will initialize and maintain a video stream, establish a virtual channel to a sink monitor, and transmit the stream.</li></ul>
|
|
<p>
|
|
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.<p>
|
|
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.<p>
|
|
<b>Driver description: RX mode of operation</b><p>
|
|
The device driver enables higher-level software (e.g., an application) to configure and control a DisplayPort RX soft IP.<p>
|
|
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.<p>
|
|
Link training is done automatically by the hardware.<p>
|
|
<b>Interrupt processing: TX mode of operation</b><p>
|
|
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 <a class="el" href="xdp__intr_8c.html">xdp_intr.c</a>).<p>
|
|
<b>Interrupt processing: TX mode of operation</b><p>
|
|
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.<p>
|
|
The DisplayPort TX's XDP_TX_INTERRUPT_STATUS register indicates the type of interrupt that has occured, 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.<p>
|
|
The HPD event handler may be set up by using the XDp_TxSetHpdEventHandler function and, for the HPD pulse handler, the XDp_TxSetHpdPulseHandler function.<p>
|
|
<b>Interrupt processing: RX mode of operation</b><p>
|
|
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.<p>
|
|
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.<p>
|
|
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.<p>
|
|
The handlers are set up using the XDp_RxSetIntr* functions.<p>
|
|
Specific interrupts may be enabled or disabled using the XDp_RxInterruptEnable and XDp_RxInterruptDisable functions.<p>
|
|
<b>Multi-stream transport (MST) mode: TX mode of operation</b><p>
|
|
The current version of this driver doesn't support MST functionality when the core is configured do run in the RX mode of operation.<p>
|
|
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.<p>
|
|
MST testing has been done at all possible link rate/lane count/topology/ resolution/color depth combinations with each setting using following values:<ul>
|
|
<li>Link rate: 1.62, 2.70, and 5.40Gbps per lane.</li><li>Lane count: 1, 2, and 4 lanes.</li><li>Number of sink displays: 1, 2, 3, and 4 sink displays in both a daisy-chain configuration and in a configuration using a combination of a 1-to-3 hub and daisy-chain. Each stream was using the same resolution.</li><li>Resolutions (60Hz): 640x480, 800x600, 1024x768, 1280x800, 1280x1024, 1360x768, 1400x1050, 1680x1050, 1920x1080, 1920x2160, and 3840x2160.</li><li>Color depths: 18, 24, 30, 36, and 48 bits per pixel.</li></ul>
|
|
<p>
|
|
<b>Audio</b><p>
|
|
The 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.<p>
|
|
<b>Asserts</b><p>
|
|
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.<p>
|
|
<b>Limitations: TX mode of operation</b><p>
|
|
<ul>
|
|
<li>For MST mode to correctly display, the current version of the driver requires that each of the DisplayPort TX streams be allocated without skipping streams (i.e. assign stream 1, stream 2, and stream 3 - problems were experienced if skipping stream 2 and assigning stream 4 instead). skipping monitors in a daisy chain is OK as long as they are assigned to streams in order.</li><li>In MST mode, the current version of the driver does not support removal of an allocated stream from the virtual channel payload ID table without clearing the entire table.</li><li>Some sideband messages have not been implemented in the current version of the driver for MST mode. Notably, reception of a CONNECTION_STATUS_NOTIFY sideband message.</li><li>The driver does not handle audio. See the audio example in the driver examples directory for the required sequence for enabling audio.</li></ul>
|
|
<p>
|
|
<dl compact><dt><b>Note:</b></dt><dd>For a 5.4Gbps link rate, a high performance 7 series FPGA is required with a speed grade of -2 or -3.</dd></dl>
|
|
<pre>
|
|
MODIFICATION HISTORY:</pre><p>
|
|
<pre> Ver Who Date Changes
|
|
----- ---- -------- -----------------------------------------------
|
|
1.0 als 01/20/15 Initial release.
|
|
</pre> Copyright @ 1995-2014 Xilinx, Inc. All rights reserved.
|