Page 1
i.MX 6SoloLite Linux Reference
Manual
Document Number: IMXL6SLRM
Rev L3.0.35_4.1.0, 09/2013
Page 2
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
2 Freescale Semiconductor, Inc.
Page 3
Contents
Section number Title Page
Chapter 1
About This Book
1.1 Audience.........................................................................................................................................................................17
1.1.1 Conventions.......................................................................................................................................................17
1.1.2 Definitions, Acronyms, and Abbreviations........................................................................................................17
Chapter 2
Introduction
2.1 Overview.........................................................................................................................................................................21
2.1.1 Software Base....................................................................................................................................................21
2.1.2 Features..............................................................................................................................................................22
Chapter 3
Machine Specific Layer (MSL)
3.1 Introduction.....................................................................................................................................................................27
3.2 Interrupts (Operation).....................................................................................................................................................28
3.2.1 Interrupt Hardware Operation............................................................................................................................28
3.2.2 Interrupt Software Operation.............................................................................................................................28
3.2.3 Interrupt Features...............................................................................................................................................29
3.2.4 Interrupt Source Code Structure........................................................................................................................29
3.2.5 Interrupt Programming Interface.......................................................................................................................29
3.3 Timer...............................................................................................................................................................................30
3.3.1 Timer Software Operation.................................................................................................................................30
3.3.2 Timer Features...................................................................................................................................................30
3.3.3 Timer Source Code Structure.............................................................................................................................31
3.3.4 Timer Programming Interface............................................................................................................................31
3.4 Memory Map..................................................................................................................................................................31
3.4.1 Memory Map Hardware Operation....................................................................................................................31
3.4.2 Memory Map Software Operation.....................................................................................................................31
3.4.3 Memory Map Features.......................................................................................................................................31
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 3
Page 4
Section number Title Page
3.4.4 Memory Map Source Code Structure................................................................................................................32
3.4.5 Memory Map Programming Interface...............................................................................................................32
3.5 IOMUX...........................................................................................................................................................................32
3.5.1 IOMUX Hardware Operation............................................................................................................................33
3.5.2 IOMUX Software Operation..............................................................................................................................33
3.5.3 IOMUX Features................................................................................................................................................34
3.5.4 IOMUX Source Code Structure.........................................................................................................................34
3.5.5 IOMUX Programming Interface........................................................................................................................34
3.5.6 IOMUX Control Through GPIO Module..........................................................................................................34
3.5.6.1 GPIO Hardware Operation.................................................................................................................35
3.5.6.1.1 Muxing Control.................................................................................................................35
3.5.6.1.2 PULLUP Control..............................................................................................................35
3.5.6.2 GPIO Software Operation (general)..................................................................................................35
3.5.6.3 GPIO Implementation........................................................................................................................35
3.5.6.4 GPIO Source Code Structure.............................................................................................................36
3.5.6.5 GPIO Programming Interface............................................................................................................36
3.6 General Purpose Input/Output(GPIO)............................................................................................................................36
3.6.1 GPIO Software Operation..................................................................................................................................36
3.6.1.1 API for GPIO.....................................................................................................................................37
3.6.2 GPIO Features....................................................................................................................................................37
3.6.3 GPIO Module Source Code Structure................................................................................................................37
3.6.4 GPIO Programming Interface 2.........................................................................................................................38
Chapter 4
Smart Direct Memory Access (SDMA) API
4.1 Overview.........................................................................................................................................................................39
4.1.1 Hardware Operation...........................................................................................................................................39
4.1.2 Software Operation............................................................................................................................................39
4.1.3 Source Code Structure.......................................................................................................................................40
4.1.4 Menu Configuration Options.............................................................................................................................41
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
4 Freescale Semiconductor, Inc.
Page 5
Section number Title Page
4.1.5 Programming Interface......................................................................................................................................41
4.1.6 Usage Example..................................................................................................................................................41
Chapter 5
Electrophoretic Display Controller (EPDC) Frame Buffer Driver
5.1 Introduction.....................................................................................................................................................................43
5.2 Hardware Operation........................................................................................................................................................44
5.3 Software Operation.........................................................................................................................................................44
5.3.1 EPDC Frame Buffer Driver Overview...............................................................................................................44
5.3.2 EPDC Frame Buffer Driver Extensions.............................................................................................................45
5.3.3 EPDC Panel Configuration................................................................................................................................45
5.3.3.1 Boot Command Line Parameters.......................................................................................................46
5.3.4 EPDC Waveform Loading.................................................................................................................................47
5.3.4.1 Using a Default Waveform File.........................................................................................................47
5.3.4.2 Using a Custom Waveform File.........................................................................................................48
5.3.5 EPDC Panel Initialization..................................................................................................................................48
5.3.6 Grayscale Framebuffer Selection.......................................................................................................................49
5.3.7 Enabling An EPDC Splash Screen.....................................................................................................................49
5.4 Source Code Structure ...................................................................................................................................................50
5.5 Menu Configuration Options..........................................................................................................................................51
5.6 Programming Interface...................................................................................................................................................51
5.6.1 IOCTLs/Functions.............................................................................................................................................52
5.6.2 Structures and Defines.......................................................................................................................................55
Chapter 6
Sipix Display Controller (SPDC) Frame Buffer Driver
6.1 Introduction.....................................................................................................................................................................57
6.2 Hardware Operation........................................................................................................................................................58
6.3 Software Operation.........................................................................................................................................................58
6.3.1 SPDC Frame Buffer Driver Overview...............................................................................................................58
6.3.2 SPDC Frame Buffer Driver Extensions.............................................................................................................59
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 5
Page 6
Section number Title Page
6.3.3 SPDC Panel Configuration................................................................................................................................59
6.3.3.1 Boot Command Line Parameters.......................................................................................................60
6.3.4 SPDC Waveform Loading.................................................................................................................................60
6.3.4.1 Using a Default Waveform File.........................................................................................................61
6.3.4.2 Using a Custom Waveform File.........................................................................................................61
6.3.5 SPDC Panel Initialization..................................................................................................................................62
6.3.6 Grayscale Framebuffer Selection.......................................................................................................................62
6.4 Source Code Structure ...................................................................................................................................................63
6.5 Menu Configuration Options..........................................................................................................................................64
6.6 Programming Interface...................................................................................................................................................64
6.6.1 IOCTLs/Functions.............................................................................................................................................65
6.6.2 Structures and Defines.......................................................................................................................................68
Chapter 7
Pixel Pipeline (PxP) DMA-ENGINE Driver
7.1 Introduction.....................................................................................................................................................................71
7.2 Hardware Operation........................................................................................................................................................71
7.3 Software Operation.........................................................................................................................................................71
7.3.1 Key Data Structs................................................................................................................................................71
7.3.2 Channel Management........................................................................................................................................72
7.3.3 Descriptor Management.....................................................................................................................................72
7.3.4 Completion Notification....................................................................................................................................72
7.3.5 Limitations.........................................................................................................................................................73
7.4 Menu Configuration Options..........................................................................................................................................73
7.5 Source Code Structure....................................................................................................................................................73
Chapter 8
ELCDIF Frame Buffer Driver
8.1 Introduction.....................................................................................................................................................................75
8.2 Hardware Operation........................................................................................................................................................75
8.3 Software Operation.........................................................................................................................................................75
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
6 Freescale Semiconductor, Inc.
Page 7
Section number Title Page
8.4 Menu Configuration Options..........................................................................................................................................76
8.5 Source Code Structure....................................................................................................................................................76
Chapter 9
Graphics Processing Unit (GPU)
9.1 Introduction.....................................................................................................................................................................77
9.1.1 Driver Features...................................................................................................................................................77
9.1.1.1 Hardware Operation...........................................................................................................................77
9.1.1.2 Software Operation............................................................................................................................78
9.1.1.3 Source Code Structure ......................................................................................................................78
9.1.1.4 Library Structure ...............................................................................................................................78
9.1.1.5 API References..................................................................................................................................80
9.1.1.6 Menu Configuration Options.............................................................................................................80
Chapter 10
High-Definition Multimedia Interface (HDMI)
10.1 Introduction.....................................................................................................................................................................81
10.2 Software Operation.........................................................................................................................................................81
10.2.1 Hotplug Handling and Video Mode Changes....................................................................................................81
10.3 Source Code Structure....................................................................................................................................................82
10.3.1 Linux Menu Configuration Options...................................................................................................................83
10.4 Unit Test..........................................................................................................................................................................83
10.4.1 Video..................................................................................................................................................................83
10.4.2 Audio..................................................................................................................................................................84
Chapter 11
X Windows Acceleration
11.1 Introduction.....................................................................................................................................................................85
11.2 Hardware Operation........................................................................................................................................................85
11.3 Software Operation.........................................................................................................................................................85
11.3.1 X Windows Acceleration Architecture..............................................................................................................86
11.3.2 i.MX 6 Driver for X-Windows System..............................................................................................................87
11.3.3 xorg.conf for i.MX 6..........................................................................................................................................89
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 7
Page 8
Section number Title Page
11.3.4 Setup X-Windows System Acceleration............................................................................................................90
Chapter 12
Camera Sensor Interface (CSI) Driver
12.1 Hardware Operation........................................................................................................................................................93
12.2 Software Operation.........................................................................................................................................................93
12.2.1 CSI Software Operation.....................................................................................................................................94
12.2.2 Video for Linux 2 (V4L2) APIs.........................................................................................................................94
12.2.2.1 V4L2 Capture Device........................................................................................................................94
12.2.2.2 Use of the V4L2 Capture APIs..........................................................................................................95
12.3 Source Code Structure....................................................................................................................................................95
12.4 Linux Menu Configuration Options................................................................................................................................96
12.5 Programming Interface...................................................................................................................................................96
Chapter 13
OV5640 Using parallel interface
13.1 Hardware Operation........................................................................................................................................................97
13.2 Software Operation.........................................................................................................................................................97
13.3 Source Code Structure....................................................................................................................................................98
13.4 Linux Menu Configuration Options................................................................................................................................98
Chapter 14
Low-level Power Management (PM) Driver
14.1 Hardware Operation........................................................................................................................................................99
14.1.1 Software Operation............................................................................................................................................99
14.1.2 Source Code Structure.......................................................................................................................................100
14.1.3 Menu Configuration Options.............................................................................................................................100
14.1.4 Programming Interface......................................................................................................................................101
14.1.5 Unit Test.............................................................................................................................................................101
Chapter 15
PF100 Regulator Driver
15.1 Introduction.....................................................................................................................................................................103
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
8 Freescale Semiconductor, Inc.
Page 9
Section number Title Page
15.2 Hardware Operation........................................................................................................................................................103
15.2.1 Driver Features...................................................................................................................................................104
15.3 Software Operation.........................................................................................................................................................104
15.3.1 Regulator APIs...................................................................................................................................................104
15.4 Driver Architecture.........................................................................................................................................................106
15.4.1 Driver Interface Details......................................................................................................................................107
15.4.2 Source Code Structure.......................................................................................................................................107
15.4.3 Menu Configuration Options.............................................................................................................................107
Chapter 16
CPU Frequency Scaling (CPUFREQ) Driver
16.1 Introduction.....................................................................................................................................................................109
16.1.1 Software Operation............................................................................................................................................109
16.1.2 Source Code Structure.......................................................................................................................................110
16.2 Menu Configuration Options..........................................................................................................................................110
16.2.1 Board Configuration Options.............................................................................................................................111
Chapter 17
Dynamic Voltage Frequency Scaling (DVFS) Driver
17.1 Introduction.....................................................................................................................................................................113
17.1.1 Operation............................................................................................................................................................113
17.1.2 Software Operation............................................................................................................................................113
17.1.3 Source Code Structure.......................................................................................................................................114
17.2 Menu Configuration Options..........................................................................................................................................114
17.2.1 Board Configuration Options.............................................................................................................................114
Chapter 18
Thermal Driver
18.1 Introduction.....................................................................................................................................................................115
18.1.1 Thermal Driver Overview..................................................................................................................................115
18.2 Hardware Operation........................................................................................................................................................115
18.2.1 Thermal Driver Software Operation..................................................................................................................116
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 9
Page 10
Section number Title Page
18.3 Driver Features................................................................................................................................................................116
18.3.1 Source Code Structure.......................................................................................................................................116
18.3.2 Menu Configuration Options.............................................................................................................................116
18.3.3 Programming Interface......................................................................................................................................116
18.3.4 Interrupt Requirements......................................................................................................................................117
18.4 Unit Test..........................................................................................................................................................................117
Chapter 19
Anatop Regulator Driver
19.1 Introduction.....................................................................................................................................................................119
19.1.1 Hardware Operation...........................................................................................................................................119
19.2 Driver Features................................................................................................................................................................120
19.2.1 Software Operation............................................................................................................................................120
19.2.2 Regulator APIs...................................................................................................................................................120
19.2.3 Driver Interface Details......................................................................................................................................121
19.2.4 Source Code Structure.......................................................................................................................................121
19.2.5 Menu Configuration Options.............................................................................................................................121
Chapter 20
SNVS Real Time Clock (SRTC) Driver
20.1 Introduction.....................................................................................................................................................................123
20.1.1 Hardware Operation...........................................................................................................................................123
20.2 Software Operation.........................................................................................................................................................123
20.2.1 IOCTL................................................................................................................................................................123
20.2.2 Keeping Alive in the Power Off State...............................................................................................................124
20.3 Driver Features................................................................................................................................................................124
20.3.1 Source Code Structure.......................................................................................................................................125
20.3.2 Menu Configuration Options.............................................................................................................................125
Chapter 21
Advanced Linux Sound Architecture (ALSA) System on a Chip (ASoC) Sound Driver
21.1 ALSA Sound Driver Introduction...................................................................................................................................127
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
10 Freescale Semiconductor, Inc.
Page 11
Section number Title Page
21.2 SoC Sound Card .............................................................................................................................................................130
21.2.1 Stereo CODEC Features....................................................................................................................................130
21.2.2 Sound Card Information.....................................................................................................................................130
21.3 Hardware Operation........................................................................................................................................................131
21.3.1 Stereo Audio CODEC........................................................................................................................................131
21.4 Software Operation.........................................................................................................................................................132
21.4.1 ASoC Driver Source Architecture.....................................................................................................................132
21.4.2 Sound Card Registration....................................................................................................................................132
21.4.3 Device Open.......................................................................................................................................................133
21.4.4 Platform Data.....................................................................................................................................................133
21.4.5 Menu Configuration Options.............................................................................................................................134
21.5 Unit Test..........................................................................................................................................................................134
21.5.1 Stereo CODEC Unit Test...................................................................................................................................134
Chapter 22
SPI NOR Flash Memory Technology Device (MTD) Driver
22.1 Introduction.....................................................................................................................................................................137
22.1.1 Hardware Operation...........................................................................................................................................137
22.1.2 Software Operation............................................................................................................................................138
22.1.3 Driver Features...................................................................................................................................................138
22.1.4 Source Code Structure.......................................................................................................................................138
22.1.5 Menu Configuration Options.............................................................................................................................139
Chapter 23
MMC/SD/SDIO Host Driver
23.1 Introduction.....................................................................................................................................................................141
23.1.1 Hardware Operation...........................................................................................................................................141
23.1.2 Software Operation............................................................................................................................................142
23.2 Driver Features................................................................................................................................................................144
23.2.1 Source Code Structure.......................................................................................................................................145
23.2.2 Menu Configuration Options.............................................................................................................................145
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 11
Page 12
Section number Title Page
23.2.3 Platform Data.....................................................................................................................................................146
23.2.4 Programming Interface......................................................................................................................................146
23.2.5 Loadable Module Operations.............................................................................................................................147
Chapter 24
Inter-IC (I2C) Driver
24.1 Introduction.....................................................................................................................................................................149
24.1.1 I2C Bus Driver Overview..................................................................................................................................149
24.1.2 I2C Device Driver Overview.............................................................................................................................150
24.1.3 Hardware Operation...........................................................................................................................................150
24.2 Software Operation.........................................................................................................................................................150
24.2.1 I2C Bus Driver Software Operation...................................................................................................................150
24.2.2 I2C Device Driver Software Operation.............................................................................................................151
24.3 Driver Features................................................................................................................................................................151
24.3.1 Source Code Structure.......................................................................................................................................152
24.3.2 Menu Configuration Options.............................................................................................................................152
24.3.3 Programming Interface......................................................................................................................................152
24.3.4 Interrupt Requirements......................................................................................................................................152
Chapter 25
Enhanced Configurable Serial Peripheral Interface (ECSPI) Driver
25.1 Introduction.....................................................................................................................................................................155
25.1.1 Hardware Operation...........................................................................................................................................155
25.2 Software Operation.........................................................................................................................................................156
25.2.1 SPI Sub-System in Linux...................................................................................................................................156
25.2.2 Software Limitations..........................................................................................................................................157
25.2.3 Standard Operations...........................................................................................................................................157
25.2.4 ECSPI Synchronous Operation..........................................................................................................................158
25.3 Driver Features................................................................................................................................................................160
25.3.1 Source Code Structure.......................................................................................................................................160
25.3.2 Menu Configuration Options.............................................................................................................................160
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
12 Freescale Semiconductor, Inc.
Page 13
Section number Title Page
25.3.3 Programming Interface......................................................................................................................................160
25.3.4 Interrupt Requirements......................................................................................................................................161
Chapter 26
ARC USB Driver
26.1 Introduction.....................................................................................................................................................................163
26.1.1 Architectural Overview......................................................................................................................................163
26.2 Hardware Operation........................................................................................................................................................164
26.2.1 Software Operation............................................................................................................................................164
26.2.2 Source Code Structure.......................................................................................................................................165
26.2.3 Menu Configuration Options.............................................................................................................................166
26.2.4 Programming Interface......................................................................................................................................169
26.3 System WakeUp..............................................................................................................................................................169
26.3.1 USB Wakeup usage...........................................................................................................................................169
26.3.2 How to Enable USB WakeUp System Ability...................................................................................................169
26.3.3 WakeUp Events Supported by USB..................................................................................................................170
26.3.4 How to Close the USB Child Device Power......................................................................................................171
Chapter 27
Fast Ethernet Controller (FEC) Driver
27.1 Introduction.....................................................................................................................................................................173
27.2 Hardware Operation........................................................................................................................................................173
27.2.1 Software Operation............................................................................................................................................176
27.2.2 Source Code Structure.......................................................................................................................................176
27.2.3 Menu Configuration Options.............................................................................................................................176
27.3 Programming Interface...................................................................................................................................................177
27.3.1 Device-Specific Defines....................................................................................................................................177
27.3.2 Getting a MAC Address.....................................................................................................................................178
Chapter 28
Universal Asynchronous Receiver/Transmitter (UART) Driver
28.1 Introduction.....................................................................................................................................................................179
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 13
Page 14
Section number Title Page
28.2 Hardware Operation........................................................................................................................................................180
28.2.1 Software Operation............................................................................................................................................180
28.2.2 Driver Features...................................................................................................................................................181
28.2.3 Source Code Structure.......................................................................................................................................181
28.3 Configuration..................................................................................................................................................................182
28.3.1 Menu Configuration Options.............................................................................................................................182
28.3.2 Source Code Configuration Options..................................................................................................................183
28.3.3 Chip Configuration Options...............................................................................................................................183
28.3.4 Board Configuration Options.............................................................................................................................183
28.4 Programming Interface...................................................................................................................................................183
28.4.1 Interrupt Requirements......................................................................................................................................183
Chapter 29
Pulse-Width Modulator (PWM) Driver
29.1 Introduction.....................................................................................................................................................................185
29.1.1 Hardware Operation...........................................................................................................................................185
29.1.2 Clocks.................................................................................................................................................................186
29.1.3 Software Operation............................................................................................................................................187
29.1.4 Driver Features...................................................................................................................................................187
29.1.5 Source Code Structure.......................................................................................................................................187
29.1.6 Menu Configuration Options.............................................................................................................................188
Chapter 30
Watchdog (WDOG) Driver
30.1 Introduction.....................................................................................................................................................................189
30.1.1 Hardware Operation...........................................................................................................................................189
30.1.2 Software Operation............................................................................................................................................189
30.2 Generic WDOG Driver...................................................................................................................................................190
30.2.1 Driver Features...................................................................................................................................................190
30.2.2 Menu Configuration Options.............................................................................................................................190
30.2.3 Source Code Structure.......................................................................................................................................190
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
14 Freescale Semiconductor, Inc.
Page 15
Section number Title Page
30.2.4 Programming Interface......................................................................................................................................191
Chapter 31
OProfile
31.1 Introduction.....................................................................................................................................................................193
31.1.1 Overview............................................................................................................................................................193
31.1.2 Features..............................................................................................................................................................193
31.1.3 Hardware Operation...........................................................................................................................................194
31.2 Software Operation.........................................................................................................................................................194
31.2.1 Architecture Specific Components....................................................................................................................194
31.2.2 oprofilefs Pseudo Filesystem.............................................................................................................................195
31.2.3 Generic Kernel Driver........................................................................................................................................195
31.2.4 OProfile Daemon...............................................................................................................................................195
31.2.5 Post Profiling Tools...........................................................................................................................................196
31.3 Requirements..................................................................................................................................................................196
31.3.1 Source Code Structure.......................................................................................................................................196
31.3.2 Menu Configuration Options.............................................................................................................................196
31.3.3 Programming Interface......................................................................................................................................197
31.3.4 Interrupt Requirements......................................................................................................................................197
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 15
Page 16
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
16 Freescale Semiconductor, Inc.
Page 17
Chapter 1
About This Book
1.1 Audience
This document is targeted to individuals who will port the i.MX Linux BSP to customerspecific products.
The audience is expected to have a working knowledge of the Linux 3.0 kernel internals,
driver models, and i.MX processors.
1.1.1 Conventions
This document uses the following notational conventions:
• Courier monospaced type indicate commands, command parameters, code examples,
and file and directory names.
• Italic type indicates replaceable command or function parameters.
• Bold type indicates function names.
1.1.2 Definitions, Acronyms, and Abbreviations
The following table defines the acronyms and abbreviations used in this document.
Definitions and Acronyms
Term Definition
ADC Asynchronous Display Controller
address
translation
API Application Programming Interface
®
ARM
Freescale Semiconductor, Inc. 17
Address conversion from virtual domain to physical domain
Advanced RISC Machines processor architecture
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Page 18
Audience
Term Definition
AUDMUX Digital audio MUX-provides a programmable interconnection for voice, audio, and synchronous data routing
between host serial interfaces and peripheral serial interfaces
BCD Binary Coded Decimal
bus A path between several devices through data lines
bus load The percentage of time a bus is busy
CODEC Coder/decoder or compression/decompression algorithm-used to encode and decode (or compress and
decompress) various types of data
CPU Central Processing Unit-generic term used to describe a processing core
CRC Cyclic Redundancy Check-Bit error protection method for data communication
CSI Camera Sensor Interface
DFS Dynamic Frequency Scaling
DMA Direct Memory Access-an independent block that can initiate memory-to-memory data transfers
DPM Dynamic Power Management
DRAM Dynamic Random Access Memory
DVFS Dynamic Voltage Frequency Scaling
EMI External Memory Interface-controls all IC external memory accesses (read/write/erase/program) from all the
masters in the system
Endian Refers to byte ordering of data in memory. Little endian means that the least significant byte of the data is
stored in a lower address than the most significant byte. In big endian, the order of the bytes is reversed
EPIT Enhanced Periodic Interrupt Timer-a 32-bit set and forget timer capable of providing precise interrupts at
regular intervals with minimal processor intervention
FCS Frame Checker Sequence
FIFO First In First Out
FIPS Federal Information Processing Standards-United States Government technical standards published by the
National Institute of Standards and Technology (NIST). NIST develops FIPS when there are compelling
Federal government requirements such as for security and interoperability but no acceptable industry
standards
FIPS-140 Security requirements for cryptographic modules-Federal Information Processing Standard 140-2(FIPS 140-2)
is a standard that describes US Federal government requirements that IT products should meet for Sensitive,
but Unclassified (SBU) use
Flash A non-volatile storage device similar to EEPROM, where erasing can be done only in blocks or the entire chip.
Flash path Path within ROM bootstrap pointing to an executable Flash application
Flush Procedure to reach cache coherency. Refers to removing a data line from cache. This process includes
cleaning the line, invalidating its VBR and resetting the tag valid indicator. The flush is triggered by a software
command
GPIO General Purpose Input/Output
hash Hash values are produced to access secure data. A hash value (or simply hash), also called a message
digest, is a number generated from a string of text. The hash is substantially smaller than the text itself, and is
generated by a formula in such a way that it is extremely unlikely that some other text produces the same hash
value.
I/O Input/Output
ICE In-Circuit Emulation
IP Intellectual Property
ISR Interrupt Service Routine
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
18 Freescale Semiconductor, Inc.
Page 19
Chapter 1 About This Book
Term Definition
JTAG JTAG (IEEE Standard 1149.1) A standard specifying how to control and monitor the pins of compliant devices
on a printed circuit board
Kill Abort a memory access
KPP KeyPad Port-16-bit peripheral used as a keypad matrix interface or as general purpose input/output (I/O)
line Refers to a unit of information in the cache that is associated with a tag
LRU Least Recently Used-a policy for line replacement in the cache
MMU Memory Management Unit-a component responsible for memory protection and address translation
MPEG Moving Picture Experts Group-an ISO committee that generates standards for digital video compression and
audio. It is also the name of the algorithms used to compress moving pictures and video
MPEG
standards
MQSPI Multiple Queue Serial Peripheral Interface-used to perform serial programming operations necessary to
NAND Flash Flash ROM technology-NAND Flash architecture is one of two flash technologies (the other being NOR) used
NOR Flash See NAND Flash
PCMCIA Personal Computer Memory Card International Association-a multi-company organization that has developed
physical
address
PLL Phase Locked Loop-an electronic circuit controlling an oscillator so that it maintains a constant phase angle (a
RAM Random Access Memory
RAM path Path within ROM bootstrap leading to the downloading and the execution of a RAM application
RGB The RGB color model is based on the additive model in which Red, Green, and Blue light are combined to
RGBA RGBA color space stands for Red Green Blue Alpha. The alpha channel is the transparency channel, and is
RNGA Random Number Generator Accelerator-a security hardware module that produces 32-bit pseudo random
ROM Read Only Memory
ROM
bootstrap
RTIC Real-Time Integrity Checker-a security hardware module
SCC SeCurity Controller-a security hardware module
SDMA Smart Direct Memory Access
SDRAM Synchronous Dynamic Random Access Memory
SoC System on a Chip
SPBA Shared Peripheral Bus Arbiter-a three-to-one IP-Bus arbiter, with a resource-locking mechanism
Several standards of compression for moving pictures and video:
• MPEG-1 is optimized for CD-ROM and is the basis for MP3
• MPEG-2 is defined for broadcast video in applications such as digital television set-top boxes and DVD
• MPEG-3 was merged into MPEG-2
• MPEG-4 is a standard for low-bandwidth video telephony and multimedia on the World-Wide Web
configure radio subsystems and selected peripherals
in memory cards such as the Compact Flash cards. NAND is best suited to flash devices requiring high
capacity data storage. NAND flash devices offer storage space up to 512-Mbyte and offers faster erase, write,
and read capabilities over NOR architecture
a standard for small, credit card-sized devices, called PC Cards. There are three types of PCMCIA cards that
have the same rectangular size (85.6 by 54 millimeters), but different widths
The address by which the memory in the system is physically accessed
lock) on the frequency of an input, or reference, signal
create other colors. The abbreviation RGB comes from the three primary colors in additive light models
unique to this color space. RGBA, like RGB, is an additive color space, so the more of a color placed, the
lighter the picture gets. PNG is the best known image format that uses the RGBA color space
numbers as part of the security module
Internal boot code encompassing the main boot flow as well as exception vectors
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 19
Page 20
Audience
Term Definition
SPI Serial Peripheral Interface-a full-duplex synchronous serial interface for connecting low-/medium-bandwidth
external devices using four wires. SPI devices communicate using a master/slave relationship over two data
lines and two control lines: Also see SS, SCLK, MISO, and MOSI
SRAM Static Random Access Memory
SSI Synchronous-Serial Interface-standardized interface for serial data transfer
TBD To Be Determined
UART Universal Asynchronous Receiver/Transmitter-asynchronous serial communication to external devices
UID Unique ID-a field in the processor and CSF identifying a device or group of devices
USB Universal Serial Bus-an external bus standard that supports high speed data transfers. The USB 1.1
specification supports data transfer rates of up to 12 Mb/s and USB 2.0 has a maximum transfer rate of 480
Mbps. A single USB port can be used to connect up to 127 peripheral devices, such as mice, modems, and
keyboards. USB also supports Plug-and-Play installation and hot plugging
USBOTG USB On The Go-an extension of the USB 2.0 specification for connecting peripheral devices to each other.
USBOTG devices, also known as dual-role peripherals, can act as limited hosts or peripherals themselves
depending on how the cables are connected to the devices, and they also can connect to a host PC
word A group of bits comprising 32-bits
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
20 Freescale Semiconductor, Inc.
Page 21
Chapter 2
Introduction
2.1 Overview
The i.MX family Linux Board Support Package (BSP) supports the Linux Operating
System (OS) on the following processor:
• i.MX 6SoloLite Applications Processor
The purpose of this software package is to support Linux on the i.MX 6SoloLite family
of Integrated Circuits (ICs) and their associated platforms. It provides the necessary
software to interface the standard open-source Linux kernel to the i.MX hardware. The
goal is to enable Freescale customers to rapidly build products based on i.MX devices
that use the Linux OS.
The BSP is not a platform or product reference implementation. It does not contain all of
the product-specific drivers, hardware-independent software stacks, Graphical User
Interface (GUI) components, Java Virtual Machine (JVM), and applications required for
a product. Some of these are made available in their original open-source form as part of
the base kernel.
The BSP is not intended to be used for silicon verification. While it can play a role in
this, the BSP functionality and the tests run on the BSP do not have sufficient coverage to
replace traditional silicon verification test suites.
2.1.1 Software Base
The i.MX BSP is based on version 3.0.35 of the Linux kernel from the official Linux
kernel web site (http://www.kernel.org ). It is enhanced with the features provided by
Freescale.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 21
Page 22
Overview
2.1.2 Features
Table below describes the features supported by the Linux BSP for specific platforms.
Table 2-1. Linux BSP Supported Features
Feature Description Chapter Source Applicable
Platform
Machine Specific Layer
MSL Machine Specific Layer (MSL) supports interrupts,
Timer, Memory Map, GPIO/IOMUX, SPBA, SDMA.
• Interrupts GIC: The linux kernel contains common
ARM GIC interrupts handling code.
• Timer (GPT): The General Purpose Timer (GPT)
is set up to generate an interrupt as programmed
to provide OS ticks. Linux facilitates timer use
through various functions for timing delays,
measurement, events, alarms, high resolution
timer features, and so on. Linux defines the MSL
timer API required for the OS-tick timer and does
not expose it beyond the kernel tick
implementation.
• GPIO/EDIO/IOMUX: The GPIO and EDIO
components in the MSL provide an abstraction
layer between the various drivers and the
configuration and utilization of the system,
including GPIO, IOMUX, and external board I/O.
The IO software module is board-specific, and
resides in the MSL layer as a self-contained set
of files. I/O configuration changes are centralized
in the GPIO module so that changes are not
required in the various drivers.
• SPBA: The Shared Peripheral Bus Arbiter
(SPBA) provides an arbitration mechanism
among multiple masters to allow access to the
shared peripherals. The SPBA implementation
under MSL defines the API to allow different
masters to take or release ownership of a shared
peripheral.
SDMA API The Smart Direct Memory Access (SDMA) API driver
controls the SDMA hardware. It provides an API to
other drivers for transferring data between MCU, DSP
and peripherals. . The SDMA controller is responsible
for transferring data between the MCU memory space,
peripherals, and the DSP memory space. The SDMA
API allows other drivers to initialize the scripts, pass
parameters and control their execution. SDMA is based
on a microRISC engine that runs channel-specific
scripts.
Low-level PM
Drivers
The low-level power management driver is responsible
for implementing hardware-specific operations to meet
power requirements and also to conserve power on the
Table continues on the next page...
Machine Specific Layer (MSL) All
Smart Direct Memory Access
(SDMA) API
Low-level Power Management
(PM) Driver
i.MX
6SoloLite
i.MX
6SoloLite
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
22 Freescale Semiconductor, Inc.
Page 23
Chapter 2 Introduction
Table 2-1. Linux BSP Supported Features (continued)
Feature Description Chapter Source Applicable
development platforms. Driver implementations are
often different for different platforms. It is used by the
DPM layer.
CPU Frequency
Scaling
DVFS The Dynamic Voltage Frequency Scaling (DVFS)
Multimedia Drivers
LCD The LCD interface driver supports the Samsung
EPDC The Electrophoretic Display Controller (EPDC) is a
SPDC SPDC is a direct-drive active matrix EPD controller
PxP The Pixel Pipeline (PxP) DMA-ENGINE driver provides
Sound Drivers
ALSA Sound The Advanced Linux Sound Architecture (ALSA) is a
Memory Drivers
SPI NOR MTD The SPI NOR MTD driver provides the support to the
Input Device Drivers
Networking Drivers
ENET The ENET Driver performs the full set of IEEE 802.3/
The CPU frequency scaling device driver allows the
clock speed of the CPUs to be changed on the fly.
device driver allows simple dynamic voltage frequency
scaling. The frequency of the core clock domain and
the voltage of the core power domain can be changed
on the fly with all modules continuing their normal
operations.
LMS430xx 4.3" WQVGA LCD panel.
direct-drive active matrix EPD controller designed to
drive E Ink EPD panels supporting a wide variety of
TFT backplanes.
designed to drive Sipix panel for E-Book application.
The SPDC provides control signals for the source driver
and gate drivers. This IP provides a high performance,
low cost solution for SiPix EPDs (Electronic Paper
Display).
a unique API, which are implemented as a dmaengine
client that smooths over the details of different
hardware offload engine implementations.
sound driver that provides ALSA and OSS compatible
applications with the means to perform audio playback
and recording functions. ALSA has a user-space
component called ALSAlib that can extend the features
of audio hardware by emulating the same in software
(user space), such as resampling, software mixing,
snooping, and so on. The ASoC Sound driver supports
stereo CODEC playback and capture through SSI.
Atmel data Flash using the SPI interface.
Ethernet CSMA/CD media access control and channel
interface functions. The FEC requires an external
interface adaptor and transceiver function to complete
Table continues on the next page...
CPU Frequency Scaling
(CPUFREQ) Driver
Dynamic Voltage Frequency
Scaling (DVFS) Driver
ELCDIF Frame Buffer Driver i.MX
Electrophoretic Display Controller
(EPDC) Frame Buffer
Sipix Display Controller (SPDC)
Frame Buffer
PXP DMA-ENGINE Driver i.MX
ALSA Sound Driver i.MX
SPI NOR Flash Memory
Technology Device (MTD) Driver
Fast Ethernet Controller (FEC)
Driver
i.MX
6SoloLite
i.MX
6SoloLite
6SoloLite
i.MX
6SoloLite
i.MX
6SoloLite
6SoloLite
6SoloLite
i.MX
6SoloLite
i.MX
6SoloLite
Platform
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 23
Page 24
Overview
Table 2-1. Linux BSP Supported Features (continued)
Feature Description Chapter Source Applicable
the interface to the Ethernet media. It supports half or
full-duplex operation on 10M\100M related Ethernet
networks.
Bus Drivers
I2C The I2C bus driver is a low-level interface that is used
to interface with the I2C bus. This driver is invoked by
the I2C chip driver; it is not exposed to the user space.
The standard Linux kernel contains a core I2C module
that is used by the chip driver to access the bus driver
to transfer data over the I2C bus. This bus driver
supports:
• Compatibility with the I2C bus standard
• Bit rates up to 400 Kbps
• Standard I2C master mode
• Power management features by suspending and
resuming I2C.
CSPI The low-level Enhanced Configurable Serial Peripheral
Interface (ECSPI) driver interfaces a custom, kernelspace API to both ECSPI modules. It supports the
following features:
• Interrupt-driven transmit/receive of SPI frames
• Multi-client management
• Priority management between clients
• SPI device configuration per client
MMC/SD/SDIO uSDHC
UART Drivers
MXC UART The Universal Asynchronous Receiver/Transmitter
General Drivers
USB The USB driver implements a standard Linux driver
WatchDog The Watchdog Timer module protects against system
MXC PWM driver The MXC PWM driver provides the interfaces to access
The MMC/SD/SDIO Host driver implements the
standard Linux driver interface to eSDHC.
(UART) driver interfaces the Linux serial driver API to
all of the UART ports. A kernel configuration parameter
gives the user the ability to choose the UART driver
and also to choose whether the UART should be used
as the system console.
interface to the ARC USB-OTG controller.
failures by providing an escape from unexpected hang
or infinite loop situations or programming errors. This
WDOG implements the following features:
• Generates a reset signal if it is enabled but not
serviced within a predefined time-out value
• Does not generate a reset signal if it is serviced
within a predefined time-out value
MXC PWM signals
Inter-IC (I2C) Driver i.MX
Enhanced Configurable Serial
Peripheral Interface (ECSPI) Driver
MMC/SD/SDIO Host Driver i.MX
Universal Asynchronous Receiver/
Transmitter (UART) Driver
ARC USB Driver i.MX
Watchdog (WDOG) Driver i.MX
Pulse-Width Modulator (PWM)
Driver
Platform
6SoloLite
i.MX
6SoloLite
6SoloLite
i.MX
6SoloLite
6SoloLite
6SoloLite
i.MX
6SoloLite
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
24 Freescale Semiconductor, Inc.
Page 25
Chapter 2 Introduction
Table 2-1. Linux BSP Supported Features (continued)
Feature Description Chapter Source Applicable
Thermal Driver Thermal driver is a necessary driver for monitoring and
protecting the SoC. The thermal driver will monitor the
SoC's temperature in a certain frequency. It defines
three trip points: critical, hot, and active.
OProfile OProfile is a system-wide profiler for Linux systems,
capable of profiling all running code at low overhead.
Thermal Driver i.MX
6SoloLite
OProfile i.MX
6SoloLite
Platform
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 25
Page 26
Overview
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
26 Freescale Semiconductor, Inc.
Page 27
Chapter 3
Machine Specific Layer (MSL)
3.1 Introduction
The Machine Specific Layer (MSL) provides the Linux kernel with the following
machine-dependent components:
• Interrupts including GPIO and EDIO (only on certain platforms)
• Timer
• Memory map
• General Purpose Input/Output (GPIO) including IOMUX on certain platforms
• Shared Peripheral Bus Arbiter (SPBA)
• Smart Direct Memory Access (SDMA)
These modules are normally available in the following directory:
<ltib_dir>/rpm/BUILD/linux/arch/arm/mach-mx6 for i.MX 6 platform
The header files are implemented under the following directory:
<ltib_dir>/rpm/BUILD/linux/arch/arm/plat-mxc/include/mach
The MSL layer contains not only the modules common to all the boards using the same
processor, such as the interrupts and timer, but it also contains modules specific to each
board, such as the memory map. The following sections describe the basic hardware and
software operations and the software interfaces for MSL modules. First, the common
modules, such as Interrupts and Timer are discussed. Next, the board-specific modules,
such as Memory Map and General Purpose Input/Output (GPIO) (including IOMUX on
some platforms) are detailed. Because of the complexity of the SDMA module, its design
is explained in SDMA relevant chapter.
Each of the following sections contains an overview of the hardware operation. For more
information, see the corresponding device documentation.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 27
Page 28
Interrupts (Operation)
3.2 Interrupts (Operation)
This section explains the hardware and software operation of interrupts on the device.
3.2.1 Interrupt Hardware Operation
The Interrupt Controller controls and prioritizes a maximum of 128 internal and external
interrupt sources.
Each source can be enabled or disabled by configuring the Interrupt Enable Register or
using the Interrupt Enable/Disable Number Registers. When an interrupt source is
enabled and the corresponding interrupt source is asserted, the Interrupt Controller asserts
a normal or a fast interrupt request depending on the associated Interrupt Type Register
settings.
Interrupt Controller registers can only be accessed in supervisor mode. The Interrupt
Controller interrupt requests are prioritized in the following order: fast interrupts and
normal interrupts for the highest priority level, then highest source number with the same
priority. There are 16 normal interrupt levels for all interrupt sources, with level zero
being the lowest priority. The interrupt levels are configurable through eight normal
interrupt priority level registers. Those registers, along with the Normal Interrupt Mask
Register, support software-controlled priority levels for normal interrupts and priority
masking.
3.2.2 Interrupt Software Operation
For ARM-based processors, normal interrupt and fast interrupt are two different
exception types. The exception vector addresses can be configured to start at low address
(0x0) or high address (0xFFFF0000).
The ARM Linux implementation chooses the high vector address model.
The following file describes the ARM interrupt architecture.
<ltib_dir>/rpm/BUILD/linux/Documentation/arm/Interrupts
The software provides a processor-specific interrupt structure with callback functions
defined in the irqchip structure and exports one initialization function, which is called
during system startup.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
28 Freescale Semiconductor, Inc.
Page 29
Chapter 3 Machine Specific Layer (MSL)
3.2.3 Interrupt Features
The interrupt implementation supports the following features:
• Interrupt Controller interrupt disable and enable
• Functions required by the Linux interrupt architecture as defined in the standard
ARM interrupt source code (mainly the <ltib_dir>/rpm/BUILD/linux/arch/arm/
kernel/irq.c file)
3.2.4 Interrupt Source Code Structure
The interrupt module is implemented in the following file (located in the directory
<ltib_dir>/rpm/BUILD/linux/arch/arm/plat-mxc):
irq.c (If CONFIG_MXC_TZIC is not selected)
tzic.c (If CONFIG_MXC_TZIC is selected)
gic.c (If CONFIG_ARM_GIC is selected)
There are also two header files (located in the include directory specified at the beginning
of this chapter):
hardware.h
irqs.h
The following table lists the source files for interrupts.
Table 3-1. Interrupt Files
File Description
hardware.h Register descriptions
irqs.h Declarations for number of interrupts supported
gic.c Actual interrupt functions for GIC modules
3.2.5 Interrupt Programming Interface
The machine-specific interrupt implementation exports a single function.
This function initializes the Interrupt Controller hardware and registers functions for
interrupt enable and disable from each interrupt source.
This is done with the global structure irq_desc of type struct irqdesc. After the
initialization, the interrupt can be used by the drivers through the request_irq() function to
register device-specific interrupt handlers.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 29
Page 30
Timer
In addition to the native interrupt lines supported by the Interrupt Controller, the number
of interrupts is also expanded to support GPIO interrupt and (on some platforms) EDIO
interrupts. This allows drivers to use the standard interrupt interface supported by ARM
Linux, such as the request_irq() and free_irq() functions.
3.3 Timer
The Linux kernel relies on the underlying hardware to provide support for both the
system timer (which generates periodic interrupts) and the dynamic timers (to schedule
events).
After the system timer interrupt occurs, it performs the following operations:
• Updates the system uptime.
• Updates the time of day.
• Reschedules a new process if the current process has exhausted its time slice.
• Runs any dynamic timers that have expired.
• Updates resource usage and processor time statistics.
The timer hardware on most i.MX platforms consists of either Enhanced Periodic
Interrupt Timer (EPIT) or general purpose timer (GPT) or both. GPT is configured to
generate a periodic interrupt at a certain interval (every 10 ms) and is used by the Linux
kernel.
3.3.1 Timer Software Operation
The timer software implementation provides an initialization function that initializes the
GPT with the proper clock source, interrupt mode and interrupt interval.
The timer then registers its interrupt service routine and starts timing. The interrupt
service routine is required to service the OS for the purposes mentioned in Timer.
Another function provides the time elapsed as the last timer interrupt.
3.3.2 Timer Features
The timer implementation supports the following features:
• Functions required by Linux to provide the system timer and dynamic timers.
• Generates an interrupt every 10 ms.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
30 Freescale Semiconductor, Inc.
Page 31
Chapter 3 Machine Specific Layer (MSL)
3.3.3 Timer Source Code Structure
The timer module is implemented in the arch/arm/plat-mxc/time.c file.
3.3.4 Timer Programming Interface
The timer module utilizes four hardware timers, to implement clock source and clock
event objects.
This is done with the clocksource_mxc structure of struct clocksource type and
clockevent_mxc structure of struct clockevent_device type. Both structures provide
routines required for reading current timer values and scheduling the next timer event.
The module implements a timer interrupt routine that services the Linux OS with timer
events for the purposes mentioned in the beginning of this chapter.
3.4 Memory Map
A predefined virtual-to-physical memory map table is required for the device drivers to
access to the device registers since the Linux kernel is running under the virtual address
space with the Memory Management Unit (MMU) enabled.
3.4.1 Memory Map Hardware Operation
The MMU, as a part of the ARM core, provides the virtual-to-physical address mapping
defined by the page table. For more information, see the ARM Technical Reference
Manual (TRM) from ARM Limited.
3.4.2 Memory Map Software Operation
A table mapping the virtual memory to physical memory is implemented for i.MX
platforms as defined in the file in <ltib_dir>/rpm/BUILD/linux/arch/arm/mach-mx6/
mm.c .
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 31
Page 32
IOMUX
3.4.3 Memory Map Features
The Memory Map implementation programs the Memory Map module to create the
physical-to-virtual memory map for all the I/O modules.
3.4.4 Memory Map Source Code Structure
The Memory Map module implementation is in mm.c under the platform-specific MSL
directory. The hardware.h header file is used to provide macros for all the I/O module
physical and virtual base addresses and physical to virtual mapping macros. All of the
memory map source code is in the following directory:
<ltib_dir>/rpm/BUILD/linux/arch/arm/plat-mxc/include/mach
The following table lists the source files for the memory map.
Table 3-2. Memory Map Files
File Description
mx6.h Header files for the I/O module physical addresses
3.4.5 Memory Map Programming Interface
The Memory Map is implemented in the mm.c file to provide the map between physical
and virtual addresses. It defines an initialization function to be called during system
startup.
3.5 IOMUX
The limited number of pins of highly integrated processors can have multiple purposes.
The IOMUX module controls a pin usage so that the same pin can be configured for
different purposes and can be used by different modules.
This is a common way to reduce the pin count while meeting the requirements from
various customers. Platforms that do not have the IOMUX hardware module can do pin
muxing through the GPIO module.
The IOMUX module provides the multiplexing control so that each pin may be
configured either as a functional pin or as a GPIO pin. A functional pin can be subdivided
into either a primary function or alternate functions. The pin operation is controlled by a
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
32 Freescale Semiconductor, Inc.
Page 33
Chapter 3 Machine Specific Layer (MSL)
specific hardware module. A GPIO pin, is controlled by the user through software with
further configuration through the GPIO module. For example, the TXD1 pin might have
the following functions:
• TXD1: internal UART1 Transmit Data. This is the primary function of this pin.
• UART2 DTR: alternate mode 3
• LCDC_CLS: alternate mode 4
• GPIO4[22]: alternate mode 5
• SLCDC_DATA[8]: alternate mode 6
If the hardware modes are chosen at the system integration level, this pin is dedicated
only to that purpose and cannot be changed by software. Otherwise, the IOMUX module
needs to be configured to serve a particular purpose that is dictated by the system (board)
design.
• If the pin is connected to an external UART transceiver and therefore to be used as
the UART data transmit signal, it should be configured as the primary function.
• If the pin is connected to an external Ethernet controller for interrupting the ARM
core, it should be configured as GPIO input pin with interrupt enabled.
The software does not have control over what function a pin should have. The software
only configures pin usage according to the system design.
3.5.1 IOMUX Hardware Operation
The following information applies only to those processors that have an IOMUX
hardware module.
The IOMUX controller registers are briefly described in this section.
For detailed information, see the pin multiplexing section of the IC reference manual.
• SW_MUX_CTL: Selects the primary or alternate function of a pin, and enables
loopback mode when applicable.
• SW_SELECT_INPUT: Controls pin input path. This register is only required when
multiple pads drive the same internal port.
• SW_PAD_CTL: Controls pad slew rate, driver strength, pull-up/down resistance, and
so on.
3.5.2 IOMUX Software Operation
The IOMUX software implementation provides an API to set up pin functions and pad
features.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 33
Page 34
IOMUX
3.5.3 IOMUX Features
The IOMUX implementation programs the IOMUX module to configure the pins that are
supported by the hardware.
3.5.4 IOMUX Source Code Structure
The following table lists the source files for the IOMUX module. The files are in the
directory:
<ltib_dir>/rpm/BUILD/arch/arm/plat-mxc/
<ltib_dir>/rpm/BUILD/arch/arm/plat-mxc/include/mach
Table 3-3. IOMUX Files
File Description
iomux-v3.c IOMUX function implementation
iomux-mx6sl.h Pin definitions in the iomux_pins enum
3.5.5 IOMUX Programming Interface
All the IOMUX functions required for the Linux port are implemented in the iomux-v3.c
file.
3.5.6 IOMUX Control Through GPIO Module
For a multi-purpose pin, the GPIO controller provides the multiplexing control so that
each pin may be configured either as a functional pin or a GPIO pin.
The operation of the functional pin, which can be subdivided into either major function or
one alternate function, is controlled by a specific hardware module. If it is configured as a
GPIO pin, the pin is controlled by the user through software with further configuration
through the GPIO module. In addition, there are some special configurations for a GPIO
pin (such as output based A_IN, B_IN, C_IN or DATA register, but input based A_OUT
or B_OUT).
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
34 Freescale Semiconductor, Inc.
Page 35
Chapter 3 Machine Specific Layer (MSL)
The following discussion applies to those platforms that control the muxing of a pin
through the general purpose input/output (GPIO) module.
If the hardware modes are chosen at the system integration level, this pin is dedicated
only to that purpose which can not be changed by software. Otherwise, the GPIO module
needs to be configured properly to serve a particular purpose that is dictated with the
system (board) design.
• If this pin is connected to an external UART transceiver, it should be configured as
the primary function.
• If this pin is connected to an external Ethernet controller for interrupting the core, it
should be configured as GPIO input pin with interrupt enabled.
The software does not have control over what function a pin should have. The software
only configures a pin for that usage according to the system design.
3.5.6.1 GPIO Hardware Operation
The GPIO controller module is divided into MUX control and PULLUP control sub
modules. The following sections briefly describe the hardware operation. For detailed
information, refer to the relevant device documentation.
3.5.6.1.1 Muxing Control
The GPIO In Use Registers control a multiplexer in the GPIO module.
The settings in these registers choose if a pin is utilized for a peripheral function or for its
GPIO function. One 32-bit general purpose register is dedicated to each GPIO port.
These registers may be used for software control of IOMUX block of the GPIO.
3.5.6.1.2 PULLUP Control
The GPIO module has a PULLUP control register (PUEN) for each GPIO port to control
every pin of that port.
3.5.6.2 GPIO Software Operation (general)
The GPIO software implementation provides an API to setup pin functions and pad
features.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 35
Page 36
General Purpose Input/Output(GPIO)
3.5.6.3 GPIO Implementation
The GPIO implementation programs the GPIO module to configure the pins that are
supported by the hardware.
3.5.6.4 GPIO Source Code Structure
The GPIO module is implemented in the iomux.cgpio_mux.c file under the relevant MSL
directory. The header file to define the pin names is under:
<ltib_dir>/rpm/BUILD/arch/arm/plat-mxc/include/mach
The following table lists the source files for the IOMUX.
Table 3-4. IOMUX Through GPIO Files
File Description
iomux-mx6sl.h Pin name definitions
3.5.6.5 GPIO Programming Interface
All the GPIO muxing functions required for the Linux port are implemented in the
iomux-v3.c file.
3.6 General Purpose Input/Output(GPIO)
The GPIO module provides general-purpose pins that can be configured as either inputs
or outputs.
When configured as an output, the pin state (high or low) can be controlled by writing to
an internal register. When configured as an input, the pin input state can be read from an
internal register.
3.6.1 GPIO Software Operation
The general purpose input/output (GPIO) module provides an API to configure the i.MX
processor external pins and a central place to control the GPIO interrupts.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
36 Freescale Semiconductor, Inc.
Page 37
Chapter 3 Machine Specific Layer (MSL)
The GPIO utility functions should be called to configure a pin instead of directly
accessing the GPIO registers. The GPIO interrupt implementation contains functions,
such as the interrupt service routine (ISR) registration/un-registration and ISR
dispatching once an interrupt occurs. All driver-specific GPIO setup functions should be
made during device initialization at the MSL layer to provide better portability and
maintainability. This GPIO interrupt is initialized automatically during the system
startup.
If a pin is configured to GPIO by the IOMUX, the state of the pin should also be set
because it is not initialized by a dedicated hardware module. Setting the pad pull-up, pulldown, slew rate and so on, with the pad control function may be required as well.
3.6.1.1 API for GPIO
API for GPIO lists the features supported by the GPIO implementation.
The GPIO implementation supports the following features:
• An API for registering an interrupt service routine to a GPIO interrupt. This is made
possible as the number of interrupts defined by NR_IRQS is expanded to
accommodate all the possible GPIO pins that are capable of generating interrupts.
• Functions to request and free an IOMUX pin. If a pin is used as GPIO, another set of
request/free function calls are provided. The user should check the return value of the
request calls to see if the pin has already been reserved before modifying the pin
state. The free function calls should be made when the pin is not needed. See the API
document for more details.
• Aligned parameter passing for both IOMUX and GPIO function calls. In this
implementation the same enumeration for iomux_pins is used for both IOMUX and
GPIO calls and the user does not have to figure out in which bit position a pin is
located in the GPIO module.
• Minimal changes required for the public drivers such as Ethernet and UART drivers
as no special GPIO function call is needed for registering an interrupt.
3.6.2 GPIO Features
This GPIO implementation supports the following features:
• Implementing the functions for accessing the GPIO hardware modules
• Provideing a way to control GPIO signal direction and GPIO interrupts
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 37
Page 38
General Purpose Input/Output(GPIO)
3.6.3 GPIO Module Source Code Structure
All of the GPIO module source code is at the MSL layer, in the following files, located in
the directories indicated at the beginning of this chapter:
Table 3-5. GPIO Files
File Description
iomux-mx 6sl.h IOMUX common header file
gpio.h GPIO public header file
gpio.c Function implementation
3.6.4 GPIO Programming Interface 2
For more information, see the Documentation/gpio.txt under the Linux source code
directory for the programming interface.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
38 Freescale Semiconductor, Inc.
Page 39
Chapter 4
Smart Direct Memory Access (SDMA) API
4.1 Overview
The Smart Direct Memory Access (SDMA) API driver controls the SDMA hardware.
It provides an API to other drivers for transferring data between MCU memory space and
the peripherals. It supports the following features:
• Loading channel scripts from the MCU memory space into SDMA internal RAM
• Loading context parameters of the scripts
• Loading buffer descriptor parameters of the scripts
• Controlling execution of the scripts
• Callback mechanism at the end of script execution
4.1.1 Hardware Operation
The SDMA controller is responsible for transferring data between the MCU memory
space and peripherals. It has the following features:
• Multi-channel DMA, supporting up to 32 time-division multiplexed DMA channels.
• Powered by a 16-bit Instruction-Set micro-RISC engine.
• Each channel executes specific script.
• Very fast context-switching with two-level priority based preemptive multi-tasking.
• 4-KB ROM containing startup scripts (that is, boot code) and other common utilities
that can be referenced by RAM-located scripts.
• 8-KB RAM area is divided into a processor context area and a code space area used
to store channel scripts that are downloaded from the system memory.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 39
Page 40
Overview
4.1.2 Software Operation
The driver provides an API for other drivers to control SDMA channels. SDMA channels
run dedicated scripts according to peripheral and transfer types. The SDMA API driver is
responsible for loading the scripts into SDMA memory, initializing the channel
descriptors, and controlling the buffer descriptors and SDMA registers.
The table below provides a list of drivers that use SDMA and the number of SDMA
physical channels used by each driver. A driver can specify the SDMA channel number
that it wishes to use, which is called static channel allocation. It can also have the SDMA
driver and provide a free SDMA channel for the driver to use, which is called dynamic
channel allocation. For dynamic channel allocation, the list of SDMA channels is scanned
from channel 32 to channel 1. Upon finding a free channel, that channel is allocated for
the requested DMA transfers.
Table 4-1. SDMA Channel Usage
Driver Name Number of
SDMA Channels
SDMA CMD 1 Static Channel allocation-uses SDMA channels 0
SSI 2 per device Dynamic channel allocation
UART 2 per device Dynamic channel allocation
SPDIF 2 per device Dynamic channel allocation
ESAI 2 per device Dynamic channel allocation
SDMA Channel Used
4.1.3 Source Code Structure
The dmaengine.h (header file for SDMA API) is available in the directory /<ltib_dir>/
rpm/BUILD/linux/include/linux
The following table shows the source files available in the directory /<ltib_dir>/rpm/
BUILD/linux/drivers/dma
Table 4-2. SDMA API Source Files
File Description
dmaengine.c SDMA management routine
imx-sdma.c SDMA implement driver
The following table shows the image files available in the directory /<ltib_dir>/rpm/
BUILD/linux/firmware/imx/sdma
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
40 Freescale Semiconductor, Inc.
Page 41
Chapter 4 Smart Direct Memory Access (SDMA) API
Table 4-3. SDMA Script Files
File Description
sdma-mx6q-to1.bin.ihex SDMA RAM scripts
4.1.4 Menu Configuration Options
The following Linux kernel configuration option is provided for this module. To get to
this options, use the ./ltib -c command when located in the <ltib dir>. On the screen
displayed, select Configure the Kernel and exit. When the next screen appears, select
the following option to enable this module:
• CONFIG_IMX_SDMA_: This is the configuration option for the SDMA API driver.
In menuconfig, this option is available under DMA Engine support.
4.1.5 Programming Interface
The module implements standard DMA API. For more information on the functions
implemented in the driver, refer to the API documents, which are included in the Linux
documentation package. For additional information, refer to the ESAI driver.
4.1.6 Usage Example
Refer to one of the drivers, such as SPDIF driver, UART driver or SSI driver, that uses
the SDMA API driver as a usage example.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 41
Page 42
Overview
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
42 Freescale Semiconductor, Inc.
Page 43
Chapter 5
Electrophoretic Display Controller (EPDC) Frame
Buffer Driver
5.1 Introduction
The Electrophoretic Display Controller (EPDC) is a direct-drive active matrix EPD
controller designed to drive E Ink EPD panels supporting a wide variety of TFT
backplanes. The EPDC framebuffer driver acts as a standard Linux frame buffer device
while also supporting a set of custom API extensions, accessible from user space (via
IOCTL) or another kernel module (via direct function call) in order to provide the user
with access to EPD-specific functionality. The EPDC driver is abstracted from any
specific E Ink panel type, providing flexibility to work with a range of E Ink panel types
and specifications.
The EPDC driver supports the following features:
• Support for EPDC driver as a loadable or built-in module.
• Support for RGB565 and Y8 frame buffer formats.
• Support for full and partial EPD screen updates.
• Support for up to 256 panel-specific waveform modes.
• Support for automatic optimal waveform selection for a given update.
• Support for synchronization by waiting for a specific update request to complete.
• Support for screen updates from an alternate (overlay) buffer.
• Support for automated collision handling.
• Support for 64 simultaneous update regions.
• Support for pixel inversion in a Y8 frame buffer format.
• Support for 90, 180, and 270 degree HW-accelerated frame buffer rotation.
• Support for panning (y-direction only).
• Support for automated full and partial screen updates through the Linux
fb_deferred_io mechanism.
• Support for three EPDC driver display update schemes: Snapshot, Queue, and Queue
and Merge.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 43
Page 44
Hardware Operation
• Support for setting the ambient temperature through either a one-time designated API
call or on a per-update basis.
• Support for user control of the delay between completing all updates and powering
down the EPDC.
5.2 Hardware Operation
The detailed hardware operation of the EPDC is discussed in the i.MX 6SoloLite
Applications Processor Reference Manual.
5.3 Software Operation
The EPDC frame buffer driver is a self-contained driver module in the Linux kernel. It
consists of a standard frame buffer device API coupled with a custom EPD-specific API
extension, accessible through the IOCTL interface. This combined functionality provides
the user with a robust and familiar display interface while offering full control over the
contents and update mode of the E Ink display.
This section covers the software operation of the EPDC driver, both through the standard
frame buffer device architecture, and through the custom E Ink API extensions.
Additionally, panel intialization and framebuffer formats are discussed.
5.3.1 EPDC Frame Buffer Driver Overview
The frame buffer device provides an abstraction for the graphics hardware. It represents
the frame buffer video hardware and allows application software to access the graphics
hardware through a well-defined interface, so that the software is not required to know
anything about the low-level hardware registers. The EPDC driver supports this model
with one key caveat: the contents of the frame buffer are not automatically updated to the
E Ink display. Instead, a custom API function call is required to trigger an update to the E
Ink display. The details of this process are explained in the EPDC Frame Buffer Driver
Extensions.
The frame buffer driver is enabled by selecting the frame buffer option under the graphics
parameters in the kernel configuration. To supplement the frame buffer driver, the kernel
builder may also include support for fonts and a startup logo. The frame buffer device
depends on the virtual terminal (VT) console to switch from serial to graphics mode. The
device is accessed through special device nodes, located in the /dev directory, as /dev/fb*.
fb0 is generally the primary frame buffer.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
44 Freescale Semiconductor, Inc.
Page 45
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
A frame buffer device is a memory device, such as /dev/mem, and it has features similar
to a memory device. Users can read it, write to it, seek to some location in it, and mmap()
it (the main use). The difference is that the memory that appears in the special file is not
the whole memory, but the frame buffer of some video hardware.
The EPDC frame buffer driver ( drivers/video/mxc/mxc_epdc_fb.c) interacts closely with
the generic Linux frame buffer driver (drivers/video/fbmem.c).
For additional details on the frame buffer device, please refer to documentation in the
Linux kernel found in Documentation/fb/framebuffer.txt.
5.3.2 EPDC Frame Buffer Driver Extensions
E Ink display technology, in conjunction with the EPDC, has several features that
distinguish it from standard LCD-based frame buffer devices. These differences
introduce the need for API extensions to the frame buffer interface. The EPDC refreshes
the E Ink display asynchronously and supports partial screen updates. Therefore, the
EPDC requires notification from the user when the frame buffer contents have been
modified and which region needs updating. Another unique characteristic of EPDC
updates to the E Ink display is the long screen update latencies (between 300-980ms),
which introduces the need for a mechanism to allow the user to wait for a given screen
update to complete.
The custom API extensions to the frame buffer device are accessible both from user
space applications and from within kernel space. The standard device IOCTL interface
provides access to the custom API for user space applications. The IOCTL extensions,
along with relevant data structures and definitions, can be found in include/linux/
mxcfb.h. A full description of these IOCTLs can be found in the Programming Interface
section Programming Interface.
For kernel mode access to the custom API extensions, the IOCTL interface should be
bypassed in favor of direct access to the underlying functions. These functions are
included in include/linux/mxcfb_epdc_kernel.h, and are documented in the Programming
Interface section Programming Interface.
5.3.3 EPDC Panel Configuration
The EPDC driver is designed to flexibly support E Ink panels with a variety of panel
resolutions, timing parameters, and waveform modes. The EPDC driver is kept panelagnostic through the use of an EPDC panel mode structure, mxc_epdc_fb_mode, which
can be found in arch/arm/plat-mxc/include/mach/epdc.h.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 45
Page 46
Software Operation
struct mxc_epdc_fb_mode {
struct fb_videomode *vmode;
int vscan_holdoff;
int sdoed_width;
int sdoed_delay;
int sdoez_width;
int sdoez_delay;
int gdclk_hp_offs;
int gdsp_offs;
int gdoe_offs;
int gdclk_offs;
int num_ce;
};
The mxc_epdc_fb_mode structure consists of an fb_videomode structure and a set of
EPD timing parameters. The fb_videomode structure defines the panel resolution and the
basic timing parameters (pixel clock frequency, hsync and vsync margins) and the
additional timing parameters in mxc_epdc_fb_mode define EPD-specific timing
parameters, such as the source and gate driver timings. Please refer to the EPDC
programming model section within the i.MX 6SoloLite Applications Processor Reference
Manual for details on how E Ink panel timing parameters should be configured.
This EPDC panel mode is part of the mxc_epdc_fb_platform_data structure that is passed
to the EPDC driver during driver registration.
struct mxc_epdc_fb_platform_data {
struct mxc_epdc_fb_mode *epdc_mode;
int num_modes;
void (*get_pins) (void);
void (*put_pins) (void);
void (*enable_pins) (void);
void (*disable_pins) (void);
};
In addition to the EPDC panel mode data, functions may be passed to the EPDC driver to
define how to handle the EPDC pins when the EPDC driver is enabled or disabled. These
functions should disable the EPDC pins for purposes of power savings.
5.3.3.1 Boot Command Line Parameters
Additional configuration for the EPDC driver is provided through boot command line
parameters. The format of the command line option is as follows:
video=mxcepdcfb:[panel_name],bpp=16
The EPDC driver parses these options and tries to match panel_name to the name of
video mode specified in the mxc_epdc_fb_mode panel mode structure. If no match is
found, then the first panel mode provided in the platform data is used by the EPDC
driver. The bpp setting from this command line sets the initial bits per pixel setting for
the frame buffer. A setting of 16 selects RGB565 pixel format, while a setting of 8 selects
8-bit grayscale (Y8) format.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
46 Freescale Semiconductor, Inc.
Page 47
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
5.3.4 EPDC Waveform Loading
The EPDC driver requires a waveform file for proper operation. This waveform file
contains the waveform information needed to generate the waveforms that drive updates
to the E Ink panel. A pointer to the waveform file data is programmed into the EPDC
before the first update is performed.
There are two options for selecting a waveform file:
1. Select one of the default waveform files included in this BSP and built into the
kernel.
2. Use a new waveform file that is specific to the E Ink panel being used.
The waveform file is loaded by the EPDC driver using the Linux firmware APIs.
5.3.4.1 Using a Default Waveform File
The quickest and easiest way to get started using an E Ink panel and the EPDC driver is
to use one of the default waveform files provided in the Linux BSP. This should enable
updates to several different types of E Ink panel without a panel-specific waveform file.
The drawback is that optimal quality should not be expected. Typically, using a nonpanel-specific waveform file for an E Ink panel results in more ghosting artifacts and
overall poorer color quality.
The following default waveform files included in the BSP reside in firmware/imx/:
• epdc_E60_V110.fw - Default waveform for the 6.0 inch V110 E Ink panel.
• epdc_E60_V220.fw - Default waveform for the 6.0 inch V220 E Ink panel (supports
animation mode updates).
• epdc_E97_V110.fw - Default waveform for the 9.7 inch V110 E Ink panel.
• epdc_E060SCM.fw - Default waveform for the 6.0 inch Pearl E Ink panel (supports
animation mode updates).
The EPDC driver attempts to load a waveform file with the name "imx/
epdc_[panel_name].fw", where panel_name refers to the string specified in the
fb_videomode name field. This panel_name information should be provided to the EPDC
driver through the kernel command line parameters described in the preceding chapter.
For example, to load the epdc_E060SCM.fw default firmware file for a Pearl panel, set
the EPDC kernel command line paratmeter to the following:
video=mxcepdcfb:E060SCM,bpp=16
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 47
Page 48
Software Operation
5.3.4.2 Using a Custom Waveform File
To ensure the optimal E Ink display quality, use a waveform file specific to E Ink panel
being used. The raw waveform file type (.wbf) requires conversion to a format that can
be understood and read by the EPDC. This conversion script is not included as part of the
BSP, so please contact Freescale to acquire this conversion script.
Once the waveform conversion script has been run on the raw waveform file, the
converted waveform file should be renamed so that the EPDC driver can find it and load
it. The driver is going to search for a waveform file with the name "imx/
epdc_[panel_name].fw", where panel_name refers to the string specified in the
fb_videomode name field. For example, if the panel is named "E60_ABCD", then the
converted waveform file should be named epdc_E60_ABCD.fw.
The firmware script firmware.sh (lib/udev/firmware in the Linux root file system)
contains the search path used to locate the firmware file. The default search path for
firmware files is /lib/firmware;/usr/local/lib/firmware. A custom search path can be
specified by modifying firmware.sh. You’ll need to create an imx directory in one of
these paths and add your new epdc_[panel_name].fw file there.
NOTE
If the EPDC driver is searching for a firmware waveform file
that matches the names of one of the default waveform files
(see preceding chapter), it will choose the default firmware files
that are built into the BSP over any firmware file that has been
added in the firmware search path. Thus, if you leave the BSP
so that it builds those default firmware files into the OS image,
be sure to use a panel name other than those associated with the
default firmware files, since those default waveform files will
be preferred and selected over a new waveform file placed in
the firmware search path.
5.3.5 EPDC Panel Initialization
The framebuffer driver will not typically (see note below for exceptions) go through any
hardware initialization steps when the framebuffer driver module is loaded. Instead, a
subsequent user mode call must be made to request that the driver initialize itself for a
specific EPD panel. To initialize the EPDC hardware and E-ink panel, an
FBIOPUT_VSCREENINFO ioctl call must be made, with the xres and yres fields of the
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
48 Freescale Semiconductor, Inc.
Page 49
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
fb_var_screeninfo parameter set to match the X and Y resolution of a supported E-ink
panel type. To ensure that the EPDC driver receives the initialization request, the activate
field of the fb_var_screeninfo parameter should be set to FB_ACTIVATE_FORCE.
NOTE
The exception is when the FB Console driver is included in the
kernel. When the EPDC driver registers the framebuffer device,
the FB Console driver will subsequently make an
FBIOPUT_VSCREENINFO ioctl call. This will in turn
initialize the EPDC panel.
5.3.6 Grayscale Framebuffer Selection
The EPDC framebuffer driver supports the use of 8-bit grayscale (Y8) and 8-bit inverted
grayscale (Y8 inverted) pixel formats for the framebuffer (in addition to the more
common RGB565 pixel format). In order to configure the framebuffer format as 8-bit
grayscale, the application would call the FBIOPUT_VSCREENINFO framebuffer ioctl.
This ioctl takes an fb_var_screeninfo pointer as a parameter. This parameter specifies the
attributes of the framebuffer and allows the application to request changes to the
framebuffer format. There are two key members of the fb_var_screeninfo parameter that
must be set in order to request a change to 8-bit grayscale format: bits_per_pixel and
grayscale. bits_per_pixel must be set to 8 and grayscale must be set to one of the 2 valid
grayscale format values: GRAYSCALE_8BIT or GRAYSCALE_8BIT_INVERTED.
The following code snippet demonstrates a request to change the framebuffer to use the
Y8 pixel format:
fb_screen_info screen_info;
screen_info.bits_per_pixel = 8;
screen_info.grayscale = GRAYSCALE_8BIT;
retval = ioctl(fd_fb0, FBIOPUT_VSCREENINFO, &screen_info);
5.3.7 Enabling An EPDC Splash Screen
By default, the EPDC support in U-Boot is disabled, and therefore splash screen support
is also disabled. To enable splash screen support, edit the configuration file /include/
configs/mx6sl_evk.h and enable the following defines:
#define CONFIG_SPLASH_SCREEN
#define CONFIG_MXC_EPDC
Once this change has been made, rebuild the U-Boot image and flash it to your SD card.
Then perform the following steps to flash a waveform file to an SD card where U-Boot
can find it:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 49
Page 50
Source Code Structure
1. Identify the EPDC waveform file from the Linux kernel firmware directory that is
the best match for the panel you are using. For the DC2/DC3 boards, that would be
the waveform file /firmware/imx/epdc_E060SCM.fw.ihex.
2. Convert the ihex firmware file to a stripped-down binary using the script
ihex2bin.py. Please contact Freescale to acquire this script.
python ihex2bin.py -I epdc_E060SCM.fw.ihex -o epdc_E060SCM_splash.bin
3. Write the firmware file to the SD card at an offset of 6MB where U-Boot will look
for it.
dd if=./epdc_E060SCM_splash.bin of=/dev/sdX bs=1024 seek=6144
5.4 Source Code Structure
Table below lists the source files associated with the EPDC driver. These files are
available in the following directory:
drivers/video/mxc
Table 5-1. EPDC Driver Files
File Description
mxc_epdc_fb.c The EPDC frame buffer driver.
epdc_regs.h Register definitions for the EPDC module.
Table below lists the global header files associated with the EPDC driver. These files are
available in the following directory:
include/linux/
Table 5-2. EPDC Global Header Files
File Description
mxcfb.h Header file for the MXC framebuffer drivers
mxcfb_epdc_kernel.h Header file for direct kernel access to the EPDC API extension
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
50 Freescale Semiconductor, Inc.
Page 51
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
5.5 Menu Configuration Options
To get to the Linux kernel configuration options available for the EPDC module, use the
command ./ltib -c when located in the <ltib dir>. On the screen displayed, select
Configure the kernel and exit. When the next screen appears select the options to
configure. The following Linux kernel configuration options are provided for the EPDC
module:
• CONFIG_MXC_EINK_PANEL includes support for the Electrophoretic Display
Controller. In menuconfig, this option is available under:
• Device Drivers > Graphics Support > E-Ink Panel Framebuffer
• CONFIG_MXC_EINK_AUTO_UPDATE_MODE enables support for auto-update
mode, which provides automated EPD updates through the deferred I/O framebuffer
driver. This option is dependent on the MXC_EINK_PANEL option. In menuconfig,
this option is available under:
• Device Drivers > Graphics Support > E-Ink Auto-update Mode Support
NOTE
This option only enables the use of auto-update mode.
Turning on auto-update mode requires an additional
IOCTL call using the
MXCFB_SET_AUTO_UPDATE_MODE IOCTL.
• CONFIG_FB to include frame buffer support in the Linux kernel. In menuconfig,
this option is available under:
• Device Drivers > Graphics support > Support for frame buffer devices
• By default, this option is Y for all architectures.
• CONFIG_FB_MXC is a configuration option for the MXC Frame buffer driver. This
option is dependent on the CONFIG_FB option. In menuconfig, this option is
available under:
• Device Drivers > Graphics support > MXC Framebuffer support
• By default, this option is Y for all architectures.
• CONFIG_MXC_PXP enables support for the PxP. The PxP is required by the EPDC
driver for processing (color space conversion, rotation, auto-waveform selection)
framebuffer update regions. This option must be selected for the EPDC framebuffer
driver to operate correctly. In menuconfig, this option is available under:
• Device Drivers > DMA Engine support > MXC PxP support
5.6 Programming Interface
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 51
Page 52
Programming Interface
5.6.1 IOCTLs/Functions
The EPDC Frame Buffer is accessible from user space and from kernel space. A single
set of functions describes the EPDC Frame Buffer driver extension. There are, however,
two modes for accessing these functions. For user space access the IOCTL interface
should be used. For kernel space access the functions should be called directly. For each
function below both the IOCTL code and the corresponding kernel function is listed.
MXCFB_SET_WAVEFORM_MODES / mxc_epdc_fb_set_waveform_modes()
Description:
Defines a mapping for common waveform modes.
Parameters:
mxcfb_waveform_modes *modes
Pointer to a structure containing the waveform mode values for common waveform
modes. These values must be configured in order for automatic waveform mode selection
to function properly.
MXCFB_SET_TEMPERATURE / mxc_epdc_fb_set_temperature
Description:
Set the temperature to be used by the EPDC driver in subsequent panel updates.
Parameters:
int32_t temperature
Temperature value, in degrees Celsius. Note that this temperature setting may be
overridden by setting the temperature value parameter to anything other than
TEMP_USE_AMBIENT when using the MXCFB_SEND_UPDATE ioctl.
MXCFB_SET_AUTO_UPDATE_MODE / mxc_epdc_fb_set_auto_update
Description:
Select between automatic and region update mode.
Parameters:
__u32 mode
In region update mode, updates must be submitted via the MXCFB_SEND_UPDATE
IOCTL.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
52 Freescale Semiconductor, Inc.
Page 53
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
In automatic mode, updates are generated automatically by the driver by detecting pages
in frame buffer memory region that have been modified.
MXCFB_SET_UPDATE_SCHEME / mxc_epdc_fb_set_upd_scheme
Description:
Select a scheme that dictates how the flow of updates within the driver.
Parameters:
__u32 scheme
Select of the following updates schemes:
UPDATE_SCHEME_SNAPSHOT - In the Snapshot update scheme, the contents of the
framebuffer are immediately processed and stored in a driver-internal memory buffer. By
the time the call to MXCFB_SEND_UPDATE has completed, the framebuffer region is
free and can be modified without affecting the integrity of the last update. If the update
frame submission is delayed due to other pending updates, the original buffer contents
will be displayed when the update is finally submitted to the EPDC hardware. If the
update results in a collision, the original update contents will be resubmitted when the
collision has cleared.
UPDATE_SCHEME_QUEUE - The Queue update scheme uses a work queue to
aynchronously handle the processing and submission of all updates. When an update is
submitted via MXCFB_SEND_UPDATE, the update is added to the queue and then
processed in order as EPDC hardware resources become available. As a result, the
framebuffer contents processed and updated are not guaranteed to reflect what was
present in the framebuffer when the update was sent to the driver.
UPDATE_SCHEME_QUEUE_AND_MERGE - The Queue and Merge scheme uses the
queueing concept from the Queue scheme, but adds a merging step. This means that,
before an update is processed in the work queue, it is first compared with other pending
updates. If any update matches the mode and flags of the current update and also overlaps
the update region of the current update, then that update will be merged with the current
update. After attempting to merge all pending updates, the final merged update will be
processed and submitted.
MXCFB_SEND_UPDATE / mxc_epdc_fb_send_update
Description:
Request a region of the frame buffer be updated to the display.
Parameters:
mxcfb_update_data *upd_data
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 53
Page 54
Programming Interface
Pointer to a structure defining the region of the frame buffer, waveform mode, and
collision mode for the current update. This structure also includes a flags field to select
from one of the following update options:
EPDC_FLAG_ENABLE_INVERSION - Enables inversion of all pixels in the update
region.
EPDC_FLAG_FORCE_MONOCHROME - Enables full black/white posterization of all
pixels in the update region.
EPDC_FLAG_USE_ALT_BUFFER - Enables updating from an alternate (nonframebuffer) memory buffer.
If enabled, the final upd_data parameter includes detailed configuration information for
the alternate memory buffer.
MXCFB_WAIT_FOR_UPDATE_COMPLETE /
mxc_epdc_fb_wait_update_complete
Description:
Block and wait for a previous update request to complete.
Parameters:
mxfb_update_marker_data marker_data
The update_marker value used to identify a particular update (passed as a parameter in
MXCFB_SEND_UPDATE IOCTL call) should be re-used here to wait for the update to
complete. If the update was a collision test update, the collision_test variable will return
the result indicating whether a collision occurred.
MXCFB_SET_PWRDOWN_DELAY / mxc_epdc_fb_set_pwrdown_delay
Description:
Set the delay between the completion of all updates in the driver and when the driver
should power down the EPDC and the E Ink display power supplies.
Parameters:
int32_t delay
Input delay value in milliseconds. To disable EPDC power down altogether, use
FB_POWERDOWN_DISABLE (defined below).
MXCFB_GET_PWRDOWN_DELAY / mxc_epdc_fb_get_pwrdown_delay
Description:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
54 Freescale Semiconductor, Inc.
Page 55
Chapter 5 Electrophoretic Display Controller (EPDC) Frame Buffer Driver
Retrieve the driver's current power down delay value.
Parameters:
int32_t delay
Output delay value in milliseconds.
5.6.2 Structures and Defines
#define GRAYSCALE_8BIT 0x1
#define GRAYSCALE_8BIT_INVERTED 0x2
#define AUTO_UPDATE_MODE_REGION_MODE 0
#define AUTO_UPDATE_MODE_AUTOMATIC_MODE 1
#define UPDATE_SCHEME_SNAPSHOT 0
#define UPDATE_SCHEME_QUEUE 1
#define UPDATE_SCHEME_QUEUE_AND_MERGE 2
#define UPDATE_MODE_PARTIAL 0x0
#define UPDATE_MODE_FULL 0x1
#define WAVEFORM_MODE_AUTO 257
#define TEMP_USE_AMBIENT 0x1000
#define EPDC_FLAG_ENABLE_INVERSION 0x01
#define EPDC_FLAG_FORCE_MONOCHROME 0x02
#define EPDC_FLAG_USE_ALT_BUFFER 0x100
#define EPDC_FLAG_TEST_COLLISION 0x200
#define FB_POWERDOWN_DISABLE -1
struct mxcfb_rect {
__u32 left; /* Starting X coordinate for update region */
__u32 top; /* Starting Y coordinate for update region */
__u32 width; /* Width of update region */
__u32 height; /* Height of update region */
};
struct mxcfb_waveform_modes {
int mode_init; /* INIT waveform mode */
int mode_du; /* DU waveform mode */
int mode_gc4; /* GC4 waveform mode */
int mode_gc8; /* GC8 waveform mode */
int mode_gc16; /* GC16 waveform mode */
int mode_gc32; /* GC32 waveform mode */
};
struct mxcfb_alt_buffer_data {
__u32 phys_addr; /* physical address of alternate image buffer */
__u32 width; /* width of entire buffer */
__u32 height; /* height of entire buffer */
struct mxcfb_rect alt_update_region; /* region within buffer to update */
};
struct mxcfb_update_data {
struct mxcfb_rect update_region; /* Rectangular update region bounds */
__u32 waveform_mode; /* Waveform mode for update */
__u32 update_mode; /* Update mode selection (partial/full) */
__u32 update_marker; /* Marker used when waiting for completion */
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 55
Page 56
Programming Interface
int temp; /* Temperature in Celsius */
uint flags; /* Select options for the current update */
struct mxcfb_alt_buffer_data alt_buffer_data; /* Alternate buffer data */
};
struct mxcfb_update_marker_data { __u32 update_marker; __u32 collision_test; };
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
56 Freescale Semiconductor, Inc.
Page 57
Chapter 6
Sipix Display Controller (SPDC) Frame Buffer Driver
6.1 Introduction
Electrophoretic Display Timing Controller (SPDC) is a direct-drive active matrix EPD
controller designed to drive Sipix panel for E-Book application. The SPDC provides
control signals for the source driver and gate drivers. This IP provides a high
performance, low cost solution for SiPix EPDs (Electronic Paper Display). Partial update
and concurrent display updates resulting in high responsive screen changes are also
implemented for these applications. The SPDC module co-works in conjunction with the
ePXP IP module to form a complete display processing solution (such as rotation and flip
function etc).
The SPDC driver supports the following features:
• Support for SPDC driver as a loadable or built-in module.
• Support for RGB565 and Y4 frame buffer formats.
• Support 800x600 resolution.
• Support for full and partial EPD screen updates.
• Support for automatic optimal waveform selection for a given update.
• Support for synchronization by waiting for a specific update request to complete.
• Support for screen updates from an alternate (overlay) buffer.
• Support for 90, 180, and 270 degree HW-accelerated frame buffer rotation.
• Support for panning (y-direction only).
• Support for automated full and partial screen updates through the Linux
fb_deferred_io mechanism.
• Support for three SPDC driver display update schemes: Snapshot, Queue, and Queue
and Merge.
• Support for setting the ambient temperature through either a one-time designated API
call or on a per-update basis.
• Support for user control of the delay between completing all updates and powering
down the SPDC.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 57
Page 58
Hardware Operation
6.2 Hardware Operation
The detailed hardware operation of the SPDC is discussed in the i.MX 6SoloLite
Multimedia Applications Processor Reference Manual (i.MX 6SL RM).
6.3 Software Operation
The SPDC frame buffer driver is a self-contained driver module in the Linux kernel. It
consists of a standard frame buffer device API coupled with a custom EPD-specific API
extension which is accessible through the IOCTL interface. The combined functionality
provides the user with a robust and familiar display interface while offering full control
over the contents and update mode of the Sipix display.
This section covers the software operation of the SPDC driver, both through the standard
frame buffer device architecture, and through the custom Sipix API extensions.
Additionally, panel intialization and framebuffer formats are discussed.
6.3.1 SPDC Frame Buffer Driver Overview
The frame buffer device provides an abstraction for the graphics hardware. It represents
the frame buffer video hardware and allows application software to access the graphics
hardware through a well-defined interface, so that the software is not required to know
anything about the low-level hardware registers. The SPDC driver supports this model
with one key caveat: the contents of the frame buffer are not automatically updated to the
Sipix display. Instead, a custom API function call is required to trigger an update to the
Sipix display. The details of this process are explained in SPDC Frame Buffer Driver
Extensions.
The frame buffer driver is enabled by selecting the frame buffer option under the graphics
parameters in the kernel configuration. To supplement the frame buffer driver, the kernel
builder may also include support for fonts and a startup logo. The frame buffer device
depends on the virtual terminal (VT) console to switch from serial to graphics mode. The
device is accessed through special device nodes, located in the /dev directory, as /dev/fb*.
fb0 is generally the primary frame buffer.
A frame buffer device is a memory device, such as /dev/mem, and it has features similar
to a memory device. Users can read it, write to it, seek to some location in it, and mmap()
it (the main use). The difference is that the memory that appears in the special file is not
the whole memory, but the frame buffer of some video hardware.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
58 Freescale Semiconductor, Inc.
Page 59
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
The SPDC frame buffer driver (<ltib_dir>/rpm/BUILD/linux/drivers/video/mxc/
mxc_spdc_fb.cdrivers/video/mxc/mxc_spdc_fb.c) interacts closely with the generic
Linux frame buffer driver (drivers/video/fbmem.c).
For additional details on the frame buffer device, please refer to documentation in the
Linux kernel found in Documentation/fb/framebuffer.txt.
6.3.2 SPDC Frame Buffer Driver Extensions
Sipix display technology, in conjunction with the SPDC, has several features that
distinguish it from standard LCD-based frame buffer devices. These differences
introduce the need for API extensions to the frame buffer interface. The SPDC refreshes
the Sipix display asynchronously and supports partial screen updates. Therefore, the
SPDC requires notification from the user when the frame buffer contents have been
modified and which region needs updating. Another unique characteristic of SPDC
updates to the Sipix display is the long screen update latencies (between 300-980ms),
which introduces the need for a mechanism to allow the user to wait for a given screen
update to complete.
The custom API extensions to the frame buffer device are accessible both from user
space applications and from within kernel space. The standard device IOCTL interface
provides access to the custom API for user space applications. The IOCTL extensions,
along with relevant data structures and definitions, can be found in include/linux/
mxcfb.h. A full description of these IOCTLs can be found in the Programming Interface
section Programming Interface.
For kernel mode access to the custom API extensions, the IOCTL interface should be
bypassed in favor of direct access to the underlying functions. These functions are
included in include/linux/mxcfb_epdc_kernel.h, and are documented in the Programming
Interface section Programming Interface.
6.3.3 SPDC Panel Configuration
The SPDC driver is designed to flexibly support Sipix panels with a variety of panel
resolutions, timing parameters, and waveform modes. The SPDC driver is kept panelagnostic through the use of an SPDC panel mode structure, imx_spdc_fb_mode, which
can be found in arch/arm/plat-mxc/include/mach/epdc.h.
struct imx_spdc_fb_mode {
struct fb_videomode *vmode;
struct imx_spdc_panel_init_set *init_set;
const char
*wave_timing;
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 59
Page 60
Software Operation
};
The imx_spdc_fb_mode structure consists of an fb_videomode structure and a set of EPD
timing parameters. The fb_videomode structure defines the panel resolution and the basic
timing parameters (pixel clock frequency, hsync and vsync margins) and the additional
timing parameters in imx_spdc_fb_mode define EPD-specific timing parameters, such as
the source and gate driver timings. Please refer to the SPDC programming model section
within the i.MX 6SoloLite Applications Processor Reference Manual for details on how
Sipix panel timing parameters should be configured.
This SPDC panel mode is part of the mxc_spdc_fb_platform_data structure that is passed
to the SPDC driver during driver registration.
struct imx_spdc_fb_platform_data {
struct imx_spdc_fb_mode *spdc_mode;
int num_modes;
int (*get_pins) (void);
void (*put_pins) (void);
void (*enable_pins) (void);
void (*disable_pins) (void);
};
In addition to the SPDC panel mode data, functions may be passed to the SPDC driver to
define how to handle the SPDC pins when the SPDC driver is enabled or disabled. These
functions should disable the SPDC pins for purposes of power savings.
6.3.3.1 Boot Command Line Parameters
Additional configuration for the SPDC driver is provided through boot command line
parameters. The format of the command line option is as follows:
spdc video=mxcspdcfb:[panel_name],bpp=16
The SPDC driver parses these options and tries to match panel_name to the name of
video mode specified in the mxc_spdc_fb_mode panel mode structure. If no match is
found, then the first panel mode provided in the platform data is used by the SPDC
driver. The bpp setting from this command line sets the initial bits per pixel setting for
the frame buffer. A setting of 16 selects RGB565 pixel format, while a setting of 4 selects
4-bit grayscale (Y4) format.
6.3.4 SPDC Waveform Loading
The SPDC driver requires a waveform file for proper operation. This waveform file
contains the waveform information needed to generate the waveforms that drive updates
to the Sipix panel. A pointer to the waveform file data is programmed into the SPDC
before the first update is performed.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
60 Freescale Semiconductor, Inc.
Page 61
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
There are two options for selecting a waveform file:
1. Select one of the default waveform files included in this BSP and built into the
kernel.
2. Use a new waveform file that is specific to the Sipix panel being used.
The waveform file is loaded by the SPDC driver using the Linux firmware APIs.
6.3.4.1 Using a Default Waveform File
The quickest and easiest way to get started using an Sipix panel and the SPDC driver is to
use one of the default waveform files provided in the Linux BSP. This should enable
updates to several different types of Sipix panel without a panel-specific waveform file.
The drawback is that optimal quality should not be expected. Typically, using a nonpanel-specific waveform file for an Sipix panel results in more ghosting artifacts and
overall poorer color quality.
The following default waveform files included in the BSP reside in firmware/imx/:
• spdc_pvi.fw - Default waveform for the AUO Sipix panel ERK_1_4_A01 version.
The SPDC driver attempts to load a waveform file with the name "imx/
spdc_[wave_timing].fw", where wave_timing refers to the string specified in the
imx_spdc_fb_mode wave_timing field.
6.3.4.2 Using a Custom Waveform File
To ensure the optimal Sipix display quality, use a waveform file specific to Sipix panel
being used. The raw waveform file type requires conversion to a format that can be
understood and read by the SPDC. This conversion script is not included as part of the
BSP, so please contact Freescale to acquire this conversion script.
Once the waveform conversion script has been run on the raw waveform file, the
converted waveform file should be renamed so that the SPDC driver can find it and load
it. The driver is going to search for a waveform file with the name "imx/
spdc_[wave_timing].fw", where wave_timing refers to the string specified in the
imx_spdc_fb_mode wave_timing field. For example, if the panel waveform is named "pvi",
then the converted waveform file should be named spdc_pvi.fw.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 61
Page 62
Software Operation
The firmware script firmware.sh (lib/udev/firmware in the Linux root file system)
contains the search path used to locate the firmware file. The default search path for
firmware files is /lib/firmware;/usr/local/lib/firmware. A custom search path can be
specified by modifying firmware.sh. You’ll need to create an imx directory in one of
these paths and add your new spdc_[wave_timing].fw file there.
NOTE
If the SPDC driver is searching for a firmware waveform file
that matches the names of one of the default waveform files
(see preceding chapter), it will choose the default firmware files
that are built into the BSP over any firmware file that has been
added in the firmware search path. Therefore, if you leave the
BSP so that it builds those default firmware files into the OS
image, be sure to use a panel name other than those associated
with the default firmware files, since those default waveform
files will be preferred and selected over a new waveform file
placed in the firmware search path.
6.3.5 SPDC Panel Initialization
The framebuffer driver will not typically (see note below for exceptions) go through any
hardware initialization steps when the framebuffer driver module is loaded. Instead, a
subsequent user mode call must be made to request that the driver initialize itself for a
specific EPD panel. To initialize the SPDC hardware and E-ink panel, an
FBIOPUT_VSCREENINFO ioctl call must be made, with the xres and yres fields of the
fb_var_screeninfo parameter set to match the X and Y resolution of a supported E-ink
panel type. To ensure that the SPDC driver receives the initialization request, the activate
field of the fb_var_screeninfo parameter should be set to FB_ACTIVATE_FORCE.
NOTE
The exception is when the FB Console driver is included in the
kernel. When the SPDC driver registers the framebuffer device,
the FB Console driver will subsequently make an
FBIOPUT_VSCREENINFO ioctl call. This will in turn
initialize the SPDC panel.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
62 Freescale Semiconductor, Inc.
Page 63
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
6.3.6 Grayscale Framebuffer Selection
The SPDC framebuffer driver supports the use of 4-bit grayscale (Y4) and 4-bit inverted
grayscale (Y4 inverted) pixel formats for the framebuffer (in addition to the more
common RGB565 pixel format). In order to configure the framebuffer format as 4-bit
grayscale, the application would call the FBIOPUT_VSCREENINFO framebuffer ioctl.
This ioctl takes an fb_var_screeninfo pointer as a parameter. This parameter specifies the
attributes of the framebuffer and allows the application to request changes to the
framebuffer format. There are two key members of the fb_var_screeninfo parameter that
must be set in order to request a change to 4-bit grayscale format: bits_per_pixel and
grayscale. bits_per_pixel must be set to 4, and grayscale must be set to one of the 2 valid
grayscale format values: GRAYSCALE_4BIT or GRAYSCALE_4BIT_INVERTED.
The following code snippet demonstrates a request to change the framebuffer to use the
Y4 pixel format:
fb_screen_info screen_info;
screen_info.bits_per_pixel = 4;
screen_info.grayscale = GRAYSCALE_4BIT;
retval = ioctl(fd_fb0, FBIOPUT_VSCREENINFO, &screen_info);
6.4 Source Code Structure
Table below lists the source files associated with the SPDC driver. These files are
available in the following directory:
drivers/video/mxc
Table 6-1. SPDC Driver Files
File Description
mxc_spdc_fb.c The SPDC frame buffer driver.
mxc_spdc_fb.h Register definitions for the SPDC module.
Table below lists the global header files associated with the SPDC driver. These files are
available in the following directory:
include/linux/
Table 6-2. SPDC Global Header Files
File Description
mxcfb.h Header file for the MXC framebuffer drivers
mxcfb_epdc_kernel.h Header file for direct kernel access to the SPDC API extension
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 63
Page 64
Menu Configuration Options
6.5 Menu Configuration Options
The following Linux kernel configuration options are provided for the SPDC module. To
get to these options use the command ./ltib -c when located in the <ltib dir>. On the
screen displayed, select Configure the kernel and exit. When the next screen appears
select the options to configure.
• CONFIG_FB_MXC_SIPIX_PANEL includes support for the Electrophoretic
Display Controller. In menuconfig, this option is available under:
• Device Drivers > Graphics Support > Sipix Panel Framebuffer
• CONFIG_MXC_SIPIX_AUTO_UPDATE_MODE option enables support for autoupdate mode which provides automated EPD updates through the deferred I/O
framebuffer driver. This option is dependent on the MXC_SIPIX_PANEL option. In
menuconfig, this option is available under:
• Device Drivers > Graphics Support > Sipix Auto-update Mode Support
NOTE
This option only enables the use of auto-update mode.
Turning on auto-update mode requires an additional
IOCTL call using the
MXCFB_SET_AUTO_UPDATE_MODE IOCTL.
• CONFIG_FB is the configuration option to include frame buffer support in the Linux
kernel. In menuconfig, this option is available under:
• Device Drivers > Graphics support > Support for frame buffer devices
• By default, this option is Y for all architectures.
• CONFIG_FB_MXC is the configuration option for the MXC Frame buffer driver.
This option is dependent on the CONFIG_FB option. In menuconfig, this option is
available under:
• Device Drivers > Graphics support > MXC Framebuffer support
• By default, this option is Y for all architectures.
• CONFIG_MXC_PXP configuration option enables support for the PxP. The PxP is
required by the SPDC driver for processing (color space conversion, rotation, autowaveform selection) framebuffer update regions. This option must be selected for the
SPDC framebuffer driver to operate correctly. In menuconfig, this option is available
under:
• Device Drivers > DMA Engine support > MXC PxP support
6.6 Programming Interface
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
64 Freescale Semiconductor, Inc.
Page 65
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
6.6.1 IOCTLs/Functions
The SPDC Frame Buffer is accessible from user space and from kernel space. A single
set of functions describes the SPDC Frame Buffer driver extension, but there are two
modes for accessing these functions. For user space access, the IOCTL interface should
be used, and for kernel space access, the functions should be called directly. For each
function below, both the IOCTL code and the corresponding kernel function is listed.
MXCFB_SET_WAVEFORM_MODES / mxc_spdc_fb_set_waveform_modes()
Description:
Defines a mapping for common waveform modes.
Parameters:
mxcfb_waveform_modes *modes
Pointer to a structure containing the waveform mode values for common waveform
modes. These values must be configured in order for automatic waveform mode selection
to function properly.
MXCFB_SET_TEMPERATURE / mxc_spdc_fb_set_temperature
Description:
Set the temperature to be used by the SPDC driver in subsequent panel updates.
Parameters:
int32_t temperature
Temperature value, in degrees Celsius. Note that this temperature setting may be
overridden by setting the temperature value parameter to anything other than
SPDC_DEFAULT_TEMP when using the MXCFB_SEND_UPDATE ioctl.
MXCFB_SET_AUTO_UPDATE_MODE / mxc_spdc_fb_set_auto_update
Description:
Select between automatic and region update mode.
Parameters:
__u32 mode
In region update mode, updates must be submitted via the MXCFB_SEND_UPDATE
IOCTL.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 65
Page 66
Programming Interface
In automatic mode, updates are generated automatically by the driver by detecting pages
in frame buffer memory region that have been modified.
MXCFB_SET_UPDATE_SCHEME / mxc_spdc_fb_set_upd_scheme
Description:
Select a scheme that dictates how the flow of updates within the driver.
Parameters:
__u32 scheme
Select of the following updates schemes:
UPDATE_SCHEME_SNAPSHOT - In the Snapshot update scheme, the contents of the
framebuffer are immediately processed and stored in a driver-internal memory buffer. By
the time the call to MXCFB_SEND_UPDATE has completed, the framebuffer region is
free and can be modified without affecting the integrity of the last update. If the update
frame submission is delayed due to other pending updates, the original buffer contents
will be displayed when the update is finally submitted to the SPDC hardware.
UPDATE_SCHEME_QUEUE - The Queue update scheme uses a work queue to
aynchronously handle the processing and submission of all updates. When an update is
submitted via MXCFB_SEND_UPDATE, the update is added to the queue, and then
processed in order, as SPDC hardware resources become available. As a result, the
framebuffer contents processed and updated are not guaranteed to reflect what was
present in the framebuffer when the update was sent to the driver.
UPDATE_SCHEME_QUEUE_AND_MERGE - The Queue and Merge scheme uses the
queueing concept from the Queue scheme, but adds a merging step. This means that
before an update is processed in the work queue, it is first compared with other pending
updates. If any update matches the mode and flags of the current update, and also
overlaps the update region of the current update, then that update will be merged with the
current update. After attempting to merge all pending updates, the final merged update
will be processed and submitted.
MXCFB_SEND_UPDATE / mxc_spdc_fb_send_update
Description:
Request a region of the frame buffer be updated to the display.
Parameters:
mxcfb_update_data *upd_data
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
66 Freescale Semiconductor, Inc.
Page 67
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
Pointer to a structure defining the region of the frame buffer, waveform mode, and
collision mode for the current update. This structure also includes a flags field to select
from one of the following update options:
SPDC_FLAG_ENABLE_INVERSION - Enables inversion of all pixels in the update
region.
SPDC_FLAG_FORCE_MONOCHROME - Enables full black/white posterization of all
pixels in the update region.
SPDC_FLAG_USE_ALT_BUFFER - Enables updating from an alternate (nonframebuffer) memory buffer.
If enabled, the final upd_data parameter includes detailed configuration information for
the alternate memory buffer.
MXCFB_WAIT_FOR_UPDATE_COMPLETE /
mxc_spdc_fb_wait_update_complete
Description:
Block and wait for a previous update request to complete.
Parameters:
mxfb_update_marker_data marker_data
The update_marker value used to identify a particular update (passed as a parameter in
MXCFB_SEND_UPDATE IOCTL call) should be re-used here to wait for the update to
complete. If the update was a collision test update, the collision_test variable will return
the result indicating whether a collision occurred.
MXCFB_SET_PWRDOWN_DELAY / mxc_spdc_fb_set_pwrdown_delay
Description:
Set the delay between the completion of all updates in the driver and when the driver
should power down the SPDC and the Sipix display power supplies.
Parameters:
int32_t delay
Input delay value in milliseconds. To disable SPDC power down altogether, use
FB_POWERDOWN_DISABLE (defined below).
MXCFB_GET_PWRDOWN_DELAY / mxc_spdc_fb_get_pwrdown_delay
Description:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 67
Page 68
Programming Interface
Retrieve the driver's current power down delay value.
Parameters:
int32_t delay
Output delay value in milliseconds.
6.6.2 Structures and Defines
#define GRAYSCALE_4BIT 0x3
#define GRAYSCALE_4BIT_INVERTED 0x4
#define AUTO_UPDATE_MODE_REGION_MODE 0
#define AUTO_UPDATE_MODE_AUTOMATIC_MODE 1
#define UPDATE_SCHEME_SNAPSHOT 0
#define UPDATE_SCHEME_QUEUE 1
#define UPDATE_SCHEME_QUEUE_AND_MERGE 2
#define UPDATE_MODE_PARTIAL 0x0
#define UPDATE_MODE_FULL 0x1
#define WAVEFORM_MODE_AUTO 257
#define SPDC_DEFAULT_TEMP 30
#define EPDC_FLAG_ENABLE_INVERSION 0x01
#define EPDC_FLAG_FORCE_MONOCHROME 0x02
#define EPDC_FLAG_USE_ALT_BUFFER 0x100
#define FB_POWERDOWN_DISABLE -1
struct mxcfb_rect {
__u32 left; /* Starting X coordinate for update region */
__u32 top; /* Starting Y coordinate for update region */
__u32 width; /* Width of update region */
__u32 height; /* Height of update region */
};
struct mxcfb_waveform_modes {
int mode_init; /* INIT waveform mode */
int mode_du; /* DU waveform mode */
int mode_gc4; /* GC4 waveform mode */
int mode_gc8; /* GC8 waveform mode */
int mode_gc16; /* GC16 waveform mode */
int mode_gc32; /* GC32 waveform mode */
};
struct mxcfb_alt_buffer_data {
__u32 phys_addr; /* physical address of alternate image buffer */
__u32 width; /* width of entire buffer */
__u32 height; /* height of entire buffer */
struct mxcfb_rect alt_update_region; /* region within buffer to update */
};
struct mxcfb_update_data {
struct mxcfb_rect update_region; /* Rectangular update region bounds */
__u32 waveform_mode; /* Waveform mode for update */
__u32 update_mode; /* Update mode selection (partial/full) */
__u32 update_marker; /* Marker used when waiting for completion */
int temp; /* Temperature in Celsius */
uint flags; /* Select options for the current update */
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
68 Freescale Semiconductor, Inc.
Page 69
Chapter 6 Sipix Display Controller (SPDC) Frame Buffer Driver
struct mxcfb_alt_buffer_data alt_buffer_data; /* Alternate buffer data */
};
struct mxcfb_update_marker_data { __u32 update_marker; __u32 collision_test; };
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 69
Page 70
Programming Interface
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
70 Freescale Semiconductor, Inc.
Page 71
Chapter 7
Pixel Pipeline (PxP) DMA-ENGINE Driver
7.1 Introduction
The Pixel Pipeline (PxP) DMA-ENGINE driver provides a unique API, which are
implemented as a dmaengine client that smooths over the details of different hardware
offload engine implementations. Typically, the users of PxP DMA-ENGINE driver
include EPDC driver, V4L2 Output driver, and the PxP user-space library.
7.2 Hardware Operation
The PxP driver uses PxP registers to interact with the hardware. For detailed hardware
operation, please refer to the i.MX 6SoloLite Multimedia Applications Processor
Reference Manual.
7.3 Software Operation
7.3.1 Key Data Structs
The PxP DMA Engine driver implementation depends on the DMA Engine Framework.
There are three important structs in the DMA Engine Framework which are extended by
the PxP driver: struct dma_device, struct dma_chan, struct dma_async_tx_descriptor. The
PxP driver implements several callback functions which are called by the DMA Engine
Framework (or DMA slave) when a DMA slave (client) interacts with the DMA Engine.
The PxP driver implements the following callback functions in struct dma_device:
device_alloc_chan_resources /* allocate resources and descriptors */
device_free_chan_resources /* release DMA channel's resources */
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 71
Page 72
Software Operation
device_tx_status /* poll for transaction completion */
device_issue_pending /* push pending transactions to hardware */
and,
device_prep_slave_sg /* prepares a slave dma operation */
device_terminate_all /* manipulate all pending operations on a channel, returns zero or
error code */
The first four functions are used by the DMA Engine Framework, the last two are used
by the DMA slave (DMA client). Notably, device_issue_pending is used to trigger the
start of a PxP operation.
The PxP DMA driver also implements the interface tx_submit in struct
dma_async_tx_descriptor, which is used to prepare the descriptor(s) which will be
executed by the engine. When tasks are received in pxp_tx_submit, they are not
configured and executed immediately. Rather, they are added to a task queue and the
function call is allowed to return immediately.
7.3.2 Channel Management
Although ePxP does not have multiple channels in hardware, 16 virtual channels are
supported in the driver; this provides flexibility in the multiple instance/client design. At
any time, a user can call dma_request_channel() to get a free channel, and then configure
this channel with several descriptors (a descriptor is required for each input plane and for
the output plane). When the PxP is no longer being used, the channel should be released
by calling dma_release_channel(). Detailed elements of channel management are
handled by the driver and are transparent to the client.
7.3.3 Descriptor Management
The DMA Engine processes the task based on the descriptor. One DMA channel is
usually associated with several descriptors. Descriptors are recycled resources, under
control of the offload engine driver, to be reused as operations complete. The extended
TX descriptor packet (pxp_tx_desc), allows the user to pass PxP configuration
information to the driver. This includes everything that the PxP needs to execute a
processing task.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
72 Freescale Semiconductor, Inc.
Page 73
Chapter 7 Pixel Pipeline (PxP) DMA-ENGINE Driver
7.3.4 Completion Notification
There are two ways for an application to receive notification that a PxP operation has
completed.
• Call dma_wait_for_async_tx(). This call causes the CPU to spin while it polls for the
completion of the operation.
• Specify a completion callback.
The latter method is recommended. After the PxP operation completes, the PxP output
buffer data can be retrieved.
For general information for DMA Engine Framework, please refer to Documentation/
dmaengine.txt in the Linux kernel source tree.
7.3.5 Limitations
• The driver currently does not support scatterlist objects in the way they are
traditionally used. Instead of using the scatterlist parameter object to provide a chain
of memory sources and destinations, the driver currently uses it to provide the input
and output buffers (and overlay buffers, if needed) for one transfer.
• The PxP driver may not properly execute a series of transfers that is queued in rapid
sequence. It is recommended to wait for each transfer to complete before submitting
a new one.
7.4 Menu Configuration Options
The following Linux kernel configuration option is provided for this module:
Device Drivers --->
DMA Engine support --->
[*] MXC PxP support
[*] MXC PxP Client Device
7.5 Source Code Structure
The PxP driver source code is located in drivers/dma/ and include/linux/.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 73
Page 74
Source Code Structure
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
74 Freescale Semiconductor, Inc.
Page 75
Chapter 8
ELCDIF Frame Buffer Driver
8.1 Introduction
The ELCDIF frame buffer driver is designed using the Linux kernel frame buffer driver
framework. It implements the platform driver for a frame buffer device. The
implementation uses the ELCDIF API for generic LCD low-level operations. The
ELCDIF API is also defined in the ELCDIF frame buffer driver to realize low level
hardware control. Only DOTCLK mode of the ELCDIF API is tested, so theoretically the
ELCDIF frame buffer driver can work with a sync LCD panel driver to support a frame
buffer device. The sync LCD driver is organized in a flexible and extensible manner and
is abstracted from any specific sync LCD panel support. To support another sync LCD
panel, the user can write a sync LCD driver by referring to the existing one.
8.2 Hardware Operation
For detailed hardware operation, please refer to the i.MX 6SoloLite Multimedia
Applications Processor Reference Manual.
8.3 Software Operation
A frame buffer device is a memory device similar to /dev/mem and it has the same
features. It can be read from, written to, or some location in it can be sought and maped
using mmap(). The difference is that the memory that appears is not the whole memory,
but only the frame buffer of the video hardware. The device is accessed through special
device nodes, usually located in the /dev directory, /dev/fb*. /dev/fb* also has several
IOCTLs which act on it and through which information about the hardware can be
queried and set. The color map handling operates through IOCTLs as well. See linux/fb.h
for more information on which IOCTLs there are and which data structures they use.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 75
Page 76
Menu Configuration Options
The frame buffer driver implementation for i.MX 6 is abstracted from the actual
hardware. The default panel driver is picked up by video mode defined in platform data
or passed in with 'video=mxc_elcdif_fb:resolution, bpp=bits_per_pixel' kernel bootup
command during probing, where resolution should be in the common frame buffer video
mode pattern and bits_per_pixel should be the frame buffer's color depth.
8.4 Menu Configuration Options
The following Linux kernel configurations are provided for this module:
• CONFIG_FB_MXC_SEIKO_WVGA_SYNC_PANEL [=Y|N|M]
• CONFIG_FB_MXC_ELCDIF_FB [=Y|N|M] Configuration option to compile
support for the MXC ELCDIF frame buffer driver into the kernel.
8.5 Source Code Structure
The frame buffer driver source code is in drivers/video/mxc/mxc_elcdif_fb.c.
The panel support code is located in drivers/video/mxc/mxcfb_claa_wvga.c and drivers/
video/mxc/mxcfb_seiko_wvga.c.
The frame buffer driver includes the source/header files shown in table below.
Table 8-1. Frame Buffer Driver Files
File Description
drivers/video/mxc/elcdif_regs.h The register head file for ELCDIF module
include/linux/mxcfb.h The head file for MXC frame buffer drivers
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
76 Freescale Semiconductor, Inc.
Page 77
Chapter 9
Graphics Processing Unit (GPU)
9.1 Introduction
The Graphics Processing Unit (GPU) is a graphics accelerator targeting embedded 2D
graphics applications.
The 2D graphics processing unit (GPU2D) is based on the Vivante GC320 core, which is
an embedded 2D graphics accelerator targeting graphical user interfaces (GUI) rendering
boost. The VG graphics processing unit (GPUVG) is based on the Vivante GC355 core,
which is an embedded vector graphic accelerator for supporting the OpenVG 1.1 graphics
API and feature set. The GPU driver kernel module source is in kernel source tree, but
the libs are delivered as binary only.
9.1.1 Driver Features
The GPU driver enables this board to provide the following software and hardware
support:
• EGL (EGL is an interface between Khronos rendering APIs such as OpenGL ES or
OpenVG and the underlying native platform window system) 1.4 API defined by
Khronos Group.
• OpenVG (OpenVG is a royalty-free, cross-platform API that provides a low-level
hardware acceleration interface for vector graphics libraries such as Flash and SVG)
1.1 API defined by Khronos Group.
9.1.1.1 Hardware Operation
For detailed hardware operation and programming information, see the GPU chapter in
the i.MX 6SoloLiteApplications Processor Reference Manual.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 77
Page 78
Introduction
9.1.1.2 Software Operation
The GPU driver is divided into two layers. The first layer is running in kernel mode and
acts as the base driver for the whole stack . This layer provides the essential hardware
access, device management, memory management, command queue management,
context management and power management. The second layer is running in user mode,
implementing the stack logic and providing the following APIs to the upper layer
applications:
• EGL 1.4 API
• OpenVG 1.1 API
9.1.1.3 Source Code Structure
Table below lists GPU driver kernel module source structure:
<ltib_dir>/rpm/BUILD/linux/drivers/mxc/gpu-viv
Table 9-1. GPU Driver Files
File Description
Kconfig Kbuild config kernel configure file and makefile
arch/XAQ2/hal/kernel hardware specific driver code for and GC320
arch/GC350/hal/kernel hardware specific driver code for GC350
hal/kernel Kernel mode HAL driver
hal/os os layer HAL driver
9.1.1.4 Library Structure
Table below lists GPU driver user mode library structure:
<ROOTFS>/usr/lib
Table 9-2. GPU Library Files
File Description
libCLC.so OpenCL frontend compiler library
libEGL.so* EGL1.4 library
libGAL.so* GAL user mode driver
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
78 Freescale Semiconductor, Inc.
Page 79
Chapter 9 Graphics Processing Unit (GPU)
Table 9-2. GPU Library Files (continued)
File Description
libGLES_CL.so OpenGL ES 1.1 common lite library
(without EGL API, no float point support API)
libGL.so.1.2 OpenGL 2.1 common library
libGLES_CM.so OpenGL ES 1.1 common library
(without EGL API, include float point support API)
libGLESv1_CL.so OpenGL ES 1.1 common lite library
(with EGL API, no float point support API)
libGLESv1_CM.so OpenGL ES 1.1 common library
(with EGL API, include float point support API)
libGLESv2.so OpenGL ES 2.0 library
libGLSLC.so OpenGL ES shader language compiler library
libOpenCL.so OpenCL 1.1 EP library
libOpenVG.so* OpenVG 1.1 library
libVDK.so VDK wrapper library.
libVIVANTE.so* Vivante user mode driver.
directfb-1.4-0/gfxdrivers/libdirectfb_gal.so DirectFB 2D acceleration library.
dri/vivante_dri.so DRI library for OpenGL2.1.
* These libraries are actually symbolic links to the actual library file in the folder.
By default, these symbolic links are installed to point to the frame buffer version of the
libraries as such:
libGAL.so -> libGAL-fb.so
libEGL.so -> libEGL-fb.so
libVIVANTE.so -> libVIVANTE-fb.so
On X11 systems, the symbolic links to these libraries need to be redirected. This can be
done using the following sequence of commands:
> cd <ROOTFS>/usr/lib
> sudo ln -s libGAL-x11.so libGAL.so
> sudo ln -s libEGL-x11.so libEGL.so
> sudo ln -s libEGL-x11.so libEGL.so.1
> sudo ln -s libVIVANTE-x11.so libVIVANTE.so
On directFB backend, the symbolic links to these libraries need to be redirected. This can
be done using the following sequence of commands:
> cd <ROOTFS>/usr/lib
> sudo ln -s libGAL-dfb.so libGAL.so
> sudo ln -s libEGL-dfb.so libEGL.so
> sudo ln -s libEGL-dfb.so libEGL.so.1
> sudo ln -s libVIVANTE-dfb.so libVIVANTE.so
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 79
Page 80
Introduction
9.1.1.5 API References
Refer to the following web sites for detailed specifications:
• EGL 1.4 API: http://www.khronos.org/egl/
• OpenVG 1.1 API: http://www.khronos.org/openvg/
9.1.1.6 Menu Configuration Options
The following Linux kernel configurations are provided for GPU driver:
CONFIG_MXC_GPU_VIV is a configuration option for GPU driver. In menucon
figuration this option is available under Device Drivers > MXC support drivers > MXC
Vivante GPU support > MXC Vivante GPU support.
To get to the GPU library package in LTIB, use the command ./ltib -c when located in the
<ltib dir>. On the displayed screen, select Configure the kernel, select Device Drivers >
MXC support drivers > MXC Vivante GPU support > MXC Vivante GPU support, and
then exit. When the next screen appears, select the following options to enable the GPU
driver:
• Package list > gpu-viv-bin-mx6q
• This package provides proprietary binary libraries, and test code built from the GPU
for framebuffer
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
80 Freescale Semiconductor, Inc.
Page 81
Chapter 10
High-Definition Multimedia Interface (HDMI)
10.1 Introduction
The High Definition Multimedia Interface (HDMI) driver supports the external SiI9022
HDMI hardware module, which provides the capability to transfer uncompressed video,
audio, and data using a single cable.
The HDMI driver is divided into two sub-components: a video display device driver that
integrates with the Linux Frame Buffer API and an S/PDIF audio driver that transfers S/
PDIF audio data to SiI9022 HDMI hardware module.
The HDMI driver is only for demo application and supports the following features:
• HDMI video output supports 1080p60 and 720p60 resolutions.
• Support for reading EDID information from an HDMI sink device for video.
• Hotplug detection
• HDMI audio playback (2 channels, 16/24bit, 44.1KHz sample rate)
10.2 Software Operation
The HDMI driver is divided into sub-components based on its two primary purposes:
providing video and audio to an HDMI sink device.
The audio output depends on video display.
10.2.1 Hotplug Handling and Video Mode Changes
Once the connection between the ELCDIF and the HDMI has been established through
the MXC Display Driver interface, the HDMI video driver waits for a hotplug interrupt
indicating that a valid HDMI sink device is connected and ready to receive HDMI video
data. Subsequent communications between the HDMI and LECDIF FB are conducted
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 81
Page 82
Source Code Structure
through the Linux Frame Buffer APIs. The following list demonstrates the software flow
to recognize a HDMI sink device and configure the ELCDIF FB driver to drive video
output:
1. The HDMI video driver receives a hotplug interrupt and reads the EDID from the
HDMI sink device constructing a list of video modes from the retrieved EDID
information. Using either the video mode string from the Linux kernel command line
(for the initial connection) or the most recent video mode (for a later HDMI cable
connection), the HDMI driver selects a video mode from the mode list that is the
closest match.
2. The HDMI video driver calls fb_set_var() to change the video mode in the ELCDIF
FB driver. The ELCDIF FB driver completes its reconfiguration for the new mode.
3. As a result of calling fb_set_var(), a FB notification is sent back to the HDMI driver
indicating that an FB_EVENT_MODE_CHANGE has occurred. The HDMI driver
configures the HDMI hardware for the new video mode.
4. Finally, the HDMI module is enabled to generate output to the HDMI sink device.
10.3 Source Code Structure
The bulk of the source code for the HDMI driver is divided amongst the three software
components that comprise the driver: the HDMI display driver, and the HDMI audio
driver.
The source code for the HDMI display driver is available in the <ltib_dir>/rpm/BUILD/
linux/drivers/video/mxc directory.
Table 10-1. HDMI Display Driver File List
File Description
mxcfb_sii902x_elcdif.c HDMI display driver implementation.
The source code for the HDMI audio driver is available in the <ltib_dir>/rpm/BUILD/
linux/drivers and sound/soc/ director. HDMI Audio data source comes from S/PDIF TX.
Table 10-2. HDMI Audio Driver File List
File Description
sound/codecs/mxc_spdif.c S/PDIF Audio SoC CODEC driver implementation.
sound/soc/imx/imx-spdif.c S/PDIF Audio SoC Machine driver implementation.
sound/soc/imx/imx-spdif-dai.c S/PDIF Audio SoC DAI driver implementation.
sound/soc/imx/imx-pcm-dma-mx2.c S/PDIF Audio SoC platform layer driver implementation.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
82 Freescale Semiconductor, Inc.
Page 83
Chapter 10 High-Definition Multimedia Interface (HDMI)
10.3.1 Linux Menu Configuration Options
There are two main Linux kernel configuration options used to select and include HDMI
driver functionality in the Linux OS image.
The CONFIG_FB_MXC_SII902X_ELCDIFI option provides support for the Sii902x
HDMI video driver and can be selected in menuconfig at the following menu location:
• Device Drivers > Graphics support > MXC Framebuffer support.
HDMI video support is dependent on MXC ELCDIF Framebuffer.
The CONFIG_SND_MXC_SPDIF option provides support for the HDMI Audio driver
and can be selected in menuconfig at the following menu location:
• Device Drivers > Sound card support > Advanced Linux Sound Architecture >
ALSA for SoC audio support > SoC Audio for Freescale i.MX CPUs > SoC Audio
support for IMX - S/PDIF
10.4 Unit Test
The HDMI video and audio drivers each have their own set of tests.
The preparation for HDMI test:
• Insert the HDMI daughter card into J13 on EVK.
• Insert the HDMI cable into the HDMI slots of both HDMI daughter board and the
HDMI sink device.
• Power on the HDMI sink device.
10.4.1 Video
The following set of manual tests can be used to verify the proper operation of the HDMI
video driver:
1. Hotplug testing: Connect and disconnect the HDMI cable several times, from either
the end attached to the i.MX board, or the end attached to the HDMI sink device.
Each time the cable is reconnected, the driver should re-determine the appropriate
video mode based on the modes read via EDID from the HDMI sink and display that
mode on the sink device.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 83
Page 84
Unit Test
2. HDMI output device testing: Test by dynamically switching the HDMI sink device.
The HDMI driver should be able to detect the valid video modes for each different
HDMI sink device and provide video to that display that is closest to the most recent
video mode configured in the HDMI driver.
10.4.2 Audio
The following sequence of tests verifies the correct operation of the HDMI audio driver:
1. Ensure that an HDMI cable is connected between the HDMI daughter board and the
HDMI sink device, and that the HDMI video image is being properly displayed on
the device.
2. Use this command line to play out a pcm audio file "file.wav" to HDMI sink device:
$ aplay -Dplughw:1,0 file.wav
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
84 Freescale Semiconductor, Inc.
Page 85
Chapter 11
X Windows Acceleration
11.1 Introduction
X-Windows System (aka X11 or X) is a portable, client-server based, graphics display
system.
X-Windows System can run with a default frame buffer driver which handles all drawing
operations to the main display. Because there is a 2D GPU (graphics processing unit)
available, some drawing operations can be accelerated. High level X operations may get
decomposed into many low-level drawing operations where these low level operations
are accelerated for X-Windows System.
11.2 Hardware Operation
X-Windows System acceleration on i.MX 6 uses the Vivante GC320 2D GPU.
Acceleration is also dependent on the frame buffer memory.
11.3 Software Operation
X-Windows acceleration is supported by X.org X Server version 1.7.6 and later versions,
as well as the EXA interface version 2.5.
The types of operations that are accelerated for X11 are as follows. All operations
involve frame buffer memory which may be on screen or off screen:
• Solid fill of a rectangle.
• Upload image from the system memory to the video memory.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 85
Page 86
Software Operation
• Copy of a rectangle with same pixel format with possible source-target rectangle
overlap.
• Copy of a rectangle supporting most XRender compositing operations with these
options:
• Pixel format conversion.
• Repeating pattern source.
• Porter-Duff blending of source with target.
• Source alpha masking.
The following are additional features supported by the X-Windows acceleration:
• X pixmaps can be allocated directly in frame buffer memory.
11.3.1 X Windows Acceleration Architecture
The following block diagram shows the components that are involved in the acceleration
of X-Windows System:
Figure 11-1. X Driver Architecture
The components shown in green are those provided as part of the Vivante 2D/3D GPU
driver support which includes OpenGL/ES and EGL, though some of the families in the
i.MX 6 series, such as the i.MX 6SoloLite, do not contain 3D HW module. The
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
86 Freescale Semiconductor, Inc.
Page 87
Chapter 11 X Windows Acceleration
components shown in light gray are the standard components in the X-Windows System
without acceleration. The components shown in orange are those added to support XWindows System acceleration and are briefly described here.
The i.MX X Driver library module (vivante-drv.so) is loaded by the X server and
contains the high-level implementation of the X-Windows acceleration interface for i.MX
platforms containing the GC320 2D GPU core. The entire linearly contiguous frame
buffer memory in /dev/fb0 is used for allocating pixmaps for X both on screen and off
screen. The driver supports a custom X extension which allows X clients to query the
GPU address of any X pixmap stored in frame buffer memory.
The libGAL.so library module (libGAL.so) contains the register-level programming
interface to the GC320 GPU module. This includes the storing of register programming
commands into packets which can be streamed to the device. The functions in the
libGAL.so library are called by the i.MX X Driver code.
11.3.2 i.MX 6 Driver for X-Windows System
The i.MX X Driver, referred to as vivante-drv.so, implements the EXA interface of the X
server in providing acceleration.
The implementation details are as follows:
• The implementation builds upon the source from the fbdev frame buffer driver for X,
so that it can be the fallback when the acceleration is disabled.
• The implementation is based on X server EXA version 2.5.0.
• The EXA solid fill operation is accelerated, except for source/target drawables
containing less than 1024x1024 pixels, in which case software failure may occur.
• The EXA copy operation is accelerated, except for source/target drawables
containing less than 1024x1024 pixels, in which case software failure may occur.
• EXA putimage (upload into video memory) is accelerated, except for source
drawables containing less than 400x400 pixels, in which case software failure may
occur.
• For EXA solid fill, only solid plane masks and only GXcopy raster-op operations are
accelerated.
• For EXA copy operation, the raster-op operations (GXandInverted, GXnor,
GXorReverse, GXorInverted, GXnand ) are not accelerated.
• EXA composite allows for many options and combinations of source/mask/target for
rendering. Commonly used EXA composite operations are accelerated.
The following types of EXA composite operations are accelerated:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 87
Page 88
Software Operation
• Composite operations for source/target drawables containing at least 640 pixels. If
less than 640 pixels, the composite path falls to software.
• Simple source composite operations are used when source/target drawables contain
more than 1024x1024 pixels (operations with mask not supported).
• Constant source (with or without alpha mask) composite with target.
• Repeating pattern source (with or without alpha mask) composite with target.
• Only these blending functions: SOURCE, OVER, IN, IN-REVERSE, OUTREVERSE, and ADD (some of these need to support the accelerated componentalpha blending).
• In general, the following types of less commonly used EXA composite operations are
not accelerated:
• Transformed (meaning scaled, rotated) sources and masks.
• Gradient sources.
• Alpha masks with repeating patterns.
The implementation handles all pixmap allocation for X through the EXA callback
interface. A first attempt is made to allocate the memory where it can be accessed by a
physical GPU address. This attempt may fail if there is insufficient GPU accessible
memory remaining, but it can also fail when the bits per pixel, which are being requested
for the pixmap, are less than 8. If the attempt to allocate from the GPU accessible
memory fails, the memory is allocated from the system. If the pixmap memory is
allocated from the system, this pixmap cannot be involved in GPU accelerated option.
The number of pitch bytes used to access the pixmap memory may be different
depending on whether it was allocated from GPU accessible memory or from the system.
Once the memory for X pixmap has been allocated, no matter it is from GPU accessible
memory or from the system, the pixmap is locked and can never migrate to other type of
memory. Pixmap migration from GPU accessible memory to system memory is not
necessary since a system virtual address is always available for GPU accessible memory.
Pixmap migration from system memory to GPU accessible memory is not currently
implemented, but would only help in situations where there was insufficient GPU
accessible memory at initial allocation. More memory, however, becomes available
(through de-allocation) at a later time.
The GPU accessible memory pitch (horizontal) alignment for the GC320 is 8 pixels.
All of the memory allocated for /dev/fb0 is made available to an internal linear offscreen
memory manager based on the one used in EXA. The portion of this memory beyond the
screen memory is available for allocation of X pixmap, where this memory area is GPU
accessible. The amount of memory allocated to /dev/fb0 needs to be several MB more
than the amount needed for the screen. The actual amount needed depends on the number
of X-Windows and pixmaps used, the possible usage of X pixmaps as textures, and
whether X-Windows are using the XComposite extension.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
88 Freescale Semiconductor, Inc.
Page 89
Chapter 11 X Windows Acceleration
X extension is provided, so that X clients can query the physical GPU address associated
with an X pixmap if that X pixmap was allocated in the GPU accessible memory.
11.3.3 xorg.conf for i.MX 6
The /etc/X11/xorg.conf file must be properly configured to use the i.MX 6 X Driver.
This configuration appears in a Device section of the file which contains both mandatory
and optional entries. The following example shows a preferred configuration for using
the i.MX 6 X Driver:
Section "Device"
Identifier "i.MX Accelerated Framebuffer Device"
Driver "vivante"
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
Option "HWcursor" "false"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "i.MX Accelerated Framebuffer Device"
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
EndSection
Some important entries recognized by the i.MX X Driver are described as follows:
• Device Identifier and Screen Device String
The mandatory Identifierentry in the Device section specifies the unique name to
associate with this graphics device.
Section "Device"
Identifier "i.MX Accelerated Framebuffer Device"
The following entry ties a specific graphics device to a screen. The Device Identifier
string must match the Device string in a Screen section of the xorg.conf file. For
example,
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 89
Page 90
Software Operation
Section "Screen"
...
Device "i.MX Accelerated Framebuffer Device"
...
EndSection
• Device Driver String
The mandatory Driver entry specifies the name of the loadable i.MX X driver.
Section "Device"
...
Driver "vivante"
...
EndSection
• Device fbdevPath Strings
The mandatory entries fbdev and vivante_devspecifies the path for the frame buffer
device to use.
Section "Device"
...
Option "fbdev" "/dev/fb0"
Option "vivante_fbdev" "/dev/fb0"
...
EndSection
11.3.4 Setup X-Windows System Acceleration
Setup of X-Windows system acceleration consists of package installation and
verification, file verification, and verifying acceleration. The debian packages are only
available for ubuntu root fs. There's no gpu driver for X11 on gnome mobile root fs or
LTIB
• Package installation and verification:
• Verify that the following packages are available and installed:
gpu-viv-bin-mx6q_<bsp-version>_armel.deb
• This package contains gpu driver develop headers, and is installed in the /usr/
include folder
• This package contains gpu driver hal librarylibGAL.so
• All above libraries are installed in the /usr/lib folder
xserver-xorg-video-imx-viv_<bsp-version>_armel.deb
•
• This package contains the vivante-drv.so driver module for X acceleration and is
installed in the folder with all the other X.org driver modules
• File verification:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
90 Freescale Semiconductor, Inc.
Page 91
Chapter 11 X Windows Acceleration
• Verify that the device file /dev/galcore is present.
• Verify that the file /etc/X11/xorg.conf contains the correct entries as described in
the previous section.
• Verify acceleration:
• Assuming the above steps have been performed, do the following to verify that
X Window System acceleration is indeed operating.
• Examine the log file /var/log/Xorg.0.log and confirm that the following lines
present:
[ 33.767] (II) LoadModule: "vivante"
[ 33.782] (II) Loading /usr/lib/xorg/modules/drivers/vivante_drv.so
...
[ 33.881] (II) VIVANTE(0): using default device
[ 33.881] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 33.881] (II) VIVANTE(0): Creating default Display subsection in Screen section
"Default Screen" for depth/fbbpp 16/16
[ 33.881] (==) VIVANTE(0): Depth 16, (==) framebuffer bpp 16
[ 33.881] (==) VIVANTE(0): RGB weight 565
[ 33.881] (==) VIVANTE(0): Default visual is TrueColor
[ 33.881] (==) VIVANTE(0): Using gamma correction (1.0, 1.0, 1.0)
[ 33.881] (II) VIVANTE(0): hardware: mxc_elcdif_fb (video memory: 2250kB)
[ 33.882] (II) VIVANTE(0): checking modes against framebuffer device...
[ 33.882] (II) VIVANTE(0): checking modes against monitor...
[ 33.882] (--) VIVANTE(0): Virtual size is 800x480 (pitch 800)
[ 33.882] (**) VIVANTE(0): Built-in mode "current": 33.5 MHz, 31.2 kHz, 58.6 Hz
[ 33.882] (II) VIVANTE(0): Modeline "current"x0.0 33.50 800 964 974 1073 480
490 500 533 -hsync -vsync -csync (31.2 kHz)
[ 33.882] (==) VIVANTE(0): DPI set to (96, 96)
...
[ 34.228] (II) VIVANTE(0): FB Start = 0x333a8000 FB Base = 0x333a8000 FB
Offset = (nil)
[ 34.228] (II) VIVANTE(0): test Initializing EXA
[ 34.228] (II) EXA(0): Driver allocated offscreen pixmaps
[ 34.229] (II) EXA(0): Driver registered support for the following operations:
[ 34.229] (II) Solid
[ 34.229] (II) Copy
[ 34.229] (II) Composite (RENDER acceleration)
[ 34.229] (II) UploadToScreen
[ 34.244] (==) VIVANTE(0): Backing store disabled
[ 34.244] (==) VIVANTE(0): DPMS enabled
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 91
Page 92
Software Operation
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
92 Freescale Semiconductor, Inc.
Page 93
Chapter 12
Camera Sensor Interface (CSI) Driver
The CSI driver enables the i.MX device to directly connect to external CMOS sensors
and CCIR656 video sources. The CSI and sensor drivers are implemented in the Video
for Linux Two (V4L2) driver framework. It consists of the image capture driver and the
video output driver.
12.1 Hardware Operation
The CSI driver configures and operates with the hardware registers for the CSI module. It
provides:
• Configurable interface logic to support most commonly available CMOS sensors.
• Full control of 8-bit/pixel, 10-bit/pixel or 16-bit/pixel data format to 32-bit receive
FIFO packing.
• 128X32 FIFO to store received image pixel data.
• Receive FIFO overrun protection mechanism.
• Embedded DMA controllers to transfer data from receive FIFO or statistic FIFO
through AHB bus.
• Support for double buffering two frames in the external memory.
• Single interrupt source to interrupt controller from maskable interrupt sources: Start
of Frame, End of Frame, and so on.
• Configurable master clock frequency output to sensor.
For more information, see the CSI chapter in the i.MX 6SoloLite Multimedia Applications
Processor Reference Manual.
12.2 Software Operation
This section includes the following:
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 93
Page 94
Software Operation
• CSI Software Operation
• Video for Linux 2 (V4L2) APIs
12.2.1 CSI Software Operation
The CSI driver initializes the CSI interface. Applications use the V4L2 interface to
operate the CSI interface.
12.2.2 Video for Linux 2 (V4L2) APIs
Video for Linux Two (V4L2) is a Linux standard. The API specification is available at
http://v4l2spec.bytesex.org/spec/.
The V4L2 capture device includes the capture interface. The capture interface uses the
CSI embedded DMA controller to implement the function. The V4L2 driver implements
the standard V4L2 API for capture devices. The following is the data flow of capture.
1. The camera sends the data to the CSI receive FIFO, through the 8-bit/10-bit data
port.
2. The embedded DMA controllers transfer data from the receive FIFO to external
memory through the AHB bus.
3. The data is saved to the user space memory or exported to the frame buffer directly.
12.2.2.1 V4L2 Capture Device
V4L2 capture support can be selected during kernel configuration. The driver for this
device is in the file under <ltib_dir>/rpm/BUILD/linux/drivers/media/video/mxc/capture/
csi_v4l2_capture.c
The memory map stream API is supported. Supported V4L2 IOCTLs include the
following:
• VIDIOC_QUERYCAP
• VIDIOC_G_FMT
• VIDIOC_S_FMT
• VIDIOC_G_FBUF
• VIDIOC_S_FBUF
• VIDIOC_S_PARM
• VIDIOC_G_PARM
• VIDIOC_CROPCAP
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
94 Freescale Semiconductor, Inc.
Page 95
Chapter 12 Camera Sensor Interface (CSI) Driver
• VIDIOC_S_CROP
• VIDIOC_G_CROP
• VIDIOC_QUERYBUF
• VIDIOC_REQBUFS
• VIDIOC_DQBUF
• VIDIOC_QBUF
• VIDIOC_STREAMON
• VIDIOC_STREAMOFF
• VIDIOC_ENUM_FMT
• VIDIOC_ENUM_FRAMESIZES
• VIDIOC_ENUM_FRAMEINTERVALS
• VIDIOC_DBG_G_CHIP_IDENT
12.2.2.2 Use of the V4L2 Capture APIs
The following is a sample process of using the V4L2 capture APIs:
1. Set the capture pixel format and size by using IOCTL VIDIOC_S_FMT.
2. Set the control information by using IOCTL VIDIOC_S_CTRL, for rotation.
3. Request a buffer by using IOCTL VIDIOC_REQBUFS. The common V4L2 driver
creates a chain of buffers (currently the maximum number of frames is 10).
4. Memory maps the buffer to its user space.
5. Queue the buffer by using the IOCTL command VIDIOC_QBUF.
6. Start the stream by executing IOCTL VIDIOC_STREAMON.
7. Execute the IOCTL VIDIOC_DQBUF.
8. Pass the data that requires post-processing to the buffer.
9. Queue the buffer by using the IOCTL command VIDIOC_QBUF.
10. Go to step 7.
11. Stop the queuing by using the IOCTL command VIDIOC_STREAMOFF.
12.3 Source Code Structure
The following table shows the CSI sensor and V4L2 driver source files available in the
directory: <ltib_dir>/rpm/BUILD/linux/drivers/media/video/mxc/capture
Table 12-1. V4L2 and CSI Driver Files
File Description
fsl_csi.c CSI driver source file
fsl_csi.h CSI driver header file
Table continues on the next page...
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 95
Page 96
Linux Menu Configuration Options
Table 12-1. V4L2 and CSI Driver Files (continued)
File Description
csi_v4l2_capture.c V4L2 capture device driver source file
mxc_v4l2_capture.h V4L2 capture device driver header file
12.4 Linux Menu Configuration Options
The following Linux kernel configuration options are provided for this module.
• VIDEO_MXC_CSI_CAMERA: Includes support for the CSI Unit and V4L2 capture
device. In menuconfig, this option is available under: Device Drivers > Multimedia
support > Video capture adapters > MXC Video For Linux Camera > MXC Camera/
V4L2 PRP Features support
By default, this option is enabled.
• MXC_CAMERA_OV5640: Option for the OV5640 sensor driver. In menuconfig,
this option is available under: Device Drivers > Multimedia support > Video capture
adapters > MXC Video For Linux Camera > MXC Camera/V4L2 PRP Features
support
By default, this option is enabled.
12.5 Programming Interface
For more information, see the V4L2 Specification and the API Documents for the
programming interface.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
96 Freescale Semiconductor, Inc.
Page 97
Chapter 13
OV5640 Using parallel interface
This is an introduction to the OV5640 camera driver that uses the parallel interface.
13.1 Hardware Operation
The OV5640 is a small camera sensor and lens module with low-power consumption.
The camera driver is located under the Linux V4L2 architecture. and it implements the
V4L2 capture interfaces. Applications cannot use the camera driver directly. Instead, the
applications use the V4L2 capture driver to open and close the camera for preview and
image capture, controlling the camera, getting images from camera, and starting the
camera preview.
The OV5640 uses the serial camera control bus (SCCB) interface to control the sensor
operation. It works as an I2C client. V4L2 driver uses I2C bus to control camera
operation.
OV5640 supports only parallel interface.
Refer to OV5640 datasheet to get more information on the sensor.
Refer to the i.MX 6 Multimedia Applications Processor Reference Manual for more
information on CSI.
13.2 Software Operation
The camera driver implements the V4L2 capture interface and applications and uses the
V4L2 capture interface to operate the camera.
The supported operations of V4L2 capture are:
• Capture stream mode
• Capture still mode
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 97
Page 98
Source Code Structure
The supported picture formats are:
• UYVY
• YUYV
The supported picture sizes are:
• QVGA
• VGA
• 720P
• 1080P
• QSXGA
13.3 Source Code Structure
Table below shows the camera driver source files available in the directory.
<ltib_dir>/rpm/BUILD/linux/drivers/media/video/mxc/capture.
Table 13-1. Camera Driver Files
File Description
ov5640.c Camera driver implementation for ov5640 using parallel interface
13.4 Linux Menu Configuration Options
The following Linux kernel configuration option is provided for this module.
To get to this option, use the ./ltib -c command when located in the <ltib dir>. On the
displayed screen, select Configure the Kernel and exit. When the next screen appears,
select the following option to enable this module:
• Device Drivers > Multimedia devices > Video capture adapters > MXC Video For
Linux Camera > MXC Camera/V4L2 PRP Features support > OmniVision ov5640
camera support.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
98 Freescale Semiconductor, Inc.
Page 99
Chapter 14
Low-level Power Management (PM) Driver
14.1 Hardware Operation
This section describes the low-level Power Management (PM) driver which controls the
low-power modes.
The i.MX 6 supports four low-power modes: RUN, WAIT, STOP, and DORMANT.
Table below lists the detailed clock information for different low-power modes.
Table 14-1. Low Power Modes
Mode Core Modules PLL CKIH/FPM CKIL
RUN Active Active, Idle or Disable On On On
WAIT Disable Active, Idle or Disable On On On
STOP Disable Disable Off Off On
DORMANT Power off Disable Off Off On
For the detailed information about lower power modes, see the i.MX 6SoloLite
Multimedia Applications Processor Reference Manual (IMX6SLRM).
14.1.1 Software Operation
The i.MX 6 PM driver maps the low-power modes to the kernel power management
states as follows:
• Standby: maps to STOP mode that offers significant power saving, as all blocks in
the system are put into a low-power state, except for ARM core that is still powered
on, and memory is placed in self-refresh mode to retain its contents.
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
Freescale Semiconductor, Inc. 99
Page 100
Hardware Operation
• Mem (suspend to RAM): maps to DORMANT mode that offers most significant
power saving as all blocks in the system are put into a low-power state, except for
memory that is placed in self-refresh mode to retain its contents.
• System idle: maps to WAIT mode.
The i.MX 6 PM driver performs the following steps to enter and exit low-power mode:
1. Allow the Coretex-A9 platform to issue a deep-sleep mode request.
2. If it is in STOP or DORMANT mode:
• Program CCM CLPCR register to set low-power control register.
• If it is in DORMANT mode, request switching off CPU power when pdn_req is
asserted.
• Request switching off embedded memory peripheral power when pdn_req is
asserted.
• Program GPC mask register to unmask wakeup interrupts.
3. Call cpu_do_idle to execute WFI pending instructions for wait mode.
4. Execute mx6_do_suspend in IRAM.
5. If it is in DORMANT mode, save the ARM context, change the drive strength of
MMDC PADs to "low" to minimize the power leakage in DDR PADs. Execute WFI
pending instructions for stop mode.
6. Generate a wakeup interrupt and exit low-power mode. If it is in DORMANT mode,
restore the ARM core and DDR drive strength.
In DORMANT and STOP mode, the i.MX 6 can assert the VSTBY signal to the PMIC
and request a voltage change. The Machine Specific Layer (MSL) usually sets the
standby voltage in STOP mode according to i.MX 6 data sheet.
14.1.2 Source Code Structure
Table below shows the PM driver source files. These files are available in <ltib_dir>/
rpm/BUILD/linux/arch/arm/mach-mx6/.
Table 14-2. PM Driver Files
File Description
pm.c Supports suspend operation
system.c Supports low-power modes
mx6_suspend.S Assembly file for CPU suspend
i.MX 6SoloLite Linux Reference Manual, Rev. L3.0.35_4.1.0, 09/2013
100 Freescale Semiconductor, Inc.
Loading...