Driver

The DisplayPort IP requires a processor to setup the core. This can be any processor. A DisplayPort driver (prt_dp_drv) is provided for this task. It is plain C with no operating system or vendor library behind it, so it ports to whatever core sits next to the IP.

Each IP-core carries its own policy maker, and that policy maker runs the firmware for the DisplayPort protocol itself: hot plug detect, EDID, DPCD, link training and the link. This is what makes the core autonomous, and it is the main reason for having it. The protocol keeps running on the policy maker's own timers and interrupts, so the application processor is free of the low level DisplayPort work. It decides what it wants, such as starting a video stream, and hears what came of it through the callbacks.

The application processor loads that firmware into the policy maker at start up, and from then on the two communicate through a mailbox, exchanging the tokens defined in prt_dp_tokens.h. Most API functions are such an exchange: they send a token to the policy maker and wait for its answer. For the same reason a few are asynchronous: prt_dp_sta returns right away and its values arrive a moment later, in the status callback.

One prt_dp_ds_struct describes one IP-core, so either the transmitter or the receiver. A design with both keeps two of them and passes the right one to every call, which is also how the API is split: shared functions, transmitter functions and receiver functions.

The IP-core raises an interrupt when the policy maker has sent mail. prt_dp_irq_handler belongs in that interrupt. It decodes the message and calls the matching callback straight away, so a callback runs in interrupt context and should be kept short.

An IP-core is brought up in this order. The reference design shows it in full.

prt_dp_set_base (&dptx, DPTX_BASE_ADDR);      // find the IP-core
                                              // hook prt_dp_irq_handler to its interrupt
prt_dp_rom_init (&dptx, rom_len, rom);        // load the policy maker firmware
prt_dp_ram_init (&dptx, ram_len, ram);
prt_dp_init     (&dptx, PRT_DPTX_ID);

prt_dp_set_cb   (&dptx, PRT_DP_CB_HPD, &dptx_hpd_cb);
prt_dp_set_cb   (&dptx, PRT_DP_CB_LNK, &dp_lnk_cb);
/* ... the other callbacks ... */

prt_dp_lic      (&dptx, lic);                 // license key
prt_dp_ping     (&dptx);                      // is the policy maker alive?
prt_dp_cfg      (&dptx);                      // apply the configuration

API

This section provides information about the driver API. The functions are grouped the same way as in prt_dp_drv.h: shared functions that apply to both IP-cores, followed by the transmitter and receiver functions.

Shared

Transmitter

Receiver

Callbacks

The callback functions are used by the driver to signal the application about an event. Functions are registered using the prt_dp_set_cb function. The driver decodes the mail from the policy maker in prt_dp_mail_dec, which runs from prt_dp_irq_handler, and calls the handler from there. A handler therefore runs in interrupt context and should be kept short: note what happened and leave the work to the main loop. The handler names below are the ones used in the reference design. The diagram shows the DP states and the callbacks that follow from them.

Figure 1: DP callbacks