diff options
Diffstat (limited to '')
| -rw-r--r-- | Documentation/fb/pxafb.rst (renamed from Documentation/fb/pxafb.txt) | 81 |
1 files changed, 56 insertions, 25 deletions
diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.rst index d143a0a749f9..90177f5e7e76 100644 --- a/Documentation/fb/pxafb.txt +++ b/Documentation/fb/pxafb.rst @@ -1,59 +1,82 @@ +================================ 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: +For example:: + modprobe pxafb options=vmem:2M,mode:640x480-8,passive -or on the kernel command line + +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 +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 @@ -76,44 +99,50 @@ Overlay Support for PXA27x and later LCD controllers not for such purpose). 2. overlay framebuffer is allocated dynamically according to specified - 'struct fb_var_screeninfo', the amount is decided by: + 'struct fb_var_screeninfo', the amount is decided by:: - var->xres_virtual * var->yres_virtual * bpp + 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) + + 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 + 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 + 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. + word boundary, otherwise the fb_check_var() will just fail. d. the rectangle of the overlay should be within the base plane, - otherwise fail + otherwise fail Applications should follow the sequence below to operate an overlay framebuffer: - a. open("/dev/fb[1-2]", ...) + 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 @@ -124,19 +153,21 @@ Overlay Support for PXA27x and later LCD controllers 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: + the detailed bit fields are shown below:: - 31 23 20 10 0 - +-----------------+---+----------+----------+ - | ... unused ... |FOR| XPOS | YPOS | - +-----------------+---+----------+----------+ + 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 + + - 0 - RGB + - 1 - YUV444 PACKED + - 2 - YUV444 PLANAR + - 3 - YUV422 PLANAR + - 4 - YUR420 PLANAR XPOS - starting horizontal position + YPOS - starting vertical position |