diff options
Diffstat (limited to 'Documentation/fb/pxafb.txt')
| -rw-r--r-- | Documentation/fb/pxafb.txt | 142 |
1 files changed, 0 insertions, 142 deletions
diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.txt deleted file mode 100644 index d143a0a749f9..000000000000 --- a/Documentation/fb/pxafb.txt +++ /dev/null @@ -1,142 +0,0 @@ -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 - = 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->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 |