| 1 | ================================
|
| 2 | Driver for PXA25x LCD controller
|
| 3 | ================================
|
| 4 |
|
| 5 | The driver supports the following options, either via
|
| 6 | options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
|
| 7 |
|
| 8 | For example::
|
| 9 |
|
| 10 | modprobe pxafb options=vmem:2M,mode:640x480-8,passive
|
| 11 |
|
| 12 | or on the kernel command line::
|
| 13 |
|
| 14 | video=pxafb:vmem:2M,mode:640x480-8,passive
|
| 15 |
|
| 16 | vmem: VIDEO_MEM_SIZE
|
| 17 |
|
| 18 | Amount of video memory to allocate (can be suffixed with K or M
|
| 19 | for kilobytes or megabytes)
|
| 20 |
|
| 21 | mode: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 |
|
| 31 | pixclock:PIXCLOCK
|
| 32 |
|
| 33 | Pixel clock in picoseconds
|
| 34 |
|
| 35 | left:LEFT == LCCR1_BLW + 1
|
| 36 |
|
| 37 | right:RIGHT == LCCR1_ELW + 1
|
| 38 |
|
| 39 | hsynclen:HSYNC == LCCR1_HSW + 1
|
| 40 |
|
| 41 | upper:UPPER == LCCR2_BFW
|
| 42 |
|
| 43 | lower:LOWER == LCCR2_EFR
|
| 44 |
|
| 45 | vsynclen:VSYNC == LCCR2_VSW + 1
|
| 46 |
|
| 47 | Display margins and sync times
|
| 48 |
|
| 49 | color | mono => LCCR0_CMS
|
| 50 |
|
| 51 | umm...
|
| 52 |
|
| 53 | active | passive => LCCR0_PAS
|
| 54 |
|
| 55 | Active (TFT) or Passive (STN) display
|
| 56 |
|
| 57 | single | dual => LCCR0_SDS
|
| 58 |
|
| 59 | Single or dual panel passive display
|
| 60 |
|
| 61 | 4pix | 8pix => LCCR0_DPD
|
| 62 |
|
| 63 | 4 or 8 pixel monochrome single panel data
|
| 64 |
|
| 65 | hsync:HSYNC, vsync:VSYNC
|
| 66 |
|
| 67 | Horizontal and vertical sync. 0 => active low, 1 => active
|
| 68 | high.
|
| 69 |
|
| 70 | dpc:DPC
|
| 71 |
|
| 72 | Double pixel clock. 1=>true, 0=>false
|
| 73 |
|
| 74 | outputen:POLARITY
|
| 75 |
|
| 76 | Output Enable Polarity. 0 => active low, 1 => active high
|
| 77 |
|
| 78 | pixclockpol:POLARITY
|
| 79 |
|
| 80 | pixel clock polarity
|
| 81 | 0 => falling edge, 1 => rising edge
|
| 82 |
|
| 83 |
|
| 84 | Overlay 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
|