Driver for PXA25x LCD controller
The driver supports the following options, either via
options=
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:
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).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
= 24 -- for YUV444 packed = 24 -- for YUV444 planar
= 16 – for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
= 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->xresb. 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-pixelsc. 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 failApplications 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:- var->xres and var->yres
- larger var->yres_virtual if more memory is required,
usually for double-buffering - var->nonstd for starting (x, y) and color format
- 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. …
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.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 PLANARXPOS - starting horizontal position
YPOS - starting vertical position