About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / fb / pxafb.txt


Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.

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


About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog