1Driver for PXA25x LCD controller 2================================ 3 4The driver supports the following options, either via 5options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in. 6 7For example: 8 modprobe pxafb options=vmem:2M,mode:640x480-8,passive 9or on the kernel command line 10 video=pxafb:vmem:2M,mode:640x480-8,passive 11 12vmem: VIDEO_MEM_SIZE 13 Amount of video memory to allocate (can be suffixed with K or M 14 for kilobytes or megabytes) 15 16mode:XRESxYRES[-BPP] 17 XRES == LCCR1_PPL + 1 18 YRES == LLCR2_LPP + 1 19 The resolution of the display in pixels 20 BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16. 21 22pixclock:PIXCLOCK 23 Pixel clock in picoseconds 24 25left:LEFT == LCCR1_BLW + 1 26right:RIGHT == LCCR1_ELW + 1 27hsynclen:HSYNC == LCCR1_HSW + 1 28upper:UPPER == LCCR2_BFW 29lower:LOWER == LCCR2_EFR 30vsynclen:VSYNC == LCCR2_VSW + 1 31 Display margins and sync times 32 33color | mono => LCCR0_CMS 34 umm... 35 36active | passive => LCCR0_PAS 37 Active (TFT) or Passive (STN) display 38 39single | dual => LCCR0_SDS 40 Single or dual panel passive display 41 424pix | 8pix => LCCR0_DPD 43 4 or 8 pixel monochrome single panel data 44 45hsync:HSYNC 46vsync:VSYNC 47 Horizontal and vertical sync. 0 => active low, 1 => active 48 high. 49 50dpc:DPC 51 Double pixel clock. 1=>true, 0=>false 52 53outputen:POLARITY 54 Output Enable Polarity. 0 => active low, 1 => active high 55 56pixclockpol:POLARITY 57 pixel clock polarity 58 0 => falling edge, 1 => rising edge 59 60 61Overlay Support for PXA27x and later LCD controllers 62==================================================== 63 64 PXA27x and later processors support overlay1 and overlay2 on-top of the 65 base framebuffer (although under-neath the base is also possible). They 66 support palette and no-palette RGB formats, as well as YUV formats (only 67 available on overlay2). These overlays have dedicated DMA channels and 68 behave in a similar way as a framebuffer. 69 70 However, there are some differences between these overlay framebuffers 71 and normal framebuffers, as listed below: 72 73 1. overlay can start at a 32-bit word aligned position within the base 74 framebuffer, which means they have a start (x, y). This information 75 is encoded into var->nonstd (no, var->xoffset and var->yoffset are 76 not for such purpose). 77 78 2. overlay framebuffer is allocated dynamically according to specified 79 'struct fb_var_screeninfo', the amount is decided by: 80 81 var->xres_virtual * var->yres_virtual * bpp 82 83 bpp = 16 -- for RGB565 or RGBT555 84 = 24 -- for YUV444 packed 85 = 24 -- for YUV444 planar 86 = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr) 87 = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr) 88 89 NOTE: 90 91 a. overlay does not support panning in x-direction, thus 92 var->xres_virtual will always be equal to var->xres 93 94 b. line length of overlay(s) must be on a 32-bit word boundary, 95 for YUV planar modes, it is a requirement for the component 96 with minimum bits per pixel, e.g. for YUV420, Cr component 97 for one pixel is actually 2-bits, it means the line length 98 should be a multiple of 16-pixels 99 100 c. starting horizontal position (XPOS) should start on a 32-bit 101 word boundary, otherwise the fb_check_var() will just fail. 102 103 d. the rectangle of the overlay should be within the base plane, 104 otherwise fail 105 106 Applications should follow the sequence below to operate an overlay 107 framebuffer: 108 109 a. open("/dev/fb[1-2]", ...) 110 b. ioctl(fd, FBIOGET_VSCREENINFO, ...) 111 c. modify 'var' with desired parameters: 112 1) var->xres and var->yres 113 2) larger var->yres_virtual if more memory is required, 114 usually for double-buffering 115 3) var->nonstd for starting (x, y) and color format 116 4) var->{red, green, blue, transp} if RGB mode is to be used 117 d. ioctl(fd, FBIOPUT_VSCREENINFO, ...) 118 e. ioctl(fd, FBIOGET_FSCREENINFO, ...) 119 f. mmap 120 g. ... 121 122 3. for YUV planar formats, these are actually not supported within the 123 framebuffer framework, application has to take care of the offsets 124 and lengths of each component within the framebuffer. 125 126 4. var->nonstd is used to pass starting (x, y) position and color format, 127 the detailed bit fields are shown below: 128 129 31 23 20 10 0 130 +-----------------+---+----------+----------+ 131 | ... unused ... |FOR| XPOS | YPOS | 132 +-----------------+---+----------+----------+ 133 134 FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h 135 0 - RGB 136 1 - YUV444 PACKED 137 2 - YUV444 PLANAR 138 3 - YUV422 PLANAR 139 4 - YUR420 PLANAR 140 141 XPOS - starting horizontal position 142 YPOS - starting vertical position 143