0001 ================================
0002 Driver for PXA25x LCD controller
0003 ================================
0004
0005 The driver supports the following options, either via
0006 options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
0007
0008 For example::
0009
0010 modprobe pxafb options=vmem:2M,mode:640x480-8,passive
0011
0012 or on the kernel command line::
0013
0014 video=pxafb:vmem:2M,mode:640x480-8,passive
0015
0016 vmem: VIDEO_MEM_SIZE
0017
0018 Amount of video memory to allocate (can be suffixed with K or M
0019 for kilobytes or megabytes)
0020
0021 mode:XRESxYRES[-BPP]
0022
0023 XRES == LCCR1_PPL + 1
0024
0025 YRES == LLCR2_LPP + 1
0026
0027 The resolution of the display in pixels
0028
0029 BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
0030
0031 pixclock:PIXCLOCK
0032
0033 Pixel clock in picoseconds
0034
0035 left:LEFT == LCCR1_BLW + 1
0036
0037 right:RIGHT == LCCR1_ELW + 1
0038
0039 hsynclen:HSYNC == LCCR1_HSW + 1
0040
0041 upper:UPPER == LCCR2_BFW
0042
0043 lower:LOWER == LCCR2_EFR
0044
0045 vsynclen:VSYNC == LCCR2_VSW + 1
0046
0047 Display margins and sync times
0048
0049 color | mono => LCCR0_CMS
0050
0051 umm...
0052
0053 active | passive => LCCR0_PAS
0054
0055 Active (TFT) or Passive (STN) display
0056
0057 single | dual => LCCR0_SDS
0058
0059 Single or dual panel passive display
0060
0061 4pix | 8pix => LCCR0_DPD
0062
0063 4 or 8 pixel monochrome single panel data
0064
0065 hsync:HSYNC, vsync:VSYNC
0066
0067 Horizontal and vertical sync. 0 => active low, 1 => active
0068 high.
0069
0070 dpc:DPC
0071
0072 Double pixel clock. 1=>true, 0=>false
0073
0074 outputen:POLARITY
0075
0076 Output Enable Polarity. 0 => active low, 1 => active high
0077
0078 pixclockpol:POLARITY
0079
0080 pixel clock polarity
0081 0 => falling edge, 1 => rising edge
0082
0083
0084 Overlay Support for PXA27x and later LCD controllers
0085 ====================================================
0086
0087 PXA27x and later processors support overlay1 and overlay2 on-top of the
0088 base framebuffer (although under-neath the base is also possible). They
0089 support palette and no-palette RGB formats, as well as YUV formats (only
0090 available on overlay2). These overlays have dedicated DMA channels and
0091 behave in a similar way as a framebuffer.
0092
0093 However, there are some differences between these overlay framebuffers
0094 and normal framebuffers, as listed below:
0095
0096 1. overlay can start at a 32-bit word aligned position within the base
0097 framebuffer, which means they have a start (x, y). This information
0098 is encoded into var->nonstd (no, var->xoffset and var->yoffset are
0099 not for such purpose).
0100
0101 2. overlay framebuffer is allocated dynamically according to specified
0102 'struct fb_var_screeninfo', the amount is decided by::
0103
0104 var->xres_virtual * var->yres_virtual * bpp
0105
0106 bpp = 16 -- for RGB565 or RGBT555
0107
0108 bpp = 24 -- for YUV444 packed
0109
0110 bpp = 24 -- for YUV444 planar
0111
0112 bpp = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
0113
0114 bpp = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
0115
0116 NOTE:
0117
0118 a. overlay does not support panning in x-direction, thus
0119 var->xres_virtual will always be equal to var->xres
0120
0121 b. line length of overlay(s) must be on a 32-bit word boundary,
0122 for YUV planar modes, it is a requirement for the component
0123 with minimum bits per pixel, e.g. for YUV420, Cr component
0124 for one pixel is actually 2-bits, it means the line length
0125 should be a multiple of 16-pixels
0126
0127 c. starting horizontal position (XPOS) should start on a 32-bit
0128 word boundary, otherwise the fb_check_var() will just fail.
0129
0130 d. the rectangle of the overlay should be within the base plane,
0131 otherwise fail
0132
0133 Applications should follow the sequence below to operate an overlay
0134 framebuffer:
0135
0136 a. open("/dev/fb[1-2]", ...)
0137 b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
0138 c. modify 'var' with desired parameters:
0139
0140 1) var->xres and var->yres
0141 2) larger var->yres_virtual if more memory is required,
0142 usually for double-buffering
0143 3) var->nonstd for starting (x, y) and color format
0144 4) var->{red, green, blue, transp} if RGB mode is to be used
0145
0146 d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
0147 e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
0148 f. mmap
0149 g. ...
0150
0151 3. for YUV planar formats, these are actually not supported within the
0152 framebuffer framework, application has to take care of the offsets
0153 and lengths of each component within the framebuffer.
0154
0155 4. var->nonstd is used to pass starting (x, y) position and color format,
0156 the detailed bit fields are shown below::
0157
0158 31 23 20 10 0
0159 +-----------------+---+----------+----------+
0160 | ... unused ... |FOR| XPOS | YPOS |
0161 +-----------------+---+----------+----------+
0162
0163 FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
0164
0165 - 0 - RGB
0166 - 1 - YUV444 PACKED
0167 - 2 - YUV444 PLANAR
0168 - 3 - YUV422 PLANAR
0169 - 4 - YUR420 PLANAR
0170
0171 XPOS - starting horizontal position
0172
0173 YPOS - starting vertical position
