world leader in high performance signal processing
Trace: » adv7393


The ADV7393 is a new 10-bit Video Encoder Analog Devices makes. Supported Video Standards are Standard Definition (SD) PAL/NTSC an High Definition (HD) 720p, 1080p, 1080i, etc. Supported input formats are 16-bit RGB565 besides the typical 8-bit, 16-bit YCbCr 4:2:2. For further information please consult the ADV7393 datasheet.

This driver as today only supports SD PAL and NTSC.

Please see table below for supported Video Modes:

NTSC 720×480 Y
NTSC 640×480 Y Experimental
PAL 720×576 Y
PAL 640×480 Y Experimental

Adding ADV7393 Driver Support

Kernel Options

Graphics support

<M> Support for frame buffer devices
[ ]   Enable Video Mode Handling Helpers
[ ]   Enable Tile Blitting Support
< >   Blackfin ADI7171 video encoder on uClinux
<M>   Blackfin ADV7393 Video encoder on uClinux
    Video mode support (NTSC 720x480)  --->
    Size of ADV7393 frame buffer memory Single/Double Size (Single)  --->
< > SHARP LQ035 TFT LCD on uClinux (BF537 STAMP)
< > Epson S1D13XXX framebuffer support
< > Virtual Frame Buffer support (ONLY FOR TESTING!)
    Logo configuration  --->
[ ] Backlight & LCD device support  --->

Kernel Configuration for TWI/I2C support

<*> I2C support
< >   I2C device interface
      I2C Algorithms  --->
      I2C Hardware Bus support  --->
      Miscellaneous I2C Chip support  --->
[ ]   I2C Core debugging messages
[ ]   I2C Algorithm debugging messages
[ ]   I2C Bus debugging messages
[ ]   I2C Chip debugging messages

I2C Hardware Bus support

For BF533 or BF561

<*> Generic Blackfin and HHBF533/561 development board I2C support
    BFIN I2C SDA/SCL Selection  --->

For BF534, BF536 or BF537

<*> Blackfin TWI I2C support
(50)  TWI clock (kHZ)
< > Parallel port adapter (light)
< > I2C/SMBus Test Stub
< > PCA9564 on an ISA bus

Module Parameters


0 NTSC 720×480
1 PAL 720×576
2 NTSC 640×480
3 PAL 640×480

Some applications do write directly to the screen. If you’re using such a application ,and are unable to draw everything quick enough, you will see so called “tearing”. This occurs because you are able to see half of the last frame, and half of the current frame at the same time.

In these situation you can use double buffering. This technique involves two screen buffers. One that gets written to the Video Codec, and one that the application writes into. Linux SDL (Simple DirectMedia Layer) uses this technique.

If you want to allow double buffering or screen panning use mem=2.


1 Single Sized Frame Buffer Memory
2 Double Sized Frame Buffer Memory

Loading the ADV7393 framebuffer driver as kernel module

Loading the bfin_adv7393fb kernel module PAL 720x576

root:~> modprobe bfin_adv7393fb mode=1 mem=1
Using /lib/modules//
Using /lib/modules//
bfin_adv7393_fb: initializing: PAL 720x576
dma_alloc_init: dma_page @ 0x003e5000 - 512 pages at 0x03e00000
adv7393.c: starting probe for adapter bfin-twi-i2c(0x0)
adv7393.c: detecting adv7393 client on address 0x56
fb0: BFIN ADV7393 frame buffer device
fb memory address : 0x03e00000

Removing the bfin_adv7393fb kernel module

root:~> modprobe -r bfin_adv7393fb

Loading the bfin_adv7393fb kernel module NTSC 720x480 - Double Sized Frame Buffer

root:~> modprobe bfin_adv7393fb mode=0 mem=2
Using /lib/modules//
Using /lib/modules//
bfin_adv7393_fb: initializing: NTSC 720x480
adv7393.c: starting probe for adapter bfin-twi-i2c(0x0)
adv7393.c: detecting adv7393 client on address 0x56
fb0: BFIN ADV7393 frame buffer device
fb memory address : 0x03e00000

Testing the bfin_adv7393fb kernel module

root:~> jpegview -s1000 /var/FuBK-Testbild_720x480.jpg
720 480 720 960 0 0 16 0 -1 -1
framebase = 0x3e00000 err=0
ImageWidth=720 ImageHeight=480
read /var/FuBK-Testbild_720x480.jpg OK

Driver Architecture

The driver is designed to operate with ZERO overhead to the Blackfin Processor Core. During normal operation it doesn’t generate any interrupts – it therefore utilizes the extended DMA capabilities a Blackfin Processor provides

This is work in progress - please expect some more text in the future … -Michael

Descriptor-based DMA Operation In descriptor-based DMA operation, software does not set up DMA sequences by writing directly into DMA controller registers. Rather, software keeps DMA configurations, called descriptors, in memory. On demand, the DMA controller loads the descriptor from memory and overwrites the affected DMA registers by its own control. Descriptors can be fetched from L1 memory or from external memory. To minimize the external memory bus load – this driver stores descriptor in internal L1 memory.

A descriptor describes what kind of operation should be performed next by the DMA channel. This includes the DMA configuration word as well as data source/destination address, transfer count, and address modify values. A DMA sequence controlled by one descriptor is called a work unit.

For more information see here : dma_systems

More Information