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