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