forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
173 lines
4.6 KiB
173 lines
4.6 KiB
================================ |
|
Driver for PXA25x LCD controller |
|
================================ |
|
|
|
The driver supports the following options, either via |
|
options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in. |
|
|
|
For example:: |
|
|
|
modprobe pxafb options=vmem:2M,mode:640x480-8,passive |
|
|
|
or on the kernel command line:: |
|
|
|
video=pxafb:vmem:2M,mode:640x480-8,passive |
|
|
|
vmem: VIDEO_MEM_SIZE |
|
|
|
Amount of video memory to allocate (can be suffixed with K or M |
|
for kilobytes or megabytes) |
|
|
|
mode:XRESxYRES[-BPP] |
|
|
|
XRES == LCCR1_PPL + 1 |
|
|
|
YRES == LLCR2_LPP + 1 |
|
|
|
The resolution of the display in pixels |
|
|
|
BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16. |
|
|
|
pixclock:PIXCLOCK |
|
|
|
Pixel clock in picoseconds |
|
|
|
left:LEFT == LCCR1_BLW + 1 |
|
|
|
right:RIGHT == LCCR1_ELW + 1 |
|
|
|
hsynclen:HSYNC == LCCR1_HSW + 1 |
|
|
|
upper:UPPER == LCCR2_BFW |
|
|
|
lower:LOWER == LCCR2_EFR |
|
|
|
vsynclen:VSYNC == LCCR2_VSW + 1 |
|
|
|
Display margins and sync times |
|
|
|
color | mono => LCCR0_CMS |
|
|
|
umm... |
|
|
|
active | passive => LCCR0_PAS |
|
|
|
Active (TFT) or Passive (STN) display |
|
|
|
single | dual => LCCR0_SDS |
|
|
|
Single or dual panel passive display |
|
|
|
4pix | 8pix => LCCR0_DPD |
|
|
|
4 or 8 pixel monochrome single panel data |
|
|
|
hsync:HSYNC, vsync:VSYNC |
|
|
|
Horizontal and vertical sync. 0 => active low, 1 => active |
|
high. |
|
|
|
dpc:DPC |
|
|
|
Double pixel clock. 1=>true, 0=>false |
|
|
|
outputen:POLARITY |
|
|
|
Output Enable Polarity. 0 => active low, 1 => active high |
|
|
|
pixclockpol:POLARITY |
|
|
|
pixel clock polarity |
|
0 => falling edge, 1 => rising edge |
|
|
|
|
|
Overlay Support for PXA27x and later LCD controllers |
|
==================================================== |
|
|
|
PXA27x and later processors support overlay1 and overlay2 on-top of the |
|
base framebuffer (although under-neath the base is also possible). They |
|
support palette and no-palette RGB formats, as well as YUV formats (only |
|
available on overlay2). These overlays have dedicated DMA channels and |
|
behave in a similar way as a framebuffer. |
|
|
|
However, there are some differences between these overlay framebuffers |
|
and normal framebuffers, as listed below: |
|
|
|
1. overlay can start at a 32-bit word aligned position within the base |
|
framebuffer, which means they have a start (x, y). This information |
|
is encoded into var->nonstd (no, var->xoffset and var->yoffset are |
|
not for such purpose). |
|
|
|
2. overlay framebuffer is allocated dynamically according to specified |
|
'struct fb_var_screeninfo', the amount is decided by:: |
|
|
|
var->xres_virtual * var->yres_virtual * bpp |
|
|
|
bpp = 16 -- for RGB565 or RGBT555 |
|
|
|
bpp = 24 -- for YUV444 packed |
|
|
|
bpp = 24 -- for YUV444 planar |
|
|
|
bpp = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr) |
|
|
|
bpp = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr) |
|
|
|
NOTE: |
|
|
|
a. overlay does not support panning in x-direction, thus |
|
var->xres_virtual will always be equal to var->xres |
|
|
|
b. line length of overlay(s) must be on a 32-bit word boundary, |
|
for YUV planar modes, it is a requirement for the component |
|
with minimum bits per pixel, e.g. for YUV420, Cr component |
|
for one pixel is actually 2-bits, it means the line length |
|
should be a multiple of 16-pixels |
|
|
|
c. starting horizontal position (XPOS) should start on a 32-bit |
|
word boundary, otherwise the fb_check_var() will just fail. |
|
|
|
d. the rectangle of the overlay should be within the base plane, |
|
otherwise fail |
|
|
|
Applications should follow the sequence below to operate an overlay |
|
framebuffer: |
|
|
|
a. open("/dev/fb[1-2]", ...) |
|
b. ioctl(fd, FBIOGET_VSCREENINFO, ...) |
|
c. modify 'var' with desired parameters: |
|
|
|
1) var->xres and var->yres |
|
2) larger var->yres_virtual if more memory is required, |
|
usually for double-buffering |
|
3) var->nonstd for starting (x, y) and color format |
|
4) var->{red, green, blue, transp} if RGB mode is to be used |
|
|
|
d. ioctl(fd, FBIOPUT_VSCREENINFO, ...) |
|
e. ioctl(fd, FBIOGET_FSCREENINFO, ...) |
|
f. mmap |
|
g. ... |
|
|
|
3. for YUV planar formats, these are actually not supported within the |
|
framebuffer framework, application has to take care of the offsets |
|
and lengths of each component within the framebuffer. |
|
|
|
4. var->nonstd is used to pass starting (x, y) position and color format, |
|
the detailed bit fields are shown below:: |
|
|
|
31 23 20 10 0 |
|
+-----------------+---+----------+----------+ |
|
| ... unused ... |FOR| XPOS | YPOS | |
|
+-----------------+---+----------+----------+ |
|
|
|
FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h |
|
|
|
- 0 - RGB |
|
- 1 - YUV444 PACKED |
|
- 2 - YUV444 PLANAR |
|
- 3 - YUV422 PLANAR |
|
- 4 - YUR420 PLANAR |
|
|
|
XPOS - starting horizontal position |
|
|
|
YPOS - starting vertical position
|
|
|