TI81XX PSP HDMI Driver User Guide

DM816x AM389x DM814x AM387x HDMI User Guide

Linux PSP

IMPORTANT

TI81XX refers to TI816X, TI814X and TI813X.

Read This First

This section show the major updates since last release, please review this section before any SW activities.

• HDMI driver is supported for DM813X(DM385 called in other places) family.

Introduction

HDMI (High Definition Multimedia Interface) is an interface used to transport un-compressed audio / video digital data (along with other control signals). HDMI IP on above class of SoCs implements HDMI Standard Specification 1.3A. Software is not certified for any specifications or compliance. A source is device that generates video / audio content (such as DM816X, DM814x PC, DVD Player, etc…) and sink is a device that consumes the same (such as TV, Monitor, LCD, etc…)

HDMI is controlled transparently from the application through the sysfs entries exposed by the VPSS driver for controlling the displays. HDMI also exposes IOCTLs through standard Linux character driver interface. Control through character driver interface is limited. Users are encouraged to use the sysfs entries for controlling the HDMI like changing of resolution, getting the status like hot plug etc. All of the sysfs entries are explained in later part of the document.

HDMI driver is exposed as the /dev/TI81XX_HDMI under the standard Linux file system and is provide as the Linux loadable module along with the Linux PSP package. HDMI can't be compiled with kernel. It should always be a loadable module. Firmware needs to be loaded using the slave loader before inserting the HDMI Linux module.

Upgrade and Compatibility

Linux character driver interface was provided for the HDMI in all of the earlier releases. Now HDMI is controlled transparently through video driver VPSS sysfs entries. Details about the same is given in the later part of the document. Limited control is provided through the character driver interface. Application using the HDMI will have to now use the SYSFS entries to get the HDMI control. Following are the new features added compared to previous release of the HDMI

• Transperent control of HDMI using the Video driver (VPSS) SYSFS entries.
• Reading of EDID from the sink device
• Hot Plug Detect(HPD) status information.

Build TI81xx on-chip HDMI driver

• Enable TI81xx HDMI in menuconfig

$ make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- ti8168_evm_defconfig
$ make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- menuconfig

select Device Drivers

   Userspace binary formats  --->  
   Power management options  --->                                   
   [*] Networking support  --->     
 " Device Drivers  --->    "
   CBUS support  --->       
   File systems  --->                                               

select graphics support:

   Multifunction device drivers  --->                        
   [ ] Voltage and Current Regulator Support  --->                    
   < > Multimedia support  --->                                    
 " Graphics support  --->     "                  
   <*> Sound card support  ---> 
   [*] HID Devices  --->        

Select TI81XX HDMI Driver Module (EXPERIMENTAL)

   < > Fujitsu MB862xx GDC support        
   < > E-Ink Broadsheet/Epson S1D13521 controller support      
   < > OMAP frame buffer support (EXPERIMENTAL)       
 " <M> TI81XX HDMI Driver Module (EXPERIMENTAL)  ---->"
   < > TI81XX Video Processing Subsystem (EXPERIMENTAL)  ---> 
   [ ] Backlight & LCD device support  --->      

Build Kernel Modules

$ make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- modules

Features Supported

Character driver Interface

Support standard Linux character driver control (IOCTL) to provide following features

• Start / Stop HDMI
• Read EDID from the connected Sink
• Query status like hot plug detect, driver started etc.

SYSFS interface

Support standard sysfs to provide following features

• Set the display mode. Supported modes are 1080P60, 1080P30, 1080I60 and 720P60
• Start / stop HDMI
• Read sinks EDID information and display small string

Note :Changing of the resolution on HDMI also requires changing the resolution on encoder. Encoder needs to be disabled before changing the resolution on HDMI. Further all the connected display/graphics path on that Encoder needs to be stopped.

Features not verified

In this release, following features are not supported

• Deep color mode of operation

Supported System Calls

Supported standard system calls are

• open () - To open an instance of HDMI device driver
• close () - To close an instance of HDMI device driver
• ioctl () - To control the driver operations.

Module Parameter

HDMI driver module when 'insmod' can disable/enable the debug logs using the switch debug=0/1

Supported display modes

• 1080P60
• 1080I60
• 720P60
• 1080P30

Application Interface

• open

• Standard character drivers open call, the mode flags of the call is ignored by the driver.

• close

• Standard character drivers close call.

• ioctl

• TI81XXHDMI_GET_STATUS- Get current status, whether streaming or not, whether a sync detected or not.
• TI81XXHDMI_START- Used to turn ON streaming / start display
• TI81XXHDMI_STOP - Used to turn OFF streaming / stop display
• TI81XXHDMI_READ_EDID - Used to read the EDID of the HDMI sync.

Dependencies

• Pixel Clock

• The pixel clock is provided by the VIDEO PLL module, this modules has to be configured to meet the pixel rate required for given resolution. Its beyond the scope of this driver to configure this. If this driver is used along with HDVPSS driver provided by TI, HDVPSS driver ensure that pixel clock is configured for the chosen resolution. The resolution selected on HDMI should match with resolution configured of DISPLAY Driver. (In case of FBDEV, inserting the drivers/modules and connecting graphics pipeline to appropriate VENC does this. Please refer FBDEV user guide for details)

• Discrete Syncs only

• HDMI expects the VENC to provide discrete syncs
• HDMI driver with default configuration, expects the VENC to provide video data in RGB color space in either 24 bits/pixel or 30 bits/pixel

Typical Sequence

Load the Modules in the following order.

• Load VPSS module, (This module configures and starts the display 0 VENC in 1080p-60 mode.) :

 insmod vpss.ko 

• Load fbdev module :

 insmod ti81xxfb.ko

• Load on-chip HDMI module :

 insmod ti81xxhdmi.ko 

To change the mode of the Encoder on which HDMI is connected as well as of the HDMI

• Disable Venc

 echo 0 > /sys/devices/platform/vpss/display0/enabled

• Change mode

 echo 720p-60 > /sys/devices/platform/vpss/display0/mode

• Enable Venc

 echo 1 > /sys/devices/platform/vpss/display0/enabled

• Example to configure the HDMI driver and start streaming of fbdev output through on-chip HDMI is explained in the application saFbdevHdmiDisplay.c

• VPSS Video User guide at [| DM814X VPSS VideoUserGuide][| DM816X VPSS VideoUserGuide]

• Before changing the mode in the HDMI driver user needs to set the PLL clock and Venc mode accordingly. This is explained at VPSS Video User Guide shown in above.

EDID

Reading of the EDID from the sink is supported through character driver interface using TI81XXHDMI_READ_EDID. Basic information from the EDID is also displayed as a part of the sysfs entry. The following is the sysfs entry for reading the basic information from EDID

 cat /sys/devices/platform/vpss/display0/edid

TI81XX HDMI Audio Support

Note: TI81XX HDMI audio features are supported from PSP_04.00.01.13 Release onwards. Please Make sure that all VPSS modules [| TI81XX VPSS VideoUserGuide]are inserted and HDMI Video is enable before testing audio

All the sample rate and audio formats depends on the HDMI TV's capabilities.

Features

This section describes the features supported by ALSA SoC HDMI Audio driver.

• Supports HDMI audio codec on TI81XX in ALSA SoC framework.
• Multiple sample rates support (32KHz, 44.1KHz, 48KHz, 96KHz and 192KHz )playback.
• Supports audio 16bit and 24bit (S16_LE ,S24_LE) audio format.
• Supports audio in stereo mode.

Configuration

Note: HDMI audio feature is not be enabled in the default kernel configurations. You have to explicitly enable it by following the steps given bellow

To enable/disable hdmi audio support, start the Linux Kernel Configuration tool:

$ make menuconfig 

Select Device Drivers from the main menu.

    ...
    ...
    Power management options --->
    [ ] Networking support --->
    Device Drivers --->
    File systems --->
    Kernel hacking --->
    ...
    ...

Select Sound card support as shown here:

    ...
    ...
    Multimedia devices --->
    Graphics support --->
<*> Sound card support --->
[*] HID Devices --->
[*] USB support --->
    ...
    ...

Select Advanced Linux Sound Architecture as shown here:

--- Sound card support
<*> Advanced Linux Sound Architecture --->
< > Open Sound System (DEPRECATED) --->

Select ALSA for SoC audio support as shown here:

    ...
    ...
[*] ARM sound devices --->
[*] SPI sound devices --->
<*> ALSA for SoC audio support --->

For TI816x, select On-chip HDMI audio support for TI81XX EVM as shown here:

--- ALSA for SoC audio support
<*> SoC Audio for the TI81XX chip
<*> SoC Audio support for TI81XX EVM
<*> On-chip HDMI audio support for TI81XX EVM
< > Build all ASoC CODEC drivers (NEW)

Note: Soc Audio support for TI81XX EVM option appears if SoC Audio for the TI816X chips is selected Note: Currently TI814x menu options appear with TI81XX instead of TI816x mentioned here.

Note: Only TI816X PG2.0 silicon supports Auto Mode configurations and the rest all are is using the Software/Manual Mode for generate the ACR packets.

HDMI Auto Mode Configuration

In Auto – mode. An audio clock is provided to HDMI controller, N value is programmed and CTS is computed automatically by the HDMI core. ACR packets are sent out periodically to the Rx using the following relation: MCLK=(128 or 256)*Fs = TMDS*N/CTS

TI816X PG2.0 and higher supports Auto Mode by using the McBSP clock as the HDMI input MCLK. The MCLK frequency need to programs according to the Audio sampling rate requirements. The parent clock must not be used for any other modules. User can modify the parent clock by changing the a macro in the HDMI Audio driver and recompile the kernel to achieve this.

Modify the parent clock selection in the corresponding board file to use a different clock source for HDMI MCLK

TI8168

• arch/arm/mach-omap2/board-ti8168evm.c Clock sources [sysclk20, sysclk21, sysclk21, CLKS(external)].

TI8148

• arch/arm/mach-omap2/board-ti8148evm.cClock sources [sysclk20, sysclk21, sysclk21].

TI813X

• arch/arm/mach-omap2/board-dm385evm.c Clock sources [sysclk20, sysclk21, sysclk21].

/* modify the clk name from list to use different clk source */
parent = clk_get(NULL, "sysclk22_ck");/

Note: The clock source used for HDMI should not be used or shared with any other module.

Load On-Chip HDMI Module

On-Chip HDMI hardware is controlled through another kernel driver, which should be loaded after vpss.ko is loaded in order to work the HDMI audio. Please refer [#Load_On-Chip_HDMI_Module | HDMI user guide]for details.

Prerequisites

1. syslink kernel driver module, referred as "syslink.ko"
2. loader user space program, referred as "slaveloader"
3. M3 BIOS Firmware binary, referred as "ti816x_hdvpss.xem3"
4. VPSS kernel driver module, referred as "vpss.ko"
5. FBDev kernel driver module, referred as "ti81xxfb.ko"
6. V4L2 display kernel module, referred as "ti81xxvo.ko"
7. On-Chip HDMI kernel module, referred as "ti81xxhdmi.ko"

TI814X Please use the following firmware for ti814x

1. M3 BIOS Firmware binary, referred as "ti814x_hdvpss_512M or ti814x_hdvpss_1G.xem3"

Note: notifyk.vpssm3_sva=0xA0000000 must be added to the bootargs.It is required to use syslink notify driver in kernel. This address is valid for DM816X/AM389X platforms. Refer [TI81XX VPSS VideoUserGuide [1]] for more details. For ti814x_hdvpss_1G.xem3 use notifyk.vpssm3_sva=0xA0000000 must be added to the bootargs

• Load VPSS and HDMI Module

$ insmod syslink.ko
$ ./slaveloader startup VPSS-M3 ti816x_hdvpss.xem3 
$ insmode vpss.ko 
$ insmod ti81xxfb.ko
$ insmod ti81xxvo.ko
$ insmod ti81xxhdmi.ko

Enable HDMI Display

• Disable Venc

 echo 0 > /sys/devices/platform/vpss/display0/enabled

• Select mode

 echo 720p-60 > /sys/devices/platform/vpss/display0/mode

• Enable Venc

 echo 1 > /sys/devices/platform/vpss/display0/enabled

Note: Available audio sample rate support depends upon the pixel clock frequency, the video format timing, and whether or not content protection re-synchronization is needed. Please restart the audio while changing the video resolution. Refer the Feature list for the supported video resolution and audio sampling rate.

ALSA commands

Display ALSA devices

 $ aplay -l 

 **** List of PLAYBACK Hardware Devices ****
   card 0: EVM [TI81XX EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 card 0: EVM [TI81XX EVM], device 1: hdmi HDMI-DAI-CODEC-1 []
   Subdevices: 1/1
   Subdevice #0: subdevice #0

Audio Playback Test

  $ aplay -Dhw:0,1 <filename>

Amixer commands

ALSA mixer commands are not supported by the Hardware.

Note: ALSA softvol plug-in can be used for user level volume control Please find the usage in ALSA wiki http://alsa.opensrc.org/Softvol

User Space Interactions

This section depicts the sequence of operations for a simple playback.

Sample Applications

This chapter describes the audio sample applications provided along with the package. The source for these sample applications are available in the Examples directory of the Release Package folder.

Introduction

Writing an audio application involves the following steps:

• Opening the audio device
• Set the parameters of the device
• Receive audio data from the device or deliver audio data to the device
• Close the device

These steps are explained in detail in this section.

Note
User space ALSA libraries can be downloaded from this link http://www.alsa-project.org/main/index.php/Download. User needs to build and install them before he starts using the ALSA based applications.

A minimal playback application

This program opens an audio interface for playback, configures it for stereo, 16 bit, 44.1kHz, interleaved conventional read/write access. Then its delivers a chunk of random data to it, and exits. It represents about the simplest possible use of the ALSA Audio API, and isn't meant to be a real program.

Opening the audio device

To write a simple PCM application for ALSA, we first need a handle for the PCM device. Then we have to specify the direction of the PCM stream, which can be either playback or capture. We also have to provide some information about the configuration we would like to use, like buffer size, sample rate, pcm data format. So, first we declare:

#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>

#define BUFF_SIZE 4096

int main (int argc, char *argv[])
{
  int err;
  short buf[BUFF_SIZE];
  int rate = 44100; /* Sample rate */
  unsigned int exact_rate; /* Sample rate returned by */
  /* Handle for the PCM device */
  snd_pcm_t *playback_handle;
  /* Playback stream */
  snd_pcm_stream_t stream = SND_PCM_STREAM_PLAYBACK;
  /* This structure contains information about the hardware and can be used to specify the configuration to be used for */
  /* the PCM stream. */
  snd_pcm_hw_params_t *hw_params;

The most important ALSA interfaces to the PCM devices are the "plughw" and the "hw" interface. If you use the "plughw" interface, you need not care much about the sound hardware. If your sound card does not support the sample rate or sample format you specify, your data will be automatically converted. This also applies to the access type and the number of channels. With the "hw" interface, you have to check whether your hardware supports the configuration you would like to use. Otherwise, user can use the default interface for playback by:

  /* Name of the PCM device, like plughw:0,0 */
  /* The first number is the number of the soundcard, the second number is the number of the device.  HDMI codec is detected as 2nd device*/

  static char *device = "plughw:0,1"; /* playback device */

Now we can open the PCM device:

  /* Open PCM. The last parameter of this function is the mode. */
  if ((err = snd_pcm_open (&playback_handle, device, stream, 0)) < 0) {
    fprintf (stderr, "cannot open audio device (%s)\n", snd_strerror (err));
    exit (1);
  }

Setting the parameters of the device

Now we initialize the variables and allocate the hwparams structure:

  /* Allocate the snd_pcm_hw_params_t structure on the stack. */
  if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0) {
    fprintf (stderr, "cannot allocate hardware parameters (%s)\n", snd_strerror (err));
    exit (1);
  }

Before we can write PCM data to the soundcard, we have to specify access type, sample format, sample rate, number of channels, number of periods and period size. First, we initialize the hwparams structure with the full configuration space of the soundcard:

  /* Init hwparams with full configuration space */
  if ((err = snd_pcm_hw_params_any (playback_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot initialize hardware parameter structure (%s)\n", snd_strerror (err));
    exit (1);
  }

Now configure the desired parameters. For this example, we assume that the soundcard can be configured for stereo playback of 16 Bit Little Endian data, sampled at 44100 Hz. Therefore, we restrict the configuration space to match this configuration only. The access type specifies the way in which multi-channel data is stored in the buffer. For INTERLEAVED access, each frame in the buffer contains the consecutive sample data for the channels. For 16 Bit stereo data, this means that the buffer contains alternating words of sample data for the left and right channel.

  /* Set access type. */
  if ((err = snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0) {
    fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set sample format */
  if ((err = snd_pcm_hw_params_set_format (playback_handle, hw_params, SND_PCM_FORMAT_S16_LE)) < 0) {
    fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set sample rate. If the exact rate is not supported by the hardware, use nearest possible rate. */
  exact_rate = rate;
  if ((err = snd_pcm_hw_params_set_rate_near (playback_handle, hw_params, &exact_rate, 0)) < 0) {
    fprintf (stderr, "cannot set sample rate (%s)\n", snd_strerror (err));
    exit (1);
  }

  if (rate != exact_rate) {
    fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n ==> Using %d Hz instead.\n", rate, exact_rate);
  }

  /* Set number of channels */
  if ((err = snd_pcm_hw_params_set_channels (playback_handle, hw_params, 2)) < 0) {
    fprintf (stderr, "cannot set channel count (%s)\n", snd_strerror (err));
    exit (1);
  }

Now we apply the configuration to the PCM device pointed to by pcm_handle and prepare the PCM device.

  /* Apply HW parameter settings to PCM device and prepare device. */
  if ((err = snd_pcm_hw_params (playback_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot set parameters (%s)\n", snd_strerror (err));
    exit (1);
  }

  snd_pcm_hw_params_free (hw_params);

  if ((err = snd_pcm_prepare (playback_handle)) < 0) {
    fprintf (stderr, "cannot prepare audio interface for use (%s)\n", snd_strerror (err));
    exit (1);
  }

Writing data to the device

After the PCM device is configured, we can start writing PCM data to it. The first write access will start the PCM playback. For interleaved write access, we use the function:

  /* Write some junk data to produce sound. */
  if ((err = snd_pcm_writei (playback_handle, buf, BUFF_SIZE/2)) != BUFF_SIZE/2) {
    fprintf (stderr, "write to audio interface failed (%s)\n", snd_strerror (err));
    exit (1); 
  } else {
    fprintf (stdout, "snd_pcm_writei successful\n");
  }

After the PCM playback is started, we have to make sure that our application sends enough data to the soundcard buffer. Otherwise, a buffer under-run will occur. After such an under-run has occurred, snd_pcm_prepare should be called.

Closing the device

After the data has been transferred, the device needs to be closed by calling:

  snd_pcm_close (playback_handle);

  exit (0);
}

HDMI CEC

CEC stands for Consumer Electronics Control and is a feature of HDMI. CEC provides high-level control functions of HDMI connected devices, that would allow single device to control functionality of devices on the CEC network.

Consider a HDMI TV that’s connected to a set-top-box (STB), assuming that they are connected via HDMI and supports CEC.
Some of the key features of CEC are...

• One Touch Play – Allows a device to be played become the active source with a single button press.
  
• System Standby – Allows all devices to go stand-by with one button press.
  
• On touch record – Offers What You See Is What You Record, meaning that current content being displayed on TV is recorded with on button press.
  
• etc...
  

Features

• Available as a standard character driver (at /dev/TI81XX_HDMI) and each of the following feature is supported as device control call.
  
• Control to get CEC block out of by-pass mode - When CEC feature is not desired the application could, simply ignore CEC feature by not making any control call. By default, the CEC block will be by-pass mode, ignoring all the CEC messages. Applications that require to use CEC feature should explicitly enable CEC by calling control TI81XXHDMI_CEC_ACTIVATE.
  
• Receive CEC messages – A control command could be used to received both directed and broadcast messages. Applications are expected to use control TI81XXHDMI_CEC_RECEIVE_MSG to receive directed and / or broadcast messages.
  
• Register the device in CEC n/w – A control command to registers the device with CEC n/w The CEC protocol requires all devices to be registered as one of the supported device types. A device could be registered with control command TI81XXHDMI_CEC_REG_DEV.
  
• Transmit CEC messages – A control command to transmit a CEC message on the CEC n/w. Provides ability for auto-retransmission, in case first attempt does not succeed.
  

• Auto re-transmit - Provide ability to perform auto re-transmit of a given CEC message. Useful when CEC n/w is highly loaded or slow devices in the CEC n/w.
  

Configurations / Interface

• The interface file is available at include/linux/ti81xxhdmi.h
  
• Activate HDMI-CEC block - TI81XXHDMI_CEC_ACTIVATE

Activates the CEC block of HDMI, this should be first CEC call. Its recommended that HDMI interface is streaming video before any CEC calls.

• Receive CEC messages - TI81XXHDMI_CEC_RECEIVE_MSG
  

Once the HDMI-CEC is activated, the CEC blocks would receive broadcast and directed messages. The received messages are placed in an internal hardware queue, in the order of reception. The depth of this queue is 3, if received messages count is > 3, the queue would be over-written. The oldest message would be lost (along with its operands) and there is no way to recover the same.

For, every TI81XXHDMI_CEC_RECEIVE_MSG command, the driver would check if there are messages in the received queue, if so, it would retrieve the oldest message from queue, making space to receive new message. The received messages are placed in structure of type ti81xxhdmi_cec_received_msg.

When there are no more messages in the queue, an error value of EAGAIN is returned.

Its recommended that, applications polls to check if there are messages received every 2 milliseconds. This will ensure messages are not lost.

• Register device in CEC n/w - TI81XXHDMI_CEC_REG_DEV
  

Once the CEC block is activated, application can receive CEC messages, but cannot respond to messages / generate messages until the device is registered on the CEC n/w.

Once the HDMI-CEC is activated, the applications are expected to register the device with the CEC n/w. This can be achieved through ioctl TI81XXHDMI_CEC_REG_DEV.

A given device could be registered as device with multiple capabilities, e.g. a SetTopBox could registers be registered as a playback device and as well as a recorder device. The valid range is between 0 – 15, 0 – the root node of the CEC n/w typically a TV.

Once the device is registered, the physical address of the port (to which this device is connected via HDMI) is returned to the applications. This address would required as operands for some of the CEC messages.

If the device registration fails for a specific device type, the device could assume a logical address of 14 – free use logical address.

To transmit messages, the device should be registered in the CEC network, failing which the all the functionalities of CEC will not be met.

There are no explicit procedures to un-register a device from the CEC n/w.

• Transmit Messages - TI81XXHDMI_CEC_TRANSMIT_MSG -

Once a device is registered as a valid device in the CEC n/w, the device could transmit messages (either broadcast / unicast messages). The applications are expected to use TI81XXHDMI_CEC_TRANSMIT_MSG control command to transmit messages.

If the driver succeeds in transmitting the messages a return value of 0x0, indicates the same.

Its expected that the struct ti81xxhdmi_cec_transmit_msg.initiator will hold the device identifier that was registered. No check is performed by the driver to enforce the same.

The transmission could fail, when the destination device do not acknowledge the transmit command (it could be that, the destination was device busy), the driver attempts for re-transmit before giving up the transmission. Number of such re-attempts are configurable on per message basis.

The driver does not validate the command and/or its arguments. It’s up to the application to ensure appropriate arguments are passed for a given command.

PING – Is a special command, using which the applications query if a device at given destination address present or not.

Configurations / Interface

A Sink should be connected – Its recommended that applications ensure a sink is connected (use ioctl TI81XXHDMI_GET_STATUS), before attempting any CEC operations.

Demo application / Typical application flow

The sample application referenced here is not available in current (September 2013) public software releases. It exists, but you need to ask your TI representative about it. Reference this thread on the TI E2E forum: Location of sample HDMI CEC application in DM8168 PSP?

The sample application demonstrates the use of CEC. This applications demonstrates how to
1. Get the CEC device out of bypass mode
2. Register the device with CEC n/w (as a playback 1 device)
3. Transmit messages to request TV to display the screen name for the device, switch to active source, among others
4. Receives both broad cast and directed messages, responds to couple of mandatory messages and abort for others.

The Application consists of two threads, one thread display color bars via the FBDEV driver / HDMI driver and other task is for the CEC. In this we will take a closer look at the CEC thread.
The main function creates these two threads, opens HDMI driver and waits CEC thread to complete. When CEC thread completes, the main function would check if there was a TV / Sink connected, if so, it would re-create these two threads.

Open the HDMI driver

Activate the CEC block of HDMI

Register as “play back 1” device, if this is taken or registration fails, registers as an “un-registered device”

Check if sink is connected

Check if there are messages to be read

Decode the received message

Respond to following messages with indicated response.

Give physical address

Report the discovered physical address, received when device is registered.

Get CEC version

Report CEC version

Give power status

Report Powered up

Give OSD name

Report desired name

Others

Abort to indicate to originator that we cannot service this request.

If no messages (This step done only once)

Send CEC message “Active Source” and “Image View ON”

If no sink, indicate the same and exit.

FAQ

Q. How do I select an external clock (either of MCA[2]_AFSX or MCA[2]_AHCLKR) as HDMI clock source in auto-CTS mode for TI8168?

A. Follow below steps

• Select external clock as HDMI source in register CM_AUDIOCLK_McBSP_CLKSEL.
• Configure pinmux register to select CLKS functionality. Note select only one pinmux register for CLKS function and the other should not select. E.g. if MCA[2]_AHCLKR is desired for the clock source then configure pinmux register PINCTRL149 (offset=0x48140A50) for CLKS and configure pinmux register PINCTRL153(offset=0x48140A60) to NOT select CLKS.