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